introduction to relational databases

Overview

eBusiness support introduced in CICS/ESA: CICS/Internet Gateway support pack

Implemented the Business Logic Interface

This support was continued in CICS/TS 1.3Full HTTP supportNew commands to support web-aware programs

DOCUMENT APIWEB APITCPIP API

This effort is continued in CICS/TS 3.1/3.2 & 4.1SOAP/CICS feature implemented as a support pack is now fully integrated in CICS

The above feature was supported “as is” in TS Version 3 – no longer supported in TS 4.1New resource definitions

URIMAP, WEBSERVICE, PIPELINESupport for Websphere Services Registry and RepositorySupport for ATOM FEEDS (ATOMSERVICE) Service Component ArchitectureEVENT ProcessingWS-Addressing messages

3

Overview eBusiness support started in CICS/ESA with the introduction of an add-on product called CICS Internet Gateway; this product installed the Business Logic Interface in CICS. Although cumbersome to use, it introduced a means to separate presentation logic from the business logic. In CICS/TS 1.3, IBM made provisions in the CICS/API so programmers could use “EXEC CICS” commands when interacting with web-aware programs: The DOCUMENT API provides a mean to manipulate documents in a CICS program; these documents can then be sent to web just by passing a token obtained when the document was originally created

♦ The WEB API can be used to interact with the WEB; it supported HTTP and IIOP protocols

♦ The TCP/IP API could be used to interrogate CICS about the status of the communication with the browser

CICS/TS Web Services

1-2 © 2012 Themis, Inc. All rights reserved.

Introduction CICS/TS 3.1 continued this implementation started a few years ago. It now provides for:

♦ Support for SOAP and Web Services

♦ New resource definitions which will help in the implementation of web applications

♦ Enhanced WEB API which will allow a CICS program to become a client on the web

CICS/TS 3.2 added the following features:

♦ Support for WSDL 2.0

♦ Support for inter-region connectivity with TCPIP

♦ Support for Dynamic Storage management above the Bar

CICS/TS 4.1 added the following features:

♦ Support for EVENT processing, ATOM Feeds, Service Component Architecture

♦ Utilities to convert language structure to XML schema and vice versa

♦ Usage of system Z specialty engine for parsing XML document

♦ ipv6 IP address support

♦ Support for Websphere Services Registry and Repository

Introduction

© 2012 Themis, Inc. All rights reserved. 1-3

Connecting to CICS

Today’s CICS networkEasy integration to a Service Oriented ArchitectureSupports just about everythingMany components part of the product:

3270-bridgeFEPIWEB InterfaceWEBSERVICESOAPHTTP supportECI over TCP/IP

Via Enterprise COBOL, support for XML

MQ series

User socketapplication

RPC request

WEB request

MQ-CICSbridge

TCP/IPsocket

RPC/ONCsupport

CWI

DFHIRPEXCI support

CICS

LINK

VTAM

CICS program

BLI

DFHWBTTA

Bridge

Transaction

WebspherepluginICSS

WEB3270

Java appl.

MVS programs

DCE/RPCclients

Web requests(Java)

Any client

Web request

CICS CTGfor Java

3270

CICS/TS

TELNET3270

ECI

EPICICSinternetgateway

MVSproduct

IMS DB/DC

CICS/TS

4



Connecting to CICS As illustrated above, CICS is now accessible from just about anything that runs on a computer. By linking to the Business Logic Interface, CICS can interact with:

♦ MQ-series

♦ Your own TCP/IP socket programs

♦ Remote Procedure Calls

♦ Web Url’s pointing at CICS programs

EXCI can be used to support

♦ Requests from OS/390 web servers

♦ MVS programs wanting access to CICS data

♦ DCE clients

♦ Java clients

Using CICS/CLIENTS ECI interface, any client program can gain access to CICS/BLI.

CICS for INTERNET GATEWAY, combined with the External Presentation Interface, can provide access to CICS server programs

Introduction


Connecting to CICS

client Web-servernon-OS/390

VTAMTCP/IP CICSTCP/IP

SNA or

TCP/IP

client EXCITCP/IP CICSTCP/IP HTTPserver

client TCP/IPCICS

TCP/IP

TCPIPSERVICE

CWI pgm



Connecting to CICS There are 4 types of connection:

1. Non-zOS servers that connect to CICS using a network

2. z/OS servers that connect to CICS using EXCI.

3. Requests sent directly to CICS in HTTP format

4. CICS acting as an HTTP client and sending requests to other HTTP servers

Introduction


Connecting to CICS

HTTP/IIOP

HTTP/IIOPS

RPC

TELNET

3270request

TCP/IP

VTAM

SLTCB CICS

mirror program

transactiontcpipservice

tcpipservice transaction

transaction

transaction

RPTCB

CSOL

CPMI



Connecting to CICS CICS supplies its own socket listeners; transaction CSOL will listen to ports identified by the TCPIPSERVICE resource definition. It supports the following protocols:

♦ HTTP – secured or not

♦ IIOP – secured or not

♦ ECI – for connecting to CTG

♦ USER – non-HTTP requests sent via HTTP links

For all of these, you define a transaction which will act as a monitor for this connection; you will also name a program to be called by the monitor; this program will identify which user application should be executed.

Also, despite what is being shown on the above diagram, in CICS/TS, connections are now going both ways:

♦ When CICS is acting as a client, a program can:

Open a connection Send an HTTP request to another HTTP server Receive a response Close the session

When CORBASERVERs are used, IIOP requests can be sent and received by CICS

Introduction


Service-based processing

Browser CWXN

CWBA BLI DECODE

ENCODE

USERCODE

DFHCCNV

SLTCB

CSOL

DFHCCNV(HEADER)

ANALYSER(DFHWBADX)

DFHCCNV(DATA)

TCPIPSERVICE

TCPIPSERVICE

TCP/IP

RESPONSE

CICS

URIMAP?

N

Y

7

Service-based Processing HTTP requests always consist of two components: a header and user data.

♦ The header is separated from user data by two consecutive CRLF characters.

♦ When requests are received, CSOL attaches CWXN which in turn receives the data and puts it into a TSQ.

♦ The header portion is translated to EBCDIC.

♦ If a matching URIMAP is found, CICS will:

Determine if the analyser program is required:

− If it is determined that the analyzer is required, it is given control. It looks at the header to determine the names of the converter and user programs to execute. If the converter program's name is CICS, it is assumed by the analyzer that no converter services are required and, consequently, no ENCODE/DECODE functions will be provided. After the analyzer is done, it returns control to the monitoring program.



− If it is determined that the analyzer is not required, it will take the information from the URIMAP (converter name, alias and program name) and attach the alias transaction with this information

♦ If no matching URIMAP is found, it will call the analyser program which name will be found in the TCPIPSERVICE resource definition.

User data may need translation and DFHCCNV will be called if so.

♦ The alias transaction is started (the default is CWBA). The first program to execute must be DFHWBA. DFHWBA puts the information received from the analyzer in a commarea and links to the business logic interface.

♦ BLI invokes the converter program's DECODE function, if requested.

♦ BLI invokes the user program with a commarea. If no DECODE function executed, the commarea contains the request in its original form.

♦ After completion of the user program, the converter program's ENCODE function may be invoked, if necessary. At this point, BLI has a formatted response which is passed to the alias transaction. The response was formatted either by the converter program or by the user program.

♦ The alias transaction then invokes DFHCCNV to convert the response back to ASCII, if data was found in the commarea.

♦ The response is sent back to the client's browser by issuing WEB WRITE and WEB SEND commands.

CICS' Socket Domain issues the necessary interface call to TCP/IP

Introduction


Service-based Resources

4 CICS resources are used in this environment:TCPIPSERVICE for:

