Introduction to Services - Bind, Publish, Find Framework for SOA Web Services (A Realization

of SOA) - Web Services Architecture (Transport Services, Messaging Services, Service Description,
Discovery Services, Quality of Service), Interoperability REST (Representational State Transfer)
Services.

Service-oriented architectures

SOA is a logical way of designing a software system to provide services to either end-user
applications or to other services distributed in a network, via published and discoverable
interfaces.

The essential goal of an SOA is to enable general-purpose interoperability among existing

technologies and extensibility to future purposes and architectures.

A means of developing distributed systems where the components are stand-alone services.

Services may execute on different computers from different service providers.

Standard protocols have been developed to support service communication and information
exchange.

Services or components?

A service can be defined as:

A loosely-coupled, reusable software component that encapsulates discrete

functionality which may be distributed and programmatically accessed. A web service is
a service that is accessed using standard Internet and XML-based protocols.

A critical distinction between a service and a component as defined in component-based

software engineering is that services are independent.

Services do not have a requires interface.

Services rely on message-based communication with messages expressed in XML.

Benefits of SOA

Services can be provided locally or outsourced to external providers.

Services are language-independent.

Investment in legacy systems can be preserved.

Inter-organizational computing is facilitated through simplified information exchange.

SOA and Web Services

Service-oriented architecture is an architectural style

Derived from the client-server architectural style.

 Clients (service consumers or requesters) and servers (service providers) connected by a
service bus.

Services defined using formal interfaces (contracts).

Service bus supports point-to-point and messaging styles of communication.

Support for system qualities, e.g., security and transaction management.

Web services

Services provided in a SOA deployed over the web.

Key standards

SOAP (Simple Object Access Protocol)

A message exchange standard that supports service communication.

WSDL (Web Service Definition Language)

This standard allows a service interface and its bindings to be defined.

UDDI (Universal Description Discovery and Integration)

Defines the components of a service specification that may be used to discover the
existence of a service.
 Service-oriented architecture(ABOVE DIAGRAM)

The Web Services architecture is based upon the interactions between three roles: i) service
provider, ii) service registry and iii) service requestor.

The Interactions involve the publish, find and bind operations.

Together, these roles and operations act upon the Web Services artifacts: the Web service
software module and its description.

In a typical scenario, a service provider hosts a network-accessible software module (an

implementation of a Web service).

The service provider defines a service description for the Web service and publishes it to a
service requestor or service registry.

The service requestor uses a find operation to retrieve the service description locally or from the
service registry and uses the service description to bind with the service provider and invoke or
interact with the Web service implementation.

Service provider and service requestor roles are logical constructs and a service can exhibit
characteristics of both.

Operations in a Web Service Architecture

These behaviors can occur singly or iteratively. In detail, these operations are:

Publish. To be accessible, a service description needs to be published so that the service

requestor can find it. Where it is published can vary depending upon the requirements of the
application.

Find. In the find operation, the service requestor retrieves a service description directly or
queries the service registry for the type of service The find operation can be involved in two
different lifecycle phases for the service requestor: at design time to retrieve the services
interface description for program development, and at runtime to retrieve the services binding
and location description for invocation.

Bind. Eventually, a service needs to be invoked. In the bind operation the service requestor
invokes or initiates an interaction with the service at runtime using the binding details in the
service description to locate, contact and invoke the service.

Roles in a Web Services Architecture

Service provider

From a business perspective, this is the owner of the service. From a Service provider. architectural
perspective, this is the platform that hosts access to the service.

Service requestor

From a business perspective, this is the business that requires Service requestor certain functions to be
satisfied. From an architectural perspective, this is the application that is looking for and invoking or
initiating an interaction with a service. The service requestor role can be played by a browser driven by a
person or a program without a user interface, for example another Web service.

Service registry

This is a searchable registry of service descriptions where service Service registry. providers publish their
service descriptions. Service requestors find services and obtain binding information (in the service
descriptions) for services during development for static binding or during execution for dynamic binding.
For statically bound service requestors, the service registry is an optional role in the architecture,
because a service provider can send the description directly to service requestors.

Web Services (A Realization of SOA)

The Web services community has done significant work to address this interoperability issue,
and since the introduction of the first Web services, various organizations have introduced other
Web servicesrelated specifications.

Web services specifications that realize more concretely the capabilities that are described in
the SOA framework.

The specifications define formats and protocols that allow services to interoperate across those
vendor platforms that provide conformant implementations, either natively or by mapping them
onto existing proprietary middleware offerings
Transport Services:

Web services is basically an interoperable messaging architecture, and message transport

technologies form the foundation of this architecture.

We can transport Web services messages by using the ubiquitous Web protocols such as
Hypertext Transport Protocol (HTTP) or Secure HTTP (HTTPS).

We can also transport them over any communications protocol such SMTP, TCP/IP, RMI/IIOP.

IIOP (Internet Inter-ORB Protocol) is a protocol that makes it possible for distributed programs
written in different programming languages to communicate over the Internet.

Messaging Services:

The messaging services component of the framework contains the most fundamental Web
services specifications and technologies, including eXtensible Markup Language (XML), SOAP,
and WS-Addressing.

