Part V: The Web as a Distributed Computing Paradigm

Web Service Standards

SOAP, WSDL and UDDI

Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal 5-Oct-16
Introduction to Web Services

 The most popular way to achieve service orientation and implement a
Service Oriented Architecture (SOA)
 helps expose the IS functionalities via standard web technologies.
 Helps in application integration across multiple platforms.

 Microsoft coined the term “Web services” in June 2000, when the
company introduced Web services as a key component of its dotNet
initiative.

Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal 5-Oct-16
Defining Web Services
DEFINITION (W3C Web Service Activity Group)

“a software application identified by a URI, whose interfaces
& bindings are capable of being defined, described and
discovered as XML artifacts.
- also supports direct interactions with other software
agents using XML based messages exchanged via Web
protocols.”

 Definition emphasises that –
 WS must be capable of being defined, described and discovered using
Web standards (XML) and Web primitives.

Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal 5-Oct-16
Web Service Standards
 All the Web service related standards are XML-based –
 A common syntax for describing data exchanged by services.

 A mechanism to allow remote sites to interact with each other through
messages.

 Describing service capabilities in a standardized manner.

 Mechanism for identifying, discovering and locating a service.

Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal 5-Oct-16
Web Service Standards
 All the Web service related standards are XML-based –
 A common syntax for describing data exchanged by services.
- XML (Extensible Markup Language)

 A mechanism to allow remote sites to interact with each other through
messages.
- SOAP (Simple Object Access Protocol)

 Describing service capabilities in a standardized manner.
- WSDL (Web Service Description Language)

 Mechanism for identifying, discovering and locating a service.
- UDDI (Universal Description, Discovery and Integration)

Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal 5-Oct-16
Web Service Model

Service
Advertisements
UDDI
Service Registry
Broker
Publish Find
SOAP SOAP

SOAP
Bind Service
Service Service
Code Provider requestor
Service Invoke
Descriptions SOAP
WSDL Fig: The WS SOA Triangle
Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal 5-Oct-16
Web Service Model (contd.)
Roles in Web Service architecture

 Service provider
 Owner of the service or
 Platform that hosts access to the service.

 Service requestor
 Business that requires certain functions to be satisfied or
 Application looking for and invoking an interaction with a service.

 Service registry or broker (voluntary)
 Searchable registry of available services where service providers can
publish their service advertisements.

Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal 5-Oct-16
Web Service Model (contd.)
Operations in a Web Service Architecture

 Publish
 Service descriptions need to be published in order for service
requestor to find them.

 Find
 Service requestor retrieves a service description directly or queries the
service registry for the service required.

 Invoke and Bind
 Service requestor invokes or initiates an interaction with the service at
runtime.

Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal 5-Oct-16
Handling Communication between Services

Simple Object Access Protocol (SOAP)

Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal 5-Oct-16
Simple Object Access Protocol (SOAP)
 Was introduced by W3C in 1999.
 First version was based entirely on HTTP.
 SOAP 1.1 (2000) was revised to make SOAP work on top of other
transport protocols.
 SOAP1.2 (2003) is the current standard.
 A joint effort from Canon, IBM, Microsoft and Sun Microsystems.

 W3C defines the use of SOAP with XML as payload and HTTP as
transport
 but other transport protocols such as SMTP and HTTPS can be used .

Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal 5-Oct-16
Structure and Contents of a SOAP message
 SOAP exchanges information using messages.
 SOAP message consists of three parts:
 SOAP Envelope
 SOAP Header (optional)
 SOAP Body (mandatory)

Header

Envelope Body

Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal 5-Oct-16
Structure and Contents of a SOAP message (contd.)

SOAP envelope

SOAP header

header blocks

SOAP body

body blocks

Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal 5-Oct-16
Structure and Contents of a SOAP message (contd.)
SOAP Header

 The Header element is a generic container for control information.
 Header is optional.

 When used, it can have multiple subparts (called header blocks)
 Header blocks will contain information that influences payload
processing such as -
 Routing and delivery settings
 Authentication/authorization data.
 Transaction contexts

Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal 5-Oct-16
Structure and Contents of a SOAP message (contd.)
SOAP Header
<?xml version="1.0"?>
<env:Envelope
xmlns:env="http://www.w3.org/2001/12/soap-envelope"
env:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
encoding">
<
<env:Header>
indicates that the header element is intended for the very
<m:reservation first SOAP application that processes the message
xmlns:m="http://travelcompany.example.org/reservation"
env:role="http://www.w3.org/2003/05/soap-
envelope/role/next"
env:mustUnderstand=“true">

