CICS / WebSphere

The article “New Technologies Help Bridge Gap Between Mobile and the Mainframe” (available at http://entsys.me/ekjfo) discussed how CICS helps bridge the gap between the mainframe and mobile devices. It also examined the IBM CICS Transaction Server (TS) Feature Pack, which introduces native support for JavaScript Object Notation (JSON) data in CICS. In this article, we go a step further and discuss just how easy it is to create mobile-enabled services from your existing CICS assets, and how these can be rapidly incorporated into an IBM Worklight project for deployment to a multitude of mobile devices.

Feature Pack Recap

The CICS TS Feature Pack for mobile extensions provides support for the JSON data format, which is ideal for integration with mobile devices and RESTful JSON-based Web services. This makes it easy to connect a mobile device to a CICS service or to easily integrate it with a middle-tier mobile architecture, such as IBM Worklight Server. Best of all, the feature pack is freely available to download. Find out more at http://ibm.com/cics/mobile.

How Hard Can It Be?

For many customers, their first foray into mobile with CICS is likely to be exposing existing CICS applications to mobile devices. Let’s examine the basic steps necessary to expose an existing CICS application as a JSON-callable service:

1. Identify the application to enable as a JSON-callable service.
2. Generate the bindings for each service operation you require (i.e., create, read, update, delete).
3. Define the required CICS PIPELINE resources to allow your service to be called.

Those of you familiar with CICS Web services might think those three steps sound similar to the process you follow today for Web service-enabling CICS applications, and you would be right. In its simplest form, we’re building a Web service that’s invoked using the JSON data format rather than a SOAP XML message.

Step 1: Breaking It Down

This first step is heavily dependent on the nature of your application, but is perhaps the most critical step because, at this point, you decide where within your application infrastructure you define the entry point for mobile workloads. 

This might sound obvious, but for applications that have a significant heritage, there’s a good chance they weren’t built with mobile devices in mind, and the degree of abstraction between the presentation layer, business logic and data might not be ideally suited to mobile integration. 

The key thing to consider is the interaction pattern that you’re building between the mobile device and the CICS service. An existing application that has been Web service-enabled might well have a significantly richer interface than is strictly necessary for a mobile solution.

Mobile developers, who perhaps haven’t participated in the service-oriented architecture (SOA) transformation of enterprise services, won’t necessarily appreciate that SOAP Web services are a different paradigm to the RESTful service approach that’s more prevalent among mobile development teams. In a RESTful architecture, the create, read, update and delete operations are discrete interfaces, whereas a traditional Web service commonly has a single, richer interface and the operation is defined as part of the payload.

On a mobile device the workflow tends to be more restrictive with fewer options, in part due to the restricted nature of the screen, so the interaction between the mobile device and the back-end service might also be better as a discrete operation. 

4 Pages