Sunday 16 September 2012

CICS communication history

In the beginning, CICS programmers used conversational transactions – but not any more. Pseudo-conversational coding is less resource-intensive, user think time costs are eliminated, and sites can run more simultaneous transactions. On the down side, programming is more difficult, application design requires re-starting programs, it’s more difficult to debug programs, and programs require an area to store data between tasks.
 

And so we get the Communication Area (COMMAREA). It’s a terminal-based scratchpad that’s dynamic in size (0 to 32,500 bytes), and is private and chained to the terminal. The COMAREA can hold data between pseudo-conversations, has a maximum in size of 32K, can be passed from program to program, can be empty, partially full, or full, and is automatically cleaned up when not used.

However, COMMAREAs have obvious limitations, and so IBM gave us channels and containers. There are no size limitations on data in containers, the number of containers in a channel is unlimited, and there can be separate containers for input and output.
Another way round COMMAREA limitations is to use an XML (eXtensible Mark-up Language) front-end application. Associated with this are:

  • Extensible Stylesheet Language Transformation (XSLT) is the recommended style sheet language of XML.
  • XML namespaces – in XML, element names are defined by a developer.
  • XML schema is an XML document that describes the structure and constrains the contents of other XML documents.
  • XML parser is a program that is invoked by an application to process an XML document, ensure that it meets all the rules of XML as well as the syntax of the DTD or schema, making the data available to the calling application.

With the introduction of Services Oriented Architecture (SOA), programmers now use CICS Web services. A Web service is a collection of operations that are network accessible through standardized XML messaging. The Web services architecture is based on interactions between three components: a service provider, which is the platform that hosts access to the service; a service requester, which is the application that is looking for and invoking or initiating an interaction with a service; and service registry, which is a place where service providers publish their service descriptions, and where service requesters find them.


Universal Description, Discovery and Integration (UDDI) is a specification for distributed Web-based information registries of Web services. The service provider “owns” the service, creates the WSDL (Web Service Description Language – see below), publishes the WSDL, and processes the requests. The service requester “finds” the service, binds to the service, and invokes the service using the WSDL. The service registry hosts the service description and is optional for statically bound requesters.


WSDL is an XML application for describing Web services. WSDL comprises:

  • Types – the data types in the form of XML schemas
  • Message – an abstract definition of the data in the form of a message
  • PortType – an abstract set of operations mapped to one or more end points
  • Binding – the concrete protocol and data formats for the operations
  • Service – a collection of related end points.

Simple Object Access Protocol (SOAP) is an XML-based protocol for the exchange of information in a distributed environment. A SOAP message is encoded as an XML document.
 

The CICS Web services assistant is a set of batch utilities that can help users transform existing CICS applications into Web services and to enable CICS applications to use Web services provided by external providers. The CICS Web services assistant comprises two utility programs:
  • DFHLS2WS generates a Web service binding file from a language structure. This utility also generates a Web service description.
  • DFHWS2LS generates a Web service binding file from a Web service description. This utility also generates a language structure that you can use in your application programs.

You can use Rational Developer for System z for Web services and XML development. A CICS pipeline is responsible for dealing with SOAP headers. It’s implemented as a series of programs, and can be configured by end users by using message handlers. A message handler is a program in which you can perform your own processing of Web service requests and responses.

No comments: