HostBridge Technology

A HostBridge White Paper


Content > White Papers

An Object-Oriented Approach to Modernizing Complex CICS Applications


Organizations relying on legacy applications face a familiar challenge. As technology evolves and users become proficient with graphical interfaces, legacy applications become ever harder to use. As a result, productivity and efficiency decline while the costs of doing business rise. Confronted with this situation, an industry leader launched an initiative to unite its many business systems under a single, common front-end application. As a critical piece of the puzzle, they needed to modernize, simplify, and integrate their most complex legacy applications with the enterprise front end. Their choice for mainframe integration, and now their corporate standard, was HostBridge®.

Challenge: Legacy IT and the Modern Workforce

The company, in business for more than a century, implemented its first CICS®-based account management application in the late 1970s; it continues to perform and provide critical functionality. As years passed, the company also implemented mainframe databases, more CICS applications, other enterprise applications on distributed platforms, productivity suites, office programs, and so on.

In recent years, it became increasingly apparent that this complex IT portfolio with its aging applications was impacting productivity and efficiency, especially among customer service personnel, the most frequent users of the widest array of applications. On any given service call, a rep might have as many as 16 different programs open on the desktop. Reps spent considerable time working through legacy applications screen by screen, clicking from window to window to window, copying data from here to paste over there – and they needed weeks of training to learn just the basics of the legacy applications.

Determined to regain lost productivity and efficiency – and control costs – the company’s enterprise architecture group defined two strategic objectives: streamline access for users and maintain existing systems, which were tightly woven into the business process and performed exceptionally well. Doing so, they would also avoid the effort and cost of a massive migration to new platforms. The company launched a multi-phase, multi-year initiative, first, to integrate all of its applications under a single front end system and, second, to deploy access to users across the company, then to remote and mobile employees, and ultimately to customers nationwide.

One of the biggest challenges the group faced was its oldest CICS application. In addition to integrating this application, they would need to address its extreme complexity and ensure user accessibility for years to come.

Requirements

In its search for this complete solution, the group defined key requirements:

Solution

After evaluating a number of solutions, one emerged as the clear leader and able to satisfy all requirements – HostBridge.

HostBridge is Web services software that runs on the mainframe under CICS for the highest performance and reliability.1 HostBridge auto-generates XML from CICS applications and provides a JavaScript engine for Web services development and runtime integration. The HostBridge approach ensures precise fidelity to source applications, exactly replicating CICS data streams, and enables dynamic aggregation and automation of even the most complex CICS micro flows as a single Web service.

HostBridge supports XML, ACORD XML, JavaScript, SOAP, REST, and other standards for flexible integration of anything mainframe with anything distributed. And as developers attest, the HostBridge combination of Eclipse IDE and JavaScript for scripting/Web services enables easier, faster development and deployment.

Addressing Complexity

With its mainframe-resident JavaScript engine, HostBridge provided a highly efficient, effective, and economical way to simplify and integrate the customer’s oldest and toughest application.

A main HostBridge advantage over other integration products is that HostBridge installs on the mainframe. Products that run in the middle-tier cannot simplify complex applications without performance impacts. Even if they are able to merge several screens into one, doing so in the middle tier reduces mainframe performance – and the more complex the process, the more severe the impact. If a user submits a request and the appropriate functionality and data are housed on 30 screens, executing the request on the middle tier will require 30 requests/responses and 30 full transits of the network. Mainframe-based HostBridge, on the other hand, transacts those 30 screens with a single request/response. Given the large number of screens traversed in typical interactions with the customer’s highly complex application, simplification had to occur on the mainframe.

However, the application’s complexity was much more challenging than middle tier vs. mainframe-based. Not only is it a 3270 “green screen” application; it is also very cryptic, complex, and therefore difficult – for end-users and developers alike. As such, any simplification effort requires a thorough understanding of the application’s unique characteristics.

Within the application there are hundreds of screens corresponding to various aspects of the company’s products, customers, and accounts. Different account types all have unique sets of screens. Within these sets, there are unique screens for personal information, account information, account history and status, billing, payments, transaction history, changes, terminations, and so on. Then there is the complexity of the screens themselves. Each screen and nearly every data point displayed on screen appear as abbreviations or codes – thousands of codes in all.

To complete any business process, service reps are required to complete many different steps by navigating through many different screens. To do a complete account overview, for example, a rep might have to traverse 30 or 40 different screens – all while conducting a phone conversation with a customer.

Complicating matters, the application is not designed or written as a logical, linear progression of screens. There is no flow through the application as with most CICS terminal-oriented applications. Each screen functions as a discrete unit. Yet each screen typically has a large set of related screens – prerequisite screens (before completing a transaction on 3210, a rep must have visited 1601), page-down screens, and a large number of trailer screens with further information and functionality. Every time a rep accessed the application on their desktop emulation, they had no choice but to complete one screen, then jump to another as complex as the first, then another, and then another.

To cope with this complexity, reps spent weeks gaining basic familiarity with screens, codes, prerequisites, trailers, and the rest. Becoming skilled took much longer.

Web Services: Module and Assembly Level

Given the application’s lack of sequential flows, the enterprise architecture group, working with HostBridge Professional Services, had to devise a flexible new way to aggregate screens and simplify output. They did so with a unique Web services approach, conceiving an “architecture” that divides services into two distinct levels.

At the lower, module level, developers write modules that reproduce screens and perform all screen-level functions. At the higher, assembly level, they write Web services that “require” modules as needed to run a higher-level service.

From CICS application to new front end, the levels are as follows:

Figure 1

