CICS Web Services Notes

You might also like

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 9

Table of Contents

Defining a CICS Web Service:.................................................................................................................1


CICS web service using COBOL...............................................................................................................2
Process to define a Web service interface.............................................................................................3
Process of identifying a compatible Web Service Description Language...............................................4
Defining WSDL Structure.......................................................................................................................5
Process to create Web Service Bindings using Cobol and mainframe....................................................6
Steps involved in Registering a web service in CICS using RDO..............................................................7

CICS (Customer Information Control System) is a transaction processing system developed by IBM for
mainframe computers. CICS provides a robust environment for developing and running online
transaction processing applications. In recent years, CICS has also added support for web services,
allowing CICS applications to expose their functionality as web services and consume web services
from other systems. Here's an explanation of how to use CICS web services with examples:

Defining a CICS Web Service:


To define a CICS web service, you need to create a CICS application that exposes the desired
functionality as a web service. This involves defining the web service interface, operations, and data
formats. For example, let's say you have a CICS application that performs currency conversion. You
can define a web service operation called "ConvertCurrency" that takes inputs like "fromCurrency,"
"toCurrency," and "amount," and returns the converted amount.

Generating Web Service Bindings:

Once you've defined your CICS web service, you need to generate web service bindings. Web service
bindings provide the necessary code and configuration to interact with the web service. You can
generate the bindings using tools provided by IBM, such as the CICS Explorer or the CICS Web Service
Assistant.

Deploying the CICS Web Service:

After generating the web service bindings, you need to deploy the CICS web service in your CICS
region. This involves configuring the necessary resources and assigning them to the appropriate CICS
regions. The exact steps may vary depending on your specific CICS setup.

Consuming a CICS Web Service:

To consume a CICS web service from another system, you need to generate client code or use a web
service client tool. The client code or tool should allow you to invoke the web service operations and
handle the responses. Let's consider an example where you have a Java application that needs to
consume the "ConvertCurrency" web service from the previous step:

 Generate or import the necessary web service client code in your Java application. This can
be done using tools like IBM's WebSphere Development Studio or other web service client
frameworks.
 Instantiate the client stub or proxy object for the CICS web service in your Java code. This
object represents the web service endpoint and provides methods to invoke the operations.
 Call the desired web service operation, passing the appropriate parameters. In our example,
you would call the "ConvertCurrency" operation with the required input parameters.
 Handle the response returned by the web service. You can access the converted amount or
any other response data provided by the CICS web service.

By following these steps, you can use CICS web services to expose and consume functionality from
your CICS applications. Keep in mind that the specific details may vary depending on your CICS setup,
programming language, and tools used for web service development and consumption.

CICS web service using COBOL


To define a CICS web service using COBOL, you will follow a set of steps that involve defining the web
service interface, operations, and data formats. Here's an elaboration on the process:

Identify the Functionality: Determine the functionality you want to expose as a web service from
your existing COBOL application. For example, let's say you have a COBOL application that performs
customer information retrieval. You might want to expose a web service operation called
"GetCustomerDetails" that takes a customer ID as input and returns the customer's information.

Define the Web Service Interface: Define the web service interface in COBOL by creating a
copybook or a data structure that represents the input and output parameters of the web service
operation. In our example, you would define a data structure that includes fields like "CustomerID,"
"CustomerName," "Address," etc.

Create the Web Service Program: Write a COBOL program that implements the web service
functionality. This program will receive the web service requests, process them, and generate the
appropriate responses. In our example, you would write a COBOL program that receives the
"GetCustomerDetails" request, retrieves the customer information from your existing COBOL
application, and sends the response back.

Generate WSDL: Generate the Web Services Description Language (WSDL) file for your COBOL web
service. WSDL is an XML-based language that describes the web service interface and operations.
The WSDL file will be used by clients to understand how to interact with your web service. You can
use tools like the CICS Web Services Assistant or the COBOL Copybook to WSDL Converter to
generate the WSDL file.

Define the CICS Resources: Define the necessary CICS resources to support the web service. This
includes defining a CICS program, a CICS transaction, and a CICS BMS map (if required). The CICS
program will be the entry point for your COBOL web service program. The CICS transaction will
associate the program with a transaction ID. The CICS BMS map is optional and can be used if you
need to handle screen input/output for your web service.

Register the Web Service: Register the web service in CICS using the CICS Resource Definition
Online (RDO) facility. This involves providing information about the program, transaction, and other
resources associated with your web service. You'll also specify the WSDL file location.

Deploy and Test: Deploy the COBOL web service program and associated resources in your CICS
region. Ensure that the CICS region is configured to handle web service requests. Test the web
service by invoking the defined operations and validating the responses.
By following these steps, you can define a CICS web service using COBOL. It's important to note that
the process may vary based on your specific CICS version, setup, and tools used for COBOL
development and web service deployment.