SOAP Header
</env:Header>
... Block example
</env:Envelope>
used to indicate whether a processing a header
entry is mandatory or optional for the recipient.

Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal 5-Oct-16
Example Uses of Header Blocks
 Security:
 WS-Security places additional security information (like digital
signatures and public keys) in the header.

 Quality of Service:
 SOAP headers can be used for indicating particular qualities of
service such as message delivery and transactions.
 E.g. ReliableMessage, AtomicTransaction

 Session State Support:
 Many services require several steps and so will require maintenance
of session state.
 Equivalent to cookies in HTTP, puts session identifier in the header.

Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal 5-Oct-16
Structure and Contents of a SOAP message (contd.)
SOAP Body
 The Body element represents the message payload.
 is mandatory for every message (since it contains the actual
information.)
<?xml version="1.0"?>
<env:Envelope
xmlns:env="http://www.w3.org/2001/12/soap-envelope"
env:encodingStyle="http://www.w3.org/2001/12/soap-
encoding">

<env:Body>
<m:GetPrice xmlns:m="http://www.mysite.com/prices">
<m:Item>pen</m:Item>
</m:GetPrice>
</env:Body>
SOAP Request

</env:Envelope>

Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal 5-Oct-16
Structure and Contents of a SOAP message (contd.)
SOAP Body

<?xml version="1.0"?>
<env:Envelope
xmlns:env="http://www.w3.org/2001/12/soap-envelope"
env:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

<env:Body>
<m:GetPriceResponse xmlns:m="http://www.mysite.com/prices">
<m:Price>1.90</m:Price>
</m:GetPriceResponse>
</env:Body>
SOAP Request
</env:Envelope> SOAP Response

Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal 5-Oct-16
Structure and Contents of a SOAP message (contd.)
SOAP Fault

 When an error occurs during processing, the response to a SOAP
message is a SOAP fault element.

 Will be in the body of the response message.
 returns specific information about the error, including a predefined
code, a description, the address of SOAP processor that generated the
fault.
 For HTTP binding,
 a successful response – status code 200 to 299
 SOAP fault – status code range 500 to 599

Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal 5-Oct-16
Binding SOAP to a Transport Protocol
 Final step to having a functional protocol.

 Typically associated with HTTP, but can also be used with other
protocols such as SMTP, HTTPS, TCP/IP and UDP.

 Specifying which protocol to use is called a binding.
 Bindings define -
 How a message is sent over a transport protocol.
 How the message has to be treated using the transport protocol’s
primitives.

Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal 5-Oct-16
Binding SOAP to HTTP

 a SOAP envelope is sent within an HTTP request.
 Methods used –
 GET
 POST
 other methods can be used depending on what needs to be done.

Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal 5-Oct-16
Using GET method for binding SOAP to HTTP

 Used if the client simply wants to retrieve an XML document.
 An HTTP GET request message is sent with no data (no SOAP
content)
 Document (actually a SOAP envelope) is returned as the data
in the HTTP response.

GET /mytravel.com/reservations?code=FT35ZBQ
HTTP/1.1 Host: mytravel.com
Accept: text/html, application/soap+xml

Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal 5-Oct-16
Using GET method for binding SOAP to HTTP
HTTP/1.1 200 OK
Content
Content-Type: application/soap+xml; charset="utf-8"
Content-Length:
Content nnnn

<?xml version=“1.0” ?>
<env:Envelope
< xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<m:reservation xmlns:m="http://mytravel.com/reservation" …. >
<m:reference>uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d</m:reference>
<m:dateAndTime>2001-11-30T16:25:00.000-05:00</m:dateAndTime>
</m:reservation>
</env:Header>
<env:Body>
. . .
</env:Body>
</
</env:Envelope>

Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal 5-Oct-16
Embedding SOAP in HTTP POST
 SOAP envelope is embedded within the HTTP POST request.

 HTTP response message simply acknowledges receipt of HTTP
request message.
 a status code of 200 OK indicates a successful response.
 a status code of 500 Internal Server Error indicates that there
is a server error and that the SOAP response includes a Fault
element.

Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal 5-Oct-16
Embedding SOAP in HTTP POST (contd.)
 HTTP POST request specifies two HTTP headers for SOAP request
and response:
 Content-Type
 defines the MIME type for the message and the character encoding
(optional) used for the XML body of the request or response.
 Content-Length
 Specifies number of bytes in the body of the request or response.

POST /item_name
/ HTTP/1.1
Content-Type:
Content application/soap+xml; charset=utf-8
Content-Length:
Content 250
--- Followed by SOAP envelope ---

Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal 5-Oct-16
Embedding SOAP in HTTP
POST /Reservations HTTP/1.1
Host: mytravel.com
Content
Content-Type: application/soap+xml; charset="utf-8"
Content
Content-Length: nnnn