The module and assembly concept, like the HostBridge JavaScript Engine itself, adheres to and employs CommonJS standards, which define modules, requires, and more.2

JavaScript Module Level

Employing the JavaScript module concept, the customer’s Web services developers encapsulate each legacy application screen, with all of its data and functionality, as a JS module. If the screen has prerequisite screens or trailers or unique logic, all of that information is included in the JS module. In this way, everything that might ever be needed from a screen is present within the module, and every visit to the screen extracts all the content and navigates through all related screens.

A few additional issues are resolved at the module level as well. This particular CICS application is not a BMS application, so screens do not include field names, which HostBridge normally uses to identify and interact with editable screen areas. To resolve this issue, developers named all fields within the JS module.

Also, data exchanged across the customer’s networks must adhere to the ACORD XML standard. However, the old application is generally not ACORD-compliant. This means that every value has to be reformatted as an ACORD value. This significant formatting task – the ACORD schema exceeds 20,000 lines of XML specifying how data and metadata must be formatted – is also carried out at the module level.

Web Services Assembly Level

At the assembly level, Web services are written to require the modules needed to complete a business service. For example, when a customer service rep working in the front-end application requests an account overview, the request passes to HostBridge, which executes the assembly-level account overview Web service, including all the requires needed to access all relevant screen modules. Depending on the parameters and scope of the individual account, the request might require 30 or 40 modules. From the assembled data, HostBridge then generates an ACORD XML document, wraps it in the appropriate services protocol and description language, and returns the single response to the front end for display on the rep’s desktop.

Because the higher-level Web services simply assemble modules, changes at the screen/module level make no difference at the assembly level. If new screens with new functionality are added to the application, or if screens are modified in any way, the higher assembly-level Web service remains unchanged. Similarly, if a new assembly-level Web service is written, it makes no difference at the module level since services simply require the modules they need.

Object Orientation and SOA

This approach is a logical extension of the object-oriented model intrinsic to the service-oriented architecture (SOA) concept. By transforming each screen into a JS module, the customer has created a complete set of objects that can be reused by any service at any time. Similarly, at the higher assembly level, the Web services are objects that function discretely and can be reused for new and varied purposes.

By turning CICS screens into a collection of objects, the customer has effectively transformed its critical and most difficult application into a highly responsive dynamic service-oriented application and extended its life into any foreseeable future.

Business Benefits

As noted above, the overall project was planned as a multi-phase, multi-year effort. With each rollout of a process or capability, the company anticipates continuing improvements in customer service, business process efficiency, and employee productivity. They also expect to reduce training from several weeks to just a few days. And they are very confident that over time they can provide deep self-service access for customers, further improving team productivity and reducing costs.

Technical Benefits

The company has also realized many benefits specific to HostBridge and the object-oriented Web services approach.

Aggregation and Automation

By aggregating/assembling many screen modules into a single Web service, HostBridge enables the company to simplify its oldest, most complex CICS application to a degree they had scarcely imagined. Business process requests to the application, which average 20 screen transactions and can run as high as 120 transactions, are now, for the first time, organized and presented to the front end as a single response.

Performance

The customer has been particularly impressed by the level of performance HostBridge delivers. When HostBridge aggregates and automates screens, no matter the number, the entire cycle is completed in less than a second 97% of the time – that is less than a second to receive the request, interact with the application, complete dozens of transactions, analyze the results, package the results, and deliver ACORD XML back to the front-end application. Median response time for all requests is .27 seconds.

Of course the ultimate value of this performance is that customer service reps are more productive and responsive on calls, and customers enjoy a better service experience.

Development

Developing Web services from difficult legacy applications can be onerous, particularly because developers have to possess or gain a thorough knowledge of the application’s complex inner workings. Understanding that it would be easier for mainframe developers to learn Web services than for Web services developers to learn the mainframe, IT managers decided early on to utilize their mainframe team.

With its JavaScript-based Web services engine, HostBridge made this even easier than expected. According to the developer’s themselves, JavaScript has been easy to learn, reliable, and powerful.

HostBridge Web Services: Tactical to Strategic

By design, HostBridge allows customers to start with tactical implementations that solve immediate integration problems, then expand by implementing more Web services, and over time build toward a broader, more strategic level of SOA-enabling CICS applications and other mainframe assets. With this flexible mainframe Web services approach, HostBridge can grow as organizations’ services objectives grow.

Footnotes

[1]HostBridge can alternatively run inside z/OS but outside of CICS. In this case, all HostBridge processes and HostBridge Web services/integration scripts are eligible to run on the System z Integrated Information Processor (zIIP). For more on HostBridge for zIIP, download “zIIP-Enabling CICS Integration Workloads: HostBridge for zIIP” here.

[2]Visit www.commonjs.org for information on the standards.

Copyright Notice

Copyright © 2011-2015 by HostBridge Technology. All rights reserved. No part of this publication may be reproduced, transmitted, transcribed, stored in a retrieval system, or translated into any computer language, in any form or by any means, electronic, mechanical, optical, chemical, manual, or otherwise, without prior written permission. You have limited permission to make hardcopy or other reproductions of any machine-readable documentation for your own use, provided that each such reproduction shall carry this copyright notice. No other rights under copyright are granted without prior written permission. The document is not intended for production and is furnished “as is” without warranty of any kind. All warranties on this document are hereby disclaimed including the warranties of merchantability and fitness for a particular purpose.

Revision date: 6/8/2014

Trademarks

HostBridge and the HostBridge logo are trademarked by HostBridge Technology. All other trademarks mentioned are property of their respective owners.