Mapping the port in which CICS will listenEstablishing security requirementsEstablishing protocol to be used on that port

URIMAP for:Establishing usage Client Server Pipeline Atom feeds

Security requirementsEstablishing processing requirement

ATOMSERVICETo identify the location of a document template in CICS

BUNDLEDescribe composite applications deployed by using the Service Component Architecture tool set of Rational Developer for system Z

8

Service-based Resources TCPIPSERVICE There are 4 CICS resources that are used in this environment:

♦ TCPIPSERVICE ♦ URIMAP ♦ DOCTEMPLATE

TCPIPSERVICE is used to tell the CICS socket listener: ♦ Which port is to be listened to ♦ What TCP/IP protocols are to be used on this port. CICS now supports 4 protocols. They

are: − HTTP − IIOP − ECI over TCP/IP − IP connections − USER protocol used when HTTP 1.1 cannot be used

♦ Security requirements including names of the certificate CICS will be using

Introduction


URIMAP is used to tell CICS about a URL which might be coming to CICS to going out from CICS to another HTTP server. This resource can be specified when CICS is acting as a server or client; it is also used heavily by the webservice support as it will identify the pipeline used by the request. It is also used for: ♦ Providing information that will allow CICS to bypass the web analyser program

♦ Providing security for this request

♦ Providing some default processing requirements for a specific request

ATOMSERVICE is used to identify a web feed coming to CICS. A Web feed, sometimes just called a "feed", is a series of related items that a content provider publishes on the Internet. An Atom feed is a Web feed that uses the Atom Syndication Format and the Atom Publishing Protocol.

Atom comprises an XML-based format that describes an Atom feed and the items of information in it, and a protocol for publishing and editing Atom feeds.

The items of information that make up an Atom feed are known as Atom entries. A content provider publishes, or "syndicates", an Atom feed by making it available through a URL on the Internet and updating it with new items.

BUNDLE the unit of deployment for applications using EVENT processing



Service-based Resources TCPIPSERVICE

OBJECT CHARACTERISTICS CICS RELEASE = 0660

CEDA View TCpipservice( WEBSRVC )TCpipservice : WEBSRVCGROup : CWSCOMNDEScription :Urm : DFHWBADXPOrtnumber : 07581 1-65535STatus : Open Open | ClosedPROtocol : Http IIop | Http | Eci | User | IPicTRansaction : CWXNBacklog : 00001 0-32767TSqprefix :Host : ANY(Mixed Case) :Ipaddress :SOcketclose : No No | 0-240000 (HHMMSS)Maxdatalen : 000032 3-524288

SECURITY+ SSl : No Yes | No | Clientauth

SYSID=ODA2 APPLID=CICSA2

PF 1 HELP 2 COM 3 END 6 CRSR 7 SBH 8 SFH 9 MSG 10 SB 11 SF 12 CNCL--------------------------------------------------------------------------------4-© 2 Sess-2 66.252.186.222 SC0TCP04 1/3

9

Service-based Resources TCPIPSERVICE Used to define which TCP/IP services need to use CICS internal socket support such as

♦ CICS listening on multiple ports; ♦ Different flavors of CICS WEB; ♦ Different IIOP support on different ports;

Setting up connection with CICS Transaction Gateway using ECI protocol

Setting up connection with a non-HTTP client using the USER protocol.

Transaction identification should be:

♦ CWXN (program DFHWBXN) for HTTP ♦ CIRR (program DFHIIRRS) for IIOP ♦ CIEP (program DFHIEP) for ECI over TCP/IP ♦ CWXU (program DFHWBXN) for USER protocol ♦ CISS (program DFHISCOP) for IP connections

Introduction


PROTOCOL:

ECI was added as a supported protocol in CICS/TS 2.2; this will allow you to define a CTG connection to CICS using a TCPIPSERVICE

USER was added in CICS/TS 3.1; it allows you to separate HTTP processing from non-HTTP activities. This will allow CICS to perform basic acceptance checks on HTTP requests and responses, something that non-HTTP traffic should not be subjected to.

IPIC was added in CICS/TS 3.2; it is used when TCPIP connections are defined. This TCPIPSERVICE is referenced by the IPCONN resource definition used to define this type of connections between CICS systems CICS/TS will now check HTTP messages for conformity with HTTP 1.1 rules.

Authentication type: Basic Userid and password are obtained from the client

Certificate SSL client certificate authentication is used.

SSL(CLIENTAUTH) must also be specified.

Autoregister Same as CERTIFICATE but if the certificate is not registered, basic authentication services will be used to obtain a userid and password.

SSL(CLIENTAUTH) must also be specified.

Automatic Includes basic, certificate and autoregister facilities.

No When specified for an HTTP connection, the client is not required to send userid/password information. If such information is received by CICS, it will be accepted and treated accordingly.

When specified for an IIOP connection, authentication is not required but, if received, information will be treated accordingly.

MAXDATALEN Specifies the maximum length of data that can be received on an HTTP connection.

♦ Maximum: .5G ♦ Minimum: 3K ♦ Default: 32K

SOCKETCLOSE should be a number between 0 and 240000; NO should be specified when HTTP persistent session are required



Service-based Resources TCPIPSERVICE

OBJECT CHARACTERISTICS CICS RELEASE = 0660CEDA View TCpipservice( WEBSRVC )

+ CErtificate :(Mixed Case)PRIvacy : Notsupported | Required | SupportedCIphers :AUthenticate : No No | Basic | Certificate | AUTORegister

| AUTOMatic | ASsertedRealm :(Mixed Case)ATtachsec : Local | Verify

DNS CONNECTION BALANCINGDNsgroup :GRPcritical : No No | Yes

DEFINITION SIGNATUREDEFinetime : 06/28/10 06:32:29CHANGETime : 06/28/10 06:32:29CHANGEUsrid : ODYTD

+ CHANGEAGEnt : CSDBatch CSDApi | CSDBatch



10

