Introduction to Web Services

What is a Web Services?

The promise of web services is to enable a distributed environment

in which any number ofapplications, or application components, can
interoperate seamlessly among and betweenorganizations in a platform-
neutral, language-neutral fashion. This interoperation
bringsheterogeneity to the world of distributed computing once and for
all.

A web service is a piece of business logic, located somewhere on

the Internet, that isaccessible through standard-based Internet
protocols such as HTTP or SMTP. Using a webservice could be as simple as
logging into a site or as complex as facilitating a multi-organization
business negotiation.

Given this definition, several technologies used in recent years

could have been classified asweb service technology, but were not. These
technologies include win32 technologies, J2EE,CORBA, and CGI scripting.
The major difference between these technologies and the newbreed of
technology that are labeled as web services is their standardization.
This new breedof technology is based on standardized XML (as opposed to
a proprietary binary standard)and supported globally by most major
technology firms. XML provides a language-neutralway for representing
data, and the global corporate support ensures that every major
newsoftware technology will have a web services strategy within the next
couple years. Whencombined, the software integration and
interoperability possibilities for software programsleveraging the web
services model are staggering.

A web service has special behavioral characteristics:

 XML-based
By using XML as the data representation layer for all web
services protocols andtechnologies that are created, these
technologies can be interoperable at their corelevel. As a data
transport, XML eliminates any networking, operating system, orplatform
binding that a protocol has.

 Loosely coupled
A consumer of a web service is not tied to that web service
directly; the web serviceinterface can change over time without
compromising the client's ability to interactwith the service. A
tightly coupled system implies that the client and server logic
areclosely tied to one another, implying that if one interface
changes, the other must alsobe updated. Adopting a loosely coupled
architecture tends to make software systemsmore manageable and allows
simpler integration between different systems.

 Coarse-grained
Object-oriented technologies such as Java expose their services
through individualmethods. An individual method is too fine an
operation to provide any usefulcapability at a corporate level.
Building a Java program from scratch requires thecreation of several
 fine-grained methods that are then composed into a coarse-
grainedservice that is consumed by either a client or another service.
Businesses and theinterfaces that they expose should be coarse-
grained. Web services technologyprovides a natural way of defining
coarse-grained services that access the right amountof business logic.

 Ability to be synchronous or asynchronous

Synchronicity refers to the binding of the client to the
execution of the service. Insynchronous invocations, the client blocks
and waits for the service to complete itsoperation before continuing.
Asynchronous operations allow a client to invoke aservice and then
execute other functions. Asynchronous clients retrieve their result at
alater point in time, while synchronous clients receive their result
when the service hascompleted. Asynchronous capability is a key factor
in enabling loosely coupledsystems.

 Supports Remote Procedure Calls (RPCs)

Web services allow clients to invoke procedures, functions, and
methods on remoteobjects using an XML-based protocol. Remote
procedures expose input and outputparameters that a web service must
support. Component development throughEnterprise JavaBeans (EJBs)
and .NET Components has increasingly become a part ofarchitectures and
enterprise deployments over the past couple of years. Bothtechnologies
are distributed and accessible through a variety of RPC mechanisms.
Aweb service supports RPC by providing services of its own, equivalent
to those of atraditional component, or by translating incoming
invocations into an invocation of anEJB or a .NET component.

 Supports document exchange

One of the key advantages of XML is its generic way of
representing not only data,but also complex documents. These documents
can be simple, such as whenrepresenting a current address, or they can
be complex, representing an entire book orRFQ. Web services support
the transparent exchange of documents to facilitatebusiness
integration.

The Major Web Services Technologies

Several technologies have been introduced under the web service
rubric and many more willbe introduced in coming years. In fact, the web
service paradigm has grown so quickly thatseveral competing technologies
are attempting to provide the same capability. However, theweb service
vision of seamless worldwide business integration is not be feasible
unless thecore technologies are supported by every major software
company in the world.

Over the past two years, three primary technologies have emerged as
worldwide standardsthat make up the core of today's web services
technology. These technologies are:

 Simple Object Access Protocol (SOAP)

SOAP provides a standard packaging structure for transporting XML
documents overa variety of standard Internet technologies, including
SMTP, HTTP, and FTP. It alsodefines encoding and binding standards for
encoding non-XML RPC invocations inXML for transport. SOAP provides a
 simple structure for doing RPC: documentexchange. By having a standard
