Mainframes are brilliant. They are full of fantastic applications that can do lots of wonderful things quickly and easily. But, in many ways, they are limited to doing all those wonderful things only on the mainframe. What you need is to be able to take the best parts of those applications and, possibly, combine them with the best parts of other applications that exist elsewhere on cloud or mobile platforms, and create incredible new applications that people will want to use. And you don’t want to have to make any changes to your original mainframe applications.
This is basically, what they call, the API (Application Programming Interface) economy. Making the best use you can of existing applications and data by making them available as APIs and then developing new applications to meet a need of customers and potential customers. One way to do that is by using IBM’s z/OS Connect Enterprise Edition.
IBM’s z/OS Connect Enterprise Edition provides a framework enabling z/OS-based data and programs to become part of the API economy and connect with users and other APIs in the cloud and on mobile devices. z/OS Connect EE makes CICS, IMS, WebSphere MQ, Db2, and batch accessible through RESTful APIs with JSON-formatted messages. RESTful APIs and JSON are frequently used with mobile application development. And that means those developers can work with mainframes without needing to know too much about mainframes. Your mainframe makes a good API host because: it has a fast response time; it’s extremely reliable; it handles high workload volumes; and it is highly available.
A bit of background. There are three types of API, they are public, partner, and private. REST stands for Representational State Transfer. It’s an architectural style for accessing and updating data, typically using HTTP. Although not all HTTP interfaces are ‘RESTful’. REST is popular because it’s based on HTTP, which operates on TCP/IP, which is a ubiquitous networking topology. Compared to other technologies (for example, SOAP/WSDL), the REST/JSON pattern is a relatively light protocol and data model, which maps well to resource-limited devices (like phones). The REST interface is simple. So, developing the client involves very few things, eg: an understanding of the URI requirements (path, parameters); and any JSON data schema. REST/JSON is becoming more and more a de facto ‘standard’ for exposing APIs and microservices. REST is, by definition, a stateless protocol, which implies greater simplicity in topology design. There’s no need to maintain, replicate, or route based on state.
If you don’t use z/OS Connect EE, what do you use? For CICS it would be CICS Transaction Gateway (CTG) or CICS SOAP/JSON Web services. For IMS it would be IMS Mobile Feature pack. For Db2 it would be DB2 JSON. For MQ it would be a broker. And for WebSphere Application Service (WAS) it would be JAX RS Java API for RESTful Web Services). And that means there would be multiple endpoints for developers to call and maintain access to. z/OS Connect EE provides a single entry point, making the developers life much easier.
The next question is how do you know what APIs you have available? z/OS Connect EE includes a deployment artefact, called an API package. This can be deployed to the z/OS Connect EE run time as a z/OS-based RESTful API. These RESTful API definitions are discoverable through automatically generated Swagger documents, which are created by the supplied z/OS Connect EE API Editor. Swagger, in case you were unsure, is an open-source software framework that helps developers design, build, document, and consume RESTful Web services. So, these descriptions tell other application developers how to use the API. The enterprise API catalog can be populated with z/OS Connect EE-hosted APIs alongside any other provider and can be used in the same way.
Let’s look at the six steps needed to expose a z/OS asset:
- Install, set up, and start to use z/OS Connect EE server.
- Create your service definition – to start mapping an API, z/OS Connect EE needs a representation of the underlying z/OS application, ie a Service Archive file (.sar).
- Create your API by importing your .sar file into the API toolkit, and start designing your API. From the editor, then create an API Archive file(.aar), which describes your API and how it maps to underlying services.
- Configure the system-appropriate service provider to connect to your backend system in your server.xml
- Deploy your service, ie deploy the .sar file generated by the service definition utility by copying the .sar file to the services directory.
- Deploy your API using the right-click deploy in the API toolkit, or by copying the .aar file to the apis directory.
Looking at things in more details, there is a z/OS Connect EE API Editor, which lets developers create RESTful APIs from IMS or CICS, etc, making those mainframe assets available in the cloud or on mobile. z/OS Connect EE easily integrates with API management solutions. And you can have RESTful APIs to and from your mainframe. It provides point-and-click API mapping, so no code changes are required.
The z/OS Connect EE API package can be deployed manually, or it can be automated by extending an existing enterprise change control process. According to IBM: “The associated deployment capabilities provide an enterprise with the ability to meet the demands of the fast-paced API economy. z/OS Connect EE includes a significant new mapping capability that is used before the transformation from JSON messages to the required format of the z/OS subsystems. This mapping capability adds a powerful abstraction layer between the API consumer and the underlying z/OS assets and allows inline manipulation of requests, such as the mapping of HTTP headers, pass-through, redaction, or defaulting of JSON fields.”
The great thing about using z/OS Connect EE is that developers can access most mainframe assets from a single product. It also makes it easy for mainframes to join in the API economy. And the developers that you use, can access mainframe APIs without needing to know very much about mainframes. They can treat the mainframe like any other server.
The mainframe can now be even better!