Service-based Resources TCPIPSERVICE PRIVACY(REQUIRED|SUPPORTED|NOTSUPPORTED

It is used to reflect the level of SSL encryption required for inbound connections to this service that is specified by the CIPHERS attribute.

REQUIRED: Encryption is used; CICS will only advertise those cipher suites it supports.

NOTSUPPORTED: Encryption is not used; CICS will advertise only the cipher suites that do not support encryption

SUPPORTED: CICS will advertise all cipher suites

Introduction


Service-based Resources URIMAP


CEDA View Urimap( PINGURI )Urimap : PINGURIGroup : CWSCOMNDEScription :STatus : Enabled Enabled | DisabledUSAge : Client Server | Client | Pipeline | Atom

UNIVERSAL RESOURCE IDENTIFIERSCheme : HTTP HTTP | HTTPSPOrt : 7581 No | 1-65535HOST : p390.themisinc.com(Mixed Case) :PAth : /cics/cwba/dfh$wb1a(Mixed Case) :

:::

ASSOCIATED CICS RESOURCES+ TCpipservice :



12

Service-based Resources URIMAP This is resource definition was implemented in CICS/TS 3.1; it matches the URIs of HTTP or Web service requests, and provide information on how to process the requests.

Requests from a Web client, to CICS as an HTTP server. URIMAP definitions for requests for CICS as an HTTP server have a USAGE attribute of SERVER. In these cases, you could use this definition to instruct CICS to:

♦ Provide a static response stored in an HFS file

♦ Provide a dynamic response using an application program

Requests to a server, from CICS as an HTTP client. URIMAP definitions for requests from CICS as an HTTP client have a USAGE attribute of CLIENT. This could be used when an application program submits a requests to another HTTP server. Setting up a URIMAP would be useful as the programmer will not have to identify the URL in the application program

Web service requests. URIMAP definitions for Web service requests have a USAGE attribute of PIPELINE.



ANALYZER({NO|YES})

This attribute is for USAGE(SERVER), where an application-generated response is to be provided.

TCPIPSERVICE(name)

This attribute is for USAGE(SERVER) and USAGE(PIPELINE). It specifies the 1- to 8- character name of a TCPIPSERVICE resource definition, with PROTOCOL(HTTP), that defines an inbound port to which this URIMAP definition relates.

SCHEME(http or https)

Whether you will be using a secures (https) or non-secured(http) connection,

PORT(number)

Identify the port number on which the request will be serviced. This port number must be used if HOST is using a character string name as opposed to an ip address.

HOST(name or dotted ip address)

Identify the host that will be servicing the request. HOST can be a character string, for example www.mysite.com, to identify the HOST; when using this format, you must use the PORT parameter to identify the PORT number used to service this request.

You can also use an IP address in the format 99.999.999.999; using this format, the port number can also be supplied as part of the address.; to do so, end the address with a (:) followed with a port number; for example, 99.999.999.999:1234 PATH(name) Identify the request.

Introduction




CEDA View Urimap( PINGURI )+ ANalyzer : No No | Yes

COnverter :TRansaction :PRogram :PIpeline :Webservice : (Mixed Case)ATomservice :

SECURITY ATTRIBUTESUSErid :CIphers :CErtificate : (Mixed Case)AUthenticate : No No | Basic

STATIC DOCUMENT PROPERTIESMediatype :(Lower Case)CHARacterset : (Mixed Case)

+ HOSTCodepage :



13

PATH

Specified for all usage

Server related attributes are:

♦ TCPIPSERVICE ♦ CHARACTERSET ♦ HOSTCODEPAGE ♦ TEMPLATENAME ♦ HFSFILE ♦ ANALYZER ♦ CONVERTER ♦ TRANSACTION ♦ PROGRAM ♦ USERID ♦ REDIRECTTYPE ♦ LOCATION(url)

Client related attributes are:

CERTIFICATE - CYPHERS




OBJECT CHARACTERISTICS CICS RELEASE = 0660CEDA View Urimap( PINGURI )

+ TEmplatename :(Mixed Case)HFsfile :(Mixed Case) :

:::

REDIRECTIONRedirecttype : None None | Temporary | PermanentLocation :(Mixed Case) :

:::

DEFINITION SIGNATUREDEFinetime : 06/28/10 06:32:30

+ CHANGETime : 06/28/10 06:32:30



14

Service-based Resources URIMAP Templatename and redirection are parameters used when using the CICS/WEB interface.

Introduction


Atom Feeds

Series of related items published on the internet by content providerAn extension of RSS feeds – Really Simple Syndication

Uses Atom Syndication Format and Atom publishing ProtocolSupport available in CICS/TS 3.2 by installing service pack CA8KSupport available in native CICS/TS 4.1

CICS does not support RSS feeds… only Atoms

Support provided by CICS:TCPIPSERVICE to map the port on which the feed comes inURIMAP will identify the program that will be processing this feed

ATOM SEVICE can be used to display information coming from the feed.

19



Atom Feeds A Web feed, sometimes just called a "feed", is a series of related items that a content provider publishes on the Internet. An Atom feed is a Web feed that uses the Atom Syndication Format and the Atom Publishing Protocol.

Atom comprises an XML-based format that describes an Atom feed and the items of information in it, and a protocol for publishing and editing Atom feeds.

CICS supports Atom feeds using the HTTP server functions of CICS Web support, and some additional functions to carry out the actions required of a server that supports the Atom format and protocol. You must select or set up a resource that provides the data for your Atom feed, and define the feed to CICS.

Before serving an Atom feed from CICS, you must configure the base components of CICS Web support to set CICS up as an HTTP server.

Introduction


Websphere Service Registry and Repository

Facility is used to help manage web sevicesWith WSRR, you can:

enforce version controlfind web services you are requesting faster

CICS/TS 4.1 provides support to interoperate with WSSRSupport provided via the 2 web services assistants DFHLS2WS and DFHWS2LS discussed later in this book

22

WebSphere Service Registry and Repository The CICS Web services assistant can interoperate with the IBM WebSphere Service Registry and Repository (WSRR). Use WSRR to find Web services that you are requesting more quickly and enforce version control of the Web services that you are providing.

Both DFHLS2WS and DFHWS2LS include parameters to interoperate with WSRR.

DFHLS2WS also includes an optional parameter so that you can add your own customized metadata to the WSDL document in WSRR.

If you want the Web services assistant to communicate securely with WSRR, you can use secure socket level (SSL) encryption. Both DFHLS2WS and DFHWS2LS include parameters for using SSL encryption.

DFHLS2WS parameters: WSRR-CUSTOM- PropertyName = value Use this optional parameter to add customized metadata to the WSDL document in the WSRR. The WSRR-CUSTOM-PropertyName=value pairs are added into the WSDL document and appear in WSRR without the WSSR-CUSTOM prefix.



Use this parameter only when the WSRR-SERVER parameter is specified.

WSRR-VERSION = 1 | value Use this parameter to set the version property of the WSDL document in WSRR.


DFHWS2LS parameters: WSRR-NAME = value Specifies the name of the WSDL document to retrieve from WSRR. Use this parameter only when the WSRR-SERVER parameter is specified.

WSRR-NAMESPACE = value Specifies the namespace of the WSDL document to retrieve from WSRR. You can optionally use this parameter when the WSRR-SERVER parameter is specified to fully qualify the WSDL document name specified in the WSRRNAME parameter.

WSRR-PASSWORD = value Use this optional parameter if you must enter a password to access WSRR. If the WSRR-USERNAME parameter is specified, you must also specify this parameter.


WSRR-SERVER = {domain name:port number} | {IP address:port number} Use this parameter to specify the location of the IBM WebSphere Service

Registry and Repository (WSRR) server. If this parameter is specified, WSRR parameter validation is used.

WSRR-USERNAME = value Use this optional parameter if you are required to specify a user name to access WSRR. This user name is used by WSRR to set the owner property.


WSRR-VERSION = value

Specifies the version of the WSDL document to retrieve from WSRR. You can use this parameter only when the WSRR-SERVER parameter is specified.

Introduction


CICS as HTTP clientSummary

The following processing takes place:Application program initiates a connection with a CICS WEB OPEN commandCICS establishes the connection with the serverApplication program may provide HTTP headers of its ownApplication programs specifies the request on the request line using a WEB SEND or WEB CONVERSE command; the request is then initiatedCICS generates headers of its own and send the request to the serverServer provides a responseApplication program will examine the response using WEB RECEIVE or WEB CONVERSEApplication program uses a WEB CLOSE command to terminate the session with the server

Integrity of this conversation is maintained by using tokens obtained with the WEB OPEN command and passed on all subsequent CICS WEB commands

7

CICS as HTTP Client Summary The application program that initiates the HTTP request should be designed to process whatever CICS receives from the server in response to that request, which might include error responses, redirection to another URL, embedded hypertext links, HTML forms, image source, or other items that request an action from the application program. CICS can perform code page conversion for requests and responses, if required.

During this process, code page conversion is usually needed when messages enter and leave the CICS environment, so that CICS Web support processing and user-written applications which typically use an EBCDIC encoding can communicate with HTTP servers which typically use an ASCII encoding.



CICS as HTTP clientHTTP message format

Send request

REQUEST LINE

HEADERS

(CICS GENERATED)

HEADERS

BODY

Receive request

STATUS LINE

HEADERS

BODY

8

Introduction


CICS as HTTP Client HTTP Message Format The HTTP message has different formats depending on whether we have a “send” or “response” request.

On a “SEND” request:

The “REQUEST LINE” is used to identify the server and the work to be done.

In the above example, the command indicates:

♦ HTTP session – non-secured

♦ The host is: longchamps-info.com

♦ On port 5555

♦ The path: CustomerFileMaintenance/GetRecord – on my system, this is a webservice

♦ The request line is typically the area where you put in a URL to get to a specific website

HEADERS are used to tell the application program and the server about the message being sent,

♦ For example, the content-length header will tell the application program about the size of the message

http://www.longchamps-info.com:5555/CustomerFileMaintenance/GetRecord



This Page Intentionally Left Blank

Introduction


HTTP Support

♦ This is how CICS knows that it is talking to a server capable of supporting HTTP 1.1

♦ This is also used by CICS to associate a request with a virtual host

HEADERS can also be generated by the application; in this case, the server application will have to understand these headers in order to process them

The BODY is the actual message. This message could be constructed using the DOCUMENT interface in CICS or from a program working-storage. When the body is destined for a web browser, it will contain an HTML document. This body can also be pure data or even an XML document; SOAP, for example, uses HTTP as transport protocol and the document being transmitted is XML-based.

On a response, or a “RECEIVE” request:

The HTTP message is formatted a little differently. The request line is replaced by a status line. Headers will be used to describe the message being sent while the body will contain the response to the request.

The STATUS LINE describes the response from the server; typically, it consists of a code and text; the text is usually 256 bytes while a 3-digit code describe the error. In HTTP, a normal response code is usually a number in the 200 range…very often 200?!?!?!

There are times where a client will just want to send information to the server; there are other times where the client application will only want to get information from the server and there are times where we will need to send a request for which a response will be required. In HTTP, this is accomplished by using a METHOD.

There are a number of methods available in HTTP; here are the most important:

1. GET: get information from the server; using this method, a message is formatted without a body; the request is entirely formatted on the request line and this should be enough for the server program to “understand” the request

2. POST: send information to the server and wait for a response. This request will always require a body even though the request line may have all the necessary information for the server

3. PUT: Send information to the server; the body is required and will contain the necessary information for the server application

4. HEAD: request headers from the server; no body will be allowed 5. DELETE: delete a resource from the server. No body will be allowed 6. TRACE: to trace the route request of a message. Body not allowed 7. OPTIONS: to obtain information about the server; body not allowed



CICS as HTTP clientCICS commands

There are a number of facilities that can be used to perform this task:Web API:

WEB OPENWEB SENDWEB RECEIVEWEB CONVERSEWEB CLOSE

Document APITo create the message to be sent by the client program

CICS resourcesURIMAP to setup connections and security

Note: TCPIPSERVICES are not used when CICS is acting as a client

9

Introduction


CICS as HTTP Client CICS Commands A CICS program acting as an HTTP client can be used for a multitude of reasons; it can be used to:

♦ Access information stored in another HTTP server

♦ Start a server program in an environment where HTTP is supported

♦ A server program already exists for the work you have to do and the current server is CICS/WEB aware

♦ Obtain a resource readily available on the web; for example FX converters

Although these programs can interact with the web, they can also be used in a client/server environment.

A number of facilities are at your disposal when you want to use these functions:

♦ The CICS/WEB API commands will be used to communicate with the server; please note that this server can be another CICS system

WEB OPEN command will start a session WEB SEND will be used to send request and data WEB RECEIVE will be used to receive response WEB CLOSE to close the session

♦ The DOCUMENT API commands can be used to create documents which will represent the BODY of the message. These documents can be anything from pure data to full blown HTML templates

The URIMAP resource definition should be used to minimize the amount of information the programmer will need to know and provide in his/her program.



Overview

Prior to CICS/TS V3, there were 2 methods for passing data between programs of a same task:

TWAThis is an old method and should really be avoided as much as possible

COMMAREAGreat mechanismBUT it has a limit of 32K

There are other problems related to COMMAREA:It is a concept not easy to grab for new CICS programmersIt is easy to corrupt memoryPrograms get to see data it does not have to see

This leads to even more error

Task gets to carry a lot of dataData is not structured

2

Overview

Introduction


In older CICS releases, if one program wanted to pass information to another, one has to chose between the following facilities:

♦ Use a TWA

Although very popular 30 years ago, TWA are not really the proper tool to achieve this goal

− The storage must be reserved in advance − The exact amount of storage must be known

♦ Use a COMMAREA

They are not really “programmer friendly” The maximum commarea size is 32K Modern design implements 1 commarea definition for all transactions within a given

application

− This means that a lot of data gets carried to programs that don’t necessarily need to see all of it

− Because it is not in the program own storage, it is easy to corrupt other task storage or it own data

− This is a very rigid environment, difficult to modify without causing a great deal of pain

− The data is not structured − If more than 32K is required, one must look at TSQ or DB2 as a solution; that by

itself also brings its own set of problems



This Page Intentionally Left Blank

Introduction


I don’t really think it was possible to change the commarea concept; field EIBCALEN is defined as a halfword binary integer; making this a fullword meant:

♦ Recompiling every single program in your shop

♦ If you have assembler programs, it probably meant having to change the source. For example using ST as opposed to STH, L as opposed to LH, etc

♦ For IBM, it meant having to change a lot of system code in CICS

♦ All in all, in order to maintain CICS upward and downward compatible, IBM could not touch COMMAREA’s

The solution was to invent new programming constructs that did not have the short-comings of commarea. Since CICS/TS 3.1, this solution is called CHANNEL.

CHANNEL is just a mean for transferring data; like a parameter list, they don’t actually contain any data. CICS already has a mean for transferring data that is structured and does not have any limit as to the amount of data that can be transferred; this method is called a CONTAINER; CONTAINERs are available in Business Transaction Services API and have been adapted to CHANNEL

Since CICS/TS 3.2, CHANNELS and CONTAINERS are used to replace the Temporary Storage queues used by the CICS/WEB interface.



Definitions

A container is a named block of dataThis block is in storageCan be of any length

A channel is a group of containersIt is a standard mechanism for passing data to other programsThere is no limit to the number of containers that can be passed with a channelCan be used with the following commands:

LINKRETURNXCTL INVOKE WEBSERVICESTART

It is mutually exclusive with COMMAREAThe current channel is the channel with which the program was invokedCONTAINERS are not new to CICS; they were first introduced with BTS

This is why the documentation will refer to container (channel) or container (BTS)

3

Introduction


Definitions A CONTAINER is a named block of data; contrary to BTS CONTAINERS which reside on a VSAM data set called the BTS repository, CHANNEL CONTAINERS reside in main storage and they are non-recoverable. They can be of any length.

CHANNEL is a group of CONTAINERs and this is used to pass information to other programs.

♦ There is no limit to the number of containers that can be passed with a channel

♦ There is no limit to the number of channel that can be created although only one channel can be passed at any one point of time

♦ The following commands can create a channel:

LINK RETURN XCTL INVOKE WEBSERVICE START

The channel will be created when one of the above command is executed and, just like commarea, can only be seen by the program that receives it

The CURRENT CHANNEL is always the channel with which the program was invoked.



Benefits

There are numerous benefits to using this mechanism:No limit to the amount of storage that can be passedApplication data can be structured in such a way that a given program will only receive the data it needs to look atThe program receiving the channel doe s not require to know, in advance:

The exact size of the data passedThe exact name of the containersHow many containers have been passed

Can be used in any programming language program supported by CICS/TS V3 and laterA server program can be written to handle multiple channels. It can, for example:

Discover, dynamically, the channel that it was invoked withBrowse the containers in the channelVary its processing according to the channel it's been passed

4

Introduction


Benefits There is no need to know the name of a channel ahead of time; the EXEC CICS ASSIGN CHANNEL command can be used to determine the name of the channel. For containers, there is a STARTBROWSE CONTAINER command that can be used; when used with the CHANNEL option and followed by a series of GETNEXT CONTAINER command, it will return the name of all the containers in the channel.



Benefits

Can be used with DPLYou can build "components" from sets of related programs invoked through one or more channels.The loose coupling between clients and components permits easy evolution. The programmer is relieved of storage management concerns.

CICS automatically destroys containers (and their storage) when they go out of scope.

The data conversion model used by channel applications is much simpler than that used by COMMAREA applications. Programs that use containers can be called from both channel and BTS applications.Non-BTS applications that use containers can be migrated into full BTS applications.

5

Introduction


Benefits

Channel containers are not recoverable. If you need to use recoverable containers, use CICS business transaction services (BTS) containers.

Channel and Containers CANNOT BE USED in programs that will execute in a 3270-bridge environment

6

We could not find anywhere in the CICS documentation where this problem was discussed but we had a problem testing one of our 3270-bridge transaction in CICS/TS V3. Here is the scenario:

♦ From a web browser, we entered the following URL:

HTTP://MYHOST:9093/CICS/CWBA/DFHWBTTA/ABCD

♦ This command triggered ABCD under the 3270-bridge interface

♦ Program started and the first iteration of the program ran fine

♦ This program had been changed to use CHANNEL instead of COMMAREA

♦ When the data was entered in response to the first execution of the program, it executed the “first time” routine again. Running this with a debugger, we noticed the program had received a CONTAINERERR condition, container not found.

♦ This makes sense since, in a bridge environment, the virtual terminal is recreated every time a message is received.

http://myhost:9093/CICS/CWBA/DFHWBTTA/ABCD



Commands

There are 5 new commands in the API:

DELETE CONTAINERGET CONTAINERMOVE CONTAINERPUT CONTAINER START CHANNEL

Because of the introduction of container, the following commands had to be modified:

EXEC CICS ASSIGNEXEC CICS DELETE CONTAINER (BTS)EXEC CICS ENDBROWSE CONTAINEREXEC CICS GET CONTAINER (BTS)EXEC CICS GETNEXT CONTAINEREXEC CICS HANDLE ABENDEXEC CICS LINK PROGRAMEXEC CICS MOVE CONTAINER (BTS)EXEC CICS PUT CONTAINER (BTS)EXEC CICS RETURNEXEC CICS STARTBROWSE CONTAINEREXEC CICS XCTL

7

Commands There are 5 new commands in CICS that will allow you to manipulate containers:

♦ EXEC CICS DELETE CONTAINER will allow you to delete an existing container

♦ EXEC CICS GET CONTAINER will retrieve the data in the named container; note that here, the data can be read in the program working-storage as opposed to be available in Linkage Section

♦ EXEC CICS MOVE CONTAINER will allow you to move data to a new container

♦ EXEC CICS PUT CONTAINER will allow you to save data in a new container

♦ EXEC CICS START CHANNEL is now really a new command but will be used instead of START FROM when another transaction is started

There are a number of commands that have been changed to support CHANNEL and CONTAINER; the list is shown above.

Introduction


Commands

You create a channel by naming it on one of the following commands: EXEC CICS LINK PROGRAM CHANNELEXEC CICS MOVE CONTAINER CHANNEL TOCHANNELEXEC CICS PUT CONTAINER CHANNELEXEC CICS RETURN TRANSID CHANNELEXEC CICS START TRANSID CHANNELEXEC CICS XCTL PROGRAM CHANNEL

If the channel doesn't already exist, within the current program scope, it is created. If the channel named on the following commands doesn't already exist, within the current program scope, an empty channel is created:

EXEC CICS LINK PROGRAM CHANNEL(channel-name)EXEC CICS RETURN TRANSID CHANNEL(channel-name)EXEC CICS START TRANSID CHANNEL(channel-name)EXEC CICS XCTL PROGRAM CHANNEL(channel-name)

8

CHANNELs are created by using a 16-byte name. When use with one of the above commands, they are mutually exclusive with COMMAREA’s.

CHANNEL can be used with commarea’s within the same program or transaction. For example:



WebserviceOverview

Software system designed to support interoperable machine-to-machine interaction over a network.

It has an interface described in a machine-processable format (specifically, Web Service Definition Language, or WSDL).A Web service is described using a standard, formal XML notion, called its service description, that provides all of the details necessary to interact with the service, including message formats (that detail the operations), transport protocols, and location

It conforms to open-standards including:SOAP 1.1 and 1.2HTTP 1.1WSDL 2.0

CICS can be a requester or provider of services or bothThe supplied software supports 2 transport protocols:

MQ-seriesHTTP

2

Introduction


Webservice Overview Web services is a technology for deploying, and providing access to, business functions over the World Wide Web using loosely coupled servers. Web services make it possible for applications to be integrated more rapidly, easily, and cheaply than ever before.

The CICS/TS V4 implementation is conformed to the following standards:

♦ HTTP 1.1

♦ SOAP 1.1 and 1.2

♦ WSDL 2.0

Programs in CICS/TS V4 can act as requester or server. CICS/TS V4 supports the following transport mechanism:

♦ MQ-series

♦ HTTP



Webservice Overview

CICS/TS V4 also provides a web services assistant which can help deploying applications.

The assistant will support applications written in:COBOLPL/1CC++

Includes 2 utilities:DFHLS2WSDFHWS2LS

2 more utilities were introduced in CICS/TS 4.1; these utilities will help you convert data structures to schemas and convert schemas to data structure.

These utilities can also be used to help creating web servicesDFHSC2LSDFHLS2SC

3

Introduction


Webservice Overview The support for Web services includes the CICS Web services assistant, a set of batch utilities which can help you to

♦ 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, and supports COBOL, C/C++, and PL/I. It also generates information used to enable automatic runtime conversion of the SOAP messages to containers and COMMAREAs, and vice versa

Program DFHLS2WS will transform a language structure into a WSDL document

Program DFHWS2LS will transform a WSDL document into a language structure

Two new utilities were added in CICS/TS V4:

♦ DFHSC2LS is a utility that will convert an XML schema to language structure.

♦ DFHLS2SC is a utility that converts a language structure to XML schema

♦ Both utilities support COBOL, C/C++ AND PL/1

♦ CICS does not support WXS schema; only XSD schemas are supported



WebserviceOverview

WEB SERVICE application can be deployed:Using the WEB services assistant (least amount of programming effort)

Using a data structure, the CICS web services assistant can be used to generate the CICS resources that need to be deployedThe message will be transformed automatically into a SOAP message by CICS

You can write your own message handler to process the data you are receiving

This will be the case when the message you are receiving is a non-SOAP message

Note: To use the web services assistant, SOAP must be the protocol used to transfer data between nodes

4

Introduction


Webservice Overview The assistant supports rapid deployment of CICS applications for use in service providers and service requesters, with the minimum of programming effort.

When you use the Web services assistant for CICS, you do not have to write your own code for parsing inbound messages, and constructing outbound messages; CICS maps data between the body of a SOAP message and the application program's data structure.

Resource definitions are, for the most part, generated and installed automatically. You do have to define PIPELINE resources, but you can, in many cases, use one of the pipeline configuration file that CICS provides. These are:

♦ basicsoap11provider.xml

Pipeline configuration file for a service provider using the SOAP 1.1 message handler.

♦ basicsoap11requester.xml

Pipeline configuration file for a service requester using the SOAP 1.1 message handler.

If you decide not to use the CICS Web services assistant, you will have to:

♦ Provide your own code for parsing inbound messages, and constructing outbound messages

♦ Provide your own pipeline configuration file

Define and install your own URIMAP and PIPELINE resources



WebserviceDeployment

2 files are required to deploy a webservice:The Web Service Description Language file

This file is known as the Webservice file and has a file type of WSDL

The binding fileIt has a file type of WSBINDIt used by the CICS data wrappers to format the data When it is received by a webservice provider Before it is given to a webservice provider

As stated earlier, 2 utilities are provided to help generating these files:

DFHLS2WS or DFHLS2SC is used when setting up a service providerIt will take as input a data structure and create the above 2 files

DFHWS2LS or DFHSC2LS is used when setting up a service requesterIt will take a WSDL file as input and create the data structure

7

Introduction


Webservice Deployment To use web services in CICS, we need to generate 2 files:

♦ The web service description file:

It contains information about the mechanic of the webservice; information such as port number, program to invoke, target system information, etc. can be found in there

This is a file that is stored in HFS (Unix System Services File System) and it has a file type of WSDL

♦ The binding file:

Used by the CICS data wrappers to format data when it is received by the provider and before it is given to the requester

This is a file that is stored in HFS (Unix System Services File System) and it has a file type of WSBIND

In a typical environment, the provider application will be built first or will already be in existence. DFHLS2WS should be used to create the WSDL and binding files for the provider program. DFHWS2LS should use an existing WSDL file as input; this utility will create a binding file as output as well as data structures which can be copied into the requesting program.

The schema utilities, DFHSC2LS and DFHLS2SC only manipulate 1 file, the XML schema.



WebserviceMessage handlers and pipelines

Message handlers are invoked at specific points in the pipelinePipelines will typically have 2 phases:

A request phaseA response phase

Pipelines could be setup as:Service provider pipelinesService requestor pipelines

Message handlers can:Process the messageInterrupt the flowIgnore the message entirely

11

Introduction


Webservice Message Handlers and Pipelines A message handler is a CICS program used to process a Web service request during input, and to process the response during output. Message handlers use channels and containers to interact with one another, and with the system. Message handlers are defined as part of the PIPELINE configuration.

PIPELINEs can be compared to a list of pre-defined actions which must all be done in order to execute a given function. They are defined to CICS by using a PIPELINE resource definition. CICS uses this definition to get the name of the PIPELINE configuration file; this file provides the system with the following information:

♦ Transport protocol being used

♦ Name of message handlers

♦ Information about the target environment

When a message is received, CICS will start the pipeline by invoking the first message handler; then, all message handlers will be invoked, 1 after the other, until the last message handler has been invoked. This is the request phase. One all message handlers have executed, the pipeline will be in response phase and invoke all the message handlers in the reverse order. During the request phase, a message handler may decide to interrupt the process and provide a response immediately; in this case, the process will switch to response mode some handlers may not execute.



WebserviceMessage Handler

Used to process a request during input and process a response during outputSet of programs which will be invoked at various times during the execution of the pipeline

Interaction between programs is via CHANNEL CONTAINERSInteraction between programs and system is also using CHANNEL CONTAINERS

What you can do:Examine or change content of XML requestPass XML request or response to the next message handler in the pipelineUsed to parse message and provide a response automaticallyHandle errors

12

Introduction


Webservice Message Handler The message handler interface lets you perform the following tasks in a message handler program:

♦ Examine the contents of an XML request or response, without changing it

♦ Change the contents of an XML request or response

♦ In a non-terminal message handler, pass an XML request or response to the next message handler in the pipeline

♦ In a terminal message handler, call an application program, and generate a response

♦ In the request phase of the pipeline, force a transition to the response phase, by absorbing the request, and generating a response

♦ Handle errors

Note: It is advisable to use the CICS-provided SOAP 1.1 and SOAP 1.2 handlers to work with SOAP messages.



WebservicePipelines

CICS/TS V4 provides special SOAP message handlers that can help you configure your pipeline as SOAP node:

Support for SOAP 1.1 or 1.2As a service requester

It performs the initial request and is the ultimate SOAP receiver for the response

As a service providerIt is the ultimate receiver for the request and will be the SOAP sender for the response

The supplied program can invoke user routines

2 pipeline configuration files are used by CICS:basicsoap11provider.xml used for setting up service providersbasicsoap11requester.xml used for setting up a service requesterThese files are created by CICS when the product is installedThey are found as HFS files in USS

21

Webservice Pipelines When deploying web services with the help of the web service assistant, you will need to set up 2 pipelines:

♦ A Provider pipeline ♦ A requester pipelines

These pipelines will tell CICS about the configuration of the pipelines as well as tell the system about where to pickup the information about your application. This is called the pickup directory.

When the pipeline is installed, CICS will:

♦ Copy the web service information from the pickup directory to the pipeline shelf directory

♦ Install the necessary URIMAP and WEBSERVICE resources

Here is a configuration file for a provider pipeline:

Introduction


In the above file we have the following information:

♦ There is no terminal handler; we used the CICS-provided SOAP 1.1 message handler

♦ The application handler is program DFHPITP

Here is a configuration file for a requester pipeline:

The pipeline contains just one message handler, the CICS-supplied SOAP 1.1 message handler. The application program that is invoked from the SOAP handler is DFHPITP.

♦ The <provider_pipeline>element is the root element of the pipeline configuration file for a service provider pipeline.

♦ The <service>element specifies the message handlers that are invoked for every request. In the example, there is just one message handler.

♦ The <terminal_handler>element contains the definition of the terminal message handler of the pipeline.

♦ The <cics_soap_1.1_handler>indicates that the terminal handler of the pipeline is the CICS-supplied handler program for SOAP 1.1 messages.

The <apphandler>element specifies the name of the CICS program that the terminal node of the pipeline will link to by default. In this case the program is DFHPITP, which is the target program for applications deployed with the CICS Web services assistant.

<?xml version="1.0" encoding="EBCDIC-CP-US"?> <requester_pipeline xmlns="http://www.ibm.com/software/htp/cics/pipeline" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.ibm.com/software/htp/cics/pipeline requester.xsd "> <service> <service_handler_list> <cics_soap_1.1_handler/> </service_handler_list> </service>

<?xml version="1.0" encoding="EBCDIC-CP-US"?> <provider_pipeline xmlns="http://www.ibm.com/software/htp/cics/pipeline" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.ibm.com/software/htp/cics/pipeline provider.xsd "> <service> <terminal_handler> <cics_soap_1.1_handler/> </terminal_handler> </service> <apphandler>DFHPITP</apphandler>



Webservice Resources: PIPELINE

CEDA DEFINE PIPELINE(name) GROUP(group name)

CONFIGFILE(name)

RESPWAIT(value)

SHELF(/var/cicsts) or directory

STATUS(enabled or disabled)

WSDIR(directory name)

Configfile: name of an HFS file containing information about the processing node

Shelf: location of the web service binding file

WSDIR: Fully qualified name of the web service directory (pick up file)

RESPWAIT value could be DEFT or a number from 0 to 9999

22

Webservice Resources: PIPELINE PIPELINE

A PIPELINE resource definition is required in every case. It provides information about the message handler programs that act on a service request and on the response; the PIPELINE specifies the name of an HFS file which contains an XML description of the nodes and their configuration.

A PIPELINE resource that is created for a service requester cannot be used for a service provider, and vice versa. The two sorts of PIPELINE are distinguished by the contents of the pipeline configuration file that is specified in the CONFIGFILE attribute: for a service provider, the top level element is <provider_pipeline>; for a service requester it is <requester_pipeline>.

There must be a PIPELINE definition for each pipeline configuration the system will be using. PIPELINE can be reloaded in CICS when they are changed; use the following command to accomplish this: CEMT PERFORM PIPELINE(pipeline_name) SCAN

Introduction


Webservice Resources: WEBSERVICE

CEDA DEFINE WEBSERVICE(name) GROUP(group name)

PIPELINE(name)

WSBIND(hfs filename)

VALIDATION(YES or NO)

WSDLFILE(hfs file name)

PIPELINE: name of the pipeline this service is to be associated with

VALIDATION: whether SOAP message are to be validated or not

WSBIND: fully qualified name of the WS binding file

WSDLFILE: fully qualified name of the web service description language file

23

Webservice Resources: WEBSERVICE WEBSERVICE

A WEBSERVICE resource definition is required only when the mapping between application data structure and SOAP messages has been generated using the CICS Web services assistant. It defines aspects of the run time environment for a CICS application program deployed in a Web services setting.

This definition should install dynamically when the PIPELINE is installed. This is something you are likely to define yourself if you decide not to use SOAP…

The VALIDATION attribute is important: when set to yes, CICS will make sure the data with the message is compliant with the definition found in the WSDL.



SOAPOverview

This is a protocol used in exchange of information in a distributed environment.

Soap messages are encoded in XML documents

In a standard SOAP environment, you will find:SOAP messageSOAP nodesSOAP senderSOAP receiverSOAP faults

26

Soap Overview The SOAP specifications describe a distributed processing model in which a SOAP message is passed between SOAP nodes. The message originates at a SOAP sender and is sent to a SOAP receiver. Between the sender and the receiver, the message may be processed by one or more SOAP intermediaries.

A SOAP message is a one-way transmission between SOAP nodes, from a SOAP sender to a SOAP receiver, but messages can be combined to construct more complex interactions, such as request and response, and peer-to-peer conversations.

The specification also describes a set of encoding rules for expressing instances of application-defined data types; it is also a convention for representing remote procedure calls and responses.

Introduction


SOAPOverview

Contains the following elements:<Envelope> element<Header> optional element<Body> mandatory element

The SOAP envelope is the root elementThe SOAP headers are used to pass application-related information

User-written programs will have to be written to process these

SOAP body contains the information to be processedSOAP fault

Sub-element of the SOAP bodyUsed to report error and status

SOAP ENVELOPE

SOAP HEADER

SOAP BODY

27

Soap Overview A SOAP message is encoded as an XML document, consisting of an <Envelope> element, which contains an optional <Header> element, and a mandatory <Body> element. The <Fault> element, contained within the <Body> is used for reporting errors



Service Provider pipeline

CICS/TS V4

TCPIPSERVICE WEBSERVICE URIMAP PIPELINE

WEB SERVICE

CICS

APPLICATION

SERVICE

RQUESTERDATA

MAPPERPIPELINE

WSDL BINDING

FILE

2

Introduction


Service Provider Pipeline A message handler in the pipeline (typically, a CICS-supplied SOAP message handler) removes the SOAP envelope from an inbound request, and passes the SOAP body to the data mapper function.

This uses the Web service binding file to map the contents of the SOAP body to the application's data structure. If full validation of the SOAP message is active, then the SOAP body is validated against the Web service description. If there is an outbound response, the process is reversed.

The Data mapper uses the Web Service Description Language file to map the data in a channel or commarea to be passed to the application program.

THE URIMAP definition is used to provide the name of the PIPELINE to be used for this request.

The PIPELINE provides the directory names for the pickup shelf and configuration file

The WEBSERVICE definition provides the name of the binding file and the name of the PIPELINE

The TCPIPSERVICE provides the port number on which the request will come



WebserviceService Requester pipeline

WEBSERVICE PIPELINE

WEB SERVICE

CICS

APPLICATION

DATA

MAPPER

WSDL BINDING

FILE

CICS/TS V4

PIPELINESERVICE

PROVIDER

2

Introduction


Webservice Service Requester Pipeline For an outbound request, the data mapper function constructs a SOAP body from the application's data structure, using information from the Web service binding file. A message handler in the pipeline (typically, a CICS-supplied SOAP message handler) adds the SOAP envelope. If there is an inbound response, the process is reversed. If full validation of the SOAP message is active, then the inbound SOAP body is validated against the Web service description.

In both cases, the execution environment that allows a particular CICS application program to operate in a Web services setting is defined by three objects. These are the pipeline, the Web service binding file, and the Web service description. The three objects are defined to CICS as attributes of the WEBSERVICE resource definition.



WSDL 2.0

WSDL 2.0 is a “Candidate Recommendation” with the W3CCICS conditionally complies with WSDL 2.0

Mandatory requirementsOnly the message exchange patterns in-only, in-out, robust in-only, and in-optional-out may be used in the WSDLOnly one Endpoint is allowed for each ServiceThere must be at least one OperationEndpoints may only be specified with a URIThere must be a SOAP bindingThe XML schema type must be used

12

WSDL 2.0 The WSDL 2.0 specification is a W3C Candidate Recommendation. If changes are made to this specification as it progresses to a W3C Recommendation then there may be delay or change to the implementation of WSDL 2.0 support in CICS TS V3.2.

In CICS/TS 4.1, wsdl mapping level 2.2 and 3.0 are also supported.

Introduction




WSDL 2.0MTOM/XOP

In standard SOAP messages:Binary objects are base64 encodedIncluded in the message body

Significantly increases their sizeCan impact message parsing timeCan impact transmission time

MTOM/XOP provides a solution to this problemThe MTOM specification

Defines a method for optimizing SOAP messages Separates out binary data Sends it in separate binary attachments using a MIME (Multipurpose

Internet Mail Extension) Multipart/Related messageThe XOP specification

Defines an implementation for optimizing XML messages Uses binary attachments in a packaging format

» Includes but is not limited to MIME messages

18

Introduction


WSDL 2.0 MTOM/XOP In standard SOAP messages, binary objects are base64 encoded and included in the message body. This significantly increases their size, and for very large binary objects, this can impact transmission time. Implementing MTOM/XOP provides a solution to this problem.

The SOAP Message Transmission Optimization Mechanism (MTOM) and XML-binary Optimized Packaging (XOP) specifications, often referred to as MTOM/XOP, define a method for optimizing the transmission of large base64binary data objects within SOAP messages.

♦ The MTOM specification conceptually defines a method for optimizing SOAP messages by separating out binary data, that would otherwise be base64 encoded, and sending it in separate binary attachments using a MIME Multipart/Related message. This type of MIME message is called an MTOM message. Sending the data in binary format significantly reduces its size, thus optimizing the transmission of the SOAP message.

♦ The XOP specification defines an implementation for optimizing XML messages using binary attachments in a packaging format that includes but is not limited to MIME messages.

The size of the base64binary data is significantly reduced because the attachments are encoded in binary format. The XML in the SOAP message is then converted to XOP format by replacing the base64binary data with a special <xop:Include> element that references the relevant MIME attachment using a URI.



Security

In this environment, there are 4 ways to secure SOAP processing:Basic securityImplementing WS-securityImplementing WS-TrustImplementing/activating Secured Socket Layer support in CICS

Each of these facilities has its pro’s and con’sImplementation depends on:

Who is using the system?Your knowledge of the environmentHow much programming you would like to do

3

Introduction


Security There are 4 methods for securing access to our CICS systems when web services are used:

♦ Basic security which will consist of making sure the web service is processing under a userid known to the security manager

♦ WS-Security which will consist of sending a SOAP message that has the following attributes:

Authentication by means of userid/password Integrity by means of using a digital signature Confidentiality by means of using encryption

♦ Implementing WS-Trust which will perform security checking by using TOKENS as opposed to using userid’s. Authentication is performed by the Token server.

♦ Implementing SSL/TLS support in CICS

Each facility has its own pro’s and con’s and the implementation will largely depend on one installation’s security policy. There are also other factors that will influence the selection of the security mechanism. They are:

♦ Is the system used internally or is it used by the general public via internet? In this case, there is probably only one viable choice and that would be the implementation of SSL/TLS

♦ If the system is to be used internally, how sensitive is the data? And is there another mean of authenticating the user? If the user has already been authenticated, there is no point authenticating again and may be placing a USERID on the URIMAP definition will do the trick

♦ If the number of client machines is small but the application needs to know who the requester is, WS-security might be an option. This option will require you to write some code to process the SOAP header that will accompany the message; this is not complicated but it will force you to use non-standard PIPELINE configuration and it will be code you will have to support. Finally, more code means more overhead on your system.

♦ Do you already have a Token Server? If so, it should simplify the implementation of WS-Trust a great deal.

If you are new to SSL/TLS in CICS, may be starting with this means you will have to put the necessary infra-structure in place before the system goes production. This is not difficult to do but it will add activities top your workload



SecurityBasic security

Basic security is achieved by specifying a USERID on one of the following resources:

TCPIPSERVICEURIMAPCORBASERVER

When used, CICS will:Start the CPIH transaction under this transaction codeThe USERID on the URIMAP/TCPIPSERVICE will be used as surrogate USERIDThis USERID will have to be authorized to start the specified transaction

4

Introduction


Security Basic Security Basic security is achieved by providing the system a USERID under which the transaction will run. This can be done by altering one of these definitions:

♦ TCPIPSERVICE

♦ URIMAP

♦ CORBASERVER

The URIMAP resource definition should be changed when we want specific webservices to run under specific USERID’s. This method should be used when the user has already been authenticated by the system. CICS will attach the transaction under the USERID specified in the URIMAP. To activate this support, you need to modify the following SIT attributes:

SEC=YES

SECPRFX=YES

XTRAN=YES

XUSER=YES



SecurityBasic security

Advantages:Simple implementationRequires little amount of work

Disadvantages:Too simple for most installationsDoes not do any encryptionEasy to crackShould not be used in a WEB environmentDoes not provide authentication

5

Security Basic Security Advantages:

It is the simplest implementation you can have as this work can be done in less than 1 hour.

Disadvantages:

It is much too simple for most installations as it will probably not meet security requirements for these types of system.

These is also no encryption available with this method…encryption would be highly recommended if the application is to be used from the internet.

Since there is no signon, it will be impossible for you to fully authenticate the request.

Introduction


SecuritySOAP message security

This is called WS-SecurityFirst version proposed by IBM, Microsoft and Verisign in April 2002Transferred to the OASIS consortium as of that date

Latest word from this consortium came out in February 2006

It provides:Set of SOAP message extensions for building secure Web ServicesNew SOAP elements to be used in SOAP header

HTTP://www.oasis-open.org

6

Security SOAP Message Security The first version of the WS-Security specification was proposed by IBM, Microsoft, and VeriSign in April 2002. After the formalization of the April 2002 specification, the specification was transferred to the OASIS consortium: http://www.oasis-open.org.

This facility provides a set of SOAP message extensions which can be used to build secured web services. Specifically, these extensions are SOAP headers with special element containing security information.

http://www.oasis-open.org/



SecuritySOAP message security

Advantages:Provides a mean of authenticating the requesterCan be used to provide true signon mechanism as opposed to surrogate processing available with URIMAPsAlso provides confidentiality because encryption is possible

Disadvantages:Not yet supported by CICSSupport available via message handlers to process SOAP HeadersExtends the processing of the message by CICS

8

Security SOAP Message Security Advantages:

It provides a mean of authenticating the requester with integrity; depending on how the message handler is written, it can also provide a true signon mechanism.

Because it is possible to use some encryption, it also provides confidentiality.

Disadvantages:

This facility is not yet supported by CICS so the verification process must be done in message handlers written by someone in the installation. The code can be written in any of the CICS supported languages. The code will have to:

♦ Retrieve the SOAP header ♦ Parse its content to locate USER/ID and PASSWORD ♦ Issue, at the very least, a EXEC CICS VERIFY PASSWORD command ♦ Manage the various error conditions that might arise in this environment

Introduction




SecuritySSL/TLS support

This support has been available in CICS since CICS/TS 1.3It will provide:

Authentication – if CLIENTAUTH is usedIntegrityConfidentiality

It is also relatively easy to implement

9

Introduction


Security SSL/TLS Support This is probably the best approach to securing web services in CICS. This support has been available since CICS/TS 1.3 and IBM has constantly been making performance improvements to this facility.

It is strongly recommended to use CLIENT AUTHENTICATION when activating SSL/TLS support in CICS; this facility along with encryption will provide you with integrity, authentication and confidentiality attributes required to provide adequate security on your CICS systems.

Finally, as we will demonstrate in the next few pages, it is relatively easy to install.



SecuritySSL/TLS support

Advantages:Easy to implementFulfill most security requirementsSupport is available today

Disadvantages:Add about 5% overhead to CICSSomeone has to manage SSL certificates

RevocationExpiry datesFTP to client machines

11

Introduction


Security SSL/TLS Support Advantages:

This is easy to install and there is no programming required to activate this function, contrary to WS-security .

The support is readily available in CICS; it has been available since CICS/TS 1.3 and IBM has constantly been upgraded by IBM.

Disadvantages:

The main disadvantage of this facility is not technical in nature; you will have to manage the certificate environment i.e. their expiry date, revocation of certificate no longer valid, associating userid’s with certificate, etc. If you r installation has been using SSL for other applications, these mechanism are already in place so this will not pose a problem. On the other hand, if this is the first time you will be using this facility, these mechanism will have to be implemented at the same time you will be rolling out the new web service application…

There is also a slight overhead in CICS, about 5%...something to consider



WS-Trust

Submitted to OASIS standardization processDerived from W3C specification dated 25 February 2005

Provides a framework for building trust relationshipsSender and Receiver in different security domainsSecurity tokens must be vouched for by trusted third partyTrusted third party, called Security Token Service (STS)

WS-Trust defines standard protocols and standard WSDL interfaces to communicate with an STS

12

Introduction


WS-Trust The Web Services Trust Language specification enhances Web Services Security further by providing a framework for requesting and issuing security tokens, and managing trust relationships between Web service requesters and providers. This extension to the authentication of SOAP messages enables Web services to validate and exchange security tokens of different types using a trusted third party. This third party is called a Security Token Service (STS).



WS-Trust

Interoperate with a Security Token ServerCICS supplied security handler

Inbound messages

Validate the security token in the WS-Security headerExchange the security token in the WS-Security header

Outbound messages

Exchange the security token to be used in the WS-Security header

Trust Client InterfaceUser supplied custom message handler

No requirement for the CICS provided security handler

Directly interact with an STSIssue or validate security tokens from the message header

Channel and container interface

13

Introduction


WS-Trust CICS support for securing Web services has been enhanced to include an implementation of the Web Services Trust Language (or WS-Trust) specification. CICS can now interoperate with a Security Token Service (STS), such as Tivoli Federated Identity Manager, to validate and issue security tokens in Web services. This enables CICS to send and receive messages that contain a wide variety of security tokens, such as SAML assertions and Kerberos tokens, to interoperate securely with other Web services.

You can configure the CICS-supplied security handler to define how CICS should interact with an STS. The <wsse_handler> element in the pipeline configuration file now includes additional elements and attributes to configure this support. CICS can either validate or exchange the first security token or the first security token of a specific type in the message header. If you want more sophisticated processing to take place, CICS provides a separate Trust client interface that you can use in a custom message handler.

You can use the Trust client instead of the security handler or in addition to it.



WS-Trust

Advantages:Provides a mean of authenticating the requesterShould be faster than WS-securityAlso provides confidentiality because encryption is possible

Disadvantages:Not yet sanctioned by OASISSupport available via message handlers that process SOAP HeadersExtends the processing of the message by CICSIntroduces a new kind of servers: TOKEN srevers

15

WS-Trust

introduction to relational databases

Documents