|< Day Day Up >|| |
In this section we discuss Quality of Service capabilities and considerations specific to J2EE Connectors and CICS.
This section briefly discusses some of the tools important for fault monitoring and isolation.
The Tivoli Performance Viewer is a graphical performance monitor for IBM WebSphere Application Server V5.0. You can use the Performance Viewer to retrieve performance data from application servers. Data is collected continuously by application servers and retrieved as needed from within the Viewer.
The JCA Connection Pools resource category provides information about J2EE Connectors, such as the number of managed connections (ManagedConnections) and the number of connections handles (Connections).
It is often helpful to examine log and trace files when your application experiences J2EE Connector errors or problems:
Application logging: It is always important for applications to record their activity to a logging facility. When you write a log to the standard output file or standard error file, the application server will record it to the corresponding log files.
Connection factory trace: Connection factory classes can be traced using the WebSphere Application Server trace service. The trace level can also be set as a connection factory property in WebSphere Administrative Console. Connection factory tracing is often not particularly helpful when debugging the CICS interaction. CTG tracing is usually the better option.
CICS Transaction Gateway (CTG) trace: CTG trace records detailed activities of the CTG gateway process, such as processing of ECI requests from clients. Of the four levels of CTG tracing, JNI tracing between the CTG and the native client is usually the most useful. The application can enable CTG tracing programmatically. It can also be enabled dynamically in the Gateway daemon using the TCPAdmin protocol handler, or statically as a start option. CTG trace is recorded in the standard output file or standard error file.
External CICS Interface (EXCI) trace: The EXCI provides a programming interface for the non-CICS address space to invoke CICS programs. CTG utilizes EXCI to communicate with CICS program. The CTG writes trace entries to the EXCI trace when it issues an EXCI request. The trace entries in a dump can be printed using standard z/OS utilities (GTF).
CICS trace: CICS Transaction Server provides a facility for recording CICS activity. In CICS for MVS™, there are three destinations for trace entries: internal trace, auxiliary trace, and generalized trace facility (GTF).
The approaches discussed in "Scalability and availability considerations" on page 274 also provide the node redundancy and failover capabilities needed to eliminate single-point-of-failure for end-to-end production systems.
The connection management contract defined by the J2EE Connector Architecture gives an application component a connection to an EIS. To deliver performance and scalability, the connection management contract should support connection pooling and management.
The J2EE Connector Architecture Specification V1.0 explains in detail how the connection contact is implemented by various connection management components of the application server and the resource adapter.
There are several parameters you can set to optimize connection pooling properties using WebSphere Administrative Console:
See the WebSphere InfoCenter for further details.
The CICS ECI resource adapter supports connection pooling of the connections (and underlying objects) from the J2EE application server to the CICS Transaction Gateway daemon.
As shown in Figure 12-4 on page 275, there are several scalability and availability options when using J2EE Connectors to access CICS enterprise applications:
EJB workload management, as provided by WebSphere Application Server.
EJBs deployed in IBM WebSphere Application Server Network Deployment V5.0 can automatically take advantage of the WebSphere workload management (WLM) facility for EJBs. Refer to the redbook IBM WebSphere V5.0 Applications: Ensuring High Performance and Scalability, SG24-6198 for details.
Inbound CTG requests (TCP or HTTP) can be workload managed using various methods. CTG for z/OS options for workload managing requests across LPARs include:
IBM Load Balancer (a component of IBM WebSphere Edge Server) can be used to perform load balance inbound requests to CTG for z/OS.
Sysplex distributor uses a cluster IP address to provide enhanced WLM across the LPARs in a sysplex.
TCP/IP port sharing provides a simple way of workload balancing HTTP requests across multiple regions within an LPAR.
CICS requests (ECI or EPI) can be workload managed using CICS scalability technologies. Workload management functions that are applicable when CICS Transaction Gateway resides in zSeries include:
External CICS Interface (EXCI) allows basic workload balancing by including a simple CICS availability check in the CTG DFHXCURM module.
CICS multi-region operation (MRO) is a widely used technique that is a central part of CICS scalability.
CICS distributed program link (DPL) requests from the CTG can be routed to a CICS program that resides in any CICS region in a sysplex.
Figure 12-4: Scalability options
The J2EE Connector Architecture security contract extends the J2EE security model to provide secure connections to EIS. To create a connection to an EIS, there must be some form of signing on to the EIS, to authenticate the connection requester. Re-authentication can also take place if supported by the EIS. This occurs when the security context is changed after a connection is made. (For example, connection pooling could cause a re-authentication when the connection is redistributed.)
The application component has the following two choices related to EIS sign-on:
Container managed sign-on: The deployer sets up the resource principal and EIS sign-on information. For example, the deployer sets the user name and password for establishing a connection to an EIS instance.
Component managed sign-on: Application code in the component performs the sign-on to an EIS by explicitly specifying the security information for a resource principal.
If you choose component managed sign-on, you need to specify user name and password at an instance of ConnectionSpec.
WebSphere V5.0 supports container managed sign-on with the use of a user ID and password credential (Option A in the J2EE Connector Architecture Specification) and component managed sign-on (Option C in the J2EE Connector Architecture Specification).
WebSphere V5.0 for z/OS can also flow an authenticated user credential through the CICS Transaction Gateway into CICS server when using container managed sign-on.
Authentication can be performed against the Resource Access Control Facility (RACF®) using user ID and password authentication in the CTG for z/OS, by setting the variable AUTH_USERID_PASSWORD=YES in the ctgenvvar script.
If the CTG runs on a distributed platform, it is possible to use the ESIRequest to verify user IDs and passwords with the destination CICS region. On all platforms, it is also possible to use SSL client certificates to authenticate the CTG.
The client application must specify a CTG network protocol when it connects to the gateway daemon. There are basically two types of connections:
TCP/IP sockets (TCP)
HTTP sessions (HTTP)
For each of these, there is a secure version using SSL, namely SSL and HTTPS.
The local protocol can be used if the CICS Transaction Gateway and WebSphere Application Server are on the same machine. This bypasses the Gateway daemon and is also a performance optimizer.
CICS uses the z/OS System Authorization Facility (SAF) to route authorization requests to an external security manager (ESM) to perform all its security checks. Any suitable ESM could be used, but because the IBM Resource Access Control Facility (RACF) product is the most commonly used ESM, we refer to RACF when discussing CICS external security.
For more details on CICS security, refer to the following IBM publications:
CICS RACF Security Guide, SC33-1701
Securing Web Access to CICS, SG24-5756
Resource adapters that are compliant with the J2EE Connector Specification 1.0 are portable across J2EE 1.3 application servers. This makes it easier for vendors to provide resource adapters that support multiple J2EE-compliant application servers.
Using the standard Common Client Interface defined by J2EE Connector Specification 1.0 also simplifies application integration with diverse EISs. This common interface makes it easy to plug third-party or home-grown resource adapters into your applications.
In a non-managed environment, the Java application is responsible for managing transactions through the local transaction interface (provided that the resource adapter supports this). By using the managed environment, the programmer does not even need to think about managing the transaction, because the transaction manager provides this quality of service.
A resource manager consists of the resource adapter and underlying EIS. It may participate in transactions that are externally controlled by a transaction manager. A transaction manager controls and coordinates transactions across multiple resource managers.
A resource manager has three options for supporting transactions:
No support: The resource manager does not support transactions.
Local transactions: These are transactions that are managed internally by the resource manager. The coordination of such transactions involves no external transaction manager.
Global transactions: There are multiple resource managers involved, and an external transaction manager must be used to coordinate the transaction using two-phase commit.
In a managed environment, there are two options to decide where to control the scope and the behavior of global transactions:
Component managed transaction demarcation: The transaction is explicitly managed by the application component accessing the enterprise tier.
Container managed transaction demarcation: The transaction is implicitly managed by the container of an enterprise bean accessing the enterprise tier.
The local transaction optimization forces the use of one-phase commit in the situation when two-phase commit is not needed for a global transaction. This is when only one resource manager was referenced, so two-phase commit is an unnecessary overhead.
The CICS ECI resource adapter implements the LocalTransaction interface, and supports local transactions. If you use an application server that supports last-resource optimization, such as IBM WebSphere Application Server Enterprise V5.0, the resource adapter can participate in a global transaction provided that it is the only local transaction resource in the global transaction. This is called "Last Participant Support" in WebSphere Enterprise.
|< Day Day Up >|| |