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.
Basically we can consider three different architecture models, as shown in Figure 1.
Figure 1 positions the various ways of doing REST with CICS. Below we consider the relative merits of each model.
- 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.
- 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.
- 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:
- 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.
- 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.
- 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 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.