Web Services Brings Ubiquity to Integration
The benefits of Web services have been touted for a few years now. Standards for communications (TCP/IP and HTTP), message exchange (SOAP), data formatting (XML), and means of describing the access (WSDL) to services have emerged. Many vendor products support standards for creating Web services requestors and providers, and some tools can even generate code from WSDL for service requestors to access Web services.

The supporting runtime infrastructure and integration capabilities between Web services and legacy applications and data are the focus of this article. The standards don't deal with what is behind a Web service, nor should they. But behind the curtain lurks the dirty work that has to be done to make Web services real integration.

 

Service-Oriented Architecture: Bridging CICS with Web Services
Web services simply move the ability to create services into a standards-based approach that is independent of hardware/operating system platform and program language. Simply using Web services technologies to continue creating custom, point-to-point integration linkages produces just another tangled web of issues to address.

The real power of a service-oriented architecture is to think in terms beyond individual application-to-application linkages and more in terms of generic services that can be constructed for any and all applications to leverage. This is the key to effectively realizing the maximum benefit of Web services.

Typical Web Services Approach
Typical Web services products run on an outboard processor from the mainframe/CICS perspective, usually on a Unix or Windows server platform.

The ability to create Web services to wrap mainframe resources is limited by the ability of the chosen tool to integrate with the various types of resources found in CICS or accessible from CICS, including:

• COMMAREA programs
• VSAM files
• 3270 screens (BMS and others)
• DB2 tables and stored procedures
• IMS data and programs
• MQSeries-enabled applications

There is still quite a bit of separation between the mainframe/CICS resources and the Web service provider platform.The issues in this type of an approach include:

• Security
• Transactional semantics
• Change management
• Availability and scalability
• Cultural differences

Transactional Semantics
CICS is a transaction manager. Many line-of-business systems depend upon transactional capabilities from order entry to order fulfillment and shipping to billing and so on. Virtually all financial institutions from banks to brokerage firms to insurance companies - depend upon CICS. ATM networks are controlled by CICS-based systems, whose reach encompasses the ATM terminal. It's important to understand the demarcation points of where transactions begin and end, and the impact on the end-to-end system. What happens if the communication link between the Web/application server or integration broker and the mainframe has a problem? How did the failure impact the Web service? Did the failure occur before initiating any CICS transactions or after? If the request got to CICS, did the CICS transaction complete? How is the Web service requestor or provider to know?

Change Management
All of the integration techniques of the past caused problems whenever something changed in the legacy application and data:

XML and Web services help in that additional XML tags and data can be added to a SOAP message body. Only those applications that need the new tags and data need to change.

Although changes can be isolated due to the loose coupling between Web service providers and requestors and the ability of Web service requestors to dynamically react to changes via WSDL, there is still an issue. An enormous problem common among the typical approaches to integrating the mainframe with Web services is managing changes to the underlying resources and the downstream impact to the Web services that have been created to wrap them. Because most approaches call for a Web/application server or integration broker running on a platform other than the mainframe, changes must be coordinated between the two platforms and typically between two organizations.

Availability and Scalability
Utilizing a separate platform to host a Web/application server and/or gateway requires two layers of systems that must be highly available and scalable and must also deal with potential communication failures between the two layers as well. This makes for a very complex operational situation. Clearly, tools and techniques exist to address the availability and scalability of Web servers that can also be applied to Web/application servers hosting Web services. And just as clearly, the mainframe/CICS environment also provides tools and technologies to address high availability and scalability of transactional systems. But they are two distinct environments and sets of tools/ technologies solving the same basic problem in two places. These tools and technologies don't integrate with each other. This requires two skill sets on the part of operational personnel and complicates troubleshooting. Furthermore, the communications links between the two environments must also mesh well with the high availability/scalability solutions on either endpoint.

Web Services and CICS:
Can These Cultures Coexist?
The predominant approaches to constructing Web services rely upon two fairly recent technologies - Sun Microsystems' Java 2 Platform Enterprise Edition (J2EE) and Microsoft's .NET. Virtually all vendor products require the use of a Windows or Unix-based server. Many require some form of a gateway and/or third-party adapters to interface to the mainframe.

