MQ and JMS for Enterprise Transaction Managers
Pete Siddall 110000AAJG Visits (3189)
In recent years, new technologies such as mobile and cloud, and enhanced regulation of businesses have driven a need to re-engineer core business systems and to open them up to expose data and APIs to external systems. On the mainframe, we have seen customers moving to Java for this re-engineering effort to reposition these systems away from being reliant on rarer (and so more expensive) traditional mainframe programming skills in languages such as COBOL, PL/I and Assembler. In the messaging world, the de facto standard for messaging in Java is the JMS API and so we have seen many requirements to enable JMS for MQ in new application environments.
Over the last 18 months MQ has successively enhanced the MQ Classes for JMS to enable it to be used from Java applications running in z/OS transaction managers. Support for CICS applications which run in a CICS OSGi JVM server was added in CICS TS V5.2 and MQ V7.1. Later, support for JMS from IMS regions was added in MQ V8 and this was the subject of an earlier MQDev Blog Post
Most recently the CICS team have been focusing on enabling Java EE applications to be run in a Liberty JVM server. And now, MQ V9.0.1 delivers support in the MQ Classes for JMS so that Java EE applications running in a Liberty JVM server in CICS TS V5.3 can use the JMS APIs with MQ.
CICS Liberty JVM server can be configured to run in one of two modes and JMS with MQ can be used in each.
Standard Mode is for applications which require the full range of Java EE 7 APIs and which today run in WebSphere Liberty. For example, imagine an MDB which, driven by the arrival of an MQ message, updates a DB2 table and sends a response. These applications have no reliance on CICS, but there may be good reasons to host and manage them in concert with other CICS applications. To allow such Java applications to be run unchanged, the JMS connection factory supports the same capabilities as under WebSphere Liberty. Connections can be configured to use client transport for connection to MQ off platform, or elsewhere on z/OS via MQ channels. Alternatively, the connection can use bindings transport for a cross-memory connection to MQ running on the same z/OS LPAR as the CICS region. Note that in the standard mode set up, unit of work coordination is managed as Liberty transactions. Liberty in turn coordinates the MQ updates, which depending on transport type uses the XA protocol with client transport, or RRS when bindings are used.
Integrated Mode is for applications which need to perform CICS functions and coordinate CICS resources into the same unit of work as external Java connected resources such as JMS messages or JDBC data. As of MQ V9.0.1, the MQ Classes for JMS are limited to client transport (the cross-memory bindings mode cannot be used in Integrated Mode) for connection to MQ queue managers via MQ channels.
MQ for z/OS V9.0.1 enables Java applications running in additional environments to inter-operate with MQ via the standard JMS API through the addition of support for CICS Liberty JVM server.
JMS in CICS OSGi JVM server requires:
JMS in IMS requires:
JMS in Liberty JVM server requires: