A Java ES architecture is a high-level technical description of a Java ES solution. You design an architecture to identify the combination of Java ES components and other technologies that will deliver the services described in your requirements. This chapter describes the architecture that the SunWeb team developed to satisfy the requirements described in Chapter 2, SunWeb Requirements.
A Java ES architecture is developed in two stages:
The deployment scenario. The deployment scenario identifies the Java ES components and other software that provide the services named in the requirements and, separately, lists the quality of service requirements.
The deployment architecture. The deployment architecture merges the two types of information that appear in the deployment scenario. Where the deployment scenario simply identifies the components that are needed to provide the services identified in the requirements, the deployment architecture describes how to provide the services at the specified quality of service, by using multiple component instances distributed across the network, implementing one or more redundancy strategies, and choosing the appropriate hardware.
This chapter describes the architecture for the SunWeb 4.0 deployment in the following sections:
The deployment scenario for the SunWeb 4.0 deployment is a combination of the following:
The logical architecture, which identifies the Java ES components and other software needed to provide the services described in Detailed Service Requirements.
The quality of service requirements, which specify the performance required from the Java ES components and other software named in the logical architecture.
The Java ES components needed to provide the services listed in Detailed Service Requirements are diagrammed in the following figure. This set of components is prepared by examining the list of services required in the SunWeb 4.0 deployment and determining which Java ES component will be used to provide the services.
Notice that the logical architecture includes Java ES components, represented as boxes with solid outlines, and non-Java ES software, represented as boxes with dashed outlines. Non-Java ES software is used as follows:
The Portal Content Delivery API is installed as part of the SunWeb deployment, and supports interaction between the SunWeb deployment and the content management system (CMS).
The CMS is already running on the main corporate network. The SunWeb components are configured to interact with the CMS. The CMS appears in the logical architecture's data tier, but the CMS is more a service used by the SunWeb components than a part of the actual SunWeb deployment.
The logical architecture also includes existing corporate applications and web sites. These existing applications and web sites, including the corporate messaging and calendar services also running already on the main corporate network. These applications and web sites are represented in the logical architecture's business services tier, but they play a role similar to the CMS. The corporate applications and web sites are more accurately regarded as services used by the SunWeb components than as part of the actual SunWeb deployment.
The logical architectures shows SafeWord, which is already running on the main corporate network. Access Manager is configured to interact with SafeWord in order to authenticate login requests from remote users. (Access Manager ships with a module for this purpose.) SafeWord, too, is more accurately regarded as a service used by the SunWeb components than as a part of the SunWeb deployment.
The logical architecture identifies the Java ES components that provide the services named in the requirements, but does not tell you how you should install the components on your network. In a typical production deployment you satisfy quality of service requirements such as response time, service availability, and service reliability by installing and configuring multiple instances of the components and distributing the components among several computers. For example, you could provide failover capability for your portal service by configuring multiple instances of Portal Server on multiple computers behind a load balancer.
To review the quality of service requirements for the SunWeb deployment, see the following sections in Chapter 2:
The deployment architecture merges the two types of information found in the logical architecture and the quality of service requirements. To design your deployment architecture you must consider such questions as the following:
Which redundancy strategies are you using to meet your availability and reliability requirements? The main redundancy strategies available to you with Java ES are the following:
Installing and configuring multiple instances of a component and load balancing the instances
Installing and configuring multiple instances of a component on Sun Cluster nodes
Using multiple instances of Directory Server that are synchronized through the multimastering and replication features
How many instances of each component must be installed and configured in order to implement the redundancy strategies you are using in the solution? How many instances must be installed and configured to satisfy your performance requirements?
How are your component instances combined on your computers? For example, in a medium-sized solution, you could install and configure instances of both Portal Server and Access Manager on a single computer. In a larger solution with more user activity, you might install Portal Server and Access Manager on separate, dedicated computers to meet your performance requirements.
How many CPUs are needed on each computer to achieve the performance specified in your quality of service requirements?
In addition to answering these questions, you analyze use cases and usage information and determine how the Java ES components and other software can be deployed on your network to provide access and security.
This section describes how the SunWeb team analyzed the SunWeb use cases and developed a deployment architecture.
The main user interactions with the set of components used for the SunWeb deployment are illustrated in Figure 3–2 and Figure 3–3. These figures show how users interact with the Java ES components in the proposed logical architecture to obtain the specified services. As you continue the design process, you analyze the component interactions represented in these figures, factor in the user base and usage patterns, and begin to make decisions about a deployment architecture that supports these interactions with the specified quality of service.
Notice that the security requirements are being considered at this stage of the analysis. The figures include proposed access zones for the SunWeb deployment.
The following figure illustrates the interactions between a user who is logged in to the corporate network and the Java ES components in the proposed logical architecture for the SunWeb deployment.
The interactions shown in the preceding figure are described in the following table.
Table 3–1 Interacting With SunWeb Components Over the Corporate Network
The following figure illustrates the interactions between an employee who accesses SunWeb services over the public Internet and the Java ES components in the proposed logical architecture.
The interactions shown in the preceding figure are described in the following table.
Table 3–2 Interacting With SunWeb Components Over the Internet
As you analyze your requirements and user interactions, you develop a graphical representation of your proposed deployment architecture. The graphical representation uses a set of boxes that represent the computers in the deployment. Each box in the figure is labeled with the name of the computer and the components that are installed on the computer. The deployment architecture for the SunWeb deployment is illustrated in the following figure.
The system names that appear in the preceding figure are not the names used in the actual SunWeb deployment. The system names in the figure are used only to illustrate the architecture.
The architecture represented in the preceding figure uses two redundancy strategies to meet the quality of service specified for the SunWeb deployment. The two redundancy strategies, load balancing and Directory Server multimaster replication are chosen for the following reasons:
Load balancing. This solution is preferred for components that do not need to synchronize database updates. Load balancing uses redundant hardware and software components to distribute requests for a service among multiple components instances that provide the service so that no single instance is overloaded. This redundancy also means that if any one instance of a components fails, other instances are available to assume a heavier load. Depending on the latent capacity built into the deployment, a failure might not result in significant degradation of performance. Load balancing is used for several components in the SunWeb architecture, for example, the Portal Server and Access Manager components on sunwebPS1 and sunwebPS2.
Directory Server multimaster replication. This solution is preferred for Directory Server, which provides data that is crucial to the operation of the entire deployment. Multimaster replication is specifically designed for Directory Server and is therefore relatively easy to implement. The SunWeb architecture uses Directory Server multimaster replication for all the Directory Server instances included in the SunWeb deployment. The SunWeb architecture uses two instances of Directory Server. All eight instances of Access Manager normally connect to the primary Directory Server instance. If the primary Directory Server fails, all eight instances of Access Manager fail over to the secondary Directory Server.
The requirements for the SunWeb portal service posed the following security challenges:
First, each employee's access must be limited to the services and data channels that he or she is authorized to view.
Second, the SunWeb portal service must allow Sun employees secure remote access to SunWeb services and data channels over the public Internet while preventing unauthorized people from accessing the portal.
For more information on the security requirements, see Security Requirements.
The SunWeb architects met the first challenge by including Access Manager and Directory Server in the deployment to control employee access to portal content. These Access Manager and Directory Server instances are separate from the main corporate LDAP service. The SunWeb directory service is dedicated to maintaining each employee's portal desktop profile. The desktop profile includes any desktop customization performed by the employee, as well as LDAP attributes and object classes that determine what content an employee is authorized to view. For more information on this aspect of the deployment, see The LDAP Schema.
The SunWeb architects met the second challenge by including the Portal Server Secure Remote Access component and its gateway service in the deployment and by designing network access zones that take maximum advantage of the gateway service. The access zones are demarcated by firewalls. The access zones and the firewalls are represented in Figure 3–4.
The outermost zone in Figure 3–4 is the demilitarized zone (DMZ), which contains the portal gateway. The DMZ is reasonably secure. The portal gateway service behind the firewall can be accessed at one specific URL only. Employees who connect to the SunWeb portal with remote web browser clients or mobile clients access the gateway service at the specified URL. The firewall blocks all other ports and addresses.
In addition to deploying the gateway service behind Firewall 3 in the DMZ, the SunWeb architecture protects the gateway service in the following ways:
The gateway service requires users to authenticate themselves. Employees who open the URL for the gateway service in their web browsers are presented with a login page. Employees must enter a user ID and a dynamically generated password to gain access to any content.
The computers that provide the gateway service are behind a hardware load balancer. The load balancer provides a single point of contact for the gateway service, even though multiple component instances are running on multiple computers. As a result, there is only one opening in the firewall for the gateway service, and all of the traffic for the gateway service is routed through the load balancer.
Not shown in Figure 3–4, but implied in the deployment architecture, is a network topology that creates separate subnets for each of the access zones. The IP addresses used in the subnets are private IP addresses, making the subnets invisible to the public Internet. These subnets are connected only through the load balancers, further impeding the ability of intruders to see the actual computers behind the public URL. For more information on the network topology, see Preparing the Network and Connectivity Specification.
The next zone, behind Firewall 2, is the SunWeb subnet. This zone contains the actual SunWeb portal service, which is provided by eight instances of Portal Server, supported by eight instances of Access Manager and two instances of Directory Server. This zone is defined by an additional firewall (Firewall 2).
In addition to deploying the portal service on its own subnet behind Firewall 2, the SunWeb architecture protects the portal service in the following ways:
Remote access to the portal service from the public Internet is controlled by the Portal Server SRA gateway service in the DMZ. All remote access to the portal service is through the gateway service. This aspect of the architecture allows the portal service to reside behind an additional firewall and an additional layer of hardware load balancing.
The load balancer behind Firewall 2 provides a single point of contact for the portal service, even though the service consists of eight Portal Server instances that are running on eight computers. The load balancer is the only opening in the firewall for the portal service, and all of the traffic for the portal service is routed through the load balancer. Employees connected to the main corporate network also access the SunWeb portal through this load balancer.
Local access to the portal service is only from trusted computers on the main corporate network after users have authenticated themselves to the corporate LDAP directory service.
The computers running Portal Server and Access Manager are on a different subnet from the computers in the DMZ, and this subnet is defined by private IP addresses. The only bridge between the subnets is the hardware load balancer.
The main corporate network contains various corporate information services that are accessed by the SunWeb portal service. These services are protected by Firewall 1. In addition to Firewall 1, the main corporate network is protected by the following measures:
There is no direct remote access to these corporate services. All remote access is indirect, through the Portal Server instances.
The CMS only allows traffic from the PCD instances that are colocated with the Portal Server instances. All other traffic is blocked.
Not shown in Figure 3–4 is the fact that the individual computers running the Java ES services are hardened.
The Java ES services used in the SunWeb portal architecture are provided by multiple component instances running on multiple computers behind a load balancer. For example, the portal service is provided by eight Portal Server instances running on computers sunwebPS2 through sunwebPS9.
This architecture could be scaled either horizontally or vertically to handle more incoming connections in the following ways:
To scale horizontally, the number of computers running Portal Server SRA instances could be increased, up to the capacity of the load balancing hardware. The architecture would remain essentially the same, but the load balancer would be distributing a greater number of incoming connections among a greater number of Portal Server SRA instances. The load on each component instance would remain constant. Similarly, the number of computers running Portal Server, Access Manager, and Directory Server could also be increased, as needed.
The Access Manager and Directory Server instances could be installed on separate computers, giving each instance more computing resources.
To scale vertically, additional Solaris 10 zones can be created, if the computers have sufficient memory and disk storage. You can install and run additional component instances in the new zones to increase the capacity of the Java ES services on a single computer hardware system.