Design the system configuration in the order given below:
Figure 3-2 Flow for designing the system configuration (for a J2EE application execution platform)
Specify the configuration of components used in an application running on each system and decide which components of the application will serve as the access points. For details, see 3.3 Determining the configuration of an application.
Access points are the components that operate as the request-receiving window of the application, in the case of remote access from the client. The system configuration that can be implemented is determined, based on the type of the access point components.
Determine whether an application is to be connected to a database or other resources. The resource adapter to be used is determined, based on the resource to be connected.
The items that need to be determined in designing the rest of the system configuration differ according to the type of access point components determined here. The following table describes the items that need to be determined for various access point components:
Table 3-1 Items to be determined for various access point components
Design items | Types of access point components | Reference | |||
---|---|---|---|---|---|
Web front-end system | Back-end system | ||||
Servlet or JSP | Session Bean / Entity Bean | Stateless Session Beam when using CTM | Message- driven Bean | ||
Configuration of the client and server | Y | Y | Y | -- | Section 3.4 |
Method of integration between servers | -- | R | R | -- | Section 3.5 |
Transaction type | Y | Y | Y | Y | Section 3.6 |
Load balancing method as per the load-balancing cluster | R | R | R | -- | Section 3.7 |
Asynchronous communication between the servers | -- | -- | -- | Y | Section 3.8 |
Deploying the operation management process | Y | Y | Y | Y | Section 3.9 |
Configuration for inheriting the session information | R | R | -- | -- | Section 3.10 |
Configuration for node switching using cluster software | R | R | R | R | Section 3.11 |
Deploying a firewall | R | R | R | R | #2 |
Deploying a reverse proxy on DMZ | R#1 | -- | -- | -- | #3 |
Deploying a process that outputs the performance analysis trace file | Y | Y | Y | Y | Section 3.12 |
Integrating with products other than Application Server | R | R | R | R | Section 3.13 |
Operation management of the optional processes | R | R | R | R | Section 3.14 |
Specify the correspondence between the client and the server, depending on the access point components. The Application Server instances that are deployed in the system function as a client and as a server, depending on role of each instance.
The following figure shows the concept of the client and the server configuration:
Figure 3-3 Concept of the client and the server configuration
In the case of this configuration, the AP server 1 is the server for the web client and the access point is the servlet or JSP. AP server 1 is also the client for AP server 2. AP server 2 is the server for AP server 1 and the access point is the Enterprise Bean.
For details, see 3.4 Determining the configuration of the client and the server.
In the case of multiple servers, determine whether to perform server integration and if integration is performed, the way in which the integration would take place. Server integration refers to invoking and processing the access point components of other servers from the multiple servers that are arranged vertically as seen from the client.
The following figure shows the concept of server integration:
Figure 3-4 Concept of server integration
In the case of this configuration, the AP server 1 and the AP server 2 become the clients for the AP server 3 and invoke a Session Bean of AP server 3 from their respective servlets, JSPs, or Message-driven Beans.
If required, along with server integration, revise the form of the application such as division of application. Even when performing integration between multiple systems, you need to determine the method of integration between servers present in the respective systems.
For details, see 3.5 Determining integration between servers.
In the case of a system that uses a database or other resources, determine the transaction type to be used, depending on the number of resources for which the transaction management has to be performed. For details, see 3.6 Determining the transaction type.
To increase the availability of the system, determine whether the load is to be balanced by the load-balancing cluster configuration. When balancing the load, determine the implementation method depending on the type of the access point components. For details, see 3.7 Determining the load balancing method by the load-balancing cluster.
When asynchronous communication takes place between Application Server instances by using a Message-driven Bean, determine the system configuration corresponding to the product that is used. At the same time, determine the load balancing by the Message-driven Bean. For details, see 3.8 Determining the configuration for asynchronous communication between servers.
If you are using the operation management process (Management Server), determine on which server machine the Management Server is to be deployed, depending on the scope of management. For details, see 3.9 Determining the deployment of the operation management process.
If an error occurs in the J2EE application or the J2EE server running on the Web front-end system, determine the configuration for inheriting the session information in another J2EE server. For details, see 3.10 Determining the inheritance of session information.
Determine a configuration in which cluster software executes node switching to continue system operations when an error occurs in an Application Server or when you want to perform system maintenance. You can determine a configuration (mutual standby configuration) in which the executing node and the standby node are mutually switched over. For details, see 3.11 Determining node switching when cluster software is used and an error occurs.
Note that you cannot use this configuration for Solaris.
Determine the deployment of a firewall for ensuring the security of the Application Server instances and the resources. Deploy a firewall in front of the access point components to prevent invalid access to these access points. You decide the points for deploying a firewall based on the access points.
For details on allocating a basic firewall, see 3.2 Determining the configuration for using firewalls in the uCosminexus Application Server Security Management Guide.
For details about the security configuration containing an intrusion detection system, see 4.11.2 Allocating firewall and intrusion detection system in the uCosminexus Application Server Security Management Guide.
In the case of a system that is connected to the Internet, determine the deployment of a reverse proxy on DMZ to ensure the security of the Application Server instances and the resources. For details, see 3.3 Determining the allocation of a reverse proxy on DMZ in the uCosminexus Application Server Security Management Guide.
Determine the deployment of a PRF daemon (performance tracer) that is a process used for performance analysis. For details, see 3.12 Deploying a process for the output of the performance analysis trace file.
Determine the integration with products other than Application Server, such as JP1 for centralized monitoring, configuration management, or automatic execution of the system, as and when required. For details, see 3.13 Determining integration with products other than Application Server.
Determine the deployment of a user server when you want to manage user-defined optional processes by using the Management Server as a user server. For details, see 3.14 Managing optional processes with operation management.
Consider the configurations other than those determined up to (14). Determine the system configuration that is compatible with a system built on the Application Server of a version earlier than 07-00, as and when required. For details, see 3.15 Determining other configurations.