transport mechanism, heterogeneous clients andservers can suddenly
become interoperable. .NET clients can invoke EJBs exposedthrough
SOAP, and Java clients can invoke .NET Components exposed throughSOAP.

 Web Service Description Language (WSDL)

WSDL is an XML technology that describes the interface of a web
service in astandardized way. WSDL standardizes how a web service
represents the input andoutput parameters of an invocation externally,
the function's structure, the nature ofthe invocation (in only,
in/out, etc.), and the service's protocol binding. WSDL
allowsdisparate clients to automatically understand how to interact
with a web service.

 Universal Description, Discovery, and Integration (UDDI)

UDDI provides a worldwide registry of web services for
advertisement, discovery, andintegration purposes. Business analysts
and technologists use UDDI to discoveravailable web services by
searching for names, identifiers, categories, or thespecifications
implemented by the web service. UDDI provides a structure
forrepresenting businesses, business relationships, web services,
specification metadata,and web service access points.

Individually, any one of these technologies is only evolutionary. Each

provides a standard forthe next step in the advancement of web services,
their description, or their discovery.However, one of the big promises
of web services is seamless, automatic business integration:a piece of
software will discover, access, integrate, and invoke new services from
unknowncompanies dynamically without the need for human intervention.
Dynamic integration of thisnature requires the combined involvement of
SOAP, WSDL, and UDDI to provide a dynamic,standard infrastructure for
enabling the dynamic business of tomorrow. Combined, thesetechnologies
are revolutionary because they are the first standard technologies to
offer thepromise of a dynamic business. In the past, technologies
provided features equivalent toSOAP, WSDL, and UDDI in other languages,
but they weren't supported by every majorcorporation and did not have a
core language as flexible as XML.

The relationship between these pieces (SOAP, WSDL, and UDDI) can be
described asfollows: an application acting in the role of a web services
client needs to locate anotherapplication or a piece of business logic
located somewhere on the network. The client queriesa UDDI registry for
the service either by name, category, identifier, or
specificationsupported. Once located, the client obtains information
about the location of a WSDLdocument from the UDDI registry. The WSDL
document contains information about how tocontact the web service and
the format of request messages in XML schema. The clientcreates a SOAP
message in accordance with the XML schema found in the WSDL and sendsa
request to the host (where the service is).

Figure provide a diagram that demonstrates the relationship between

these threetechnologies.
 Applicatio
n HTTP Request

SOAP CLIENT SOAP PROCESSOR

HTTP Response

Servic
Discrete
e
Business Logic

UDDI Registry

Practical Applications for Web Services

Because of the cross-platform interoperability promised by SOAP and
web services, we canprovide practical business solutions to problems
that, until now, have only been a dream ofdistributed-computing
proponents.

It's easy to see the use for simple, discrete web services such as
a currency conversion servicethat converts dollars to Euros or a natural
language translation service that converts English toFrench. Today, web
sites such as www.xmethods.com are dedicated to hosting simple
webservices.

This scenario becomes more exciting when we see real companies

using web services toautomate and streamline their business processes.
Let's use the concept of a Business-to-Consumer (B2C) portal. Web-based
portals, such as those used by the travel industry, oftencombine the
offerings of multiple companies' products and services and present them
with aunified look and feel to the consumer accessing the portal. It's
difficult to integrate thebackend systems of each business to provide
the advertised portal services reliably andquickly.

Web services technology is already being used in the integration

between Dollar Rent A CarSystems, Inc. and Southwest Airlines Co. Dollar
uses the Microsoft SOAP Toolkit tointegrate its online booking system
with Southwest Airlines Co.'s site. Dollar's bookingsystem runs on a Sun
Solaris server, and Southwest's site runs on a Compaq OpenVMSserver. The
net result (no pun intended) is that a person booking a flight on
SouthwestAirline's web site can reserve a car from Dollar without
leaving the airline's site. The resultingsavings for Dollar are a lower
cost per transaction. If the booking is done online throughSouthwest and
other airline sites, the cost per transaction is about $1.00. When
bookingthrough traditional travel agent networks, this cost can be up to
$5.00 per transaction.
Software as a service

Software as a service sometimes referred to as "software on

demand," is software that is deployed over the internet and/or is
deployed to run behind a firewall on a local area network or personal
computer. With SaaS, a provider licenses an application to customers
either as a service on demand, through a subscription, in a "pay-as-you-
go" model, or (increasingly) at no charge. This approach to application
delivery is part of the utility computing model where all of the
technology is in the "cloud" accessed over the Internet as a service.

