A Java ES architecture is a high-level technical description of a Java ES solution. You develop an architecture to identify the combination Java ES components and other technologies that will deliver the services described in the use cases.
Developing an architecture is a two-step process. You do the following:
You prepare a deployment scenario. In the deployment scenario, you identify the Java ES components that provide the services described in the use cases, and, separately, you specify the quality of service requirements for the solution.
You prepare a deployment architecture. In the deployment architecture, you integrate the information you developed in the deployment scenario. You determine how many instances of each component must be installed and configured, with what redundancy strategies, on what kind of hardware, and how the instances are distributed across your network, in order to provide the services you need and the quality of service you specify.
This chapter describes both steps of developing the architecture for the evaluation solution. Although the evaluation architecture is relatively simple, the description helps you understand the process of installing and configuring the evaluation solution. For more information on the deployment planning methodology, see Java Enterprise System Deployment Planning Guide.
This chapter describes the process of developing the architecture for the evaluation solution in the following sections:
The first step in developing an architecture for a solution is preparing a deployment scenario. A deployment scenario comprises the following:
A logical architecture, which identifies the components that are needed to implement the use cases
A set of quality of service requirements, which specify the performance that you require from the solution
This section describes how to develop a deployment scenario based on the use cases described in The Evaluation Use Cases.
A logical architecture identifies the Java Enterprise System components that provide the services described in a set of use cases. A logical architecture is typically represented graphically. The components needed for the evaluation use cases are illustrated in Figure 2–1.
The components in Figure 2–1 are included in the logical architecture for the following reasons:
The portal services described in the use cases are provided by Portal Server. End users access the portal services through a web-based portal desktop. The web browser clients that appear at the far left, in the client tier, represent end users viewing the portal desktop in their web browsers. For the evaluation solution, you install a sample portal desktop.
Portal Server and several other web-based components must run in a web container. For the evaluation solution, you choose to install Web Server to provide the needed web container. AlthoughWeb Server does not directly provide any service, and is not shown in Figure 2–1, you do install it to provide web container support for Portal Server, Access Manager, Communications Express, and Instant Messaging.
End users access the mail and calender services described in the use cases through the web-based Communications Express interface. The web browser clients that appear at the far left, in the client tier, represent end users accessing Communications Express in their web browsers.
The mail services described in the use cases are provided by Messaging Server. Messaging Server has its own web container.
The calendar services described in the use cases are provided by Calendar Server. Calendar Server has its own web container.
The instant messaging services described in the use cases are provided by Instant Messaging.
The authentication and authorization services described in the use cases, including single sign-on and portal proxy authentication, are provided by Access Manager.
LDAP directory services are required to support the services described in the use cases. The LDAP services are provided by Directory Server. The LDAP directory stores configuration data about the other components, entries for administrative users, and entries for end users.
In Figure 2–1, the components are arranged in several tiers. The tiers represent the different roles that components play in the solution. In the evaluation solution, all of the tiers will be combined on a single computer system.
In a production solution, the roles that components play help you determine how to distribute your components and sub-components across your network, and how to configure them to interoperate with other software, such as stand-alone mail clients. For more information on the Java ES multi-tiered architecture, see Java Enterprise System Technical Overviewhttp://download.oracle.com/817-5764.
The logical architecture identifies the Java ES components that provide the services described in the use cases, but does not tell you how to install the components on your network. In a typical production solution, quality of service requirements such as response time, service availability, and service reliability are satisfied by installing and configuring multiple instances of the components and distributing the instances among several computer systems. For example, installing two instances of Messaging Server on two different computer systems and configuring them together with load balancing hardware will provide fail-over capability and high availability for your messaging services.
To determine the quality of service requirements for a solution, you analyze your business needs and develop a set of requirements. The quality of service requirements are based on important characteristics of your business needs, such as the number of users that must be supported, the response time that your users must experience, and the amount of down time that is permitted.
The evaluation solution described in this document only needs to support a handful of users, and there is no need for continuous availability or the other features of a production solution. Therefore, the system requirements for the evaluation solution are minimal. These requirements are listed below:
Load and performance requirements: None
Availability requirements: None
Security requirements: LDAP authentication, single sign-on
Serviceability requirements: None
Scalability requirements: None
The second step in developing an architecture for a solution is preparing a deployment architecture. The deployment architecture integrates the logical architecture and the quality of service requirements. When you develop a deployment architecture you answer such questions as the following:
Which redundancy strategies are you using to meet your availability and reliability requirements? (Some of the redundancy strategies available to you are installing and configuring multiple instance of a component and load balancing the instances to achieve availability and reliability, installing and configuring multiple instances of a component and using Sun clustering technology to achieve availability and reliability, and using multiple instances of Directory Server that are synchronized through the multi-mastering and replication features to achieve availability and reliability.)
How many instances of each component must be installed and configured in order to implement the redundancy strategies you use in your solution?
How are your component instances combined on computer hardware systems? For example, in a medium-sized solution, you could install and configure instances of both Messaging Server and Calendar Server on two computer systems. You utilize Sun Cluster technology to cluster the two computer systems, and this architecture achieves availability and reliability for your messaging and calendar services.
How many CPUs are needed on each computer system to achieve the performance specified in you quality of service requirements?
The answers to these questions lead to a deployment architecture for your solution. A deployment architecture is typically represented graphically, with a set of boxes that represent the computer systems in the solution. Each box is labeled with the components that are installed on that computer system. The deployment architecture for the evaluation solution is illustrated in Figure 2–2.
Figure 2–2 shows that the minimal quality of service requirements for the evaluation use cases are easily satisfied by installing all of the components used in the evaluation solution on one system. The system is represented by the box labeled evaluation_host. The rest of this document describes how to install, configure, and use the evaluation solution on one system.
The deployment architecture for a production solution would represent a number of computer systems, with different combinations of components installed on each system. For an example of a large scale deployment architecture suitable for a production solution, see Java ES solution, see Java Enterprise System Deployment Planning Guide (http://download.oracle.com/817-5759)