MQ for z/OS or z/OS Connect EE?
When should I use MQ for z/OS or z/OS Connect EE to interact with my mainframe assets?
For the last 25 years, MQ for z/OS* has been the communication mechanism of choice for clients who want to reliably and securely interact with their mainframe applications. More recently, z/OS Connect Enterprise Edition (zCEE) was introduced to provide a single, simple way of exposing REST APIs built on existing mainframe applications. Clients often ask us which one they should use. Several points should be considered when making this decision.
Firstly, the interaction patterns of MQ and zCEE are very different. MQ is asynchronous, while zCEE is synchronous. When you send a request with MQ, your application can do other work before receiving a response. With zCEE, your application will have to wait. For requests that will take a long time to generate a response, MQ is a better solution. For shorter duration requests, the synchronous model provided by zCEE can provide a simpler interaction pattern for the end developer.
MQ provides a reliable and transactional communications protocol, while zCEE uses HTTP, which is stateless and nontransactional. If you need to group multiple interactions into an atomic unit of work, you should be using MQ. Once a request has been sent to MQ, you can be assured that it will be processed and won’t be lost. zCEE is better suited for cases where you can accept the potential for multiple or missing updates, or you’re doing read-only operations.
When it comes to high availability and scalability, MQ has queue sharing groups which allow multiple queue managers to share the processing of requests; zCEE supports multiple servers fronted with a workload balancer. Queue sharing groups are a more powerful but complex option, as they allow for the mainframe application to pull requests for processing when it’s ready, rather than having requests allocated to it, which it might not be ready for.
zCEE is great for exposing natural, targeted REST APIs that hide the fact that underlying processing is being done on the mainframe, with mainframe-oriented data formats such as COBOL. The major benefit of REST is that it’s ubiquitous and can be used from almost any language and environment. MQ supports many languages and APIs including a REST messaging API. However, this new API is very messaging centric, and clients need to have at least some understanding of MQ to use it.
Lastly, I should mention that the answer might be to use zCEE and MQ together. Many CICS* and IMS* transactions are designed to be interacted with via a pair of MQ queues. It’s simple to use zCEE and the MQ Service Provider to expose these transactions as an easy-to-use REST API, without rewriting them or other existing mainframe applications that use them.