UNIT II

Key Technologies and Standards:

SOAP - Simple Object Access Protocol

Simple Object Access Protocol(SOAP) is a network protocol for exchanging structured

data between nodes. It uses XML format to transfer messages. It works on top of
application layer protocols like HTTP and SMTP for notations and transmission. SOAP
allows processes to communicate throughout platforms, languages, and operating system,
since protocols like HTTP are already installed on all platforms. SOAP was designed by Bob
Atkinson, Don Box, Dave Winer, and Mohsen Al-Ghosein at Microsoft in 1998. SOAP was
maintained by the XML Protocol Working Group of the World Wide Web Consortium until
2009.

 SOAP stands for Simple Object Access Protocol

 SOAP is an application communication protocol
 SOAP is a format for sending and receiving messages
 SOAP is platform independent
 SOAP is based on XML
 SOAP is a W3C recommendation

Understanding SOAP Messages, Structure (headers & body):

SOAP message transmits some basic information as given below

 Information about message structure and instructions on processing it.
 Encoding instructions for application-defined data types.
 Information about Remote Procedure Calls and their responses.

The message in XML format contains four parts-

 Envelope: This specifies that the XML message is a SOAP message. A SOAP
message is an XML document containing a header and a body, both encapsulated
within the envelope. Any fault is included within the body of the message.
 Header: This part is optional. When present, it can provide crucial information
about the applications.
 Body: This contains the actual message being transmitted. Faults are contained
within the body tags.
 Fault: This optional section contains the status of the application and any errors.
 It should not appear more than once in a SOAP message.

Sample Message

Content-Type: application/soap+xml
<env:Envelope xmlns:env="[Link]

<env:Header>
<m:GetLastTradePrice xmlns:m="Some-URI" />
</env:Header>
<env:Body>
<symbol xmlns:p="Some-URI" >DIS</symbol>
</env:Body>
</env:Envelope>

Syntax Rules
Here are some important syntax rules:

 A SOAP message MUST be encoded using XML

 A SOAP message MUST use the SOAP Envelope namespace
 A SOAP message must NOT contain a DTD reference
 A SOAP message must NOT contain XML Processing Instructions

Advantages of SOAP
 SOAP is a light weight data interchange protocol because it is based on XML.
 SOAP was designed to be OS and Platform independent.
 It is built on top of HTTP which is installed in most systems.
 It is suggested by W3 consortium which is like a governing body for the Web.
 SOAP is mainly used for Web Services and Application Programming Interfaces
(APIs).

How SOAP are used for communication between web services

A SOAP Example

In the example below, a GetStockPrice request is sent to a server. The request has a
StockName parameter, and a Price parameter that will be returned in the response. The
namespace for the function is defined in "[Link]
 A SOAP request:
POST /InStock HTTP/1.1 Host:
[Link]
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn

<?xml version="1.0"?>

<soap:Envelope
xmlns:soap="[Link]
soap:encodingStyle="[Link]

<soap:Body xmlns:m="[Link]
<m:GetStockPrice>
<m:StockName>IBM</m:StockName>
</m:GetStockPrice>
</soap:Body>

</soap:Envelope>

The SOAP response:

HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn

<?xml version="1.0"?>

<soap:Envelope
xmlns:soap="[Link]
soap:encodingStyle="[Link]

<soap:Body xmlns:m="[Link]
<m:GetStockPriceResponse>
<m:Price>34.5</m:Price>
</m:GetStockPriceResponse>
</soap:Body>

</soap:Envelope>
WSDL

 WSDL stands for Web Services Description Language

 WSDL is used to describe web services
 WSDL is written in XML
 WSDL is a W3C recommendation from 26. June 2007

How WSDL is used to describe the functionalities and interfaces of web services

WSDL Documents

An WSDL document describes a web service. It specifies the location of the service, and the
methods of the service, using these major elements:

Element Description

<types> Defines the (XML Schema) data types used by the web service

<message> Defines the data elements for each operation

<portType> Describes the operations that can be performed and the

messages involved.

<binding> Defines the protocol and data format for each port type