Advantages:

 Pay per use

 Anytime, anywhere accessibility
 Pay as you go
 Instant scalability
 Security
 Reliability
 APIs

SaaS was initially widely deployed for sales force automation and
Customer Relationship Management (CRM). Now it has become commonplace
for many business tasks, including accounting software, computerized
billing, ERP software, invoicing, human resource management, financials,
content management, collaboration, document management, and service desk
management.

Software and business professionals generally associate the term

SaaS with business software, and as a possibly lower-cost way for
businesses to use software as needed rather than license every
application on every device. With a well-designed implementation and
properly priced licenses, on-demand SaaS provides license benefits
without the associated complexity and the potential high cost to equip
devices with applications they may not need.

Though many Unix applications already work using the SaaS model,
EULA applications did not have this flexibility before SaaS. A licensed
copy of a word processor, for example, had to reside on each machine in
order to create a document on that machine. The equipped program has no
intrinsic value loaded on a computer that is turned off for the night.
The same employee would need another fully paid license to write or edit
a report at home on their own computer, while the work license is
inoperative.

Key characteristics:

 Network-based access to, and management of, commercially available

software.
 Activities managed from central locations rather than at each
customer's site, enabling customers to access applications remotely
via the Web.
 Application delivery typically closer to a one-to-many model
(single instance, multi-tenant architecture) than to a one-to-one
 model, including architecture, pricing, partnering, and management
characteristics.
 Centralized feature updating, which obviates the need for end-users
to download patches and upgrades.
 Frequent integration into a larger network of communicating
software—either as part of a mashup or a plugin to a platform as a
service.

SaaS providers generally price applications on a per-user basis

and/or per business basis, sometimes with a relatively small minimum
number of users and often with additional fees for extra bandwidth and
storage. SaaS revenue streams to the vendor are therefore lower initially
than traditional software license fees, but are also recurring, and
therefore viewed as more predictable, much like maintenance fees for
licensed software.

Some SaaS applications are free to the user, with revenue being
derived from alternate sources such as advertising, or upgrade fees for
enhanced functionality (often referred to as "freemium"). Examples of
free SaaS applications include large players such as Gmail and Google
Docs, as well as smaller providers like Wave Accounting (free
accounting) and Freshbooks (freemium time tracking and invoicing).

In addition to characteristics mentioned above, SaaS sometimes provides:

 More feature requests from users, since there is frequently no

marginal cost for requesting new features
 Faster new feature releases, since the entire community of users
benefits
 Embodiment of recognized best practices, since the user community
drives the software publisher to support best practice

Benefits:

 Save money by not having to purchase servers or other software to

support use.
 Faster Implementation. Customers can deploy SaaS services/products
within hours rather than weeks or months.
 Focus Budgets on competitive advantage rather than infrastructure
(Low Total Cost of Ownership)
 Monthly obligation rather than up front capital cost
 Reduced need to predict scale of demand and infrastructure
investment up front as available capacity matches demand
 Multi-Tenant efficiency
 Flexibility and scalability
 Reliability

Implementation:

One of the companies that sells that kind of service classifies SaaS
into four "maturity levels," whose key attributes are configurability,
multi-tenant efficiency, and scalability. Each level is distinguished
from the previous one by the addition of one of those three attributes:
  Level 1 - Ad-hoc/custom: Each customer has a customized version of
the hosted application that runs as its own instance on the host's
servers. Migrating a traditional non-networked or client–server
application to this level of SaaS typically requires the least
development effort, and reduces operating costs by consolidating
server hardware and administration.

 Level 2 - Configurable: This adds greater program flexibility

through configurable metadata, so many customers use separate
instances of the same application code. This lets the vendor meet
different customer needs through detailed configuration options,
while simplifying common code base maintenance and updating.

 Level 3 - Configurable, multi-tenant-efficient: This adds multi-

tenancy to the second level, so a single program instance serves
all customers. This enables more efficient server resource use
without apparent difference to the end user, but ultimately faces
scalability limits.

 Level 4 - Scalable, configurable, multi-tenant-efficient: The

fourth and final SaaS maturity level adds scalability through a
multitier architecture that supports a load-balanced farm of
identical application instances that run on a variable number of
servers. The provider can adjust system capacity to match demand by
adding or removing servers without further altering the software
architecture.

