You’re most likely familiar with Service Oriented Architecture (SOA), which is an architecture for creating SOAP and WSDL from CICS and IMS transactions. Using SOA, it’s possible to make a transaction available from a browser, not just from a specially dedicated terminal. Once you Web-enable an application, it makes combining the transactions much easier.
An Enterprise Service Bus (ESB) provides a way to link what would otherwise be disparate systems—such as IMS and CICS. It can take one message type from one source and translate it to the message type the receiver requires. It can reverse the process when a response comes back. So the ESB monitors and controls the routing of message exchanges between services and deals with issues such as event handling and event choreography, data transformation and mapping, message and event queueing and sequencing, security or exception handling, protocol conversion, and enforcing communication service quality.
Using WebSphere MQ, you can connect to IMS and CICS. Messages are sent to and received from the appropriate MQ bridge. An ESB is connected to IMS and CICS services using MQ. Information can be carried in the MQIIH for IMS or the MQCIH for CICS, and is defined in this header region by the MQ CICS bridge. The Custom Mediation primitive or the MQ Header Setter mediation primitive provide access to this information. Users can create and modify the header information.
IBM provides the IMS Enterprise Suite SOAP Gateway, which it claims allows IMS applications to “send business event data to business event processing and monitoring engines such as IBM WebSphere Business Events.” The product lets a variety of applications, including .NET, Java, and most other sources, submit SOAP requests into IMS. IBM’s IMS Connect improves IMS TCP/IP access, making it easier to access IMS from the Internet. This is useful when connecting to TCP/IP clients and local z/OS clients.
IBM describes its IMS Universal drivers as “a set of SMP/E-installable Java drivers and resource adapters that enable access to IMS from z/OS and distributed (non-z/OS) platforms.” This can be local connectivity to IMS databases on the same Logical Partition (LPAR) or distributed connectivity through TCP/IP. This provides a way for IMS to be accessed from WebSphere Application Server (WAS), CICS, and other IMS systems.
IBM’s IMS XML DB lets applications access IMS DB while making it appear to be an XML database. There’s work involved here because the IMS DLIModel utility must create the IMS-to-XML mapping. This Java application can run in IMS, CICS, DB2, or WebSphere using the retrieveXML() and storeXML() User-Defined Function (UDF) extensions to the IMS Java Database Connectivity (JDBC) driver.
Many IMS TM users may be using the IMS Message Format Service (MFS), which handles formatting of messages sent between terminals and IMS. This extra layer means the IMS applications don’t need to handle device-specific characteristics in messages. Using IMS MFS SOA support (a combination of Rational Application Developer and IBM Integrated Designer), you can Web-enable existing business logic.
There are also several third-party software products that can help make IMS applications available on the Web.
Once a transaction is Web-enabled, users can access it from any browser on any platform. That opens up the possibility of making IMS data available to users sitting in front of PCs as well as people using tablets or smartphones. To see IMS in action, go to http://www.youtube.com/watch?v=c2bGHjCQQZo to see “Invoking z/OS IMS using iPhone, using Web 2.0 and Web services.”