It was inevitable that CICS' support of Web services got covered. As you know, Web services are the "future" of IT (as opposed to the many other futures that were championed in the past), and CICS is at the forefront of support of the Web services menagerie. Here is a short overview of CICS/TS 3.1 Web services as I understand them.
What are Web services?
Web services support the exchange of information between disparate systems in various protocols over an IP network. The systems exchange self-describing messages in Simple Object Access Protocol (SOAP) written in text-based extensible markup language (XML). All the items are self-describing in that they are bounded by beginning and ending labels with text in between, similar to hypertext markup language (HTML), with the difference that XML labels, aside from those that mark SOAP elements, are user defined.
The system initiating the communication is the service requestor. The computer receiving the message is the service provider. A third element is the service registry. The service registry is a repository for service providers to publish their services where requesters can find them. The Web service's description itself is written in Web Service Description Language (WSDL) stored in the repository. Note that CICS applications can be service requestors or providers, but CICS itself cannot be a repository.
All of these components are wrapped up with the idea that requestors do not have to worry about the provider's platform or the implementation of the application. All they need to know is where the service lives and how the messages work. One problem is XML's bulkiness. SOAP is also not binary data friendly as binary objects must be expanded through encoding to pass for text through the jaws of communication. This, however, is streamlined with the new Message Transmission Optimization Mechanism (MTOM) supported in CICS/TS 3.2
How CICS does it
CICS takes two approaches. First, there is the "roll your own" idea where an application parses its own inbound and builds its own outbound SOAP messages. Second, CICS provides facilities that translate incoming XML into application data structures. Similarly, these facilities take data structures and whip them into SOAP messages suitable for transmitting.
This leads to a recurring theme in the CICS documentation regarding Web services; the separation of communication and business logic. The ideal application has a communication layer that understands the incoming message and can translate it into a data structure to be passed as a communications area (COMMAREA) or channel containers to business logic modules. The business logic processes the input and returns a structure the communication modules can turn into a message. IBM spends a lot of time flogging this concept because an application structured in this way is very easily exposed as a web service using CICS' tooling.
In addition CICS has the concept of a pipeline. Conceptually a message goes in one side and gets passed through a series of programs called message handlers. Each message handler gets a crack at the input message and passes the results to the next. The last message handler in the pipeline performs the actual work and presents the result. The result travels back up the chain of message handlers until XML pops out, ready for transmission.
To support the two approaches outlined above, you can either use CICS' default message handlers or write your own. Note: One pipeline can support any number of Web services.
CICS also provides two utilities, DFHLS2WS (language structure to Web service) and DFHWS2LS (Web service to language structure), collectively known as the Web services assistant. As you can tell by the names, these utilities provide ways to get WSDL out of programming language structures and vice versa. They also produce binding files that tell CICS how to map between Web service messages and the structures.
Overview of a service request
Assume we have a UNIX client that wants to use Web services to retrieve some information from CICS. Also assume the target CICS has an HTTP TCPIPSERVICE definition and an active listener.
The whole process starts when the client creates and sends a SOAP message from CICS. The actual format and content of the SOAP message is way beyond the scope of this column. Instead we have to assume that somewhere in the SOAP header there's a Uniform Resource Identifier (URI) identifying the desired Web service.
CICS receives the request and parses the SOAP header to find the incoming URI. It then looks through its URIMAP definitions for a match. URIMAP resources associate incoming message URI's with a pipeline or Web service.
If CICS finds a match, it uses the pipeline or Web service definitions to begin processing the message. CICS orchestrates passing the message down the various handlers until it reaches the program that actually retrieves the desired information. Once it has the data it passes it back through the pipeline using the proper language structure. Again, CICS manages the flow back out of the pipeline until it has a SOAP message to return to the client.
Of course the above description of Web services is criminally oversimplified. In the next few months I hope to explain more of the nuts and bolts going along with it.
ABOUT THE AUTHOR: For 24 years, Robert Crawford has worked off and on as a CICS systems programmer. He is experienced in debugging and tuning applications and has written in COBOL, Assembler and C++ using VSAM, DLI and DB2.
Did you find this helpful? Write to Matt Stansberry about your data center concerns at mstansberry@techtarget.com.