<?xml version='1.0’?>
<
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-
envelope" >
<env:Header>
<t:transaction
xmlns:t=“…….">5</t:transaction>
</env:Header>
<env:Body> ….
</
</env:Body>
</
</env:Envelope>
SOAP Request
with POST

Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal 5-Oct-16
Embedding SOAP response in HTTP
HTTP/1.1 200 OK
Content-Type:
Content application/soap+xml; charset="utf-8"
Content-Length:
Content nnnn

<?xml version=“1.0” ?>
<env:Envelope
<
xmlns:env="http://www.w3.org/2003/05/soap-envelope"
xmlns:env >
<env:Header>
...
...
</env:Header>
<env:Body>
...
...
SOAP Response
</env:Body>
with POST
</env:Envelope>
</
Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal 5-Oct-16
Describing Web Services Capabilities

Web Service Description Language

Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal 5-Oct-16
Web Service Description Language
 Was proposed in May 2001 by IBM, Microsoft and Ariba by merging three
previous proposals with the same objective -
 Microsoft’s SOAP Contract Language (SCL)
+
 Microsoft’s Service Description Language (SDL)
+
 IBM’s Network Accessible Service Specification Language (NASSL)

 The present standard is WSDL 2.0.

Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal 5-Oct-16
WSDL as a contract

 WSDL is platform and language independent and is used primarily to
describe SOAP-enabled services.

 WSDL is used to describe precisely -
 what a service does
 i.e., the operations the service provides.
 how to invoke it
 i.e., details of the data formats and protocols necessary to access the
service’s operations.
 where it resides
 i.e., details of the protocol-specific address, e.g., a URL.

Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal 5-Oct-16
Describe service interfaces…
 The two main parts of WSDL

 Service interface definition (Abstract part)
 operations supported by the service
 operation parameters and
 data types definitions

 Service implementation part (Concrete part)
 Information required to bind the interface to
 a concrete network address
 a specific protocol

 a Web service client may bind to such an implementation and invoke the
service.

Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal 5-Oct-16
Structure of a WSDL Description

Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal 5-Oct-16
Structure of a WSDL Description (contd.)
data type definitions
types
Reference to the data being sent
part part part part
Way of sending the data
message message message
action supported by the service.
portType a set of operations supported
input output input
operation operation operation by one or more portTypes.

a concrete protocol and data format
myBinding#1 binding specification for a particular portType.

a single endpoint defined as a combination
of a binding and a network address
Port#1 service
A collection of related endpoints
Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal 5-Oct-16
WSDL – Conceptual View

Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal 5-Oct-16
<?xml version="1.0"?>
<definitions name="Procurement"
targetNamespace="http://example.com/procurement/definitions"
xmlns:tns="http://example.com/procurement/definitions"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" ABSTRACT
xmlns="http://schemas.xmlsoap.org/wsdl/" >
PART
<message name="OrderMsg">
<part name="productName" type="xs:string"/>
<part name="quantity" type="xs:integer"/>
</message>
messages
<portType name="procurementPortType">
<operation name="orderGoods">
<input message = "OrderMsg"/>
</operation> operation and
</portType>
port type
<binding name="ProcurementSoapBinding" type="tns:procurementPortType">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="orderGoods"> CONCRETE
<soap:operation soapAction="http://example.com/orderGoods"/>
<input> PART
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
binding
</output>
</operation>
</binding>

<service name="ProcurementService">
<port name="ProcurementPort" binding="tns:ProcurementSoapBinding">
<soap:address location="http://example.com/procurement"/>
</port>
</service>
port and service

</definitions>
An Example: NameAndAge.wsdl
<definitions>: PersonRecord
<types>: XML Schema
– two variables Name and Age

<message>: 1. showRecordResquest
2. showRecordResponse
<portType>:showRecord that consists of
a request/response service

<binding>: use the SOAP-HTTP transport
protocol

<service>: Service available at
http://localhost:8080/axis/services/
NameAndAge

Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal 5-Oct-16
Web Service Discovery

Universal Description, Discovery and Integration (UDDI)

Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal 5-Oct-16
Universal Description, Discovery and Integration
 Proposed by IBM, Microsoft, SAP and Ariba in 2000.
 More than 300 companies were involved.

 Current version is UDDI v3.0 (Feb 2005) and is hosted by
