|< Day Day Up >|| |
Figure 12-1 shows the Runtime pattern and Product mapping for the Call Connection variation of the Direct Connection application pattern within the business domain of an organization, using a J2EE Connector.
Figure 12-1: Direct Connection--Call Connection- J2EE Connector Product mapping
This product mapping uses the CICS Transaction Gateway TCP protocol to communicate with the CICS Transaction Gateway on the zSeries enterprise system. The source J2EE application uses the CICS ECI J2EE Connector to access the existing CICS enterprise application via the CICS Transaction Gateway.
The following sections outline design guidelines for application integration using the J2EE Connector Architecture. We discuss the Common Connector Interface (CCI) API, the CICS resource adapters, and the IBM WebSphere Application Server V5.0 J2EE Connector environment.
As shown in Figure 12-2 on page 266, Version 1.0 of the J2EE Connector Architecture defines a number of components and interfaces that make up this architecture:
Common Client Interface (CCI)
The CCI defines a common API for interacting with resource adapters. It is independent of a specific EIS. A Java developer communicates to the resource adapter using this API.
A set of system-level contracts between an application server and EIS. These extend the application server to provide:
These system contracts are transparent to the application developer, meaning that they do not implement these services themselves.
Resource adapter deployment and packaging
A resource adapter provider develops a set of Java interfaces/classes as part of its implementation of a resource adapter. The Java interfaces/classes are packaged together with a deployment descriptor to create a Resource Adapter Archive (represented by a file with an extension of .rar). This Resource Adapter Archive is used to deploy the resource adapter into the application server.
Figure 12-2: J2EE Connector Architecture components
A number of factors affect the design of systems using J2EE Connectors. In this section we discuss some of the issues that should be considered when building an application.
There are two different types of environments that a Java application using J2EE Connectors can run in:
Managed environment: Management of connections, transactions, and security is provided by an application server. The Java application developer does not have to code this management manually.
To use the managed environment, you need to define a J2C connection factory in the J2EE application server. At deployment time you can then map a resource reference in your J2EE application to the JNDI name of the J2C connection factory.
Non-managed environment: The Java application directly uses the resource adapter to access an EIS. Management of connections, transactions, and security must be handled manually by the application.
You can find further details in the WebSphere Developer Domain article Using J2EE Resource Adapters in a Non-managed Environment at:
The CICS Transaction Gateway (CTG) is a set of client and server software components that allow a Java application to invoke services in a CICS region. The Java application can be an applet, a servlet, an enterprise bean, or any other Java application.
Two J2EE Connector CICS resource adapters are provided with the IBM CICS Transaction Gateway (CTG):
ECI (External Call Interface) is a call interface to COMMAREA-based CICS applications. The J2EE Connector RAR file is cicseci.rar.
EPI (External Presentation Interface) is an API to invoke 3270-based transactions. The J2EE Connector RAR file is cicsepi.rar.
Characteristics of the two CICS resource adapters and the situations in which each would be selected are:
External Call Interface: ECI uses COMMAREA as an interface to a CICS enterprise application. If the enterprise application is not using COMMAREA as an interface, it needs to be modified to use COMMAREA. ECI has a simple calling type interface rather than the screen-oriented, conversational type interface of EPI. For this reason, we recommend that ECI be used for new enterprise applications that will be Web-enabled.
External Presentation Interface: EPI uses 3270 data stream as an interface to a 3270 CICS application. If the enterprise application is a 3270 CICS application, EPI should be used for the resource adapter. There is no need to change the enterprise 3270 application at all. Using J2EE Connector Architecture CCI, the EPI application can use the same interface as ECI, but the underlying interface is conversational.
Table 12-1 summarizes the characteristics of ECI and EPI.
3270 data stream
Max data length
Screen size (eg 24x80) plus control characters
CTG JCA support
Distributed or z/OS
Use with new applications or existing COMMAREA based applications
Use with existing 3270 applications only
You can avoid a blocking call when you invoke an enterprise application using asynchronous CCI calls. This allows your Java application to call a CICS program without blocking while waiting for the response from CICS.
A non-blocking call type option can be specified for the CCI InteractionSpec using setInteractionVerb as follows:
Synchronous calls can be specified as follows:
Some application design considerations when selecting the CICS ECI resource adapter are:
If your legacy CICS application does not use COMMAREA interface, it must be changed to use COMMAREA.
The COMMAREA size and interaction complexity. For performance reasons, the size of COMMAREA and the number of interactions between the Web application and enterprise application should be minimized. The maximum COMMAREA size is 32 KB.
DPL considerations. In the CICS world, ECI calls are treated as Distributed Program Link (DPL) calls. Refer to CICS Application Programming Guide, SC33-1687 for details on DPL considerations.
|< Day Day Up >|| |