HostBridge Technology


Integrate CICS in a Service-Oriented Architecture

Modernizing and Revitalizing Legacy Applications with Web Services

Soon after Web services emerged as the most efficient, effective way to integrate disparate information systems, service-oriented architecture (SOA) followed as the preferred model for enterprise-wide and inter-enterprise interoperability. A great many organizations have adopted Web services for integration and to support an SOA strategy. Others lag behind.

Web services and service-oriented architecture continue to deliver on the promise of universal interoperability – breaking down proprietary silos, unifying the welter of applications and data assets that perform myriad business functions, and streamlining information-driven business processes. Organizations that adopt them gain new efficiencies, improve productivity, increase agility, cut costs, and create revenue opportunities.

One of the most appealing aspects of the Web services/SOA approach is that it allows organizations to leverage and even revitalize existing assets – while avoiding the expense of migrating or re-engineering. The System z mainframe and CICS Transaction Server are prime candidates for this approach. There are many reasons to continue using legacy applications – they do what they were designed to do, they perform exceptionally well, they are highly reliable, and migrating them to new platforms is a long, dark, expensive undertaking. The Web services/SOA approach is an ideal way to keep the mainframe in business and to make it even better – without any change to the mainframe itself.

The experiences of real organizations suggest that there are two basic ways of SOA-enabling CICS applications and System z data assets – implement Web services to achieve tactical integration objectives and build toward a strategic SOA, or start with an SOA in place or envisioned and use Web services to incorporate the mainframe into it.

From Tactical Services to Strategic Service-Oriented Architecture

A large insurance provider maintains numerous policy applications implemented over many decades even as they deploy new systems – workflow, imaging, office, messaging, and more – to keep pace with business and technology innovation. Their oldest insurance application, still a workhorse that manages tens of thousands of policies, is a highly complex terminal-oriented CICS/VSAM-based program.

Several years ago, the company realized that the combination of aging assets and complex applications was having a detrimental effect on productivity, efficiency, and costs. As a step toward simplifying processes and infrastructure, the company implemented a browser-based application to handle new policies and function as a common front end for the legacy applications. These were integrated with the front end app using a number of products; a middle-tier screen scraper was used to integrate the oldest application. When support for the screen scraper ended, the insurance company had to find a replacement.

The company had two requirements – address the immediate integration need and, to the degree possible, simplify the complex legacy app so it would be easier to integrate and use within the front end system. After onsite proofs of concept, the company chose a Web services solution. Not only was it the right solution to meet the simplification and integration objectives, it also started the company on a new path – to planning and building an enterprise SOA.

Simplify and Integrate Legacy Applications

The Web services approach, in this case using HostBridge and the HostBridge JavaScript Engine (HB.js)[1], provided a highly efficient, effective, and economical way for the insurer to simplify and integrate its legacy application. A brief description of the application shows why.

First developed in the 1970s, the classic green-screen application was cryptic, complex, and difficult to use for office personnel and developers alike. Within the application are hundreds of screens corresponding to various aspects of insurance products and policies. Universal life, term life, and annuity products all have unique sets of screens. Within these sets, there are specific screens for personal information, coverage information, policy face amounts, new billing, payments, transaction history, claims information, agent information, quotes, underwriting status, terminations, and so on.

Complicating matters, the application wasn’t designed or written as a logical, linear sequence of screens. Each screen functions as a discrete unit. Yet each one also has a large set of related screens – prerequisites (before completing a transaction on 3005, a user must have visited 1601), page-down screens, and a great many trailer screens with further information and functionality.

Then there is the complexity of the screens themselves. Each screen and nearly every data value displayed on screen appear as abbreviations or codes – thousands of codes in all.

To complete a standard business service – get a policy overview, for example – a customer service rep had to traverse 30 to 40 of these screens – all while on the phone with a customer or agent.

JavaScript Web Services Solution: Module and Assembly-Level

JavaScript-based Web services offered an elegant solution to this complexity, allowing developers to devise a new way to aggregate screens and simplify presentation. They did so by dividing services into two distinct levels.

JavaScript Module Level
Leveraging the JavaScript module concept, developers encapsulated each CICS screen, with all of its data and functionality, as a JS module. If the screen has prerequisites or trailers or unique logic, all of that information is now included in the JS module. In this way, everything that might be needed from a screen is present in the module, and every visit to the screen traverses all related screens and extracts related data. The module and assembly concept adheres to and employs CommonJS standards, which define modules, requires, etc.

Web Services Assembly Level
At the assembly level, JavaScript Web services are written to require any and all modules needed to complete a business service. Now when a user submits a policy overview request, the policy overview Web service requires and aggregates data from the modules corresponding to the 30 to 40 relevant CICS screens. From the assembled data, the Web service then generates an ACORD XML document, packages it as a SOAP or RESTful service, and returns the single response to the front end application.

Toward Service-Oriented Architecture

This solution is an excellent example of how the Web services approach can simplify, aggregate, and integrate legacy applications – and help organizations achieve tactical integration objectives. For the insurance provider, however, the ramifications turned out to be much more significant.

During planning and development, the insurer quickly came to appreciate how Web services of this type “reinvent” legacy applications as flexible, higher-order dynamic applications. With reusable module- and assembly-level objects in store, the provider realized that they were creating the building blocks and starting down the path toward a services-oriented architecture.

Soon after completing the initial integration, the company launched a comprehensive initiative to design and build out the SOA. As they progress along that path, their experience with their tactical Web services gives them confidence that all their CICS applications and System z data assets can readily be enabled as integral parts of a new, more flexible, more extensible enterprise-wide architecture.

Whether organizations grow a service-oriented architecture strategy from tactical Web services implementations or begin with a strategic SOA vision and plan to integrate existing systems into it, HB.js offers a fast, flexible, powerful way to make the mainframe a fully engaged citizen of the SOA world.


[1] HB.js was formerly known as the HostBridge Process Automation Engine.