Editor’s note: the first version of this post was published earlier this year, and it came to the attention of the IBM® z/OS® Connect EE product team. It led to a very productive dialogue about our respective solutions. That created a better, mutual understanding of each solution’s capabilities and how IBM® z/OS® Connect EE and HostBridge complement each other. As a result, this article has been extensively revised.

As we work with our enterprise customers and prospects on CICS integration opportunities, we’re increasingly hearing about IBM® z/OS® Connect EE (ZCEE). The question we’re getting is simple: are HostBridge and ZCEE competing solutions? If so, why would an enterprise IT organization choose one over the other? And if not, how can they work together? Spoiler alert: these solutions are highly complementary for CICS integration and orchestration. We’ll explain how and why in the rest of this post.

The HostBridge JavaScript Engine is the implementation of the CICS API, and ZCEE will manage access to the API from the non-mainframe world.

On the surface, it might appear as if these solutions compete. The IBM website says this: “IBM® z/OS® Connect Enterprise Edition provides a framework that enables z/OS based programs and data to participate fully in the new API economy for mobile and cloud applications.” At HostBridge, we use similar language to describe the HostBridge value proposition, so it’s easy to understand why z/OS shops are confused about the differences. It sounds like “buzz-word” bingo either way!

HostBridge has a long-standing partnership with the IBM, and we have for decades engaged various IBM product management teams to share our opinion (often based on customer input) of the best ways for CICS to participate in hybrid IT.

So What’s the Difference?

There are a few, but one obvious difference between HostBridge and ZCEE that highlights the role each product plays in a CICS environment. When providing direct access to CICS, ZCEE can only invoke a single LINKable program. It’s important to note that ZCEE supports other environments, not just CICS, and its capabilities differ by environment. However, if you want ZCEE to directly invoke CICS programs, it will be on a 1:1 basis (one external API call maps to a one LINKable program). It has no support for CICS terminal-oriented transactions, that is, of course, apart from HostBridge, customer-written software, or other IBM products.

Our HostBridge JavaScript Engine (HB.js) product, on the other hand, has been designed from the ground up to be a CICS-based, orchestration engine that allows you to interact with LINKable programs OR terminal-oriented transaction on a 1:many basis.

How Big is This Difference?

The limitation of only being able to invoke a single, LINKable program in CICS matters because it can force orchestration to occur outside of CICS (which usually means off the System z platform). Of course, if your legacy LINKable (aka “commarea”) programs directly map (1:1) to the modern API-based services you wish to expose, then you are in luck! However, in our experience this is exceedingly rare. Thus, for most organizations, the ability for ZCEE to only invoke a single LINKable program is a limitation that ends up forcing orchestration OFF the mainframe. That is, unless they use HB.js from HostBridge (which runs inside of CICS).

This issue of where orchestration occurs is no small matter.

In the two decades that HostBridge has helped enterprises make CICS applications available via an API or as a service, we’ve learned this: most of the time, the need isn’t simply to provide an interface to a single CICS program, but to expose a business service which requires the execution of multiple programs or transactions. In some cases, such a service may orchestrate the interaction a human operator was originally intended/required to perform. For example, the case study about Bank of Ayudhya perfectly describes this orchestration use case.

One of the bank’s CICS application access sequences required a human operator to navigate more than 20 host application screens, at an average of a minute per screen. The bank’s IT team created a web service with the HostBridge JavaScript Engine to orchestrate the navigation sequence and data flows. The orchestration script runs inside CICS, but is invoked with a single click from a human operator from a middle-tier application. Now the sequence, including human operator time, completes in a minute, reducing the elapsed time by 95%.

Intellyx president and analyst Jason Bloomberg, in his recent post, “Integration Idées Fortes on the Mainframe: Stronger than Ever” shares why where the orchestration layer runs matters: performance. Most enterprises aren’t willing to see response times for core business applications go from milliseconds to seconds because the integration and orchestration layer runs off the host. However, when orchestration occurs outside of CICS, the latency goes up, as does CPU consumption. For this reason, HostBridge has long advocated doing integration and orchestration inside of CICS. A recent benchmark reveals the performance differences that result from where this layer resides.

Data Transformation

Another way to compare and contrast ZCEE and HB.js is by examining the matter of data transformation. Specifically, is it required and where is it performed? This will ultimately highlight how ZCEE and HB.js can be used together.

Let’s start with two observations about z/OS® Connect EE. First, ZCEE includes the capability to transform JSON documents to binary data structures like COBOL copybooks or C structs (the tooling provided is very robust). Second, and this is a key point, when ZCEE LINKs to a CICS program, this data transformation step is required. It’s understandable how this requirement came to be: the vast majority of all LINKable programs assume that the data being passed to it is a binary data structure described by a copybook, etc.

Now, let’s make a couple of observations about HB.js. First, JSON is the “native tongue” of HB.js. That is, as a JavaScript engine, the key data structure is a JavaScript object. JavaScript objects can be created directly from an input JSON document, and an output JSON document can be generated directly from a JavaScript object. Second, if a HB.js script needs to LINK to a commarea program, then (and only then) will the data in the JavaScript object be converted to a binary format (according to the copybook, etc.).

Given that a not-so-secret rule of building robust, high-performing integrations to host applications is to not do any more transformations than are necessary, it’s pretty clear why you would never want to do the following:

• Send an HTTP/REST/JSON request to ZCEE
• Have ZCEE transform the JSON input to a binary data structure
• Have ZCEE LINK to HB.js, passing it the binary data structure
• Have HB.js transform the input binary data structure back to JSON so it can be processed by the JavaScript engine.
• Have HB.js transform its JSON output into a binary data structure
• Have ZCEE transform the binary data structure back to JSON
• Send the HTTP/REST/JSON response from ZCEE

That would be a terrible idea!  If the processing program on z/OS (CICS or otherwise) wants to receive and work with a JSON document natively, it’s a total waste of CPU to do needless conversions to/from binary data structures.  Thankfully, ZCEE provides an alternative path for communicating to CICS and HB.js: REST endpoints!

Using REST endpoints is the trick to making ZCEE and HB.js work together as a powerful “tag team”.  When an inbound request is processed by ZCEE and is destined for a REST endpoint (think HB.js), the JSON input will not be transformed into a binary data structure.  However, ZCEE can do JSON-to-JSON mapping — and there are many situations in which this is a very good thing!

Different and Complementary

Well… sort of.  If you have an existing inventory of LINKable CICS programs, and the functionality they implement is exactly what you wish to expose across a RESTful API, then you should strongly consider using ZCEE.  We recommend it!  However, ZCEE is not a complete solution if you have one of the following use-cases:

• You need to execute more than one LINKable program to implement the API/service functionality you wish to expose
• Some or all of the functionality needed to implement the API/service is currently implemented by CICS terminal-oriented transactions

These are two cases in which you will need something in addition to ZCEE – something, somewhere to perform orchestration (whether a little or a lot).  And, when you encounter these cases, it’s exactly when you need to consider HB.js and ZCEE as a “tag team”.  Why?  We can’t say it often enough: Because you don’t want to fall into the trap of orchestrating fine-grained CICS app/data artifacts from outside the mainframe. Developing a service using HB.js that runs inside CICS will provide the best performance.

A Tag Team for Sure

As you can see, ZCEE and HostBridge’s CICS-based orchestration engine may be the perfect tag team for your organization.  HB.js is the implementation of the API, and ZCEE will manage access to the API from the non-mainframe world.

If you use ZCEE and would like to trial HB.js for free, and with support from our team, simply reach out using the contact information found at the bottom of this page.