2. Please Note
IBM’s statements regarding its plans, directions, and intent are subject to change
or withdrawal without notice at IBM’s sole discretion.
Information regarding potential future products is intended to outline our general
product direction and it should not be relied on in making a purchasing decision.
The information mentioned regarding potential future products is not a
commitment, promise, or legal obligation to deliver any material, code or
functionality. Information about potential future products may not be incorporated
into any contract. The development, release, and timing of any future features or
functionality described for our products remains at our sole discretion.
Performance is based on measurements and projections using standard IBM
benchmarks in a controlled environment. The actual throughput or performance
that any user will experience will vary depending upon many factors, including
considerations such as the amount of multiprogramming in the user’s job stream,
the I/O configuration, the storage configuration, and the workload processed.
Therefore, no assurance can be given that an individual user will achieve results
similar to those stated here.
2
3. Abstract
CICS provides a rich set of connectivity options for SOA integration
including CICS web services, JCA and CICS sockets. The best
choice will depend on your application architecture, existing
middleware environment and required transport protocols. Other
considerations include development languages, client server
coupling and whether requests are to be synchronous or
asynchronous. This session will outline the key SOA deployment
scenarios used by customers today and the best practice choice of
technology in each case. Also covered will be references to
supporting material including redbooks and articles.
This session will also cover recent enhancements to CICS web
services. Data mapping for SOAP and JSON now supports UTF-16
data types, as well as additional COBOL data clauses. Also CICS
web services definitions can now be managed through CICS
bundles and deployed as part of a cloud workload.
3
5. Choice factors
Application interface
• Operations, input/output messages, message formats, message
exchange patterns and transport protocols
Client/server coupling
• Tightly or loosely coupled?
Synchronous or asynchronous invocation
• Request/reply or event-based?
Application development tools
• Depends on preference or what you already have
Security
• Does choice support your security requirements?
Transactional scope
• 2PC or not 2PC (that is not the only question!)
High availability and scalability
• Who doesn’t want high availability and scalability?
5
6. SOA Connectivity Options
1. Web services over SOAP
2. JCA – CICS TG or WOLA
3. CICS Web Support
4. Messaging
5. CICS sockets
6
8. CICS essential design concepts
Pseudo-conversational programming
Communication area: COMMAREA, Channels & Containers
Program-to-program communication
8
9. Problems with raw data communication
Data must be accessed using its relative position
Modifications to fields require application changes
Addition of new fields affect all existing users
Data requires a separate document to describe fields
Data is not portable therefore platform dependent
9
10. Introduction to XML
Extensible Markup Language (XML), is owned by the World
Wide Web Consortium (W3C).
XML is an open standard protocol that provides a mechanism to
create and define a meta-language that can be used to structure
information.
XML is extensible in that there are no pre-defined tags, as in
HTML. Each set of users defines tags that have meaning to
them and their peers, such as within a business, across an
industry, or across multiple industries.
XML is used to create new Internet languages.
10
11. Two models of CICS SOA integration
CICS TS
Web
service
Client
CICS Program
Business
logic
B
Requester
connector
Web
services
end-point
Service Provider
D
Integration
logic
I
A
SOAP
CICS TS
Web
service
Client
CICS
Web
services
support
Integration
logic
Data
access
Business Function
DI
Business
logic
B
Requester (Service Provider)
SOAP
A
CICS Web Services
CICS Transaction Gateway
11
13. Exposing CICS application as Web service
Direct service call approach
Web Services Clients (examples):
• WebSphere BPEL process (Process Choreography)
• WebSphere Datapower
• .NET assembly
• WebSphere MQ client
• Another program in CICS (invoke Web service)
• Anything that can invoke a Web Service !
CICS TS
Web
service
Client
CICS
Web
services
support
Integration
logic
Data
access
Business Function
DI
Business
logic
B
Requester (Service Provider)
SOAP
A
15. Standard architecture – Web services
With CICS TS V3.x a CICS application can be Web service provider or consumer
• HTTP or MQ transport
Development using CICS supplied utilities or Rational Developer for System z (RDz)
• Used to generate the data mapping
Runtime
• SOAP envelope removed by a message handler in the Web services pipeline
• COMMAREA or container built by “data mapper”
EXEC CICS INVOKE WEBSERVICE|SERVICE API for outbound support
Client
A
CICS Web support
WebSphere MQ Trigger Monitor
Pipeline
CICS or custom data mapping
CICS TS
SOAP
DB
Proxy
15
17. CICS web services overview
Web services terms and concepts available in CICS TS
Web services architecture:
• Service provider
• Service requestor
• Service registry
WSDL
SOAP messages
Message handlers and pipelines
PIPELINE and WEBSERVICE resource definitions
17
18. Bottom up – Start with a language
structure and convert it into a form
usable as a CICS web service
Approach to web services development (1 of 2)
Top down – Start with a WSDL
document and convert it into a form
usable as a CICS web service.
Web service
requester
Web service
provider
CICS as provider CICS as requesterCICS
Bottom
up
Top
down
WSDL
Language
structures
Provider – means that
CICS is the host of the
web service which is
being invoked from
elsewhere.
Requester – means
that CICS is the user
of a web service
provided elsewhere
19. Approach to web services development (2 of 2)
Existing
business application
(COBOL, C, C++, PLI)
New service: WSDL
New business application
(COBOL, C, C++, PLI)
Existing service
description WSDL
Existing service
description WSDL
Existing
business application
(COBOL, C, C++, PLI)
Bottom-up Top-down Meet in the middle
Generate Generate Map
and
Generate
20. Rational Developer for System z
Web Services and XML development
• Offers the ability to create, view, edit and validate WSDL,
document-type definitions (DTD) and XML schemas, transforms
XML documents into text, HTML, or other XML document types.
• Integrates relational databases and XML.
• Generates COBOL adapters and CICS TS V3 WSBind and
COBOL artifacts for converting between Web Service Definition
Language.
The CICS service flow feature provides components that extend CICS
Transaction Server by providing adapters that exploit CICS interfaces
to invoke the CICS terminal-oriented transactions and COMMAREA
programs required by the web service generated from the service flow
project.
21. Client
SOAP/HTTP
WAS+CICS connector
CICS Web ServicesSOAP/HTTP
Security and Management for CICS Web services
DataPower
XI52
DataPower
XI52
CICS
CICSApplication
MQServer
CICS
Brdg
MQClient
COBOL/MQ
Client
SOAP/HTTP
DataPower provides Web service enablement
Using DataPower XI52
21
22. Summary: CICS Web Services
Web services in CICS builds on established CICS concepts and
technologies such as pseudo- conversational transactions and
program-to-program communication via COMMAREAs (or channels
and containers)
Web services introduce new concepts and technologies such as XML,
SOAP, and WSDL
Web services involve a combination of CICS resource definitions
(PIPELINE, WEBSERVICE, URIMAP)
CICS TS provides utilities for converting existing CICS applications
into web services
IBM provides other tools to help develop web services
22
24. Exposing CICS applications as Web service
Connector approach
CICS TS
Web
Service
Client
CICS Program
Business
logic
B
Other/Any
CICS
Transaction
Gateway
CICS TG
WebSphere
Application
Server Web
Service
Support
JEE Server
J
C
A
D
CICS Transaction Gateway JCA (J2EE Connector Architecture) Resource Adapter
• Different topologies and transports are supported
Development using Rational Application Developer (RAD)
• Used to generate J2C bean and records
Runtime
• ECI (External Call Interface) used for calling COMMAREA or container based programs
• J2C bean performs data conversion and formatting
•
CICS TG V7.2 supports direct .NET connectivity with ECI V2
CICS TG V8.0 provides Open Integration with any JEE Server compliant with J2EE V1.4 or higher
A
26. J2EE Connector Architecture (JCA)
JEE Server
(e.g WebSphere Application Server)
Application
Component
(e.g EJB)
Resource Adapter
(e.g CICS ECI resource
adapter)
Enterprise Information
System (e.g CICS)
System Contracts
Container-Component
Contract
Common Client
Interface (CCI)
EIS Specific
Interface
ConnectionFactory cf =<JNDI lookup>
Connection connection =cf.getConnection();
Interaction interaction
=connection.createInteraction();
interaction.execute(<input and output data>);
interaction.close();
connection.close();
Resource adapters provided by CICS TG
ECI (cicseci.rar)
EPI (cicsepi.rar)
Connection
Management
Transaction
Management
Security
Management
26
27. CICS Transaction Gateway Topologies
Whitepaper: Integrating WebSphere Application Server and
CICS using the CICS Transaction Gateway
http://www.ibm.com/software/htp/cics/ctg/zos/
CICS
Network
HTML
WebSphere
Application Server
and CICS TG
on System z
WebSphere
Application Server
and CICS TG on a
distributed platform
WebSphere
Application Server
on a distributed
platform
CICS TG
z/OS
Topology 1
Topology 3
Topology 2
System z
Service
Consumer SOAP
27
30. CICS messaging support
Web
Service
Client
Other/Any
WebSphere
Application
Server Web
Service
Support
WAS
J
M
S
A
WebSphere MQ
Trigger Monitor
CICS MQ Bridge
CICS TS
DB
MQ Trigger Monitor
• Starts CICS program that reads the message queue
• Program can be MQ-aware or COMMAREA-based program
CICS MQ Bridge
• Transfers the message to the unchanged CICS business logic.
• Transfers the output message to the Reply_To_Queue
Inbound and outbound
Medium coupling
Asynchronous, with almost-synchronous capabilities
Assured delivery
31. HTTP / Atom / REST
Inbound and outbound
Medium coupling
Synchronous
Medium QoS
31
32. CICS Sockets
Inbound and outbound
Very tight coupling
Synchronous
Limited QoS
Use only when remote client/server only supports TCP/IP sockets
communication.
32
34. New in CICS TS V5.2
Easier Interaction with Mobile Devices & Gateways
• Integration of CICS TS Feature Pack for Mobile Extensions
JAX-WS and JAXB support in Liberty profile
COBOL Data mapping enhancements
• Arrays of characters are mapped as Strings
• OCCURS DEPENDING ON and OCCURS INDEXED BY
supported in COBOL
CICS Explorer and cloud support for web services
• WEBSERVICE definition
• PIPELINE configuration
34
35. Easier Interaction with Mobile Devices & Gateways
JSON RESTful web service scenarios
JSON request/response web service scenarios
• Web services assistant programs
• Linkable interface
– Equivalent to EXEC CICS XMLTRANSFORM allows application
programs to process JSON data
Support for Liberty profile JAX-RS and JSON features
35
36. New in CICS TG V9.1 open beta
Mobile support
• JSON web services
IPIC enhancements
• heartbeat exploitation
• connections managed independently of Gateway lifecycle
Security enhancements
• compliance with NIST SP800-131A
• SSL for .NET applications
36
37. 37
CICS TG for z/OS V9.1 open beta - JSON Web
Services
Technology aligned with
z/OS Connect
39. More Information
Redbook/Whitepaper Title Publication N° Last Update
Architecting Access to CICS within an SOA SG24-5466-06 March 2012
Options for Integrating CICS applications in an SOA
WSW11339-USEN-00 Sept 2007
Implementing CICS Web Services SG24-7657-00 Nov 2008
Application Development for CICS Web Services SG24-7126-00 May 2006
Securing Access to CICS Within an SOA SG24-5756-01 Dec 2006
Securing CICS Web Services SG24-7658-00 Dec 2008
WebSphere for z/OS to CICS and IMS Connectivity Performance REDP-3959-00 May 2006
CICS Web Services Performance SG24-7687-00 2009
Deploying CICS Web services to preserve IT investments in the Banking Industry WSW14002-USEN-00 Dec 2007
Integrating WebSphere Application Server and CICS using the CTG WSW14013-USEN-00 March 2008
CICS Transaction Gateway for z/OS V6.1 SG24-7161-00 May 2006
Developing Connector Applications for CICS SG24-7714-00 Arpil 2009
Increase the value of CICS applications with WebSphere MQ WSW14006-USEN-01 Feb 2008
WebSphere MQ for z/OS Highly Available System Design SupportPac MD17 Jan 2006
41. We Value Your Feedback
Don’t forget to submit your Impact session and speaker
feedback! Your feedback is very important to us – we use it to
continually improve the conference.
Use the Conference Mobile App or the online Agenda Builder to
quickly submit your survey
• Navigate to “Surveys” to see a view of surveys for sessions
you’ve attended
41
I have grouped these options into two.
First standard architectures and interfaces provide comprehensive options and support in CICS and tools.
1. SOAP (Simple Object Access Protocol)
2. JCA (J2EE Connector Architecture)
3. Java RMI (Remote Method Invocation)
Second, standard transports are typically used for applications that require greater control of the protocol and as such use transport specific APIs and assume more responsibility for systems management and recovery.
4. JMS (Java Messaging Service)
5. HTTP (HyperText Transfer Protocol)
6. TCP/IP sockets
The highlighted options are the ones that we focus on today.
In this session we concentrate on the first approach which I refer to as the ‘connector approach’. The most commonly used connector is the CICS Transaction Gateway.
In my next session, we will look more closely at the 2nd approach which is a direct Web service call to CICS.
The choice of architectural approach is a key decision because it may affect the costs of developing e-business applications and their long term value. Business factors, such as the availability of skills, may be just as significant as technical factors influencing this decision. It’s important to recognize that there is no single right answer, just as there is no right programming language for all applications.
Some technical factors to take into account include…
Security
Transactionality
Performance and scalability
This is an area in which the Design Centers can help you make decisions on what’s the best approach for you.
The CICS Web services support enables CICS programs to be a SOAP Web service provider or service requester.
Supports HTTP and MQ
The definition of the SOAP service is defined in a WSDL (Web Services Definition Language) file.
Typically tools are used to import the WSDL file and generate a proxy for the e-business client to use to construct and send the SOAP message.
Concept of pipeline for processing SOAP message (see later)
Adapter runs in CICS (SOAP/COMMAREA conversion)
Normally generated
Web services support is based on loose coupling
Any Web service client
i/f defined in WSDL
Can change implementation without changing client (so long as messages/operations stay the same)
If these change, open process for updating client, re-generate WSDL, recreate client proxy code
But lacks the maturity and some of the QoS of JCA/CTG solution. But these are coming (see subsequent charts)
Link: closer look at how it works
The XI50z can be used in conjunction with CICS Web services to help secure the services and to offload expensive operations by processing the complex part of XML messages (such as an XML signature) at wirespeed. Note that this model works also with WebSphere based services, these then may connect to CICS using a connector such as the CICS Transaction Gateway.
The XI50z can be used for Web service enablement. It can convert a SOAP message into a COBOL COMMAREA and send the binary format message to CICS over MQ.
Both of these methods are being used by our customers today.
RDz
This slide is just a reminder that the Java architected way of accessing information from Java applications is using JCA, which for CICS means the CICS TG.
Explain strengths of connector solution and using CIC STG.
The CICS TG has been around for quite some time. Its roots go back to 1989, so the code is very stable and highly optimized.
The CICS TG provides a method of accessing programs running under CICS from programs running outside CICS. These programs can be written in many different languages, and can be running on several different platforms. One of the most popular languages using the CICS TG to access programs running in CICS is Java. The Java architected way of accessing EISs (Enterprise Information Systems) is using a standard called the Java 2 Connector Architecture (commonly referred to as JCA or J2C).
When using the JCA, you would normally have an Application Server such as WebSphere Application Server act as a Web Service provider and receive Web Services requests. The Application Server would then give the Web Services request to a program running the in the Application Server. The application program would take the information in the Web Service request and format the data for invocation of a CICS program via the CICS TG. When the data was return via the CICS TG, an application program would format the data into XML and the Application Server would return the response to the Web Service requester.
Wizards are available in Rational Application Developer, WebSphere Integration Developer, and WebSphere Developer for zSeries to generate the objects that do any necessary conversion and data formatting before invoking the CICS program via the CICS TG.
Additionally, these tools can also take the generated objects and expose them as Web Services.
Due to this tool support, exposing a CICS program as a Web Service via the CICS TG requires little if any coding.
Key points:
Standard for connecting from J2EE world to EIS
EIS provides resource adapter (in case of CICS, provided by CICS TG – ECI and EPI)
Resource adapter expose common interface to applications (CCI) - comprised of two sets of classes, generic classes applicable to any EIS, and a set of classes specific to the EIS (in this case CICS specific classes).
Main advantage of JCA, however, over other connectors are the system contracts
A connection-management contract
Provides a consistent application programming model for connection acquisition and enables a J2EE application server to pool connections to a back-end EIS.
• A transaction-management contract
Defines the scope of transactional integration between the J2EE application server and an EIS.
• A security-management contract
How security context is passed. Both container-managed sign-on and component-managed sign-on are supported.
Link: Platform/topology choices
The JCA system contracts are the key to the qualities of service provided by WebSphere Application Server and CICS ECI resource adapters. They provide the mechanisms by which the management of connections, security and transactions are performed.
However, the qualities of service depend on the topology in use. The three topologies, shown in this chart, are:
• Topology 1. WebSphere Application Server and the CICS TG are both deployed on a distributed platform.
• Topology 2. WebSphere Application Server is deployed on a distributed platform and CICS TG is deployed on an IBM z/OS system.
• Topology 3. Both WebSphere Application Server and CICS TG are deployed on an IBM System z platform.
In this session we will focus on topologies 2 and 3 because these are the most common ones and they offer the best qualities of service.
The JCA system contracts are the key to the qualities of service provided by WebSphere Application Server and CICS ECI resource adapters. They provide the mechanisms by which the management of connections, security and transactions are performed.
However, the qualities of service depend on the topology in use. The three topologies, shown in this chart, are:
• Topology 1. WebSphere Application Server and the CICS TG are both deployed on a distributed platform.
• Topology 2. WebSphere Application Server is deployed on a distributed platform and CICS TG is deployed on an IBM z/OS system.
• Topology 3. Both WebSphere Application Server and CICS TG are deployed on an IBM System z platform.
Topology 4- WAS, CICS and db2 – all on same LPAR, bidirectional connectivity using WOLA
This chart shows another implementation of the indirect approach. This time messaging is used rather than a synchronous connector.
When using JMS to service-enable a CICS application, an application server acts as a Web Service provider and receives Web Services requests. The JEE application takes the information in the Web Service request and formats the data as a message (normally using the message type JMSBytesMessage) and sends it to a CICS program via a message queue.
The WebSphere MQ trigger-monitor program supplied by CICS starts the CICS program that will read the queue. The CICS program may be an MQ-aware program, in which case it uses the MQ native APIs to receive the message, or it may be a normal COMMAREA-based program, in which case the CICS MQ bridge maps the incoming message to the expected COMMAREA.
Using JMS in this way provides a choice between the pseudo-synchronous request-and-response style of CICS integration, or the fire-and-forget style, or a mixture of both.
Don’t forget that JMS can also be used as a transport mechanism with the CICS Web services support.
Linkage: So what are the key considerations and best practice for using with JMS?