Process to define a Web service interface


To define a web service interface, you need to specify the operations, input and output parameters,
and data formats that the web service will support. Here's a step-by-step process to define a web
service interface:

Identify the Functionality: Determine the functionality that you want to expose through your web
service. Clearly define the operations or actions that the web service will perform. For example, if
you are building a customer management system, your operations might include "CreateCustomer,"
"GetCustomer," "UpdateCustomer," and "DeleteCustomer."

Define the Input and Output Parameters: For each operation, define the input and output
parameters that are required. Specify the data types, names, and any constraints or validation rules.
Consider the information that needs to be passed to the web service and the information that will be
returned. For example, for the "CreateCustomer" operation, you might define input parameters like
"CustomerName," "Email," and "Address," and for the "GetCustomer" operation, you might define
an input parameter like "CustomerID" and an output parameter like "CustomerDetails."

Choose a Web Service Description Language: Select a Web Service Description Language (WSDL) to
define the web service interface. WSDL is an XML-based language that describes the operations, data
types, and message formats of a web service. Commonly used WSDL versions include WSDL 1.1 and
WSDL 2.0.

Define the WSDL Structure: Start creating the WSDL file by defining the structure using XML
elements. Typically, a WSDL document includes sections such as types, messages, port types,
bindings, and services.

a. Types: Define the data types used in your web service. This can include simple types (e.g., string,
integer) and complex types (e.g., structures, arrays). Specify the data format using XML Schema
Definition (XSD) or other supported type systems.

b. Messages: Define the input and output messages for each operation. Messages describe the
structure and format of the data being exchanged. They consist of parts that correspond to the input
and output parameters defined earlier.

c. Port Types: Define the port type, which represents the operations that can be invoked on the web
service. Associate each operation with its corresponding input and output messages.

d. Bindings: Specify the protocol and data format bindings for your web service. Common choices
include SOAP (Simple Object Access Protocol) and HTTP as the transport protocol, and XML or JSON
as the message format.

e. Services: Define the service, which represents the endpoint where the web service can be
accessed. Associate the service with the port type and specify the service endpoint address.

Additional Annotations and Policies: Optionally, you can add annotations and policies to provide
additional information about the web service. This can include documentation, security
requirements, message-level policies, and more. Annotations are typically defined using the Web
Services Metadata Exchange (WS-MetadataExchange) format.
Validate and Publish the WSDL: Validate the WSDL file to ensure it conforms to the chosen WSDL
version and is syntactically correct. Once validated, publish the WSDL file so that it can be accessed
by clients who want to consume the web service.

By following these steps, you can define a web service interface using WSDL. Remember that specific
tools and frameworks might provide a more streamlined approach to defining web service interfaces,
allowing you to generate the WSDL file automatically based on code annotations or configurations.

Process of identifying a compatible Web Service Description


Language
When identifying a compatible Web Service Description Language (WSDL), you need to consider
various factors such as the technology stack you're using, the standards and protocols supported by
your development environment, and the requirements of your project. Here's a process to help you
identify a compatible WSDL:

Understand the Technology Stack: Familiarize yourself with the technology stack you are using for
developing the web service. Different programming languages and frameworks have varying levels of
support for different WSDL versions. Determine which languages and frameworks are commonly
used in your project.

Check Language and Framework Support: Research the supported versions of WSDL by the
programming languages and frameworks you are using. For example, if you are using Java, check
which versions of WSDL are supported by the Java-based web service frameworks like Apache CXF,
Spring Web Services, or JAX-WS. Similarly, if you are using .NET, check the compatibility with WSDL in
frameworks like ASP.NET Web API or WCF.

Consider Interoperability: If your web service needs to communicate with external systems or clients
developed in different technologies, consider the interoperability requirements. Ensure that the
chosen WSDL version is widely supported and compatible with other commonly used platforms and
technologies.

Evaluate Standards and Protocols: WSDL is closely tied to other web service standards and protocols
such as SOAP, REST, XML, and JSON. Evaluate the standards and protocols required for your project
and consider the compatibility of WSDL with these technologies. For example, if you are building a
SOAP-based web service, WSDL 1.1 is a common choice. If you are developing a RESTful web service,
you might consider using alternatives like WADL (Web Application Description Language) or OpenAPI
(formerly known as Swagger).

Analyze Version-Specific Features: Different versions of WSDL introduce new features and
capabilities. Analyze the specific features offered by each WSDL version and determine if any of
those features align with your project requirements. Consider factors like schema imports,
extensibility, message-level policies, and support for metadata exchange.

Community Support and Documentation: Consider the availability of community support and
documentation for the chosen WSDL version. Check if there are active forums, tutorials, and
examples available for your preferred version. This can help you troubleshoot issues, find resources,
and leverage the knowledge of the community.