OASIS.org

 Goals:
 Provide a framework for -
 Describing advertisements for business services.
 Discovering services.
 Discovering service providers.
 Providing search and category options.

Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal 5-Oct-16
Organization of a UDDI Registry
 White Pages
 listings of organizations, contact info, list of general services provided.

 Yellow Pages
 Classifications of both companies and services according to taxonomies
(standard or user defined)

 Green pages
 Full descriptions of individual web services.
 Provides pointers to service descriptions, which are usually stored
outside of the registry (e.g. at the provider’s site).

Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal 5-Oct-16
UDDI Data Structures

 UDDI registry contains 4 types of information –
 Business information
 Service information
 Binding information
 Information about service specifications.

 Specifies a data structure standard to provide each of the above
information.

Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal 5-Oct-16
UDDI Data Structures (contd.)
 businessEntity: a description of the organization that provides the
service.

 businessService: a list of all the Web services offered by the
business entity.

 bindingTemplate: describes the technical aspects of the service
being offered.

 tModel: (“technical model”) is a generic element that can be used
to store technical information on how to use the service, conditions
for use, guarantees, etc.
Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal 5-Oct-16
APIs for interaction with an UDDI registry
 UDDI registries have 3 main types of users –
 Service providers who publish services.
 Service requestors who look for services.
 Other registries that need to exchange information

 UDDI provides several APIs for interacting with it.

Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal 5-Oct-16
UDDI Registry APIs
 Clients can access registry using 6 different APIs -
 UDDI inquiry: to locate and find details about entries in a UDDI
registry.
 UDDI publication: to publish and modify information in a UDDI
registry.
 UDDI security: for access control to UDDI registry (token based).
 UDDI subscription: for clients to subscribe to changes of information
in the UDDI registry.
 UDDI custody and ownership transfer: to change the owner
(publisher) of information.
 UDDI replication: to perform replication of information across nodes
in a UDDI registry. (helps in keeping different registries synchronized)

Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal 5-Oct-16
UDDI Registry Types.
 Types:
 Public Registry: provides open access to all.

 Private Registry: for the internal operations of a organization. (e.g.
mail, leave management etc)

 Shared or semi-private Registry: deployed within a controlled
environment and shared with trusted business partners.

Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal 5-Oct-16
UDDI Registry Types.
 Types:
 Public Registry: provides open access to all.

 Private Registry: for the internal operations of a organization. (e.g.
mail, leave management etc)

 Shared or semi-private Registry: deployed within a controlled
environment and shared with trusted business partners.

 UDDI was envisioned to be an Universal Business Registry (UBR)
 However most of today’s Web service applications are either -
 Intra-enterprise or
 shared between trusted partners.
Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal 5-Oct-16
Current deployments strategies for UDDI Registries

 e-marketplace UDDI:
 an e-marketplace or a consortium of organizations that participate and
compete in the industry can host a private UDDI node.

 Portal UDDI:
 this type of deployment is on an enterprise’s server and is a private
UDDI node that contains only meta-data related to the enterprise’s
Web services.
 External users are allowed to use registry; however, a publish operation
would be restricted to services internal to the portal.

Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal 5-Oct-16
Current deployments strategies for UDDI Registries
(contd.)

 Business partner UDDI registry:
 a private UDDI node hosted behind one of the business partner’s
firewall and only trusted partners can access the registry.

 Internal UDDI:
 this allows applications in different departments of the organization to
publish and find services, and is useful for large organizations.
 called EAI UDDI, as it allows corporations to deploy and advertise
Intranet services.

Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal 5-Oct-16
UDDI Products
 Open Source:
 Apache jUDDI http://uddi-jbossoverlord.rhcloud.com/
 Ruddi
 WSO2 Governance Registry
 UDDI Browser

 Commercial:
 IBM WebSphere Service Registry
 Oracle WebLogic Server
 INFRAVIO X-Registry Platform 6
 Mercury: Systinet Registry
 Novell: Nsure UDDI Server.

Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal 5-Oct-16
UDDI Implementations
 Java Implementations:
 UDDI4J (UDDI for Java) - is a Java class library that provides an API to
interact with a UDDI.
 jUDDI - is an open source Java implementation of a UDDI registry and
a toolkit for accessing UDDI services.
 Perl Implementation:
 UDDI:Lite - provides a basic UDDI client for inquiry and publishing.
 Ruby Implementation:
 UDDI4r - provides a basic UDDI client for inquiry and publishing.
 Python Implementation:
 UDDI4Py - is a Python package that allows the sending of requests to
and processing of responses from the UDDI Version 2 APIs.
Dr. Sowmya Kamath S, Dept of IT, NITK Surathkal 5-Oct-16