The result is still two independent camps, much like in past EAI efforts, that require cooperation and communication. Worse yet is the ownership issue. Whichever group "owns" the integration between the two environments is critical to the operations team. One of the greatest challenges to any EAI effort between the mainframe and other platforms is communication and cooperation among the different development and support organizations.

The Solution: CICS as the Web Services Hub
To overcome these issues, as well as provide for a more robust integration environment, CICS itself should host the Web services provider and integration layer. Furthermore, the task of creating and managing services should be performed by the same organization that maintains and manages the legacy applications and data being wrapped to ensure consistency and eliminate communications problems typically found in most integration scenarios.

This approach offers a single point of control for both the Web services and the CICS resources behind them. The Web service provider is, in effect, also the CICS resource provider. When problems arise, there is no issue over who owns the problem. And because there are no longer two distinct environments separated by a network, problem determination is simpler.

All sorts of operational issues are eliminated. Another layer of hardware/software to maintain and manage is removed, reducing operational costs. The same management tools currently being employed to support CICS can also be used to deal with the Web services also running in CICS. No retraining of operational staff is necessary.

The Web service provider, by virtue of the fact that it is under the control of CICS, immediately inherits all the benefits of CICS, including transactional semantics, availability, and scalability. Security can be more tightly integrated with CICS from the Web service provider as well.

 

Putting the Pieces Together
CICS offers a feature known as CICS Web Support (CWS), which allows a Web browser to connect directly to CICS to invoke a CICS transaction using the EXEC CICS LINK call and passing data via the COMMAREA. EBCDIC/ASCII translations are automatically handled. And decode/encode functions may be plugged in to manipulate the data being passed between the Web interface and COMMAREA of the invoked transaction. All the hooks necessary to support Web services via HTTP exist in the CICS environment.

When combined with the capability to form Sysplex and CICSplex configurations, CICS Web Support provides a highly available and scalable platform for creating Web services second to none.

What Is Needed?
Additional capabilities are needed to enable CICS to operate as a Web services provider and integration hub:

Each item should be controlled under the auspices of CICS, easily understood by the mainframe/CICS Systems Programmer, and easily linked with CICS resources.

XML Translation
The ability to translate between XML and native data types (COBOL, DB2, etc.) and record formats (DB2 tables, VSAM files) is necessary. An XML parser is available for COBOL. However, there are a number of issues involved:

SOAP Messaging
Decoding/encoding of SOAP message formats for both inbound and reply messages requires the use of a SOAP processor.

Repository
A repository of metadata should be maintained to define Web services and their mappings to various CICS resources.

Dynamically Generate WSDL
With the Web services defined via metadata in a repository accessible via CICS, it's easy to configure the Web service to respond to inquiries and generate WSDL on the fly to specify available services and interfaces.

Accessing Programs and Data Using a Structured Approach
Simply providing a CICS-resident means of supporting Web services is necessary but not sufficient to allow IT organizations to realize the benefits of Web services/CICS integration.

For simple resources such as VSAM files and DB2 tables, one recommendation is to offer an SQL-like mechanism to define the methods or operations that may be invoked on the service. The methods should include select(), insert(), update(), and delete(). Programs, including DB2 stored procedures, can be executed using the executeProcedure() method.

By defining a standard set of methods, it becomes easier to generate code to support the service level interfaces, especially when combined with the ability to map XML to/from native CICS structures.

Setting the Stage for Composite Services and Beyond
Once various CICS-accessible resources have been wrapped as Web services, they may also be invoked within CICS itself, thereby creating the opportunity for realizing composite services at the source. Furthermore, with the appropriate building blocks in CICS, business processes can be constructed and exposed as Web services as well.

Conclusion
This article explains the benefits and advantages of supporting Web services directly inside CICS instead of the traditional approach most vendors have taken by providing this support on a middle tier. A number of vendors are moving in this strategic direction - one of which is IBM, the CICS provider. IBM's traditional approach to providing Web services access to CICS resources is via the WebSphere Application Server and the CICS Transaction Gateway. IBM recently announced a technology preview that supports SOAP enablement directly from CICS Transaction Server 2.2. While not a complete implementation of a Web services integration platform as prescribed in this article, it is a first step toward leveraging CICS as the hub for Web services and validates the approach taken in this article.

References