The main structure of a WSDL document looks like this:

<definitions>

<types>
data type definitions........
</types>

<message>
definition of the data being communicated....
</message>

<portType>
set of operations......
</portType>
 <binding>
protocol and data format specification....
</binding>
</definitions>

WSDL Example
This is a simplified fraction of a WSDL document:

<message name="getTermRequest">
<part name="term" type="xs:string"/>
</message>

<message name="getTermResponse">
<part name="value" type="xs:string"/>
</message>

<portType name="glossaryTerms">
<operation name="getTerm">
<input message="getTermRequest"/>
<output message="getTermResponse"/>
</operation>
</portType>

In this example the <portType> element defines "glossaryTerms" as the name of a port,
and "getTerm" as the name of an operation.

The "getTerm" operation has an input message called "getTermRequest" and an output
message called "getTermResponse".

The <message> elements define the parts of each message and the associated data types.

The <portType> Element

The <portType> element defines a web service, the operations that can be performed,
and the messages that are involved.
The request-response type is the most common operation type, but WSDL defines four
types:

Type Definition

One-way The operation can receive a message but will not return
a response

Request-response The operation can receive a request and will return a

response
Solicit-response The operation can send a request and will wait for a
response
Notification The operation can send a message but will not wait for
a response

WSDL One-Way Operation

A one-way operation example:

<message name="newTermValues">
<part name="term" type="xs:string"/>
<part name="value" type="xs:string"/>
</message>

<portType name="glossaryTerms">
<operation name="setTerm">
<input name="newTerm" message="newTermValues"/>
</operation>
</portType >

In the example above, the portType "glossaryTerms" defines a one-way operation called
"setTerm".

The "setTerm" operation allows input of new glossary terms messages using a
"newTermValues" message with the input parameters "term" and "value". However, no
output is defined for the operation.

WSDL Request-Response Operation

A request-response operation example:

<message name="getTermRequest">
 <part name="term" type="xs:string"/>
</message>

<message name="getTermResponse">
<part name="value" type="xs:string"/>
</message>

<portType name="glossaryTerms">
<operation name="getTerm">
<input message="getTermRequest"/>
<output message="getTermResponse"/>
</operation>
</portType>

In the example above, the portType "glossaryTerms" defines a request-response operation

called "getTerm".

The "getTerm" operation requires an input message called "getTermRequest" with a

parameter called "term", and will return an output message called "getTermResponse"
with a parameter called "value".

WSDL Binding to SOAP

WSDL bindings defines the message format and protocol details for a web service.

A request-response operation example:

<message name="getTermRequest">
<part name="term" type="xs:string"/>
</message>

<message name="getTermResponse">
<part name="value" type="xs:string"/>
</message>

<portType name="glossaryTerms">
<operation name="getTerm">
<input message="getTermRequest"/>
<output message="getTermResponse"/>
</operation>
</portType>

<binding type="glossaryTerms" name="b1">

<soap:binding style="document"
 transport="[Link] />
<operation>
<soap:operation soapAction="[Link]
<input><soap:body use="literal"/></input>
<output><soap:body use="literal"/></output>
</operation>
</binding>

The binding element has two attributes - name and type.

The name attribute (you can use any name you want) defines the name of the binding, and
the type attribute points to the port for the binding, in this case the "glossaryTerms" port.

The soap:binding element has two attributes - style and transport.

The style attribute can be "rpc" or "document". In this case we use document. The
transport attribute defines the SOAP protocol to use. In this case we use HTTP.

The operation element defines each operation that the portType exposes.

For each operation the corresponding SOAP action has to be defined. You must also specify
how the input and output are encoded. In this case we use "literal".

UDDI
UDDI is an XML-based standard for describing, publishing, and finding web services.
 UDDI stands for Universal Description, Discovery, and Integration.
 UDDI is a specification for a distributed registry of web services.
 UDDI is a platform-independent, open framework.
 UDDI can communicate via SOAP, CORBA, Java RMI Protocol.
 UDDI uses Web Service Definition Language (WSDL) to describe interfaces to web
