Web services are an increasingly common design paradigm, and where these applications are to be provided is the first design decision. IBM’s CICS Transaction Server may not be an obvious choice, but CICS is a good environment for hosting some Web service applications. CICS isn’t a general-purpose Web server; it’s a 40-year-old transaction processor. Its utility for Web services boils down to secure, scalable access to existing applications and data. The Web services of interest are those based on SOAP/XML, and CICS can act as a Web service provider for these services.
This article describes the facilities CICS provides to act as a Web service provider. A future z/Journal article will build on this and consider how various attacks on a Web server fail in the CICS environment.
Setting the Stage
Before we delve into the details, let’s examine a few terms that will be used throughout this article. First of all, a Web server is something that supports a request sent over the Internet. In the IBM mainframe world, WebSphere is a Web server. Apache (freely available on many platforms) is another example. A Web server can execute many types of requests; it’s a general processor of requests and uses a variety of languages—Java and PHP being common.
A Web services provider performs a specific function and doesn’t provide generalized functionality. All requests a Web services provider performs could be executed in a Web server, but not all the functionality of a Web server would be available in a Web services provider.
You wouldn’t consider using CICS to act as a host for video streaming; that’s a long-running operation and CICS is optimized for processing lots of short operations. However, if the desire is to process lots of short-lived requests, CICS would be suitable.
CICS TS 4.1 isn’t a Web server, but it can act as a Web services provider. CICS can execute some types of functionality that a Web server could also execute. This article is concerned with the execution by CICS of SOAP/XML Web service requests—the basic functionality can be viewed as equivalent to a CICS Distributed Program Link (DPL) or Remote Procedure Call (RPC). These requests would usually, but not always, be concerned with function or data that already resides in the CICS environment.
An example of this would be some function accessed by many CICS applications and needed outside the CICS environment. A Web service request would be sent to CICS with the request parameters inside a SOAP envelope. CICS runs the function as if it were being requested in the “usual” CICS application manner. It returns the information as a SOAP response. If the CICS name/counter facilities are being used to generate a globally unique identifier, then a CICS-supplied Web service could provide this globally unique identifier in a wider scope.
In general, any CICS application function that’s executed in a discrete application program (coded to the RPC/DPL design pattern) can be run as a CICS-supplied Web service. You must create the SOAP/XML structures for input and output using suitable Eclipse-based tooling and a program acting as a wrapper; existing programs will be unchanged.
The CICS community is most familiar with compiled languages running applications written using EXEC CICS commands. Consequently, the common approach of implementing a Web service in a dynamic, interpretative language may not fit with your site’s existing skills. CICS provides the ability for relevant Web service applications to be written in familiar languages such as COBOL, PL/1, or Assembler.