SaaS architectures may also use virtualization, either in addition

to multi-tenancy, or in place of it. A principal virtualization benefit
is that it can increase system capacity without additional programming.
On the other hand, much programming may be required to construct a more
efficient multi-tenant application. Combining multi-tenancy and
virtualization provides still greater flexibility to tune the system for
optimal performance. In addition to full operating system-level
virtualization, other virtualization techniques applied to SaaS include
application virtualization and virtual appliances.

SaaS application development may use various types of software

components and frameworks. These tools can reduce time-to-market and the
cost of converting a traditional on-premise software product or building
and deploying a new SaaS solution. Examples include components for
subscription management, grid computing software, web application
frameworks, and complete SaaS platform products.

SaaS and SOA:

Much like other software, SaaS can also take advantage of Service
Oriented Architecture to let software applications communicate with each
other. Each software service can act as a service provider, exposing its
functionality to other applications via public brokers, and can also act
as a service requester, incorporating data and functionality from other
services. Enterprise Resource Planning (ERP) Software providers leverage
SOA in building their SaaS offerings.
 Software as a secure service (SaSS) is a variation of SaaS that
provides security in the link to the service, content storage on the
service, and non-proprietary format data backups and restores of data
stored on the service.

Web Service Architecture

There are two ways to view the web service architecture. The first
is to examine the individual roles of each web service actor; the second
is to examine the emerging web service protocol stack.

1. Web Service Roles:

There are three major roles within the web service architecture:
 Service provider: This is the provider of the web service.
The service provider implements the service and makes it
available on the Internet.

 Service requestor: This is any consumer of the web service.

The requestor utilizes an existing web service by opening a
network connection and sending an XML request.

 Service registry: This is a logically centralized directory

of services. The registry provides a central place where
developers can publish new services or find existing ones.
It therefore serves as a centralized clearinghouse for
companies and their services.

Service
Registry

Service Service
2 Provider
Requestor

2. Web Service Protocol Stack

A second option for viewing the web service architecture is to
examine the emerging web service protocol stack. The stack is still
evolving, but currently has four main layers. Following is a brief
description of each layer.

 Service transport: This layer is responsible for transporting

messages between applications. Currently, this layer includes
hypertext transfer protocol (HTTP), Simple Mail Transfer Protocol
 (SMTP), file transfer protocol (FTP), and newer protocols, such
as Blocks Extensible Exchange Protocol (BEEP).

 XML messaging: This layer is responsible for encoding messages in

a common XML format so that messages can be understood at either
end. Currently, this layer includes XML-RPC and SOAP.

 Service description: This layer is responsible for describing the

public interface to a specific web service. Currently, service
description is handled via the Web Service Description Language
(WSDL).

 Service discovery: This layer is responsible for centralizing

services into a common registry, and providing easy publish/find
functionality. Currently, service discovery is handled via
Universal Description, Discovery, and Integration (UDDI). As web
services evolve, additional layers may be added, and additional
technologies may be added to each layer.

Service Discovery
UDDI

Service Description
WSDL

Service Invocation
SOAP

Transport
HTTP

 UDDI:

The Universal Description, Discovery, and Integration (UDDI)

Project provides a standardized method for publishing and discovering
information about web services. The UDDI Project is an industry
initiative that attempts to create a platform-independent, open
framework for describing services, discovering businesses, and
integrating business services. UDDI focuses on the process of
discovery in the service-oriented architecture.
 Web services are becoming the basis for electronic commerce of
all forms. Companies invoke the services of other companies to
accomplish a business transaction. In an environment in which only a
few companies participate, managing the discovery of business partners
manually would be simple. After all, how difficult would it be to
figure out if one of your few business partners has an access point
that adheres to your requirements? This model breaks down, however, as
the number of companies that you need to interact with grows, along
with the number and types of interfaces they export. How do you
discover all the business partners that you can do business with? If
you attempted to account for them manually, you could never be sure
that you discovered every partner. UDDI is a single conceptual
registry distributed among many nodes that replicate the participating
businesses' data with one another. The UDDI registry of services
(hosted by different businesses on the Internet) attempts to solve
this problem.

Prior to the UDDI project, no industry-wide approach was

available for businesses to reach their customers and partners with
information about their products and web services. Nor was there a
uniform method that detailed how to integrate the systems and
processes that are already in place at and between business partners.
Nothing attempted to cover both the business and development aspects
of publishing and locating information associated with a piece of
software on a global scale.