Project Requirements and Constraints: Take into account any specific requirements or constraints of
your project. For example, if you are working in a legacy environment, you may need to adhere to
existing WSDL versions already in use.
By following these steps and considering the compatibility with your technology stack,
interoperability needs, standards and protocols, features, community support, and project
requirements, you can identify a compatible WSDL version that aligns with your web service
development.

Defining WSDL Structure


Defining a WSDL (Web Service Description Language) structure involves creating an XML document
that describes the interface, operations, and data types of a web service. Here's a step-by-step
process to define a WSDL structure:

1. Start with the WSDL Element: Begin by creating the root element of the WSDL document,
which is <wsdl:definitions>. This element encapsulates the entire WSDL structure and
contains various child elements.
2. Define Namespaces: Declare the necessary namespaces in the <wsdl:definitions> element.
The required namespaces include the WSDL namespace (xmlns:wsdl) and namespaces for
XML Schema (xmlns:xs) and SOAP (xmlns:soap). For example:
<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/">
3. Define Types: Within the <wsdl:definitions> element, add a <wsdl:types> element to define
the data types used by the web service. You can use XML Schema (XSD) to define the data
types. For example:
<wsdl:types>
<xs:schema>
<!-- Define data types using XML Schema -->
</xs:schema>
</wsdl:types>
4. Define Messages: Define the input and output messages for each operation in the
<wsdl:message> element. Each message consists of one or more parts, where each part
specifies the name and type of a parameter. For example:
<wsdl:message name="MyOperationRequest">
<wsdl:part name="param1" type="xs:string"/>
<wsdl:part name="param2" type="xs:int"/>
</wsdl:message>
<wsdl:message name="MyOperationResponse">
<wsdl:part name="result" type="xs:string"/>
</wsdl:message>
5. Define Port Type: Add a <wsdl:portType> element to define the abstract interface of the web
service. This element contains one or more <wsdl:operation> elements, each representing an
operation that the web service supports. Specify the input and output messages for each
operation. For example:
<wsdl:portType name="MyServicePortType">
<wsdl:operation name="MyOperation">
<wsdl:input message="tns:MyOperationRequest"/>
<wsdl:output message="tns:MyOperationResponse"/>
</wsdl:operation>
</wsdl:portType>
6. Define Binding: Within the <wsdl:definitions> element, add a <wsdl:binding> element to
specify the concrete protocol and data format used for the web service. This can be SOAP,
REST, or other protocols. Associate the binding with the port type and define the details of
the binding. For example:
<wsdl:binding name="MyServiceBinding" type="tns:MyServicePortType">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<wsdl:operation name="MyOperation">
<soap:operation soapAction="urn:MyOperation"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>
<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
7. Define Service: Finally, add a <wsdl:service> element to define the endpoint where the web
service is available. Associate the service with the binding and specify the endpoint address.
For example:
<wsdl:service name="MyService">
<wsdl:port name="MyServicePort" binding="tns:MyServiceBinding">
<soap:address location="http://example.com/myservice"/>
</wsdl:port>
</wsdl:service>
Using above steps, you can define the structure of a WSDL document by specifying the namespaces,
types, messages, port types, bindings, and services. Customize the elements, attributes, and data
types according to your web service requirements.

Process to create Web Service Bindings using Cobol and mainframe


Creating web service bindings in COBOL for a mainframe environment typically involves utilizing
IBM's CICS (Customer Information Control System) and related tools. Here's a high-level process to
create web service bindings using COBOL and the mainframe:

1. Define the Web Service Interface: Identify the operations, input/output parameters, and
data formats you want to expose as web service operations. Define the COBOL copybook or
data structures that represent the input and output parameters.
2. Generate Web Service Bindings: Use IBM's CICS Web Service Assistant or CICS Explorer to
generate the web service bindings. These tools provide wizards or utilities to guide you
through the process of creating the necessary artifacts for web service invocation.
3. Configure CICS Resources: Configure the CICS resources required to support the web service.
This includes defining a CICS program, transaction, and potentially a BMS map for screen
input/output if needed. The CICS program will be the entry point for your COBOL code
handling the web service operations.
4. Implement Web Service Operations: Write COBOL code to implement the web service
operations defined in the web service bindings. This code will receive incoming web service
requests, process them using your existing COBOL application logic, and generate
appropriate responses.
5. Deploy the COBOL Program: Deploy the COBOL program and associated resources in your
CICS region. Ensure that the CICS region is configured to handle web service requests. You
may need to work with your system administrator or operations team to deploy and activate
the program.
6. Test and Validate: Test the web service by invoking the defined operations and validating the
responses. You can use tools like CICS Explorer, SOAP UI, or other web service testing tools to
send requests and verify the correctness of the responses.

