Monday, June 23, 2008

Components and the ways of using the CTG facilities

The CICS Transaction Gateway contains the following components:· A Java gateway application that resides on a web server. On non-S/390 platforms, itcommunicates with CICS applications through facilities provided by the CICS Universal Client. OnS/390 systems, it communicates inbetween virtual memory spaces with CICS applications via theCICS External Communication Interface (EXCI).· A CICS Universal Client that provides the External Call Interface (ECI) and External PresentationInterface (EPI), as well as a terminal emulation function. The ECI interface enables a non-CICSclient application to call a CICS program as a subroutine using distributed program link calls. TheEPI interface enables a non-CICS client application to act as a logical 3270 terminal and socontrol a CICS 3270-based application. It uses transaction routing. The CICS Universal Client isthe same program that is used on workstations to access CICS. It runs only on non-S/390platforms.· A CICS Java class library that provides an API for communication between the Java gatewayapplication and a user-written Java application, either applet or servlet. The class JavaGateway isused to establish communication with the gateway process. The ECIRequest class is used tospecify ECI calls and the EPIRequest class for EPI calls (through the CICS Universal Client).· A set of Java EPI beans for creating Java front-ends to existing CICS 3270-based applications.· A terminal servlet that allows to use a web browser as an emulator for a 3270 CICS application.There are 5 alternative ways to use the CICS Transaction Gateway facilities:· Writing servlets (Java web server programs): The CICS Transaction Gateway supplies Javaclasses and Java beans that allows to write Java web server code to handle a browser requestthat requires services from CICS. They may be used to provide access to existing CICSapplications, to entirely new function, or a combination of both. They include all of the dataconversion and manipulation functions that are ordinarily needed to invoke S/390 CICStransactions with a 3270 or COMMAREA interface, and to communicate with the browser.· Writing applets: The same facilities may be used to code an applet. An applet has the samefunction as a servlet, but executes on the end-user workstation after download by a server. Itrequires a Java-enabled browser on the workstation.· Turnkey access to 3270 transactions: The CICS Transaction Gateway supplies one pre-codedservlet, called the "terminal servlet", that provides turnkey browser access to CICS 3270-interfacetransactions. The servlet translates browser requests to CICS interactions on a on a one-for-onebasis, so that the user sees the browser equivalent of the "green" 24x80 screens that wouldappear on a real 3270 terminal. It uses the Java classes and beans described above to convertURL-encoded HTTP browser input to 3270-format data inbound, and to convert 3270-formattransaction output to HMTL for return to the browser.· Tailored access to 3270 transactions: These facilities permit modifying, without reprogramming,the green-screen interface produced by the terminal servlet. You can change the HTML on ascreen-for-screen basis with CICS facilities, and you can use variable substitution with web serverserver-side includes to map one browser request to several 3270 interactions, or to invoke a 3270transaction and extract data from the returned screen.· CORBA client support: ORB-enabled browsers can run Java beans which interoperate withserver-side Java beans running in a CORBA server (such as WebSphere Application Server) viathe CORBA IIOP protocol. The server-side beans can then invoke CICS Transaction GatewayJava methods to execute 3270- or COMMAREA-based CICS applications.

(1) User-written servlet on a S/390 web server invoking multiple COMMAREA-based transactions forone browser request;(2) turnkey 3270 access through the Terminal Servlet;(3) a user-written servlet on a non-S/390 web server invoking multiple transactions (3270 orCOMMAREA) for one browser request;(4) applet counterpart for (3).The CICS Transaction Gateway permits to drive existing or new applications from a set of providedJava classes. The interface could be a workstation, web browser or NC. The classes (which arerepresentations of the ECI and EPI APIs) communicate with a Java application named the "CICS JavaGateway" that is part of CICS TG. In a middle tier configuration it uses the CICS Universal Client tocommunicate with the CICS server. If CICS TG and its Java Gateway runs directly on OS/390, it usesthe EXCI (External CICS Interface) to communicate with CICS. The EXCI is an OS/390 cross-memoryinterface packaged with CICS/390. It allows an OS/390 application to call a CICS program in an RPCstyle. SSL security is supported for this interface.3. e-business connectorsAssume a company has existing CICS applications written in COBOL, which are to be leveraged in amodern Web environment. The end-user GUI may be implemented via a Java Applet or a Java Servletand HTML. In all cases, there is a requirement to efficiently access CICS applications, which providethe core business logic, from the Java code, which provides the user interface. Assume the CICSapplications are callable using the CICS External Call Interface (ECI). This may be done using theCICS Transaction Gateway (CICS TG).The need to access existing logic and data from Java is not unique to CICS. Companies often havevaluable applications that exist in other enterprise servers such as IMS or which can be accessed viaMQSeries. Rather than accessing these resources using disparate APIs, a common technology hasbeen adopted by several IBM products. Called the Common Connector Framework (CCF), it providesa consistent means of connecting to, and interacting with, enterprise resources from any Javaexecution environment.A set of IBM e-business Connectors have been written to fit into the CCF model. A CICS Connector isincluded as part of the CICS Transaction Gateway. Connectors also exist for IMS, MQSeries andEncina/DCE.The CCF provides consistency in two ways :· It provides a consistent client-application view of enterprise resources, whatever Connector isbeing used. This consistent view also makes it easier for AD tools such as VisualAge for Java togenerate client code to use the CCF.· It provides a consistent run-time view to a Connector, so that the Connector can be hosted in anyrun-time environment that supports CCF. As a result, any client code that uses the Connectorsshould be applicable anywhere that supports CCF.The CCF is currently key in providing access to enterprise resources from within VisualAge for Java,WebSphere and IBM's Enterprise Server for Java implementations.

1 comment:

Android app development said...

Lot of useful points are there. Its really keeps me updated.