Conceptually, a business can register three types of information

into a UDDI registry. The specification does not call out these types
specifically, but they provide a good summary of what UDDI can store
for a business:

 White pages: Basic contact information and identifiers about a

company, including business name, address, contact information, and
unique identifiers such as D-U-N-S numbers or tax IDs. This
information allows others to discover your web service based upon
your business identification.

 Yellow pages: Information that describes a web service using

different categorizations (taxonomies). This information allows
others to discover your web service based upon its categorization
(such as being in the manufacturing or car sales business).

 Green pages: Technical information that describes the behaviors and

supported functions of a web service hosted by your business. This
information includes pointers to the grouping information of web
services and where the web services are located.

 Web Service Description Language:

WSDL describes what a service does, how to invoke its

operations, and where to find it. WSDL has created separate
definitions and terminology for defining a web service, the
communication endpoint where that web service exists, the legal format
for input and output messages for the web service, and an abstract way
to declare a binding to a concrete protocol and data format.
Everything defined within a WSDL file is abstract: it's just the
definition of parameters and constraints for how communication should
occur at runtime. The web service implementation has to adhere to the
guidelines defined in the WSDL file but has some flexibility over
specifics. WSDL also provides the ability to define a binding that
attaches an abstract set of message definitions to a concrete protocol
or data format. A bindingextension is a type of binding defined for a
major protocol. WSDL defines out-of-the-box binding extensions for
SOAP 1.1, HTTP GET, HTTP POST, and MIME.

Since WSDL is just an abstract description of a web service's

interface, it is conceivable that implementation code can be generated
from a WSDL definition and that WSDL definitions can be created
automatically from existing implementation code. From a programming
perspective, using WSDL to generate code is one of its biggest values.
Methods of generating WSDL from existing components have also been
discovered. Both techniques are a boon to developers and nondevelopers
alike and lend credibility to the notion of truly dynamic computing
models.

 Simple Object Access Protocol:

Simple Object Access Protocol (SOAP) means various things to

different people. It's a wire protocol. It's an RPC mechanism. It's an
interoperability standard. It's a document exchange protocol. It's a
universal business-to-business communications language. It's
everything you would ever need. It's not nearly enough.
 Simple:
For starters, the "S" in SOAP stands for "simple." The basic
approach of expressing data as XML and transporting it across the
Internet using HTTP is simple. In the SOAP protocol, everything that
goes across the wire is expressed in terms of HTTP or SMTP headers,
MIME encoding, and a special XML grammar for encoding application data
and objects. However, a full understanding of the details and rules of
SOAP is not for the faint of heart. For instance, the idea of
expressing a SOAP document with attachments using the email and MIME
metaphor is simple. Is MIME simple? It is simple only because it uses
a data formatting convention that is already in widespread use, is
familiar to most IT people, and is conceptually understood by less
technical people. Perhaps the "S" should stand for "simpler."
Perhaps the "S" should stand for "straightforward." In SOAP,
nothing is hidden intentionally. Every aspect of a SOAP request is
intended to be completely self-describing and largely based on a
conglomeration of proven, well-established conventions. That's the
real beauty behind SOAP; the platforms and programming languages on
both sides of a SOAP conversation are independent of one another, yet
they can communicate as long as each side of the conversation can:

o Send and receive data transmissions across a network using

either HTTP or SMTP1
o Understand MIME encoding rules and base the means of
constructing and deconstructing binary attachments on those
rules
o Construct and deconstruct XML documents that conform to the
enveloping and encoding rules established by SOAP
 o Perform the required action, if an action is indicated in the
SOAP document

 Object:
The "O" in SOAP stands for "object" and has to do with its roots
as a way of invoking COM objects across the Internet. As with its
close cousin XML-RPC, SOAP is fully capable of describing a remote
procedure call or method invocation.
 Access:
A key feature of SOAP and web services is their accessibility.
The initial developers of SOAP intended for all SOAP conversations to
be carried out via a "binding" to another lower-level protocol, and
that binding would most likely be HTTP or SMTP. These protocols were
chosen because they are almost universally available. Most firewalls
have been trained to allow HTTP sessions and SMTP exchanges, so SOAP
conversations can easily cross corporate boundaries.
It's possible to create a SOAP binding for almost any protocol—
however, for the time being, HTTP is the de facto binding (and most
widely used). Other bindings, such as SOAP over RMI, or SOAP over JMS
(for improved reliability), are emerging.

 Protocol:
Put all these factors together and we have a protocol. SOAP is an
XML based protocol used to exchange information throughout a
distributed environment.

 Message-Based Document Exchange and RPC: SOAP has its roots in

synchronous remote procedure calls over HTTP—although you wouldn't
know it by reading the specification these days. In fact, the
specification seems to go out of its way to distance itself from
that association. Although special provisions are available for
performing synchronous RPC calls in SOAP, there is also an
asynchronous, message-based document exchange model. Actually, the
document exchange model is the default method of exchanging data
between two endpoints. An RPC call is a specialized case of
combining multiple one-way asynchronous messages into a request-
response.

 TRANSPORT:

The bottom of the web service protocol stack is service

transport. This layer is responsible for actually transporting XML
messages between two computers.

Currently, HTTP is the most popular option for service transport.

HTTP is simple, stable, and widely deployed. Furthermore, most
firewalls allow HTTP traffic. This allows XMLRPC or SOAP messages to
masquerade as HTTP messages. This is good if you want to easily
integrate remote applications, but it does raise a number of security
concerns.

While HTTP does get the job done, a number of critics have argued
that HTTP is not ideal for web services. In particular, HTTP was
originally designed for remote document retrieval, and is now being
 reworked to support RPCs. RPCs demand greater efficiency and
reliability than document retrieval does.

SOA

The composite computing model defines a vision for what computing

should be. Service oriented architecture (SOA) represents a way to
achieve this vision using the set of technologies that make up the Web
Services Technology Stack. This set of technologies currently consists
of SOAP, WSDL, and UDDI, though other components may be added in the
future.

SOA seemed to appear almost out of nowhere in September 2000. The