XML provides the interoperable format to describe message content between Web services and
is the basic language in which the Web services specifications are defined.

Three important characteristics of XML

1. XML is extensible: XML allows you to create your own self-descriptive tags, or language, that
suits your application.

2. XML carries the data, does not present it: XML allows you to store the data irrespective of how it
will be presented.

3. XML is a public standard: XML was developed by an organization called the World Wide Web
Consortium (W3C) and is available as an open standard.

XML Usage

XML can be used to exchange the information between organizations and systems.

XML can be used for offloading and reloading of databases.

XML can be used to store and arrange the data, which can customize your data handling needs.

XML can easily be merged with style sheets to create almost any desired output.

Virtually, any type of data can be expressed as an XML document.

Messaging Services:

<definitions targetNamespace=...>

<!-- WSDL definitions in this document -->

<!-- XSD definitions for this service -->

<xsd:schema>

<xsd:import namespace=http://www.purchase.com/xsd/svp-svc>

</xsd:schema>

</types>

<message name=purchaseResponse>

<part name=purchaseResponse element=xsd1:PurchaseStatus/>

</message>

<message name=purchaseRequest> <part name=purchaseRequest

element=xsd1:PurchaseRequest/> </message> <message name=ServicePacValidationInput>

SOAP(Simple Object Access Protocol)

SOAP, one of the significant underpinnings of Web services, provides a simple and relatively
lightweight mechanism for exchanging structured and typed information between services.

SOAP is designed to reduce the cost and complexity of integrating applications that are built on
different platforms.

SOAP defines an extensible enveloping mechanism that scopes and structures the message
exchange between Web services.

A SOAP message is an XML document that contains three distinct elements:

I. an envelope,

II. a header,

and a body.

