Components of the solution
Enterprise Service
Tools
Enterprise Service Tools (EST) are a set of features that lets you transform
COBOL- and PL/I-based business programs and applications, thereby exposing them
as Web services.
The Enterprise Service Tools perspective provides views and editors that allow
you to develop service flow projects and EST single-service projects (including
Web services for CICS projects, SOAP for CICS projects, IMS SOAP Gateway
projects, and Batch, TSO, and USS projects).
XML Services for the
Enterprise
The XML Services for the Enterprise (XSE) tools are part of Enterprise Service
Tools, along with other tools, such as the Service Flow features
The XSE capability of Rational Developer provides tools that let you easily
adapt COBOL-based applications so that they can consume and produce XML
messages. This adaptation is accomplished without modifying the existing COBOL
applications; and, more importantly, without modifying other applications that
call the existing COBOL application. A COBOL application must be able to process
XML messages to become a Web service, because XML is the transport used to
describe the Web service request and the parameters that are passed to the
existing application. XSE supports the creation of driver programs that work
with existing CICS or IMS applications.
XSE consists of the following wizards:
- The Create New Service Interface (bottom-up) wizard that generates a
new Web service interface for an existing running program. Typically, this is
called a bottom-up approach, because the existing COBOL application is
at the "bottom" of the new Web service creation process.
This tutorial covers this capability.
- The Create New Service Implementation (top-down) wizard that
generates a new Web service implementation template for a CICS Web Service
runtime. Typically, this is called a top-down approach, because the
COBOL application is created "top-down," starting from the
existing Web service definition (typically, a WSDL file).
- The XML to COBOL mapping wizard and tools that help map existing Web
service interfaces (or an XML data definition) to the existing COBOL program.
- The Batch processor that allows you to generate the Web service
interface in unattended (batch) mode. The Batch processor currently supports
the bottom-up Web services creation with compiled XML message conversion
technology at runtime. The functionality provided by the Batch processor is
equivalent to that of the Create new service interface (Bottom up) wizard for
compiled XML conversion.
This tutorial focuses on the bottom-up approach. In this scenario, you generate
a Web service description and runtime-specific XML message processing artifacts
from a high-level language data structure, as shown in Figure 1. This enables
you to expose an application program as a service provider.
Figure 1. Components of the bottom-up approach
These are the components shown in Figure 1.
-
WSBind. This is the Web service binding file used by CICS Transaction
Server for z/OS® to perform the mapping between application data
structures and XML based SOAP messages. This is generated when the Web
Services for CICS converter type is specified.
-
Web Services Description Language (WSDL) file. This is an XML-based
language for describing a Web service and how to access it.
These are generated only if you choose the Compiled XML Conversion option
instead of Interpretive XML Conversion alternative:
-
Web Services for CICS Driver Program. This is the COBOL program that
determines how the input and output converters that interact with the existing
COBOL application.
-
CICS SOAP Inbound XML converter. This is a COBOL program that takes
an incoming XML document and maps it into the corresponding COBOL data
structure that the existing COBOL application expects.
-
Outbound XML converter. This is a COBOL program that takes the COBOL
data results returned from the existing COBOL application and maps them to an
outbound XML document.
-
Inbound XML schema definition (XSD). This is the XML schema that
describes the incoming XML document for processing by the input converter.
-
Outbound XML schema definition (XSD). XML schema that describes the
outgoing XML document produced by the output converter.
CICS Web Services
Previous support for Web services in CICS Transaction Server for z/OS was
provided through the SOAP for CICS feature. This support has now been fully
integrated into CICS Transaction Server for z/OS, as shown in Figure 2. With
this new release of CICS, applications can now act in the role of both service
provider and service requester, where the services are defined using WSDL. The
infrastructure provided as part of CICS Transaction Server includes a
distributed transaction coordination capability compatible with the WS-Atomic
Transaction specification.
The support for Web services includes the CICS Web Services Assistant
Integration, a batch utility that can help you:
- Transform an existing CICS application into a Web service
- Enable a CICS application to use a Web service provided by an external
provider
The assistant can create a WSDL document from a simple language structure, or a
language structure from an existing WSDL document. It supports COBOL, C/C++, and
PL/I. It also generates information used to enable automatic runtime conversion
of the SOAP messages to containers and COMMAREA, and vice versa.
The XML Services for the Enterprise capability of Rational Developer for
zSeries extends and complements this by providing conversion for COBOL types and
constructs which are not covered natively by CICS. For example,
OCCURS DEPENDING ON and
REDEFINES used in data description entries are not
supported by the CICS Web services assistant.
Figure 2. CICS Web services support
Overview of development tasks
This tutorial creates a CICS Web Service from an existing COBOL/CICS program
(LAB3POT) that is invoked by another one (LAB3CLI), as shown in Figure 3.
Figure 3. Structure for CICS Web service
The COBOL program LAB3CLI sends a 3270 map and asks for a customer number. If
the customer number is valid, it invokes another COBOL program named LAB3POT
using EXEC CICS LINK via CICS COMMAREA. LAB3POT receives the customer number,
reads a KSDS VSAM dataset, and sends back to the COMMAREA the data retrieved
(Name, last name and address). When LAB3CLI receives the control it display the
data received back to the 3270 screen.
Because the objective here is to learn CICS Web services, this example is quite
simple, using VSAM instead of IBM® DB2® to simplify the deployment
of the generated artifacts.
The idea is to create a WSDL and use the Web Services Explorer tool, which will
invoke the server using CICS Web services without making any change in the
existing server program, as shown in Figure 4.
Figure 4. Invoke the server
These are the main tasks that you will perform:
- Create a Project to hold the assets.
- Import the COBOL program into a Web Services for CICS Project .
- Generate the converter driver, input and output. converters, XML schemas,
WSDL, and CICS required file (WSBind).
- Use the Web Services explorer to test the CICS-based Web service.
| 