originator was IBM and the introduction mechanism was an article by the
IBM Web Services Architecture team on the developerWorks web site
(http://www.ibm.com/developerWorks). Since then, this group has used it
as a way to extol the virtues of web services to nontechnical users. The
SOA is an instance of a composite computing model, and thus something
that can be used to further our understanding of it. Conceptually, the
SOA model is comprised of three roles performing three fundamental
interactions. The components of the SOA are our good friends, web
services. Each web service is made up of two parts:

 Service: The implementation for a web service. A service can be as

minuscule as a JavaScript file or as elaborate as a 30-year-old,
industrial-strength COBOL application running on a mainframe. The
key requirement is that it be on a network-accessible platform,
provided by the web service provider.

 Service description: The interface for a web service. It is

expressed in XML and is governed by one or more standards. This
description includes the datatypes, operations, protocol bindings
and network location (i.e., the URL, etc.) for the web service's
implementation. Additional documents provide categorization and
other metadata to facilitate discovery.

Participant Roles:
The SOA is based upon the interactions between three roles: a
provider, a registry (or broker), and a requestor. The interactions
between these roles involve publishing information about a service,
finding which services are available, and binding to those services.

In a typical scenario, a provider hosts the implementation for a

service. Providers define service descriptions for services and publish
them to a registry. A requestor then uses a registry to find service
descriptions for services they are interested in using. With the service
description in hand, the requestor binds (i.e., creates a service
request for) to a service.
Requestor Registry

Find
UDDI

Provider

Bind Publish
WSDL, SOAP UDDI

Provider

Provider

SERVICE-ORIENTED ARCHITECTURE

 Provider:
In the SOA, a provider is considered the owner of a service. From
a composite computing perspective, it is a software asset that others
regard as a network-accessible service. In most cases, this software
asset is exposed as a web service, which by definition:

 Has an XMLized description

 Has a concrete implementation that encapsulates its behavior
 Almost any piece of logic can be exposed as a service in an SOA—
from a single component to a full-blown, mainframe-based business
process, such as loan processing. Likewise, how the service is exposed
is up to the provider; you can access it through SOAP over HTTP, through
a JMS message queue, or via other technologies (such as SMTP); the
service may implement a request/response protocol, or it may just
receive messages and deliver asynchronous replies.

As is often the case in modern software development, some

fundamental ambiguities exist in basic terms such as "provider." Does it
mean the organization providing the service, the software itself, or the
computer (or computers) on which the software runs? The meaning is
almost always clear from the context.

 Registry (broker)
A registry, or a broker, manages repositories of information on
providers and their software assets. This information includes:

 Business data such as name, description, and contact information

("white pages" data)
 Data describing policies, business processes, and software
bindings—in other words, information needed to make use of the
service ("green pages" data)

A service broker usually offers intelligent search

capabilities and business classification or taxonomy data (called
"yellow pages" data). From a composite computing perspective, a
broker represents a searchable registry of service descriptions,
published by providers. During the development cycle for a web
service, a programmer (or tool) can use the information in
registries to create static bindings to services. At runtime, an
application can tap into a registry (local or remote) to obtain
service descriptions and create dynamic bindings to services.

Registries often sound abstract, but they solve a very

concrete problem. They allow you (or, more properly, your software)
to ask questions such as, "Who sells widgets?" Once you have an
answer to that question, you can ask more questions, such as, "How
do I interact with their service to find prices, place orders,
etc.?" In short, a registry lets you look up a service and then
find its programmatic interface.

 Requestor
In the service-oriented architecture, a requestor is a business
that discovers and invokes software assets provided by one or more
providers. From a composite computing perspective, a requestor is an
application that looks for and initiates an interaction with a
provider. This role could be played by:

 A person using a web browser

 Computational entities without a user interface, such as another
web service
 Again, there's a lot of ambiguity: is a requestor a person, an
organization, or a piece of software? If it's software, is it a
browser of some sort, or is it another kind of software? Again, the
answer depends on the context.

Participant Interactions
Having defined the roles that participants in web services can
play, we'll look in more detail at how they interact. There are three
fundamental types of interaction: publishing, service location, and
binding.

 2.1.2.1 Publishing
Providers publish information (or metadata) about services to a
registry. These providers are usually standards organizations,
software vendors, and developers. According to IBM's Web Services
Conceptual Architecture document, several different mechanisms are
used to publish service descriptions:

Direct: The service requestor retrieves the service description

directly from the service provider, using email, FTP, or a
distribution CD. Here, the service provider delivers the service
description and simultaneously makes the service available to a
requestor. There is no registry as such; the requestor is responsible
for locating services and retrieving their descriptions.

HTTP GET request: This mechanism is currently used at

http://www.xmethods.com/, a public repository of web services that
developers can use to test their wares. The service requestor
retrieves the service description directly from the service provider
by using an HTTP GET request. This model has a registry (the public
web repository), though only in a limited sense.

Dynamic discovery: This mechanism uses local and public registries

to store and retrieve service descriptions programmatically. In the
web services world, the most frequently used registry is UDDI, though
others exist (for example, ebXML R). Contextually, the service
provider is an application that uses a specialized set of APIs to
publish the service description.

The direct publishing method is a historical artifact and of

little interest to us. Publishing with a GET request is more
interesting, particularly since http://www.xmethods.com/ has been on
the forefront of web services development. However, we see this means
of publishing as transitional—a temporary tool to get us from direct
publishing to dynamic discovery. Dynamic discovery is the most
interesting and versatile publishing model. UDDI and other protocols
designed to support dynamic discovery are at the center of the web
services landscape.

Provider Registry

Here’s my Service
 Publishing for dynamic discovery
 2.1.2.2 Service location (finding)
Given that registries or brokers publish services, how do you
locate services that you wish to use? Requestors find services using a
registry or broker. Service location is closely associated with
dynamic discovery. In this context, the requestor is an application
that uses a specialized set of APIs to query a public or private
registry for service descriptions. These queries are formatted in a
well-defined, standard XML format and transmitted using an XML
messaging format, such as SOAP or XML-RPC. The criteria used to find a
service include the quality of service (How quickly can the service
respond? How good are its results?), supported protocols (Can my
client talk to your service?), and the service taxonomy (What kind of
service?). It's easy to imagine other criteria that you could use to
locate a service.

Requestor Registry

Where can I find ?

Look Here

Service location
 2.1.2.3 Binding
The binding interaction involves the requestor and provider and,
optionally, the registry. In context, binding is what an application
does when it uses the service description to create a message to be
sent to the service provider. Web service description documents (WSDL
documents) specify the network protocols (i.e., HTTP, MIME, SMTP,
etc.) that a service supports, the APIs by which the service is
accessed, and everything else that a requestor needs to use a service.

Requestor Registry

How do I access?

Here’s how
What is the price of tea in China ?

$ 1.50/ pound
Provider