Deciding the Correct CICS Web Integration Option
By
Donald Fowler, MCE, Inc
November 2005
Over the last nine
or ten months, CICS-L has had some questions posted related to what CICS e-commerce1 integration option might be used. Most of these
queries have been along the line of “I’ve got to tie a xyz computer system to
CICS. Can I do it with this CICS integration option?”
The answer is
almost always ‘yes’ - you can do it. However, maybe the question should be
rephrased. Such as, “Which CICS option makes the most sense for my organization and
application requirements?”
And folks, the
option making sense for an organization may not always be the cheapest solution. Much
depends on what problem you are trying to solve. You problem is not making computer xyz
tie into CICS. Your problem is that computer xyz needs to use some resource on the
mainframe and do it with data integrity and reasonable performance.
The answer to that
problem is a careful evaluation of the pros and cons of each CICS options for e-commerce
integration.
IBM recently
delivered a paper, Delivering
e-business To CICS: Strategic Options, that addresses the general requirements each
option can address. This article is an extension on that paper.
What criteria would one use to
evaluate each option?
Here is a set that covers the
more critical areas that one should be concerned about when determining the
‘right’ option. We will include
much under the term SOA (Service oriented Architecture). For a good description of SOA as
it pertains to CICS, read our prior paper on SOA And CICS.
Please note that we are writing about CICS TS 3.1 and above and MQ for z/OS V6
and above. Do not assume earlier releases of these products will
match the narrative nor decision table in this article.
Capabilities – Support for
synchronous invocation, which means make a request and wait for a response. Alternately in
an asynchronous invocation approach, generate an immediate response confirming that the
request has been received and continues processing as soon as the confirmation response is
received. Inbound and outbound support provides the ability to be either the server or the
client (provider or requester).
Security – The most common security requirement is to authenticate end users
and middle-tier servers. Simple user ID and password authentication is still widely used,
although x.501 client certificates, SSL – TSL Payload encryption, and other schemes
are today’s implementations.
Transactional Scope – The capability of a given access
option to support local transactions (one-phase commit), enabling a number of updates
performed by CICS applications to be processed as a single unit of work; or global
transactions (two-phase commit), enabling an external server to coordinate updates
performed by CICS with updates to local resources held by that server.
Interface – The access option needs to
support the CICS program interface either directly or by using an adapter without imposing
additional restrictions. The interface encompasses the data elements, the code page and
the size of the message. For example, with CICS TS 3.1, the old COMMAREA restriction of
32KB is replaced with Containers and Channels providing almost unlimited storage.
Coupling – Some access options are described
as tightly coupled, while others are described as loosely coupled. Tight coupling implies
that the client and server share many assumptions and dependencies. In general, access
options that are loosely coupled are more robust. Planned or unplanned outages, software
upgrades and other operational events have less impact on their ability to interoperate,
while tightly coupled systems are optimized for run-time performance and operational
control. Further differences are that loosely coupled implies that:
1)
client and CICS may be in disparate platforms,
2) client and
CICS may process concurrently,
3) client and CICS do not have to be upgraded at the same time.
Performance – Response time and cost per
transaction are important aspects of performance in a production system. Most e-business
solutions require additional elements (such as connectors, adapters, encrypted data flows or
new data stream architectures), which are less optimized, and impose an overhead on the
execution of the target business program. This overhead might be characterized by
expressing it as a percentage of the base execution cost of the target program, which is
typically one to two million-processor instructions for a CICS/COBOL/VSAM terminal-driven
program.
Skills
Required – The user
skills required to implement any particular solution could vary. Some solutions provide
assistant utilities to take existing components and build the web equivalents. Other
solutions require significant knowledge of a programming language and industry standards
of web architectures and protocols.
The majority of access options
support synchronous invocation, meaning that a client request receives a single reply from
CICS and the client waits for the reply. In the alternative approach, known as
asynchronous invocation, CICS generates an immediate response confirming that the request
has been received, as well as one or more deferred responses containing replies to the
original request. Typically, the client system continues processing as soon as the
confirmation response is received and does not wait for the deferred response. Inbound and
outbound support provides the ability to be either the server or the client (provider or
requester).
The use of
cipher suites (up to 256-bit AES levels) and SSL’s Transport Security Layer provide
multiple encryption capabilities for the message payload.
The use of
simple user ID and password authentication to authenticate end users and middle-tier
servers is widely used, and x.501 client certificates are widespread.
Whichever
technique you adopt, the user’s credentials must eventually be mapped to an external
security manager (ESM) user ID to support the authorization and accounting requirements
that normally apply to CICS applications.
CICS applications have
traditionally passed parameter data using the EXEC CICS LINK (API) application programming
interface specifying a communications area (COMMAREA). The COMMAREA is an allocated area
of memory that contains the typed parameter data values in the structure defined by the
applications.
Historically, CICS applications
were highly optimized to be memory efficient and were easily able to pass the parameter
data required within the size constraints imposed by the CICS API on COMMAREA memory size.
Where large quantities of shared data were required between applications’ components,
managed shared systems resources were utilized (such as Temporary Storage.)
Now, modern CICS
applications are required to process large quantities of structured parameter data, in
both XML and non-XML formats, as the integration of CICS applications with the elements of
enterprise solutions outside the bounds of the CICS environment becomes the norm.
The consequence of
extending CICS applications to new enterprise solutions is that the constraints caused by
COMMAREA size on the system become a major roadblock.
CICS Transaction
Server V3.1 introduces a new approach provided by two new data passing capabilities known
as Containers and Channels.
An individual
Container is analogous to a COMMAREA but one that is free of length constraints imposed
through the old EXEC CICS API.
A Container is a
named reference to a particular data structure that exists within a collection of data. A
Container may be any size in length and can contain data in any format required by the
application. An application can be associated with any number of Containers as required. A
Channel is a named reference to a collection of Containers unique to an application.
Also the ability to
run under the OTE TCB as a separate operating system task can add a great deal of
flexibility to how you structure new approaches to e-commerce oriented applications.
Transactional scope deals with the aspects of recoverability of the business transaction and how the states of the components and data objects of a transaction are left when something goes wrong.
One will hear the term “Atomic Transaction” in the Web Services world.
Atomic
transactions are "all or nothing." They either work or they don't – they're
never left incomplete. For example, an online sale may involve the following steps:
The transaction can
end in one of two ways:
(1) in a commit and everything is saved; or
(2) if any step within the transaction fails, the
effects of all preceding steps are rolled back or undone. For example, if the shipping
database can't be updated, the charge isn't made and the sale database isn't updated.
The actions
taken prior to commit are only tentative (i.e., not persistent and not visible to other
activities). When an application completes, it requests the identified transaction
coordinator to determine the outcome for the transaction. The coordinator determines if
there were any processing failures by asking the participants to vote (successful
completion or abort).
If the
participants all vote that they were able to execute successfully, the coordinator commits
all actions taken. If a participant votes that it needs to abort or a participant does not
respond at all, the coordinator aborts all actions taken. Commit makes the tentative
actions visible to other transactions. Abort makes the tentative actions appear as if the
actions never happened.
The
WS-Coordination Specification defines an extensible framework for defining coordination
types. This specification provides the definition of an atomic transaction coordination
type used to coordinate activities having an "all or nothing" property.
Atomic
transactions commonly require:
· A Transaction Coordinator
· A high-level of trust between participants, and
· An architecture design of being short in duration.
The Atomic Transaction specification defines protocols that enable existing transaction processing systems to wrap their proprietary protocols and interoperate across different hardware and software vendors.
A CICS Transaction
(or local transaction) refers to the capability of a given
access option to support local transactions (one-phase commit), enabling a number of
updates performed by CICS applications to be processed as a single unit of work.*
*If the CICS
Transaction Gateway, Websphere Application Server, and CICS reside within z/OS, RRS, as
the Transaction Coordinator, can be used to provide full two-phase commit.
The Local Transaction
refers to transactions that are managed internally to a resource manager without the
involvement of an external transaction manager.
A Global
Transaction is a two-phase commit, enabling an external server to coordinate updates
performed by CICS with updates to local resources held by that server.
Some access options
are described as tightly coupled, while others are described as loosely coupled. Loosely
coupled frameworks allow individual nodes in a distributed system to change without
affecting or requiring change in any other part of the system.
Tight coupling
implies that the client and server share many assumptions and dependencies.
Loose coupling is
not a precise concept but refers to several possibilities:
· • The client and CICS may process concurrently.
· • The client might use dissimilar technology from CICS.
· • The client need not be maintained or upgraded in step with CICS.
In general, access options that are loosely coupled are more robust.
Planned or unplanned outages, software upgrades and other operational events have less impact on their ability to interoperate, while tightly coupled systems are optimized for run-time performance and operational control.
Response time
and cost per transaction are important aspects of performance in a production system.
Let’s be
honest, it took IBM twenty-five years to get the most out of the 3270 green screen
applications. And in those days, IBM owned all of the proprietary technologies involved.
In
today’s modern world of open systems, performance is last in the list of
characteristics of functions. You are not going to get the same level of performance from
a SOA web services application then a corresponding 3270 application.
CICS has
always sought to minimize these and is highly optimized for traditional styles of access,
such as 3270 terminal access over a System Network Architecture (SNA) network.
However, most
e-business solutions require additional elements (such as connectors, adapters, encrypted
data flows or new data stream architectures), which are less optimized, and impose an
overhead on the execution of the target business program.
Performance today should be thought of in terms of consistent responsiveness at reasonable resource utilization. Gone are the days of trying to wring out the last millisecond from the user response time.
Do not attempt to
apply a performance paradigm from the twentieth century in today’s SOA world. It will
not fly and you will be looked at as a hindrance to
progress. This is not to imply that your knowledge of performance and tuning are archaic.
What it means is that the days of wringing the last ounce from a resource are going away.
The absolute best response time in most cases will be replaced by the most reasonable and
consistent response time at an acceptable cost.
SOA means getting beyond the usual
object-oriented thinking in programming, as Microsoft's Ron Jacobs, product manager,
platform architecture, has said in Web seminars. SOA differs from the more general
client-server model in its emphasis on loose coupling between software components and its
use of separately standing interfaces.
SOA means thinking of a set of
independently running services, loosely bound to each other via event driven messages.
Call it the aggregation of components satisfying a business driver.
Reusing code and maintaining best
practices libraries for application development is an aspect of SOA thinking.
In a larger sense, SOA means the hype
about business agility is more than a marketing construct. Given the mind-boggling
complexities in heterogeneous environments (and that's no slight to the Java world)
development teams need to build on architectures that can support swift rollouts of new
applications.
Skills will need to be updated across
the board by all IT staff members regardless of architecture you embrace. Some implementations will require more new skills
than others.
Web
services solutions and service-oriented architectures (SOAs) include service requestor
(client) and service provider (server) implementations, which communicate via SOAP (XML
messaging). Web Services Description Language (WSDL) service descriptions provide the glue
between requestors and providers. Optionally, a service broker, for example a Universal
Description, Discovery and Integration (UDDI) registry, might be involved. The service
descriptions and interactions as well as XML schemas for shared data have to be modeled.
Implementations have to be designed, developed, deployed, and tested. Now, the question
is: how does a project team get there?
Any
development project runs through different phases, requiring different skills and
collaborations throughout its lifecycle. Web services are no exception here. Depending on
the methodology used in your environment, you probably have already come across generic
terms such as the following:
Project
Manager
Has the
overall management and leadership responsibility for the project team. Defines and tracks
project plan and work breakdown structure.
Business
Analyst
Harvests
the business users' functional requirements and provides domain knowledge to the team.
Must understand the business language and have industry and domain skills.
Architect
Technical
leader of the project. Develops the logical and physical layout (structure) of the overall
solution and its components.
Developer
A.k.a.
code warrior. No need to introduce this role here!
Security
Specialist
Responsible
for the definition of security guidelines (policies) and the implementation of security
means adhering to these guidelines.
System
and Database Administrator
Performs
installation and ongoing maintenance work on hardware, operating and database systems, and
middleware.
New
and additional roles you can see on Web services projects:
SOA
Architect
Responsible
for the end-to-end service requestor and provider design. Takes care of inquiring on and
stating the non-functional service requirements.
Service
Modeler
Applies
data and function modeling techniques to define the service interface contracts including
the schemas of exchanged messages.
Process
Flow Designer
Investigates
explicit, declarative service orchestration (aggregation, composition) possibilities. An
optional role.
Service
Developer
J2EE
developer familiar with Web services concepts and XML. Develops service interface and
implementation (provider side) and service invocation code (requestor side).
Interoperability
Tester
Verifies
that the developed requestor and provider implementations interoperate seamlessly and
ensures Web Services Interoperability (WS-I) conformance.
UDDI
Administrator
Defines
how the generic UDDI data model is customized and populated. An optional role.
Each of
these roles requires unique skills. Identifying
roles helps, but finding the right people with appropriate skills is crucial. Don't
underestimate the effort. Technologically, Web services usually are rather lightweight and
simple; this is part of their power. With Web services, heterogeneous system islands can
be opened up for collaboration easier than ever before. However, along with these new
possibilities come new sources of errors. Web services projects may be a new kind
of project for your organization, but chances are they will not be a simpler kind
of project.
A fairly comprehensive table of roles to skills is contained in the Web Services project roles paper on IBM Developerworks website. Use that Skills table to complete the skills portion of the decision table in this paper.
The following table shows the main architectures and transports
available to the CICS environment. You can use this table as a basis for completing your
own decision table and add any other items deemed important to you or your organization.
Standard
Architecture |
Performance |
|||||||
SOAP |
Synchronous
(HTTP) Asynchronous (WebSphere MQ) Inbound and outbound |
User ID + password SSL - TSL
|
CICS Transaction |
XML
in a Container |
Low |
Low |
||
JCA |
32kb message
limit Inbound Only Synchronous
and Asynchronous |
User ID + password SSL |
Depends on Topology: Global
transaction |
COMMAREA + CTG |
Medium |
Scalable - |
High |
|
Enterprise Java
Beans (EJB) |
EJB state
management Inbound and
outbound Synchronous |
EJB security
roles SSL |
CICS transaction
Global
transaction |
EJB High
(session bean) |
High |
Scalable |
Medium |
|
Standard Transport |
|
|
|
|
|
|
||
Websphere MQ |
Inbound and
outbound Asynchronous Assured
delivery |
User ID + password SSL |
CICS Transaction |
WebSphere MQ API
or COMMAREA |
Medium |
Scalable |
Medium |
|
HTTP |
Inbound and
outbound Synchronous |
User ID + password SSL |
CICS Transaction |
CICS WEB API |
Medium |
Scalable CICS TS 3.1
and Above |
Low |
|
CICS sockets API |
Inbound and
outbound Synchronous
and Asynchronous |
User ID + password |
CICS Transaction |
CICS sockets API |
High |
Good Low level
Interface |
Medium |
|
1 e-commerce is the exchange of goods and services by means of the Internet or other computer networks.