What is a Web service?
Many people and companies have debated the exact definition of Web services. At a
minimum, however, a Web service is any piece of software that makes itself available
over the Internet and uses a standardized XML messaging system.
XML is used to encode all communications to a Web service. For example, a client
invokes a Web service by sending an XML message, then waits for a corresponding XML
response. Because all communication is in XML, Web services are not tied to any one
operating system or programming language--Java can talk with Perl; Windows
applications can talk with Unix applications.
Beyond this basic definition, a Web service may also have two additional (and
desirable) properties:
First, a Web service can have a public interface, defined in a common XML grammar.
The interface describes all the methods available to clients and specifies the
signature for each method. Currently, interface definition is accomplished via theWeb Service Description Language (WSDL).
Second, if you create a Web service, there should be some relatively simple mechanism
for you to publish this fact. Likewise, there should be some simple mechanism for
interested parties to locate the service and locate its public interface. The most
prominent directory of Web services is currently available via UDDI, or Universal
\Description, Discovery, and Integration.
Web services currently run a wide gamut from news syndication and stock-market data
to weather reports and package-tracking systems. For a quick look at the range of Web
services currently available, check out the XMethods directory of Web services.
What is the Web service protocol stack?
The Web service protocol stack is an evolving set of protocols used to define,
discover, and implement Web services. The core protocol stack consists of four
layers:
Service Transport: This layer is responsible for transporting messages between
applications. Currently, this includes HTTP, SMTP, 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 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 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 the UDDI.
Beyond the essentials of XML-RPC, SOAP, WSDL, and UDDI, the Web service protocol
stack includes a whole zoo of newer, evolving protocols.
What is SOAP?
SOAP stands for Simple Object Access Protocol
SOAP is a communication protocol
SOAP is a format for sending messages
SOAP is designed to communicate via Internet
SOAP is platform independent
SOAP is language independent
SOAP is based on XML
SOAP is simple and extensible
SOAP allows you to get around firewalls
SOAP is a W3C standard
SOAP is an XML-based protocol for exchanging information between computers. Although
SOAP can be used in a variety of messaging systems and can be delivered via a variety
of transport protocols, the main focus of SOAP is Remote Procedure Calls (RPC)
transported via HTTP. Like XML-RPC, SOAP is platform independent, and therefore
enables diverse applications to communicate with one another.
To get a quick sense of SOAP, here is a sample SOAP request to a weather service
(with the HTTP Headers omitted):
<?xml version='1.0' encoding='UTF-8'?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://www.w3.org/2001/09/soap-envelope"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<SOAP-ENV:Body>
<ns1:getWeather
xmlns:ns1="urn:examples:weatherservice"
SOAP-ENV:encodingStyle=" http://www.w3.org/2001/09/soap-encoding
<zipcode xsi:type="xsd:string">10016</zipcode>
</ns1:getWeather>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
As you can see, the request is slightly more complicated than XML-RPC and makes use
of both XML namespaces and XML Schemas. Much like XML-RPC, however, the body of the
request specifies both a method name (getWeather), and a list of parameters
(zipcode).
Here is a sample SOAP response from the weather service:
<?xml version='1.0' encoding='UTF-8'?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://www.w3.org/2001/09/soap-envelope"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<SOAP-ENV:Body>
<ns1:getWeatherResponse
xmlns:ns1="urn:examples:weatherservice"
SOAP-ENV:encodingStyle="http://www.w3.org/2001/09/soap-encoding">
<return xsi:type="xsd:int">65</return>
</ns1:getWeatherResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
The response indicates a single integer return value (the current temperature).
SOAP Building Blocks
A SOAP message is an ordinary XML document containing the following elements:
An Envelope element that identifies the XML document as a SOAP message
A Header element that contains header information
A Body element that contains call and response information
A Fault element containing errors and status information
All the elements above are declared in the default namespace for the SOAP envelope:
http://www.w3.org/2001/12/soap-envelope
and the default namespace for SOAP encoding and data types is:
http://www.w3.org/2001/12/soap-encoding
Syntax Rules
Here are some important syntax rules:
A SOAP message MUST be encoded using XML
A SOAP message MUST use the SOAP Envelope namespace
A SOAP message MUST use the SOAP Encoding namespace
A SOAP message must NOT contain a DTD reference
A SOAP message must NOT contain XML Processing Instructions
Skeleton SOAP Message
<?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:Fault>
...
</soap:Fault>
</soap:Body>
</soap:Envelope>
What is WSDL?
The Web Services Description Language (WSDL) currently represents the service
description layer within the Web service protocol stack.
In a nutshell, WSDL is an XML grammar for specifying a public interface for a Web
service. This public interface can include the following:
Information on all publicly available functions.
Data type information for all XML messages.
Binding information about the specific transport protocol to be used.
Address information for locating the specified service.
WSDL is not necessarily tied to a specific XML messaging system, but it does include
built-in extensions for describing SOAP services.
Below is a sample WSDL file. This file describes the public interface for the weather
service used in the SOAP example above. Obviously, there are many details to
understanding the example. For now, just consider two points.
First, the <message> elements specify the individual XML messages that are
transferred between computers. In this case, we have a getWeatherRequest and a
getWeatherResponse. Second, the element specifies that the service is available via
SOAP and is available at a specific URL.
<?xml version="1.0" encoding="UTF-8"?>
<definitions name="WeatherService"
targetNamespace="http://www.ecerami.com/wsdl/WeatherService.wsdl"
xmlns="http://schemas.xmlsoap.org/wsdl/"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="http://www.ecerami.com/wsdl/WeatherService.wsdl"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<message name="getWeatherRequest">
<part name="zipcode" type="xsd:string"/>
</message>
<message name="getWeatherResponse">
<part name="temperature" type="xsd:int"/>
</message>
<portType name="Weather_PortType">
<operation name="getWeather">
<input message="tns:getWeatherRequest"/>
<output message="tns:getWeatherResponse"/>
</operation>
</portType>
<binding name="Weather_Binding" type="tns:Weather_PortType">
<soap:binding style="rpc"
transport="http://schemas.xmlsoap.org/soap/http"/>
<operation name="getWeather">
<soap:operation soapAction=""/>
<input>
<soap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="urn:examples:weatherservice"
use="encoded"/>
</input>
<output>
<soap:body
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
namespace="urn:examples:weatherservice"
use="encoded"/>
</output>
</operation>
</binding>
<service name="Weather_Service">
<documentation>WSDL File for Weather Service</documentation>
<port binding="tns:Weather_Binding" name="Weather_Port">
<soap:address
location="http://localhost:8080/soap/servlet/rpcrouter"/>
</port>
</service>
</definitions>
Using WSDL, a client can locate a Web service, and invoke any of the publicly
available functions. With WSDL-aware tools, this process can be entirely automated,
enabling applications to easily integrate new services with little or no manual code.
For example, check out the GLUE platform from the Mind
Electric.
The WSDL Document Structure
A WSDL document describes a web service using these major elements:
Element Defines
<types> The data types used by the web service
<message> The messages used by the web service
<portType> The operations performed by the web service
<binding> The communication protocols used by the web service
The main structure of a WSDL document looks like this:
<definitions>
<types>
definition of types........
</types>
<message>
definition of a message....
</message>
<portType>
definition of a port.......
</portType>
<binding>
definition of a binding....
</binding>
</definitions>
A WSDL document can also contain other elements, like extension elements, and a
service element that makes it possible to group together the definitions of several
web services in one single WSDL document.
WSDL Ports
The <portType> element is the most important WSDL element.
It describes a web service, the operations that can be performed, and the messages
that are involved.
The <portType> element can be compared to a function library (or a module, or a
class) in a traditional programming language.
WSDL Messages
The <message> element defines the data elements of an operation.
Each message can consist of one or more parts. The parts can be compared to the
parameters of a function call in a traditional programming language.
WSDL Types
The <types> element defines the data types that are used by the web service.
For maximum platform neutrality, WSDL uses XML Schema syntax to define data types.
WSDL Bindings
The <binding> element defines the message format and protocol details for each port.
WSDL Example
This is a simplified fraction of a WSDL document:
<message name="getTermRequest">
<part name="term" type="xs:string"/>
</message>
<message name="getTermResponse">
<part name="value" type="xs:string"/>
</message>
<portType name="glossaryTerms">
<operation name="getTerm">
<input message="getTermRequest"/>
<output message="getTermResponse"/>
</operation>
</portType>
In this example the <portType> element defines "glossaryTerms" as the name of a port,
and "getTerm" as the name of an operation.
The "getTerm" operation has an input message called "getTermRequest" and an output
message called "getTermResponse".
The <message> elements define the parts of each message and the associated data
types.
Compared to traditional programming, glossaryTerms is a function library, "getTerm"
is a function with "getTermRequest" as the input parameter, and getTermResponse as
the return parameter.
What is UDDI?
UDDI stands for Universal Description, Discovery and Integration
UDDI is a directory for storing information about web services
UDDI is a directory of web service interfaces described by WSDL
UDDI communicates via SOAP
UDDI is built into the Microsoft .NET platform
UDDI (Universal Description, Discovery, and Integration) currently represents the
discovery layer within the Web services protocol stack.
UDDI was originally created by Microsoft, IBM, and Ariba, and represents a technical
specification for publishing and finding businesses and Web services.
At its core, UDDI consists of two parts.
First, UDDI is a technical specification for building a distributed directory of
businesses and Web services. Data is stored within a specific XML format, and the
UDDI specification includes API details for searching existing data and publishing
new data.
Second, the UDDI Business Registry is a fully operational implementation of the UDDI
specification. Launched in May 2001 by Microsoft and IBM, the UDDI registry now
enables anyone to search existing UDDI data. It also enables any company to register
themselves and their services.
The data captured within UDDI is divided into three main categories:
White Pages: This includes general information about a specific company. For example,
business name, business description, and address.
Yellow Pages: This includes general classification data for either the company or the
service offered. For example, this data may include industry, product, or geographic
codes based on standard taxonomies.
Green Pages: This includes technical information about a Web service. Generally, this
includes a pointer to an external specification, and an address for invoking the Web
service.
You can view the Microsoft UDDI site, or the IBM UDDI site.
What is UDDI Based On?
UDDI uses World Wide Web Consortium (W3C) and Internet Engineering Task Force (IETF) Internet standards such as XML, HTTP, and DNS protocols.
UDDI uses WSDL to describe interfaces to web services
Additionally, cross platform programming features are addressed by adopting SOAP, known as XML Protocol messaging specifications found at the W3C Web site.
UDDI Benefits
Any industry or businesses of all sizes can benefit from UDDI.
Before UDDI, there was no Internet standard for businesses to reach their customers and partners with information about their products and services. Nor was there a method of how to integrate into each other's systems and processes.
Problems the UDDI specification can help to solve:
- Making it possible to discover the right business from the millions currently online
- Defining how to enable commerce once the preferred business is discovered
- Reaching new customers and increasing access to current customers
- Expanding offerings and extending market reach
- Solving customer-driven need to remove barriers to allow for rapid participation in the global Internet economy
- Describing services and business processes programmatically in a single, open, and secure environment
How can UDDI be Used
If the industry published an UDDI standard for flight rate checking and reservation, airlines could register their services into an UDDI directory. Travel agencies could then search the UDDI directory to find the airline's reservation interface. When the interface is found, the travel agency can communicate with the service immediately because it uses a well-defined reservation interface.