It's important to note that the process may involve additional steps or specific configurations
depending on your mainframe setup, version of CICS, and tools in use. Additionally, IBM provides
extensive documentation and resources for working with CICS web services, which can offer more
detailed guidance on creating web service bindings using COBOL and the mainframe environment.

Steps involved in Registering a web service in CICS using RDO


Registering a web service in CICS (Customer Information Control System) using RDO (Resource
Definition Online) involves configuring the necessary resources and associating them with the web
service. Here are the steps involved in registering a web service in CICS using RDO:

1. Identify the Required Resources: Determine the resources that need to be defined and
associated with your web service. This typically includes a Program, a Transaction, a Terminal
Control Table (TCT), and a Web Service Definition (WSD) resource.
2. Access RDO: Use the appropriate tool or interface to access the CICS Resource Definition
Online (RDO) facility. This can be done through tools such as CICS Explorer, CEDA (CICS
Execution Diagnostic Assistant), or through a direct RDO interface.
3. Define the Program: Define a CICS program that will serve as the entry point for your web
service. The program should contain the necessary COBOL or other language code to handle
the web service operations. Assign a unique program name and specify the appropriate
transaction ID associated with the program.
4. Define the Transaction: Define a CICS transaction that will be used to invoke your web
service. Assign a unique transaction ID and associate it with the program defined in the
previous step. Specify any transaction attributes or options required for your web service.
5. Configure the Terminal Control Table (TCT): If your web service requires terminal control
or screen handling, configure the Terminal Control Table (TCT). This table specifies the
characteristics and attributes associated with terminals or devices interacting with your web
service.
6. Define the Web Service Definition (WSD) Resource: Create a Web Service Definition
(WSD) resource that defines the details of your web service. This includes specifying the
program and transaction associated with the web service, the endpoint URL, the WSDL
location, and any additional configuration options.
7. Associate Resources: Associate the previously defined resources (program, transaction, TCT,
and WSD) with each other. This typically involves specifying the appropriate resource names,
IDs, and dependencies in the RDO configuration.
8. Activate and Test: Activate the changes made in RDO to make them effective in the CICS
region. Test the web service by invoking the defined operations and validating the responses.
Ensure that the web service is accessible and functioning as expected.

It's important to note that the specific steps may vary depending on your CICS version, setup, and
tools used for RDO configuration. Additionally, some CICS installations might have their own specific
conventions and guidelines for registering web services using RDO. Refer to the documentation and
resources provided by IBM or your system administrator for detailed instructions specific to your
CICS environment.
Steps involved in creating a web services program in COBOL
To create a web services program in COBOL, you will follow a set of steps to define the program
structure, handle web service requests, and generate appropriate responses. Here are the steps
involved in creating a web services program in COBOL:

1. Define the Program Structure:

Start by creating a new COBOL source file for your web services program. Define the
necessary COBOL data structures and variables to hold the input parameters, output results, and any
intermediate data required for processing.

2. Include Web Service Libraries and Copybooks:

Identify and include any required libraries or copybooks specific to web services. These may
include COBOL copybooks containing structures or data types used in the web service interface.

3. Handle Web Service Requests:

Define the entry point for your web service program. This could be a specific procedure or
section within the program. Retrieve the incoming web service request. This can be done by
accessing the appropriate variables or fields provided by the web service framework you are using.
Extract the input parameters from the web service request and assign them to the corresponding
COBOL variables defined in your program.

4. Implement Web Service Operations:

Write the logic to perform the operations defined by your web service. This may involve
invoking existing COBOL modules or programs, manipulating data, performing calculations, or any
other required business logic. Use the input parameters received from the web service request to
drive the processing. Generate the output results or response data based on the operation
performed. Assign the results to the appropriate COBOL variables.

5. Format the Web Service Response:

Create the structure or format required for the web service response. This may involve
defining COBOL data structures or using specific libraries or copybooks. Assign the output results
generated by your program to the response variables. Prepare the web service response by
formatting the data according to the specified message format (XML, JSON, etc.).

6. Return the Web Service Response:

Provide the generated response data to the web service framework or runtime. This is
typically done by assigning the response to the appropriate variables or fields provided by the
framework. Return control to the web service framework, which will handle sending the response
back to the client.

7. Compile and Test:

Compile your COBOL web services program using the appropriate COBOL compiler or build
system. Test the program by invoking the web service operations and validating the responses. This
can be done using web service testing tools or by integrating the program into your web service
environment.
By following these steps, you can create a web services program in COBOL that handles web service
requests, performs the required operations, and generates appropriate responses. Keep in mind that
the specific implementation may vary depending on the web service framework or tools you are
using, as well as any specific requirements or conventions in your COBOL development environment.

You might also like