SOAP(Simple Object Access Protocol

ENVELOPE :The envelope is the root element of the SOAP message. It contains an optional
header element and a mandatory body element.

HEADER: Contains any optional attributes of the message used in processing the message.

SOAP defines several well-known attributes that you can use to indicate who should deal with a
header block and whether processing of it is optional or mandatory
 BODY :The body element is always the last child element of the envelope, and it is the container
for the payloadthe actual message content that is intended for the ultimate recipient who will
process it.

Fault An optional Fault element that provides information about errors that occur while
processing the message

SOAP Message Structure

<?xml version="1.0"?>

<SOAP-ENV:Envelope xmlns:SOAP- ENV="http://www.w3.org/2001/12/soap-envelope" SOAP-

ENV:encodingStyle="http://www.w3.org/2001/12/soap-encoding">

<SOAP-ENV:Header>

...

</SOAP-ENV:Header>

<SOAP-ENV:Body>

...

<SOAP-ENV:Fault>

...

</SOAP-ENV:Fault>

...

</SOAP-ENV:Body>

</SOAP_ENV:Envelope>

WS-Addressing:

WS-Addressing provides an interoperable, transport-independent way of identifying message

senders and receivers that are associated with message exchange.

It decouples address information from the specific transport used by providing a mechanism to
place the target, source, and other important address information directly within the Web
service message.

Identify Web services endpoints and to secure end-to end endpoint identification in messages

Enables messaging systems to support message transmission through networks

WS-Addressing defines two interoperable constructs

1. Endpoint References
 2. Message Information Headers.

A Web services endpoint is a referenceable entity, processor, or resource in which Web services
messages can be targeted

An endpoint reference (EPR) is an XML structure encapsulating information useful for addressing
a message to a Web service

This includes the destination address of the message, any additional parameters (called
reference parameters) necessary to route the message to the destination, and optional
metadata (such as WSDL or WS-Policy) about the service.

Message Information Headers that allows uniform addressing of messages independent of

underlying transport. These message information headers convey end-to-end message
characteristics, including addressing for source and destination endpoints and message identity

Service Description

Service description defines metadata that fully describes the characteristics of services that are
deployed on a network.

Metadata is fundamental to achieving the loose coupling that is associated with an SOA.

WSDL Web Services Description Language:

It is the most mature of metadata describing Web services.

 It allows developers to describe the functional characteristics of a Web servicewhat actions
or functions the service performs in terms of the messages it receives and sends.

WSDL offers a standard, language-agnostic view of services it offers to clients.

WSDL is an XML format for describing (network) services as a set of endpoints that operate on
messages containing either document-oriented or procedure oriented information.

WSDL Features

WSDL is an XML-based protocol for information exchange in decentralized and distributed

environments.

WSDL definitions describe how to access a web service and what operations it will perform.

WSDL is a language for describing how to interface with XML-based services.

WSDL is an integral part of Universal Description, Discovery, and Integration (UDDI), an XML-
based worldwide business registry.

A WSDL document has two parts:

1. abstract definitions

2. Concrete descriptions.

Web service description language

The service interface is defined in a service description expressed in WSDL. The WSDL
specification defines:

What operations the service supports and the format of the messages that are sent and
received by the service.

How the service is accessed - that is, the binding maps the abstract interface onto a
concrete set of protocols.

Where the service is located. This is usually expressed as a URI (Universal Resource
Identifier).

STRUCTURE OF WSDL SPECIFICATION

Abstract Definitions

Types: Machine- and language-independent type definitions.

Messages: Contains function parameters (inputs are separate from outputs) or document
descriptions.

PortTypes: Refers to message definitions in Messages section that describe function signatures
(operation name, input parameters, output parameters).

Concrete Descriptions

Bindings: Specifies binding(s) of each operation in the PortTypes section.

Services: Specifies port address(es) of each binding

An Example

<message name="Simple.foo">
<part name="arg" type="xsd:int"/>
</message>
<message name="Simple.fooResponse">
<part name="result" type="xsd:int"/>
</message>

<portType name="SimplePortType">
<operation name="foo" parameterOrder="arg" >
<input message="wsdlns:Simple.foo"/>
<output message="wsdlns:Simple.fooResponse"/> </operation>
</portType>

WS-Policy

WS-Policy is a specification that allows web services to use XML to advertise their policies
(on security, quality of service, etc.) and for web service consumers to specify their policy
requirements.

The business interface (including business operations such as open/close account,

debit/credit/transfer, and so on), they do not provide information about how the service
delivers its interface or what the service expects of the caller when it uses the service.

WS-Policy represents a set of specifications that describe the capabilities and constraints of the
security (and other business) policies on intermediaries and end points (for example, required
security tokens, supported encryption algorithms, and privacy rules) and how to associate
policies with services and end points.

Discovery Services:

The transport, description, and messaging layer are fundamental to allowing Web services to
communicate in an interoperable way using messages.
 However, to facilitate this, it is necessary to collect and store the important metadata that
describes these services.

The metadata must be in a form that is discoverable and searchable by users who are looking
for appropriate services they require to solve some particular business problem.

Also, such metadata aggregation and discovery services are a useful repository/registry in which
many different organizations might want to publish the services that they host, describe the
interfaces to their services, and enable domain-specific taxonomies of services.

UDDI(Universal Description and Discovery Interface )

The UDDI is a widely acknowledged specification of a Web service registry.

It defines a metadata aggregation service and specifies protocols for querying and updating a
common repository of Web services information.

UDDI is a specification for a distributed registry of web services.

UDDI repositories can be provided in one of three ways:

Public UDDIThese are UDDI repositories that can serve as a resource for Internet-based
Web services. An example of this is the UDDI Business Registry [UBR]hosted by a group of
vendors led by IBM, Microsoft, and SAPthat is replicated across multiple hosting
organizations.

Intra Enterprise UDDI- An enterprise has a private internal UDDI repository that provides
much more control over which service descriptions

are allowed to be placed there and used by application developers within that specific
enterprise.

Inter Enterprise UDDIThis basically scopes the content of the UDDI to services that are
shareable between specific business partners.
 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:

1.White Pages,

2.Yellow Pages, and

3.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

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 Green pages through the listings and find exactly what they want.

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.

Quality of Service

This layer include security, reliability of message delivery, and support for transactions
(guaranteeing and agreeing on the outcome of a business application).

WS-Security:

Most distributed Web services rely on transport-level support for security functions (for
example, HTTPS).

WS-Security uses existing security models (such as Kerberos and X509).

Security relies on predefined trust relationships. Kerberos works because participants trust the
Kerberos Key Distribution Center. Public Key Infrastructure (PKI) works because participants
trust the root certificate authorities.

WS-Trust defines an extensible model for setting up and verifying trust relationships. The key
concept in WS-Trust is a Security Token Service (STS). An STS is a distinguished

Web service that issues, exchanges, and validates security tokens. WS Trust allows Web services
to set up and agree on which security servers they trust, and to rely on these servers.
 Reliable Messaging:

WS-ReliableMessaging addresses Communication issues and defines protocols that enable Web
services to ensure reliable, interoperable exchange of messages with specified delivery
assurances.

The specification defines three basic assurances:

In-order deliveryThe messages are delivered in the same order in which they were sent.

At least once deliveryEach message that is sent is delivered at least one time.

At most once deliveryNo duplicate messages are delivered.

Transactions:

Business scenarios necessitates the development of applications that consist of multiple Web
services exchanging many messages.

An example might be a group of financial institutions setting up a financial offering that involves
insurance policies, annuities, checking accounts, and brokerage accounts

A coordinated orchestration of the outcome of the participating services that make up the
business application is essential so that a coherent outcome of the whole business application
can be agreed upon and guaranteed.

The Web services involved are able to do the following:

Start new tasks, the execution and disposition of which are coordinated with other tasks

Agree on the outcome of the computation. For example, does everyone agree that the
financial packages were set up?

WS-Coordination, WS-AtomicTransaction, and WS-BusinessActivity define protocols that are

designed specifically to address these requirements.

WS-Coordination is a general mechanism for initiating and agreeing on the outcome of

multiparty, multimessage Web service tasks

A coordination contextThis is a message element that is associated with exchanges during

the interaction of Web services. This coordination context contains the WS-Addressing endpoint
reference of a coordination service, in addition to the information that identifies the specific
task being coordinated.

A coordinator serviceThis provides a service to start a coordinated task, terminate a

coordinated task, allow participants to register in a task, and produce a coordination context
that is part of all messages exchanged within a group of participants.

An interfaceParticipating services can use the interface to inform them of an outcome that
all of the participants have agreed upon.
 WS-AtomicTransaction defines a specific set of protocols that plug into WS-Coordination to
implement the traditional two-phase atomic ACID transaction protocols.

WS-BusinessActivity defines a specific set of protocols that plug into the WS-Coordination model
to provide such long-running, compensation- based transaction protocols.

For example, although WS-BPEL defines a transaction model for business processes, it is WS-
BusinessActivity that specifies the corresponding protocol rendering.

Service Components

A business process specifies the potential execution order of operations from a collection of
Web services, the data that is shared between these composed Web services, which partners
are involved, and how they are involved in the business process, joint exception handling for
collections of Web services, and so on.

Business Process Execution Language for Web services (WS-BPEL, often shortened to BPEL)
provides a language to specify business processes and process states and how they relate to
Web services.

Composeability:

The term composeable describes independent Web service specifications that you can readily
combine to develop much more powerful capabilities

Interoperability

The fundamental premise of Web services is that standardization, predicated on the promise of
easy interoperability, resolves many of the long-standing issues facing businesses

WS-I
 WS-I [WSI] is an open industry organization that is chartered to promote Web services
interoperability across differing platforms, operating systems/middleware, programming
languages, and tools.

It works across the varied existing industry and standards organizations to respond to
customer needs by providing guidance and best practices to help develop Web service
solutions.

WS-I was formed specifically for the creation, promotion, and support of generic protocols for
interoperable exchange of messages between Web services.

Emerging web services platform(Architecture)

Standards for web service composition Standards for web service composition

Standards for web service composition

Service orchestration

WS-BPEL is an XML-based language for workflow specification.

WS-BPEL is an orchestration language.

 Service orchestration defines the sequence and conditions in which one Web
service invokes other Web services.

Can be used to create a composite service out of other services.

Service choreography

WS-CDL is an XML-based language for describing service choreography.

Choreography defines the allowable message exchanges between services.

Orchestration vs. choreography

Orchestration Choreography Defines Interaction

A Single Director In Control.

Orchestration and choreography example

REST - Representational State Transfer

REST is an architecture style of networked systems to represent resources in different ways.

The resources are acted upon by using a set of simple, well-defined operations

The REST architectural style constrains an architecture to a client/server architecture and is

designed to use a stateless communication protocol, typically HTTP

Rest An architectural Style

Elements

Components Proxy , gateway etc

Connectors client , server etc

 Data resource , representation etc

REST

Ignores component implementation details.

Focus on roles of components,their interactions and their

interpretation of data elements

URI

"Representational State Transfer is intended to evoke an image of how a well-designed Web

application behaves: a network of web pages (a virtual state-machine), where the user progresses
through an application by selecting links (state transitions), resulting in the next page (representing
the next state of the application) being transferred to the user and rendered for their use."

REST - An Architectural Style of Networked System

Underlying Architectural model of the world wide web.

Guiding framework for Web protocol standards.

REST based web services

 Online shopping

Search services

Dictionary services

REST way of Implementing the web services

Service Get parts list

The web service makes available a URL to a parts list resource

Client uses : http://www.parts-depot.com/parts

Document Client receives :

<?xml version="1.0"?>

<p:Parts xmlns:p="http://www.parts-depot.com" xmlns:xlink="http://www.w3.org/1999/xlink">

<Part id="00345" xlink:href="http://www.parts-depot.com/parts/00345"/>

<Part id="00346" xlink:href="http://www.parts-depot.com/parts/00346"/>

<Part id="00347" xlink:href="http://www.parts-depot.com/parts/00347"/>

<Part id="00348" xlink:href="http://www.parts-depot.com/parts/00348"/>

</p:Parts>

Service Get detailed part data

The web service makes available a URL to each part resource.

Client uses : http://www.parts-depot.com/parts/00345

Document Client receives :

<?xml version="1.0"?>

<p:Part xmlns:p="http://www.parts-depot.com" xmlns:xlink="http://www.w3.org/1999/xlink">

<Part-ID>00345</Part-ID>

<Name>Widget-A</Name>

<Description>This part is used within the frap assembly</Description>

<Specification xlink:href="http://www.parts-depot.com/parts/00345/specification"/> <UnitCost

currency="USD">0.10</UnitCost>

<Quantity>10</Quantity>

</p:Part> diagram at last

Characteristics of a REST based network

Client-Server: a pull-based interaction style(Client request data from servers as and when
needed).

Stateless: each request from client to server must contain all the information necessary to
understand the request, and cannot take advantage of any stored context on the server.

Cache: to improve network efficiency, responses must be capable of being labeled as

cacheable or non-cacheable.
 Uniform interface: all resources are accessed with a generic interface (e.g., HTTP GET, POST,
PUT, DELETE).

Named resources - the system is comprised of resources which are named using a URL.

Interconnected resource representations - the representations of the resources are interconnected

using URLs, thereby enabling a client to progress from one state to another

Principles of REST web service design

1.Identify all the conceptual entities that we wish to expose as services. (Examples we saw
include resources such as : parts list, detailed part data, purchase order)

2. Create a URL to each resource.

3. Categorize our resources according to whether clients can just receive a representation of
the resource (using an HTTP GET), or whether clients can modify (add to) the resource using
HTTP POST, PUT, and/or DELETE).

4. All resources accessible via HTTP GET should be side-effect free. That is, the resource should
just return a representation of the resource. Invoking the resource should not result in
modifying the resource.

5.Put hyperlinks within resource representations to enable clients to drill down for more
information, and/or to obtain related information.

6. Design to reveal data gradually. Don't reveal everything in a single response document.
Provide hyperlinks to obtain more details.

7. Specify the format of response data using a schema (DTD, W3C Schema, RelaxNG, or
Schematron). For those services that require a POST or PUT to it, also provide a schema to
specify the format of the response.

8. Describe how our services are to be invoked using either a WSDL document, or simply an
HTML document.

Service Submit purchase order (PO)

UNIT 2
XML(eXtensible Markup Language)

XML stands for eXtensible Markup Language.

It is a text-based markup language derived from Standard Generalized Markup Language

(SGML).

XML tags identify the data and are used to store and organize the data, rather than specifying
how to display it like HTML tags, which are used to display the data.

XML can be used to exchange the information between organizations and systems.

A web service is any service that is available over the Internet, uses a standardized XML
messaging system, and is not tied to any one operating system or programming language
XML Documents

Whats in an XML document?

Declartions

Elements

Attributes

Comments etc

XML Documents

XML Declaration: contains details that prepare an XML processor to parse the XML document. It
is optional, but when used, it must appear in first line of the XML document.

<?xml version="1.0" encoding="UTF-8"?>

UTF-8 is the default character encoding for XML documents.

XML elements can be defined as building blocks of an XML. Elements can behave as containers
to hold text, elements, attributes, media objects or all of these.

An XML element is everything from (including) the element's start tag to (including) the
element's end tag.

<element-name attribute1 attribute2> ....content </element-name>

Ex. <price>29.99</price>

Attributes are designed to contain data related to a specific element.

<person gender="female">

Comments can be used to include related links, information and terms

<!-------Your comment----->

An XML document:

1.<article>

<author>Gerhard Weikum</author>

<title>The Web in Ten Years</title>

<text>

<abstract>In order to evolve...</abstract>

<section number=1 title=Introduction>

The <index>Web</index> provides the universal...

</section>

</text>

</article>

2.<article>

<author>Gerhard Weikum</author>

<title>The Web in Ten Years</title>

<text>

<abstract>In order to evolve...</abstract>

<section number=1 title=Introduction>

The <index>Web</index> provides the universal...

</section>

</text>

</article>

3. <article>

<author>Gerhard Weikum</author>

<title>The Web in Ten Years</title>

 <text>

<abstract>In order to evolve...</abstract>

<section number=1 title=Introduction>

The <index>Web</index> provides the universal...

</section>

</text>

</article>

(Freely definable) tags: article, title, author

with start tag: <article> etc.

and end tag: </article> etc.

Elements: <article> ... </article>

Elements have a name (article) and a content (...)

Elements may be nested.

Elements may be empty: <this_is_empty/>

Element content is typically parsed character data (PCDATA), i.e., strings with special
characters, and/or nested elements (mixed content if both).

Each XML document has exactly one root element and forms a tree.

Elements with a common parent are ordered.

Elements vs. Attributes

Elements may have attributes (in the start tag) that have a name and

a value, e.g. <section number=1>.

What is the difference between elements and attributes?

Only one attribute with a given name per element (but an arbitrary number of subelements)

Attributes have no structure, simply strings (while elements can have subelements)

As a rule of thumb:

Content into elements

Metadata into attributes

Example:

<person born=1912-06-23 died=1954-06-07>

 Alan Turing</person> proved that

XML Documents as Ordered Trees

Some special characters must be escaped using entities:

< &lt;
& &amp;

Some other characters may be escaped, too:

> &gt;
&quot;
&apos;

Well-Formed XML Documents

A well-formed document must adher to, among others, the following rules:

Every start tag has a matching end tag.

Elements may nest, but must not overlap.

There must be exactly one root element.

Attribute values must be quoted.

An element may not have two attributes with the same name.

Comments and processing instructions may not appear inside tags.

No unescaped < or & signs may occur inside character data.

Message: A collection of data fields sent or received together between software applications. A message
contains a header (which stores control information about the message) and a payload (the actual
content of message).
 Messaging uses messages to communicate with different systems to perform some kind of
function

When developers decided to build a web service messaging system, XML was therefore a
natural choice.

There are two main contenders for XML messaging:

XML-RPC and SOAP

XML Messaging

Message: A collection of data fields sent or received together between software applications. A message
contains a header (which stores control information about the message) and a payload (the actual
content of message).

Messaging uses messages to communicate with different systems to perform some kind of
function

When developers decided to build a web service messaging system, XML was therefore a
natural choice.

There are two main contenders for XML messaging:

XML-RPC and SOAP

An example XML message

<?xml version="1.0"?>

<message>

<header>

