©Don Fowler, MCE Inc, December 2004 - Revised May 2005
Before we can discuss the newest CICS Version 3.1 features, some descriptions and discussions have to be done on certain Web-related terms and architectures that may not be familar to the CICS professional. CICS 3.1 touts the inclusion of CICS in the Service-Oriented Architecture (SOA) umbrella. It would behoove us to spend a little time on this architecture and certain world-wide organizations and standards deemed important in this architecture. As such, we will focus on the Web Services Interoperability Organization (WS-I) and its published specifications on the basic profile for Web Services Requests. The use of and adherence to this WS-I Basic Profile is described in the IBM literature on CICS TS V3. Please be aware that SOA does not imply Web Services is required. But in today's world, Web Services is the best fit for connections of SOA participants.
Since first publishing this document in 2004, HostBridge has created an excellent 17-page paper on CICS TS enhancements and HostBridge additional components. The paper describes how both CICS COMMAREA-based and traditional BMS integrated applications can play with a mix of HostBridge components and CICS TS 3.1 features. The industry jargon today defines a COMMAREA based application as a 'non-visual' application. If you have a traditional CICS application with integrated BMS APIs where mapping is done directly within the application logic, it is a 'visual' application.
The importance here is you can now make these 'visual', non-COMMAREA based, CICS applications (visual and non-visual) play nicely in modernization projects using the full power of the SOA components. The earlier cost effective webifying approaches relied on the CICS application being one of the non-visual classification.
This paper is the best I have seen on defining SOA and how introduced CICS functions along with HostBridge components provide an effective solution to bringing the legacy applications into the webified environments that companies are seeking to accomlish today. Some people might call this an approach to legacy applications modernization, or 'webifying' your application.
You can download their paper in PDF format by clicking here.
Computer Science majors have again re-invented the wheel and provided us with the latest hep acronym 'SOA'. SOA can be said to be the latest and greatest 'have to have' for the 'management by magazine' crowd running today's IT shops.
Service-oriented architecture is not a new concept. The first and early service-oriented architectures for many people were with the use IBM's VM Server/Requestor concept in the mid-80's, or DCOM, or Object Request Brokers (ORBs) based on the CORBA specification.
A Service-Oriented Architecture is at the most basic level nothing more than a collection of services that can communicate with each other over some form of connection technology.
A service is a function that is well-defined, self-contained, and does not depend on the context or state of other services. The technology known as 'Web Services' is the proper connection technology of service-oriented architecture. Web Services essentially uses XML to create a robust connection.
The services are loosely coupled which means that an application doesn't have to know the technical details of another application in order to talk to it. The services also have well-defined, platform-independent interfaces, and are reusable.
In SOA, a service is defined at a coarse abstract level, say, a business process such as generating a phone bill.
A service in SOA is an exposed piece of functionality with three properties:
A platform-independent interface contract implies that a client from anywhere, on any OS, and in any language, can consume the service. Dynamic discovery means that a discovery service (e.g., a directory service) is available. The directory service enables a look-up mechanism where consumers can go to find a service based on some criteria.
So why do we care about this SOA concept anyway? Well wouldn't it be nice to
interoperate any existing applications (services) with new business services via one set
of industry-standard APIs? Another reason is that we need to start talking about business
services instead of business functions. By speaking in the 'services' terms, the business
user is more engaged and less confused by technology jargon. After all, when you get down
to it, all they want is to use a service and not invent functions.
Gartner Group estimates that by 2008, more than 60 percent of enterprises will use SOA as
a "guiding principle" when creating mission-critical applications and processes.
In the above diagram of SOA, a service consumer dynamically requests a service provider from a directory service. This service provider has published a 'contract' so that the consumer can just go after the provider whose contract meets the consumer's needs. After finding the service provider of choice, the consumer is connected to the provider by a connection service (web services).
Service providers and consumers communicate via messages. Services expose an interface contract. This contract defines the behavior of the service and the messages they accept and return. Messages are typically constructed using XML documents that conform to XML schema. XML provides all of the functionality, granularity, and scalability required by messages.
Although the concepts behind SOA were established long before web services came along, web services play a major role in a SOA. This is because web services are built on top of well-known and platform-independent protocols. These protocols include HTTP, XML, UDDI, WSDL, and SOAP. It is the combination of these protocols that make web services so attractive. Moreover, it is these protocols that fulfill the key requirements of a SOA. That is, a SOA requires that a service be dynamically discoverable and invokeable. This requirement is fulfilled by UDDI, WSDL, and SOAP. SOA requires that a service have a platform-independent interface contract. This requirement is fulfilled by XML. SOA stresses interoperability. This requirement is fulfilled by HTTP. This is why web services lie at the heart of SOA.
For comprehensive and entertaining reading matter on SOA, the author suggests you read:
Service-Oriented Architecture Explained by Sayed Hashimi,
Term of the Week: Service Oriented Architecture by Jim MinatelConsider this. I like to golf. I need new golf clubs. I could buy the equipment needed to build golf clubs and learn how to make my own clubs. However this would be very expensive and my expertise in making clubs would probably cause the initial clubs to be somewhat defect ridden (poor quality of service). Chances are the first time I swing the club, the head flies off of the thing, or the head is on backwards, or some other defect that causes the club to be less than 100% effective and useable.
It is far cheaper and more likely to achieve a higher quality of service if I buy custom clubs from a professional who makes golf clubs for a living. That service provider already has the proper equipment and expertise to make a proper club and fit that club to a specific person.
I'll normally find such a service provider in the yellow pages and through references from other happy clients.
Thus it is with the concept of SOA in the IT world. Find a service provider who has the tools and expertise and request the service from that provider. The service is normally a coarse high-level business function. How the function is done is irrelevant. The requestor simply needs to know, what the service request message must contain, and what the returned completed service request message contains. The provider will have published their service (message contract, service name, and contact information) in a UDDI directory that one can use like a yellow pages. The requestor only needs to lookup the service provider in these 'yellow pages' and adhere to the published contract terms to enter into a service exchange with the provider.
In April 2001, a several technology vendors (including IBM and Microsoft) met in San Jose California for the W3C XML Workshop on Web Services. As a result of that workshop, they published the Web Services Framework paper. In this paper was an outline for a framework for the rapidly evolving XML Protocol’s functions. The Web Service framework is the foundation within which automated, decentralized services can be defined, deployed, manipulated and evolved in an automated fashion. The goal is a scalable, layered architecture, one that can appropriately meet the needs of both simple and extremely robust high-volume deployments.
The result of this ongoing effort is today's WS-I Basic Profile 1.0a Final Specification for Interoperable Web Services. This Basic Profile is used by CICS to provide the core Web Services delivery.
The WS-I Basic Profile consists of implementation guidelines on how core Web services specifications should be used together to develop interoperable Web services. The non-proprietary Web services specifications covered by the Basic Profile include SOAP 1.1, WSDL 1.1, UDDI 2.0, XML 1.0, and W3C XML Schema. The profile identifies and resolves "more than 200 interoperability issues" associated with the use of core Web services specifications referenced in the document. WS-I is currently developing interoperability guidelines for SOAP with Attachments, and for the Basic Security Profile. These efforts will extend the functionality provided by the Basic Profile and will reference existing specifications.
The Profile is how CICS provides the required Web Services. This is all you need to know about the Basic Profile as it relates to this article. You are now a trained 007 on acronyms that you will need to discuss and understand CICS TS 3.1 content.
To quote an InfoWorld
article:
"In a move to modernize its venerable line of mainframe-based CICS middleware, IBM
on Wednesday introduced an updated version of its CICS Transaction Server that enables
corporate IT administrators to extend the product to work better with SOAs
(service-oriented architectures) through Web services. With the release of CICS
Transaction Server for z/OS Version 3.1, administrators can now integrate their
traditional workloads to fully participate in an SOA. This capability should lay the
groundwork for being able to extend older CICS applications to go after fresh business
opportunities.."
CICS participates in two ways in the SOA. The first is CICS Integration and the second Application Transformation.
We will take each in turn and touch on the high-level elements of each participation.
You might wish to review the CICS TS 31 Release Guide for more detailed information on each element.
–
WS-I Basic Profile 1.0a (for interoperability with between providers and requesters using SOAP 1.1)–
WS-Coordination (for extensible coordination framework, and specific coordination of AtomicTransactions)–
WS-AtomicTransaction (for transaction coordination)–
WS-Security (for authentication and encryption of all or part of a message) • SOAP Message Security•
Username Token Profile 1.0•
X.509 Certificate Token Profile– SOAP over HTTP/1.1 and WebSphereMQ ( For flexible deployment dependant on application and IT requirements)
A group of functions is introduced to enhance access to CICS. Major new support is provided for Web services, by an evolution of the functions previously provided as the SOAP for CICS optional feature. These capabilities allow CICS-based applications to be integrated with a Service Oriented Architecture (SOA), enabling them to be exposed as Web services.
Distributed transaction coordination is provided for partners complying with the WS-Atomic transaction specification. Message-level security function that complies with the WS-Security specification will be provided later in this release.
New HTTP capabilities are offered as part of CICS Web support, moving the level of specification supported to HTTP 1.1, and adding outbound HTTP function. Security enhancements are provided to the existing support for Secure Sockets Layer (SSL), including support for the TLS 1.0 protocol.
The following two graphics shows CICS TS 3.1 acting as a SOA Service Provider and a Service Requester. The graphics were copied from the formal IBM CICS TS 31 Technical Overview Presentation (click here to access that presentation in PDF format).
Each Web Service has a file that fully defines the service and importantly how other systems can connect to it and exchange information. Consumers of the service only need this file before building their components and start using the service. This approach enables software developers to use their development environment of choice to focus on the client application, easily selecting and using Web Services available in CICS.
To ensure the easy transformation of an existing CICS application into a Web Service, there is an application development capability supplied called the CICS Web Services Assistant. This support is provided for COBOL, C, C++ and PL/I to automatically convert between XML and their language structures ensuring they are able to participate and deliver immediate value. This is a tool to convert between XML and language structures for COBOL, PL/I and C. CICS Web services Assistant runs in z/OS batch to:
• Generate a language structure and a WSBind from a WSDL
– Top down approach to implement an existing Web service or invoke a Web service
• Generate a WSDL and a WSBind from a language structure
– A bottom-up approach to expose an existing CICS application as a Web service
– Based on Eclipse technology
WSBind is used for data mapping support automatically by CICS at runtime It converts between SOAP messages (typically XML document literal) and language structures.
The second important group of enhancements to CICS TS provides new capabilities for the generation of new applications, and the development of existing applications, using contemporary programming languages and techniques. Support is introduced for totally Language Environment®-enabled Assembler application programs.
A new mechanism is provided for inter-program data transfer, which offers an alternative that is not subject to the 32-KB restriction of the COMMAREA mechanism. All the EXEC CICS Web API commands have been made threadsafe. Support for the XPLink feature of z/OS enables improved performance of applications written in C/C++.
More efficient use of z/OS multiprocessor capabilities is enabled by extension of Open Transaction Environment (OTE) support to use open TCBs.
The Information Center is provided as a plug-in to the Eclipse platform. It brings benefits through commonality with this framework now being employed by many other IBM products.
For those of you wishing to learn more about using CICS in the e-business 'web world', try the documents listed below. Also keep an eye on the 'Architecting e-business Access to CICS' Redbook for a future update to include the new CICS V31 speeds and feeds.
IBM Redbook, Architecting e-business Access to CICS Update, August 2004
IBM Redbook, WebSphere for z/OS Connectivity Architectural Choices, November 2004 - Using CICS, IMS, MQ and DB2 as back-end systems to Websphere.