IBM CICS and IMS are two widely used Transaction Processing Monitors (TP-Monitors) in the enterprise computing world. It's likely that many applications will need to interoperate with CICS or IMS applications. Windows NT applications can interoperate with CICS and IMS applications using the LU 6.2 protocol with the help of COMTI. LU 6.2 is a peer-to-peer transaction protocol supported by CICS and IMS.
COMTI supports sending and receiving information to and from IMS message queues, as well as sending and receiving information to and from CICS. COMTI also enables CICS transaction programs to participate in MTS-coordinated transactions using Sync Point Level 2 LU 6.2 conversations. Using the distributed program link (DPL) emulation provided by COMTI, CICS applications need not even be aware they are participating within a larger distributed transaction.
COMTI effectively encapsulates CICS and IMS applications behind Automation objects, as shown in Figure 6-2. Client applications view the mainframe application as an Automation object. This object is generated by the COMTI run time, which runs within MTS. The run time uses a type library produced by COMTI development tools to generate the Automation object. Method calls are translated into CICS or IMS application invocations. Method parameters are translated into fields in LU 6.2 messages, data entries on IMS queues, or variables in CICS COMMAREAs, to make them available to the CICS or IMS application. Microsoft SNA Server is used to provide LU 6.2 communication with the mainframe.
Figure 6-2. Using COMTI to encapsulate CICS and IMS applications.
Internally, COMTI consists of a set of COM components that interact with each other, with MTS, and with the MS DTC. The COMTI architecture is shown in Figure 6-3. The generic COMTI component exposes the appropriate Automation interface to clients. The COMTI state machine sequences the acquisition of input data, marshaling the inputs, sending the inputs, receiving outputs, unmarshaling the outputs, and delivering outputs back through the Automation interface. A Transport object isolates the state machine from the specific transport being used, and a Convert object isolates it from details of data conversion for the target mainframe. The resource dispenser mechanism in MTS is used to cache instances of the state machine and associated objects to improve performance. The MS DTC coordinates transactions and manages the necessary translation between the transaction identifiers (TRIDs) since MS DTC uses OLE TRIDs and mainframe applications use LU 6.2 logical unit-of-work identifiers (LUWIDs).
Figure 6-3. The COMTI architecture.
The primary advantage of COMTI is that it makes mainframe applications accessible to Windows-based workstations and servers, using standard Windows development tools such as Visual Basic and scripting languages. Developers do not need to learn COBOL, CICS, or IMS programming to take advantage of existing applications.
To create the COMTI Automation component, a developer can simply take the data declarations representing the mainframe application's interface and import these definitions into the COMTI Interface Builder tool. The Interface Builder is used to create a type library that defines the Automation component's interface. The component is then registered on the host machine. Unlike other components we've seen up to now, COMTI components contain no custom code. The registry entries for the component point to the generic COMTI server and the Interface Builder_generated type library. At run time, the generic COMTI server uses the type library information to expose the correct Automation interface for the application.
From the system administrator's perspective, COMTI does not require any software on the mainframe or client workstations. COMTI needs to be installed only on machines hosting COMTI Automation components.