<to>companyReceiver</to>

<from>companySender</from>

<type>saveInvoice</type>

</header>

<body>

<saveInvoice>

<invoicedate="01-20-2000" number="123">

<address country="US">

<name>John Smith</name>

<street>123 George St.</street>

<city>Mountain View</city>

<state>CA</state>

<zip>94041</zip>

</address>

<billTo country="US">

<name>Company A</name>

<street>100 Main St.</street>

<city>Washington</city>

<state>DC</state>

<zip>20015</zip>

</billTo>

<items>

<item number="1">

<name>IBM A20 Laptop</name>

<quantity>1</quantity>
 <USPrice>2000.00</USPrice>

</item>

</items>

</invoice>

</saveInvoice>

</body>

</message>

XML-RPC:

What is XML-RPC?

XML-RPC is a remote procedure call protocol using XML as data format and HTTP as transport

protocol.

Advantages of XML-RPC:

Simple mechanism to call remote procedures on a machine with a different OS.

XML-RPC is language and platform independent. XML-RPC libraries are available in Java and
other languages.

XML-RPC is not more than its name implies and thus is very simple and lean

Protocols and techniques behind XML-RPC:

1. XML - Formatting of the request and response and the arguments (wire protocol)

2. RPC - Remote call of procedures.

3. HTTP - Transport protocol for the XML (firewall-friendly).

XML-RPC architecture

The client application accesses the server through a URL (= location where service resides).

The XML-RPC listener receives requests and passes these to the handler (= user defined class
servicing the request).

Diagram:
 XML-RPC is a simple protocol that uses XML messages to perform RPCs. Requests are encoded in
XML and sent via HTTP POST. XML responses are embedded in the body of the HTTP response.

Because XML-RPC is platform-independent, it allows diverse applications to communicate. For

example, a Java client can speak XML-RPC to a Perl server.

To gain a high-level understanding of XML-RPC, consider a simple weather service. The service
expects a zip code and returns the current temperature for the area. Here is a sample XML-RPC
request to the weather service (HTTP headers omitted):

<?xml version="1.0" encoding="ISO-8859-1"?>

<methodCall>

<methodName> weather.getWeather </methodName>

<params>

<param> <value>10016</value> </param>

</params>

</methodCall>

The request consists of a simple methodCall element that specifies the method name and any
method parameters.

A sample XML-RPC response from the weather service:

<?xml version="1.0" encoding="ISO-8859-1"?>

<methodResponse>

<params>

<param>

<value> <int>65</int> </value>

</param>

</params>

</methodResponse>

The response consists of a single methodResponse element that specifies the return value.

In this case, the return value is specified as an integer.

3. XML-RPC protocol

Request (example from www.xmlrpc.com/spec):

The XML body of the HTTP request contains a single method call (getStateName).
 The method is called on a service name under which the method is available.

The URL does not need to be specified (service is indicated by the string before the dot in the
method name element).

3. XML-RPC protocol

Request (example from www.xmlrpc.com/spec):

The XML body of the HTTP request contains a single method call (getStateName).

The method is called on a service name under which the method is available.

The URL does not need to be specified (service is indicated by the string before the dot in the
method name element).

POST /RPC2 HTTP/1.0

User-Agent: Frontier/5.1.2 (WinNT) Host: betty.userland.com

Content-Type: text/xml Content-length: 181

<methodCall>

<methodName>examples.getStateName</methodName> ..list of parametes

<params>

3. XML-RPC protocol

Response (example from www.xmlrpc.com/spec):

The HTTP return code is always 200 OK, even in case of an XML-RPC fault (see below).

The response contains a single value (like a return argument of a local procedure call).

HTTP/1.1 200 OK

Connection: close Content-Length: 158 Content-Type: text/xml

Date: Fri, 17 Jul 1998 19:55:08 GMT

Server: UserLand Frontier/5.1.2-WinNT

HTTP header (response)

with required header fields (blue)

<?xml version="1.0"?>

<methodResponse>
<params>

<param>

<value>

<string>South

</value>

</param>

</params>

</methodResponse>

XML-RPC protocol

Response with a failure (example from www.xmlrpc.com/spec):

Even in case of an XML-RPC level failure the HTTP return code is 200 OK.

The failure is indicated with the <fault> element.

HTTP/1.1 200 OK

Connection: close Content-Length: 426 Content-Type: text/xml

Date: Fri, 17 Jul 1998 19:55:02 GMT

Server: UserLand Frontier/5.1.2-WinNT

<fault>

<value>

<struct>

<member><name>faultCode</name><value><int>4</int></value></member>

<member><name>faultString</name>

<value><string>Too many parameters.</string>

</value>

</member>

</struct>

</value>

</fault>

XML-RPC protocol
 Parameter types :

Base types:

XML-RPC has a very limited set of base types:

Type Description Example

<i4> or <int> Four-byte signed integer -12

<boolean> 0 (false) or 1 (true) 1

<string> ASCII string (string is default) Hi!

<double> Double-precision 3.1415

<dateTime.iso8601> Date/time 19980717

<base64> Base64-encoded binary eW91IGN

Structs:

