Organizations now are complex environments which implement their own internal clouds made up of many types of machines.  In this Hybrid IT environment, the mainframe is one participant in the cloud. 

At HostBridge, our relationship with many customers began because of problems letting their mainframes fully participate in their cloud strategy. For the cloud to work, the machines need to have standards-based ways to talk to each other without requiring an intimate knowledge of each other’s internal workings. If the .NET or Java servers have to understand information about the mainframe screens and how they flow, it creates an affinity and a more complicated boundary. In this case, you have two sets of code related to each other, but running on different machines: the mainframe code and the associated interface code running on the .NET or Java platforms.  This interface code must remain in sync with any mainframe changes to screens or screen flow.  If someone in the organization starts interfacing to the mainframe to get information, it is easy to lose track of all the clients and affinities in doing change planning.

Creating a Web Service Boundary

We’re proponents of creating mainframe-based web services, where the mainframe logic stays on the mainframe. A web service boundary is put around that logic to make available the business process that the mainframe screens perform.

An example that applies to most businesses is a “Change Address” function. You can make this function available as a web service using standards-based HTTP(S) and standard ASCII/UTF XML, or JSON. In fact, you can choose any needed format for communication depending on business needs.  Then, non-mainframe cloud participants need only do a standard web service call to this “Change Address” business service (or any other service you create).   The non-mainframe participants don’t have to know anything about mainframe screens, transactions or EBCDIC.  To the non-mainframe part of the cloud, it just looks like a normal web service. They don’t even know if it is running on or off the mainframe.  The implementation is now hidden from the rest of the cloud, breaking that affinity where the .NET or Java program must know about mainframe screens and flows. 

A web service layer implemented with the HostBridge JavaScript Engine is an ideal way to allow the mainframe to fully participate in the cloud.

This approach to making CICS screens and business logic available as services is very resilient. If, for example, the mainframe screens change, only the mainframe web service needs to change. It’s not necessary to change the cloud participants since the web service API didn’t change.  If you need to change the web service API, you can handle that in various ways. Versioning is one that lets existing clients use the older version, while new clients can use the improved API.  This applies to mainframe and non-mainframe web services and is just part of the normal cloud API management strategy.

Web Service APIs Make Migration Easier

If you choose to move off the mainframe, you can wholesale replace these mainframe web service APIs with non-mainframe web services. Or, you can take an incremental, API by API approach.  Since the APIs they are standards based, there is nothing mainframe specific about them.  A “Change Address” function is just another standards based web service API on the internal cloud.  The user of the web service API doesn’t know or care whether it is hosted on a mainframe, a Windows, or Linux machine.

Prototype a CICS Web Service

It doesn’t take much time to develop, test, and deploy a web service API. With a little help from our team, you can create a set of APIs to make the application logic in CICS screens available. We’ll provide free, trial software so you can know with certainty what you’ll get from a web services strategy. Contact us to learn more: