Becoming a digital enterprise

Becoming a successful digital enterprise requires a combination of improved customer service and employee engagement through convenient and easy-to-consume services. This requires the digitization of processes and platforms, and simpler integration across an organization’s core technology systems

These core systems are often mainframe applications. So what is the best way to bring these applications into the digital journey; so that their value is maximized through new customer touch points like mobile, IoT and wearables?

Today, progressive companies are exposing their mainframe applications as APIs. The mainframe today is capable of servicing REST requests, and also consuming REST APIs. Which brings me to the main question of this article; ‘What is the best way to do REST with the mainframe?’

Many technologies and solutions can be used to enable REST integration with the mainframe, including web APIs, services, and connectors and so on. The best solution for you depends on a number of factors, including the type of application, the age of the application, where the application runs and the software currency of the subsystem middleware. It also depends on your propensity for ‘turnkey’ solutions vs DIY (‘Do It Yourself’) solutions.

In this article we’ll take a CICS application as our example. Let’s look at the architecture options.

Architecture options

Basically we can consider three different architecture models, as shown in Figure 1.

REST mainframe architecture options
Figure 1 Architecture models

Figure 1 positions the various ways of doing REST with CICS. Below we consider the relative merits of each model.

  1. The first approach is to handle the REST call on a mid-tier device or function, and process non-REST calls to CICS from there. For example, the mid-tier device could be a DataPower appliance, or perhaps the IBM Integration Bus and the protocol to the back-end could be messaging over JMS using Web-Sphere MQ. This approach has the least impact on the mainframe, but it is arguably the least flexible because it requires a manual process to create and maintain the data mappings in the mid-tier server.
  2. The second approach is to bring the REST directly into CICS. For example, bringing the REST call directly into a CICS region configured with JSON web services. This solution may consist of a mid-tier function that proxies the REST request to the back-end. This is the most direct approach, but it means that a different solution is required for each type of mainframe application.
  3. The third approach is to provide a “gateway” on the LPAR and handle all REST requests there. This is the z/OS Connect model. An often-cited reason for this approach is it provides a controllable entry point to the LPAR … you can accept or reject at this “gateway” based on your criteria, and you can capture audit records about the access through this function. When either of the first two approaches is used there is the potential of having multiple protocols and multiple pathways in, and the challenge of keeping track of it all increases.

Note that I am not saying one approach is always better than the others. Some solutions are only available with certain versions of CICS, and each solution has its own strengths and weaknesses.

Nor am I saying that the different models are mutually exclusive; it is quite possible to have a blended solution of all three. The approach you use is based on the factors listed above, your architectural considerations, and what application integration architecture you already have in place.

z/OS Connect Enterprise Edition

z/OS Connect Enterprise Edition (z/OS Connect EE) is IBM’s strategic solution for enabling natural REST APIs for z Systems applications and data, in a unified manner with integrated auditing, security and scalability.

The three key points differentiating z/OS Connect EE are:

  1. Single, focused REST API entry to all z Systems subsystems. As opposed to the subsystems specific solutions that require specific configuration and administration (defining new resources etc.) to achieve the same outcome.
  2. An integrated REST API Editor enabling APIs to be designed and mapped to the services that are ex-posed in the back-end subsystems. As opposed to coding it up for the specific subsystem.
  3. Discovery of APIs via dynamically created Swagger (OpenAPI) documents; letting the developer know exactly where and how to invoke an API. As opposed to other solutions having to keep documentation in step with changes that are made to the REST API.

More information

More information on all of the different ways of doing REST with the mainframe, including CICS, IMS and DB2, can be found in the ITSO Redbooks publication IBM z Systems Integration Guide for the Mobile and API Economy (REDP-5319-00) which was published in December 2015. The good news is that an update of this publication is planned for December 2016. The Redpaper also outlines several integration scenarios which illustrate how different solutions have been used in real-world scenarios.

You should also watch out for further articles on the advantages of using z/OS Connect EE.

7 comments on"What is the best way to do REST with the mainframe?"

  1. Are there any apparent disadvantages of using IBM EC framework for integration with Mainframe? If we invoke a CICS transaction or a CICS program using the same, does it have any performance nuances that one should be aware of?

  2. Khadhar Basha December 05, 2017

    Does new Z14 comes with these (REST) services integrated.

    • Nigel Williams January 04, 2018

      z/OS Connect EE works on z14 and other IBM Z machines. However, it is a separate product – it’s capabilities are not integrated with z/OS . The API Toolkit used for API creation is freely downloadable but the run time server is charged based on the number of instances deployed.

  3. Hubert Becker February 09, 2018

    I understand that REST inbound calls are possible for CICS, IMS and DB2. Is it also possible to call other REST services from CICS or IMS using z / OS Connect EE? If not, what is recommended?

    • Nigel Williams February 09, 2018

      Hello Hubert. At the time this article was written z/OS Connect EE only supported inbound API requests. Now in V3 it also supports outbound requests. This is referred to as the ‘API requester’ support which you will find documented in the Knowledge Center.

  4. Hi, If I have a JSON payload that contains some fields / objects encrypted with JWE + JWS, can z / OS Connect EE handle it?

    • Nigel Williams September 04, 2018

      Hi Thiago, z/OS Connect EE supports JWT authentication by configuring the Liberty openidConnectClient feature. There are no Liberty features that enable JWE and JWS support. Therefore I do not think that z/OS Connect EE is able to process JSON messages that contain a signature (JWS) or encrypted JSON fields (JWE).

Join The Discussion

Your email address will not be published. Required fields are marked *