Structs contain elements (<member>) with a <name> and <value> element ("named" values). Structs
may be recursive (value in a struct may be a struct again).

<struct>

<member>

<name>lowerBound</name>

<value><i4>18</i4></value>

</member>

<member>

<name>upperBound</name>

<value><i4>139</i4></value>

</member>

</struct>

XML-RPC protocol

Parameter types :

Arrays:
An array contains a single <data> element that in turn contains an array of <value> elements. An
array differs from a struct in that its elements are simple values (without <name> element). Arrays
may be recursive (value in array may be an array or also a struct).

<array>

<data>

<value><i4>12</i4></value>

<value><string>Egypt</string></value>

<value><boolean>0</boolean></value>

<value><i4>-31</i4></value>

</data>

</array>

Where to use XML-RPC

XML-RPC may be suited for simple applications or situations where clients implemented in
different technologies need to interact with a server with simple read-write operations where
a more complex middleware technology would be overkill.

XML-RPC is a solution to integrate different platforms with a simple middleware.

XML-RPC is very simple so it can be implemented also for platforms without open source or

commercially available XML-RPC libraries.

Three Main Parts of XML-RPC

Data Model

A set of type for passing parameters, return values and faults (error messages)

Use by both request and response

Request Structure

An HTTP post request containing method name and parameter information

Response Structure

An HTTP response containing return values or fault information

XML-RPC Data Model

Define only 6 basic data types and 2 compound data types

Seems to be enough for most practical applications

Basic Type names Description Examples

int or i4 32-bit integers <int>27</int>

<i4>27</i4>

double 64-bit floating pt <double>27.31415</double>

<double>-1.1465</double>

boolean true(1) or false(0) <boolean>1</boolean>

<boolean>0</boolean>

string ASCII text, usually <string>Hello</string>

support Unicode
<string>bonkers! @</string>

dateTime.iso8601 Dates in ISO8601 <dateTime.iso8601>20021125T02:20:04

format:
</dateTime.iso8601>
CCYYMMDDTHH:MM:SS
<dateTime.iso8601>20020104T17:27:30

</dateTime.iso8601>
base64 Binary defined as in <base64>SGVsbG8sIFdvcmxkIQ==
RFC2045
</base64>

Some examples:

<int>27</int>

<double>27.31415</double>

<boolean>1</boolean>

<string>Hello</string>

<dateTime.iso8601>20020125T02:20:04

</dateTime.iso8601>

<base64>SGVsbG8sIFdvcmxkIQ==</base64>

These basic types are always enclosed in value elements

<value>

<double> -12.45 </double>

</value>

These basic types can be combined into two more complex types: Array and Struct

<value>

<array>

<data>

<value><string>This </string></value>

<value><string>is </string></value>

<value><string>an </string></value>

<value><string>array.</string></value>

</data>

</array>

</value>

Arrays can contain mixtures of different types

<value>
<array>
 <data>
<value><boolean>1</boolean></value>
<value><string>Chan Tai-Man </string></value>
<value><int> -91 </int></value>
<value><double>0.1234</double></value>
</data>
</array>
</value>
Arrays can be multi-dimensional
E.g.

value>
<array>
<data>
<value>
<array>
<data>
<value><int>10</int></value>
<value><int>20</int></value>
</data>
</array>
</value>
<value>
<array>
<data>
<value><int>30</int></value>
<value><int>40</int></value>
</data>
</array>
</value>
</data>
</array>
</value>
Struct contains unordered content, identified by name
Names are string, although it is not necessary to enclose them by string elements
Each struct element contains a list of member elements
Member elements each contain one name element and one value element
The order of members is not important
<value>
<struct>
<member>
<name>givenName</name>

<value><string>Tai-Man </string></value>
 </member>
<member>
<name>familyName</name>
<value><string>Chan </string></value>
</member>
<member>
<name>age</name>
<value><int>27</int></value>
</member>
</struct>
</value>

.

<value>
<struct>
<member>
<name>Name</name>
<value><string>a</string></value>
</member>
<member>
<name>attributes</name>
<value><struct>
<member><name>href</name>
<value><string>http://ex.com</string></value>
</member>
<member><name>target</name>
<value><string>_top</string></value>
</member>
</struct></value>
</member>
</struct>
</value>

XML-RPC Request Structure

XML-RPC requests are a combination of XML content and HTTP headers

HTTP header: a wrapper for passing the request over the Web
XML content: pass parameters and identify the procedure to be called
EXAMPLE:
POST /xmlrpc HTTP 1.0
User-Agent: myXMLRPCClient/1.0
 Host: 192.168.124.2
Content-Type: text/html
Content-Length: 169
:
XML statements

..
<?xml version=1.0?>
<methodCall>
<methodName>circleArea</methodName>
<params>
<param>
<value><double>2.42</double></value>
</param>
<param>
<value>
<array>
<data>
<value><int>10</int></value>
<value><int>20</int></value>
</data>
</array>
</value>
</param>
</params>
</methodCall>

XML-RPC Response Structure

If a request is successful the procedure was found, executed correctly, the result will be
returned thru the response to the client

Similar to request, a response needs to be attached to a HTTP header for surfing on the Web