services.
 UDDI is seen with SOAP and WSDL as one of the three foundation standards of web
services.
 UDDI is an open industry initiative, enabling businesses to discover each other
 and define how they interact over the Internet.

UDDI has two sections −

 A registry of all web service's metadata, including a pointer to the WSDL
description of a service.
 A set of WSDL port type definitions for manipulating and searching that registry.
Partner Interface Processes
Partner Interface Processes (PIPs) are XML based interfaces that enable two trading
partners to exchange data. Dozens of PIPs already exist. Some of them are listed here −
 PIP2A2 − Enables a partner to query another for product information.
 PIP3A2 − Enables a partner to query the price and availability of specific products.
 PIP3A4 − Enables a partner to submit an electronic purchase order and
receive acknowledgment of the order.
 PIP3A3 − Enables a partner to transfer the contents of an electronic shopping cart.
 PIP3B4 − Enables a partner to query the status of a specific shipment.
Private UDDI Registries
As an alternative to using the public federated network of UDDI registries available on the
Internet, companies or industry groups may choose to implement their own private UDDI
registries.
These exclusive services are designed for the sole purpose of allowing members of the
company or of the industry group to share and advertise services among themselves.
Regardless of whether the UDDI registry is a part of the global federated network or a
privately owned and operated registry, the one thing that ties them all together is a common
web services API for publishing and locating businesses and services advertised within the
UDDI registry.
UDDI - Elements
A business or a company can register three types of information into a UDDI registry. This
information is contained in three elements of UDDI.

These three elements are −

 White Pages,
 Yellow Pages, and
 Green Pages.
White Pages

White pages contain −

 Basic information about the company and its business.
 Basic contact information including business name, address, contact phone
number, etc.
 A Unique identifiers for the company tax IDs. This information allows others to
discover your web service based upon your business identification.
Yellow Pages
 Yellow pages contain more details about the company. They include descriptions of
the kind of electronic capabilities the company can offer to anyone who wants to
do business with it.
 Yellow pages uses commonly accepted industrial categorization schemes,
industry codes, product codes, business identification codes and the like to make
it easier for companies to search through the listings and find exactly what they
want.
Green Pages
Green pages contains technical information about a web service. A green page allows
someone to bind to a Web service after it's been found. It includes −

 The various interfaces

 The URL locations
 Discovery information and similar data required to find and run the Web service.
NOTE − UDDI is not restricted to describing web services based on SOAP. Rather, UDDI
can be used to describe any service, from a single webpage or email address all the way
up to SOAP, CORBA, and Java RMI services.
 How UDDI Enables Discovery of Web Services

UDDI registries enable discovery by providing a centralized repository for metadata

about service providers and their services.
 Search Mechanisms: Users can search the registry for web services based on business
name, industry classification (e.g., NAICS, UNSPSC), or technical specifications.

 Taxonomic Classification: UDDI includes standard classification schemes to make search

more efficient, allowing users to locate services based on industry, product, or
geographic location.

 Structure Components:

o White Pages: Contain basic business contact information.

o Yellow Pages: Use standard industrial categorizations to classify services.

o Green Pages: Contain technical information about services, including references to

Web Services Description Language (WSDL) documents.

 Public vs. Private: Public registries (often synchronized worldwide) enable inter-
enterprise discovery, while private UDDI registries allow corporations to manage and
discover internal services.
How UDDI Enables Access to Web Services

Once a service is discovered, UDDI facilitates access through detailed technical pointers.
 WSDL Integration: UDDI stores tModel (technical model) structures that point to WSDL
documents. These WSDLs define the service's interface, operations, and input/output
parameters.

 Binding Templates: The registry provides a bindingTemplate

structure, which acts as the
technical pointer to the service's access point (the URI where the service is hosted).

 Programmatic Access: Service consumers can use the UDDI Inquiry API—usually accessed
via SOAP messages—to programmatically find services, retrieve binding details, and
dynamically connect to them.

 Caching: To enhance performance and reduce load on the registry, consumers often
cache the binding information, only refreshing it when a service call fails.