This chapter is from the book
This chapter is from the book
This chapter is from the book
23.4 The Container
23.4.1 Topology
As with all platforms, the J2EE Server z/OS can be run as a stand-alone server, or servers can be incorporated into cells and clustered with other servers. In the V5 release, cells cannot be heterogeneous. Cells must contain only z/OS servers, and they must all be contained within the same sysplex. The restrictions should be eased in future releases. In that there are limitations on distributed platforms (i.e., CTG on distributed cannot fully participate in two-phase commit), there may be compromises in running applications across different platforms.
At a more granular level, there is a difference between a distributed server and a z/OS server. A distributed server is a single process that runs a JVM. A z/OS server consists of two or more address spaces (processes) with different roles, each running a JVM. As shown in Figure 23.1, there is a Controller and one or more Servants. The Controller handles
Communications (it is the end point for container communication, including Message-Driven Beans [MDB]). Of course, applications can use HTTP, Java Secure Socket Extension (JSSE), or other transport clients for specific outbound communication from the Servant.
Most Object Requestor Broker (ORB) functionality.
Transactional behavior.
Security.
Executing authorized code.
)
Figure
23.1 WebSphere z/OS V5 Controllers and Servants.
The Servant is the JVM where the application(s) run. Servants are all on the same image (LPAR). To achieve the parallelism and failover of splitting the work across multiple images, you must set up servers under nodes on each image and cluster them.
Network Deployment is the more appropriate topology for a robust production environment as shown in Figure 23.2. The components in the topology are similar to the distributed platforms, with the following differences:
A server is two or more address spaces.
A cell can consist only of z/OS nodes and is constrained to a single sysplex.
It is more common for z/OS images to contain multiple nodes and for a sysplex to contain multiple cells.
)
Figure
23.2 WebSphere z/OS V5 overall topology possibilities.
TIP
WebSphere V5 can be architected in any number of ways. To accurately predict performance of a production system, the architecture of a test system should be as close as possible to the architecture of the production system.
23.4.2 Run Time Settings in the Controller
Many environmental settings have a direct impact on performance. As work arrives at the Controller, it is classified and placed on the appropriate WLM queue (for WLM details, see chapter 19). The WebSphere Administrator can control how the work is classified into Transaction Classes. The WLM administrator can then use these Transaction Classes to classify the work into Service Classes with defined goals. These goals will cause WLM to appropriately prioritize and report on the WebSphere work on the system or sysplex. The WebSphere Controller should run with a high-velocity goal as it is the initial dispatch point to potentially multiple Servants. Servants should also run with a high-velocity goal (not quite as high as the Controller) as dispatching work should not be a bottleneck. Garbage Collection also runs under this class (nonenclave). Prioritization of the enclaves is business-need dependent.