Web services IBM-CICS

Web services are self-contained, modular applications that can be described, published, located, and invoked over a network.

Web services are becoming the standard for basic SOA implementation by taking advantage of existing open-standard Web technologies such as XML, URL, and HTTP. These comprise a set of standards that facilitate open system-to-system communication. By adhering to Web services, applications that are based on different platforms and technologies can cooperate through well defined interfaces. Web services follow the SOA philosophy of loose coupling between service requesters and providers.

The formal definition of a Web service, provided by the World Wide Web consortium (W3C) Services Architecture Working Group is as follows:
A web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web services in a manner prescribed by it’s description using SOAP messages, typically conveyed using HTTP with and XML serialization inconjunction with other Web-related standards.

1.Properties of a Web service
While this is widely documented, it can be summarized that all Web services share the following properties:

  • Web services are self contained. On the client side, no additional software is required. A programming language with XML and HTTP client support is a minimum requirement. On the server side, an HTTP server and a SOAP server are required.
  • Web services are self-describing. A Web Service Description Language (WSDL) file provides all the information needed to implement a Web service as a provider, or to invoke a Web service as a requester.
  • Web services can be published, located, and invoked across the Web. Existing infrastructure by way of established lightweight internet standards such as HTTP are used.
  • Web services are modular. Simple Web services can combined to form more complex implementations, shortening development time.
  • Web services are language-independent and interoperable. The client and server can be implemented in different environments and operating system platforms. Any language can be used to implement Web service clients and servers.
  • Web services are inherently open and standards-based. XML and HTTP are the major technical foundation. A large part of the Web service technology was built using open source methodology, maintaining vendor independence.
  • Web services are loosely coupled. A service requester has to know the interface to a Web service, but not the details of how it was implemented.
  • Web services provide the ability to wrap existing applications. This is done by providing a Web service as an interface to the application.

2.Web service standards

Web services standards and specifications change rapidly to keep up with emerging technologies.

Then, within each standard there are a number of specifications that we will outline.

Core standards of Web Services

Core standards of Web Services

Figure outlines the eight standards of Web service, which we discuss further in the following list.

a. Business processes

A business process specifies the potential execution order of operations from a collection of Web services, the data shared between these Web services, which partners are involved, and how they are involved in the business process. It also includes joint exception handling for collections of Web services and other issues involving how multiple services and organizations participate. BPEL (Business Process Execution Language) specifies business processes and how they relate to Web services.

b. Management

Web services manageability is defined as a set of capabilities for discovering the existence, availability, health, performance, usage, as well as the control and configuration of a Web service within the Web services architecture. As Web services become pervasive and critical to business operations, the task of managing and implementing them is imperative to the success of business operations.

c. Reliability

It is not possible to solve business issues if the participants are unable to be sure of the completion of message exchanges. Reliable messaging, which allows messages to be delivered reliably between distributed applications in the presence of software component, system, or network failures, is therefore critical to Web services.

d. Transactions

Transactions are a fundamental concept in building reliable distributed applications. A Web service environment requires coordination behavior provided by a traditional transaction mechanism to control the operations and outcome of an application. The specifications include the following:

  • Web services atomic transactions
  • Web services business activity
  • Web services co-ordination

e. Security

There are a number of specifications that applications can engage in secure communication that are designed to work with the general Web services framework. Following are some of these specifications:

  • Web services Federation Languages
  • Web services Trust
  • Web services Security policy
  • Web services Secure Conversation Language

f. Description and discovery

Web services are meaningful only if potential users may find information sufficient to permit their execution. The focus of these specifications and standards is the definition of a set of services supporting the description and discovery of businesses, organizations, and other Web services providers, the Web services they make available, and the technical interfaces which may be used to access those services.

Amongst others, some of these specifications are discussed in a following section and pertain to the CICS implementation of Web services:

  • UDDI
  • WSDL

g. Messaging

These messaging standards and specifications are intended to give a framework for exchanging information in a decentralized, distributed environment. CICS TS provides support for the SOAP specifications.

h. Transports

BEEP, the Blocks Extensible Exchange Protocol (formerly referred to as BXXP), is a framework for building application protocols. It was standardized by IETF and does for Internet protocols what XML does for data.

3.WS standards in CICS TS

Certainly CICS TS adheres to many of the specifications outlined in the previous section, and the following are of particular interest to the development of Web services in CICS:

  • Description and Discovery - in particular UDDI and WSDL.
  • WS-Transactions - the family of specifications that relate to transactional Web services.
  • WS-Security - the family of specifications that relate to securing Web services.
  • Messaging - the SOAP for CICS feature and incorporation of SOAP message handlers.

Following is additional terminology that describes some key specifications that are useful within the scope of this publication:


Extensible Markup Language or XML is the foundation of Web services. However, since much information is already written about XML, we do not describe it here.


SOAP provides an XML, text-based platform and language neutral message format. Originally proposed by Microsoft®, SOAP was designed to be a simple and extensible specification for the exchange of structured XML-based information in a decentralized, distributed environment. As such, it represents the main means of communication between the three functional components in an SOA: the service provider, the service requester, and the service registry.

There are currently two versions of SOAP: Version 1.1 and Version 1.2.

The SOAP specification consists of the following three parts:

  • An envelope that defines a framework for describing message content and processing instructions. Each SOAP message consists of an envelope that contains a number of headers and one body that carries the payload, or data, to exchange. SOAP messages may also contain faults that report failures or unexpected conditions.
  • A set of encoding rules for expressing instances of application-defined data types.
  • A convention for representing remote procedure calls and responses.

A SOAP message is, in principle, independent of the transport protocol that is used: HTTP, JMS, SMTP, or FTP. The most common way of exchanging SOAP messages is through HTTP.


Web services Description Language (WSDL) uses XML to specify the characteristics of a Web service, what the Web service can do, where it resides, and how it is invoked. WSDL can be extended to allow descriptions of different bindings, regardless of what message formats or network protocols are used to communicate.

WSDL enables a service provider to specify the following characteristics of a Web service:

  • The name of the Web service and addressing information.
  • The protocol and encoding style to be used when accessing the public operations of the Web service
  • The Type information: operations, parameters, and data types comprising the interface of the Web service, including a name for this interface.

WSDL is not bound to any protocol or network service. It can be extended to support many different message formats and network protocols. However, because Web services are mainly implemented using SOAP and HTTP, the corresponding bindings are part of this standard.


The Universal Description, Discovery, and Integration standard defines a means to publish and to discover Web services. The current release is UDDI Version 3.0.

4. Implementing Web services

Implementing Web services

Web services invocation model

Following is a description of the interaction in above Figure

  • The service provider publishes the Web Services Description Language (WSDL) data that defines its interface and location to a service registry such as the Universal Description, Discovery, and Integration (UDDI) service registry.
  • The service requester contacts the service registry to obtain reference to a service provider.
  • The service requester, having obtained the location of the service provider, makes calls on the provider by sending a SOAP-formatted message.

Web service Usage Models

Basic Web services support provides the following three simple usage models:

  • One-way usage scenario - a Web services message is sent from a requester to a provider, and no response message is expected.
  • Synchronous request or response usage scenario - a message is sent from a requester to a provider and a response message is expected.
  • Basic callback usage scenario - a message is sent from a requester to a provider using the 2-way invocation model, but the response is treated only as an acknowledgement of a request having been received. The provider then responds by using a Web service callback to the requester.

Other Web service standards are built upon these basic standards and invocation models to provide higher level functions and qualities of service.

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status