<?xml version=1.0?>

<methodResponse>

<params>

<param>

<value><double>2.42</double></value>

</param>

</params>
 </methodResponse>

<?xml version=1.0?>

<methodResponse>

<fault>

<value><string>No such method!</string></value>

</fault>

</methodResponse>

..

<?xml version="1.0"?>

<methodResponse>

<fault>

<value>

<struct>

<member>

<name>code</name>

<value><int>26</int></value>

</member>

<member>

<name>message</name>

<value><string>No such method!</string>

</value>

</member>

</struct>

</value>

</fault>

</methodResponse>
Web Services Protocol Stack

Web Services Standards

A web service is a type of component that is available on the web and can be incorporated in
applications or used as a standalone service
The goal of web services is to achieve universal interoperability between applications by using
Web standards.
There are three organizations that are key to the evolution of Web services standards.
W3C
OASIS
WSI Organization
Basic Web Services Standards
XML (eXtensible Markup Language) 1.1
SOAP 1.2 (Simple Object Access Protocol)
WSDL (Web Services Description Language) 1.1
UDDI (Universal, Description, Discovery, and Integration) 3.0.2
 Developed by W3C
Fee-free open standard
Its primary purpose is to facilitate the sharing of structured data across different information
systems, particularly via the Internet.
A subset of SGML (Standard Generalized Markup Language)
SOAP 1.2
OASIS Standard
SOAP version 1.2 is a lightweight protocol for exchange of information in a decentralized,
distributed environment
SOAP 1.2 Structure
<?xml version="1.0"?>
<soap:Envelope xmlns:soap=http://www.w3.org/2001/12/soap-envelope
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">
<soap:Header>
... ...
</soap:Header>
<soap:Body>
... ...
</soap:Body>
</soap:Envelope>

WSDL
It is an XML-based language for describing Web Services and how to access them.
It specifies the location of the service and the operations the services exposes.
A WSDL document is simply a set of definitions.
WSDL Structure
 The UDDI:
The Universal Description, Discovery, and Integration specs define a way to publish and discover
information about Web services.
The UDDI business registration is an XML file that describes a business entity and its Web
services
UDDI Secority:
Not specified in detail, only general policies
Only authorized individuals can publish or change information in the registry
Changes or deletions can only be made by the originator of the information
Each instance of a registry can define its own user authentication mechanism

State Management Model in Web Services

In a typical implementation of web services (such as the .NET implementation), all web
applications execute in a single worker process space .
A single application error may crash the process, leading to the failure of all co-resident
applications

1. State Server Model,

2. The Database Model, And
3. The Proxy Model
1 State Server Model:
To avoid application failure coupling, it would be possible to simply run a single application in
each worker process address space.
Maintaining server state in another process on the same machine
 Database Model
Another common solution is to store application state in a database. State access is now
performed indirectly through database queries and updates.
State maintenance issues are effectively delegated to the database but with an increase in
complexity and a potential decrease in performance.
The database model naturally supports persistence of application state.

Proxy Model
In the first approach, application state was moved from inside the process address space to an
external process. In the second model, application data is moved into an external (persistent)
data store. In the third approach application logic as well as state is migrated outside the web
service infrastructure.
In this model, the web service worker process simply proxies application requests to a third-tier
computation..
The proxy is freed from almost all state maintenance concerns. The web service itself acts, in
this case, merely to provide interoperability. Some computation in the form of data and
protocol conversion can be done within the proxy itself as necessary.
 Building web services
Web services are web apps that return data, not presentation. Since applications are typically
about accessing data, web services are poised to become the next evolutionary step in
distributed software development...
Why?
cross-platform application development
legacy system integration

Web services involve many technologies:

WSDL to learn about web service
to call: proxy objects, SOAP, XML, HTTP and .ASMX pages
 Example:
Google
A great search engine
www.google.com
but what if I want my own GUI?
Google web service
Google offers a web service that performs searches for you
Why?
clients can build custom GUIs
google.com can make money!

Working With Web Services

Two steps:
1. build a web service
2. build clients to use it
Start by creating a project of type ASP.NET Web Service
 One or more objects that respond to web-based method calls
there is no GUI design to a web service
only raw classes with methods

Example
Looks like C#, but keep in mind these are web-based methods
client could be calling from any platform
parameters passed using XML
Building a client
Start by creating a client
WinForm, WebForm, console-based, anything you want!
for fun, let's use VB

Reference the component

As usual, we need to reference component
this will activate IntelliSense
this will make sure we call it correctly
this will enable underlying XML +
SOAP communication
How?
 project references, right-click, Add web reference
type URL for web service, e.g.
http://localhost/WebService/Service1.asmx

Program against component

Treat web service like any other class!
use new to create instances
make method calls
pass parameters
Private Sub Button1_Click(...) Handles Button1.Click
Dim i, j, k As Integer
i = CInt(TextBox1.Text)
j = CInt(TextBox2.Text)
Dim obj As localhost.Service1
obj = New localhost.Service1()
k = obj.Add(i, j)
MessageBox.Show("Sum = " + k.ToString())

End Sub
Here's what the call to Add() actually looks like