Web Services
Introduction
The popular view of the Internet is the worldwide web. People sit at their computers using a browser to view static web pages stored on a distant server, or view dynamic pages generated by those servers. This use of the Internet is people-centric.The Internet is also used in environments where the human involvement is quite small. Applications programs communicate with each other across the network with little or no human involvement. Typically, a client/server model is used.
Before the introduction of web service standards the interfaces between a server and its clients were developed on an ad-hoc basis. This approach gives rise to a number of problems.
Suppose a rail operating company develops a server that provides pricing and timetable information. By publishing the server interface the company allows travel agents to query the travel information to help plan client’s journeys.
Another rail operating company may wish to provide a similar service, so they develop their own server and publish the interface. A travel agent can develop software for this new interface but he may think that he is duplicating some effort. In addition, the travel agent will have to reconcile difference in the interfaces if he wishes to plan journeys that cross the networks.
The information provided by the rail operators would be far more useful to the travel agents if the rail operators provided the information using the same interface. Using web services, this can be achieved. Web services standards provide ways of describing client/server interfaces. A rail industry standard could be developed which would describe an interface to travel information.
As time goes on, the web service standard for the rail industry would be adopted by more rail operators. The new services would only be of use once the travel agents become aware that the service is available. There are web service standards that provide means whereby service providers can publish the availability of a service and allow potential clients to discover those services.
In summary, there are web service standards for:
- Registration of the availability of a service.
- Discovery of a service.
- Description of a service interface.
- The client/server interface.
The following sections look at the components of a web service and the standards for registration, discovery and description.
Components
Web service architecture identifies three types of component, the service provider, service client and service registry. Communications between components is based on XML messaging. The web service components are described in the following sub-sections.Service Provider
The service provider implements the server side of the client/server interface. It provides a service to its clients. The services are published within the registry.Service Client
The service client makes use of the service. It implements the client side of the client server interface. It uses the registry to discover a service and its description.Service Registry
The registry is a network server that maintains details of available services. The registry data is provided by the service providers and queried by the service clients.
Protocols
Communications between the web service components is based on messaging. XML formatted messages are exchanged between components. Typically, delivery is by HTTP but other protocols may be used. SOAP allows methods to be invoked remotely. UDDI includes the procedures for updating and searching service registries. WSDL is a language for describing client/server interfaces. Communications between client and server is application dependent but based on SOAP.
HTTP
The Hypertext Transfer Protocol (HTTP) is the protocol used by web browsers to access pages on the worldwide web. HTTP is also used to transfer messages between clients and servers in web service environments.HTTP is a client/server protocol. Web services are based on the client/server model. Web services make use of the following HTTP messages:
- HTTP GET messages to download files from servers.
- HTTP POST messages are used by the client to cause particular application code to be executed on the server.
Web service clients operate as clients to the registry servers as well as to the web services. Clients request services using HTTP POST messages; they download service descriptions in WSDL files using HTTP GET messages.
HTTP is a good choice as a transport mechanism for web service data. The protocol is widely understood, widely available and stable. HTTP messages are permitted by most firewalls so there should be few set-up problems.
The web service standards allow other transport mechanism to be used. File transfer and email mechanisms such as FTP and SMTP could be used. There are questions over the efficiency of HTTP. To address these concerns a new protocol, the Blocks Extensible Exchange Protocol (BEEP) is being developed.
XML
The basis of web services is messaging. Clients send messages to servers, the servers respond with messages. Web service messages are encoded using the Extensible Markup Language (XML). The content of XML messages is independent of the participating hardware, operating systems and protocols.XML defines syntax for marking up data in a human readable form. The language is extensible, XML based languages can be defined for particular application areas. The extensibility of XML is made use of by the higher web-services protocols.
SOAP
The Simple Object Access Protocol (SOAP) is a protocol for Remote Procedure Calls (RPCs). As it is an extension of XML it is independent of the operating system, programming language and protocols used.A client invokes a procedure (or method) on a remote server by transmitting a SOAP message to the server. The message identifies the remote method and carries the method arguments as objects. When HTTP is used as the underlying transport, the HTTP POST message is sent by the client to initiate the processing of the SOAP messages.
The server performs the invoked procedure and returns the results as objects in another SOAP message.
An example SOAP message follows.
<?xml version="1.0" encoding="UTF-8" ?>
<envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/">
<body>
<get_tModelDetail xmlns="urn:uddi-org:api" generic="1.0">
<tModelKey>
uuid:0e727db0-3e14-11d5-98bf-002035229c64
</tModelKey>
</get_tModelDetail>
</Body>
</Envelope>
This message requests execution of the get_tModelDetail method with a tModelKey parameter.
UDDI
The Universal Description, Discovery and Integration (UDDI) service is the specification to which web service registries conform. UDDI consists of a data model and an application program interface (API).The UDDI data model describes four core object types.
The businessEntity objects describe individual businesses that provide web services. These objects carry information such as the business address and contact information.
The businessService objects describe available web services. Information carried in these objects includes a service name and description as well as bindingTemplate objects.
The bindingTemplate objects describe where a particular object is located and how it should be accessed. This includes the access point of the service and details of the protocol to use (e.g. FTP or HTTP).
The tModel describes the technical model of the interface. This describes the interface. The tModel includes pointers to the WSDL files that describe the interface.
The UDDI API is an extension of SOAP, it provides an RPC interface to the registry database. The methods provided by the UDDI API allow registry data to be published or searched.
The publishing interface to UDDI is used by service provider to advertise the availability of their services. The API includes save_binding, save_business, save_service, save_tModel, delete_binding, delete_business and delete_tModel methods for creating the UDDI objects. It also includes getAuthToken and discard_authToken methods, these ensure that the UDDI data is only modified by those users who are authorised to do so.
The search interface to UDDI is used by potential clients looking for service details. The API includes find_binding, find_business, find_service and find_tModel methods to find UDDI objects matching particular criteria. It also includes getBindingDetail, getBusinessDetail, getServiceDetail and get_tModelDetail to obtain details of particular UDDI objects.
WSDL
The Web Service Definition Language (WSDL) is an XML extension. It is used to describe the client/server interface that should between web service clients and servers. WSDL is capable of describing:- All publicly available methods provided by the service.
- Data types used in method calls and responses.
- Information about how to use the underlying transport mechanism (HTTP, FTP etc).
- The address of the server.
The WSDL file describing a service is stored on a server, perhaps on the registry or the application server. It will be read by the client using a simple HTTP GET exchange.
SAML
Some web service application will be made available to a closed set of users, those who have paid for the service, those who work for particular organisations or those who are known to provide reliable information. The web service standards include the Security Assertion Markup Language (SAML). SAML is a SOAP extension used to provide security functions to web services.The core idea of SAML is the assertion, a fact about something. For example, there may be an assertion that a particular user has been authenticated. A client uses SAML to request an authentication assertion from a security service. The assertion is then used in subsequent requests to other services.
Client/Server Protocols
The interface provided by the server and used by the client is devised by the designers of the service and described in the WSDL file. The client invokes methods on the server, providing any necessary parameters. The server returns objects in the reply. The protocol is based on SOAP.Procedures
In this section, we show how the web services are used in order to discover, describe and use a web service. As an example, we use the Delayed Stock Quote service provided by XMethods.Discovery
Web service clients use web service registries to discover the available web services. There are several web service registries on the Internet. Registries are operated by IBM and Microsoft. In our examples, we use the Microsoft registry, which is accessed via the URL: http://uddi.microsoft.com/inquire.The client wishes to use the Delayed Stock Quotes service provided by XMethods. In order to discover the service, sends a UDDI message to the registry, requesting details about the XMethods services.
<?xml version="1.0" encoding="UTF-8" ?>
<Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/">
<Body>
<find_business xmlns="urn:uddi-org:api" generic="1.0" maxRows="100">
<findQualifiers />
<name>XMethods</name>
</find_business>
</Body>
</Envelope>
The message contains a request for an execution of the
find_business
method on the registry server.
The parameters to the method include the business being requested, in our case
XMethods.
The registry returns a BusinessList object. The BusinessList contains a single element, this lists the services provided by XMethods.
<?xml version="1.0" encoding="utf-8" ?>
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Body>
<businessList
generic="1.0"
operator="Microsoft Corporation"
truncated="false"
xmlns="urn:uddi-org:api">
<businessInfos>
<businessInfo businessKey="ba744ed0-3aaf-11d5-80dc002035229c64">
<name>
XMethods
</name>
<description xml:lang="en">
Web services resource site
</description>
<serviceInfos>
<serviceInfo
serviceKey="d5b180a0-4342-11d5-bd6c-002035229c64"
businessKey="ba744ed0-3aaf-11d5-80dc-002035229c64">
<name>
XMethods Barnes and Noble Quote
</name>
</serviceInfo>
<serviceInfo
serviceKey="ed85f000-4345-11d5-bd6c-002035229c64"
businessKey="ba744ed0-3aaf-11d5-80dc-002035229c64">
<name>
XMethods Pacific Bell SMS Service
</name>
</serviceInfo>
<serviceInfo
serviceKey="d5921160-3e16-11d5-98bf-002035229c64"
businessKey="ba744ed0-3aaf-11d5-80dc-002035229c64">
<name>
XMethods Delayed Stock Quotes
</name>
</serviceInfo>
<serviceInfo
serviceKey="618167a0-3e64-11d5-98bf-002035229c64"
businessKey="ba744ed0-3aaf-11d5-80dc-002035229c64">
<name>
XMethods Currency Exchange Rates
</name>
</serviceInfo>
</serviceInfos>
</businessInfo>
</businessInfos>
</businessList>
</soap:Body>
</soap:Envelope>
The response shows that XMethods provides four services:
- XMethods Barnes and Noble Quote.
- XMethods Pacific Bell SMS Service.
- XMethods Delayed Stock Quotes.
- XMethods Currency Exchange Rates.
Notice that XMethods is uniquely identified by a businessKey value and that each service is uniquely identified by a serviceKey. If the client needs to know more about the XMethods business such as contact names, phone numbers or email addresses, it could make further queries on the registry using the businessKey.
Out client needs to find out more about the Delayed Quote Service so it makes use of the serviceKey. The client invokes the get_serviceDetail method at the registry, quoting the appropriate service key (d5921160-3e16-11d5-98bf-002035229c64).
<?xml version="1.0" encoding="UTF-8" ?>
<Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/">
<Body>
<get_serviceDetail xmlns="urn:uddi-org:api" generic="1.0">
<serviceKey>
d5921160-3e16-11d5-98bf-002035229c64
</serviceKey>
</get_serviceDetail>
</Body>
</Envelope>
The registry returns a serviceDetail object that describes the XMethods Delayed Stock Quote Service.
<?xml version="1.0" encoding="utf-8" ?>
<soap:Envelope
xlmns:soap=http://schemas.xmlsoap.org/soap/envelope/
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Body>
<serviceDetail
generic="1.0"
operator="Microsoft Corporation" truncated="false"
xmlns="urn:uddi-org:api">
<businessService
serviceKey="d5921160-3e16-11d5-98bf-002035229c64"
businessKey="ba744ed0-3aaf-11d5-80dc-002035229c64">
<name>
XMethods Delayed Stock Quotes
</name>
<description xml:lang="en">
20-minute delayed stock quotes
</description>
<bindingTemplates>
<bindingTemplate
bindingKey="d594a970-3e16-11d5-98bf-002035229c64"
serviceKey="d5921160-3e16-11d5-98bf-002035229c64">
<description xml:lang="en">
SOAP binding for delayed stock quotes service
</description>
<accessPoint URLType="http">
http://services.xmethods.net:80/soap
</accessPoint>
<tModelInstanceDetails>
<tModelInstanceInfo
tModelKey="uuid:0e727db0-3e14-11d5-98bf-002035229c64"/>
</tModelInstanceDetails>
</bindingTemplate>
</bindingTemplates>
</businessService>
</serviceDetail>
</soap:Body>
</soap:Envelope>
The serviceDetail object contains information such as the service name and a brief description. The tModelKey uniquely identifies the technical model, the interface used by the XMethods Delayed Quote Service. The access point is the URL used to access the service (http://services.xmethod.net:80/soap).
The client could use the tModelKey to find out more about the service interface. For example, the registry can provide a list of services that make use of the model. So we could discover other stock quote services, providing data from other financial exchanges. Using our train operator example, we could discover a list of services using the standardised timetable and pricing information.
The client can find out more about a particular model by sending a message to the registry that requests execution of the get_tModelDetail method, quoting the tModelKey.
<?xml version="1.0" encoding="UTF-8" ?>
<Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/">
<Body>
<get_tModelDetail xmlns="urn:uddi-org:api" generic="1.0">
<tModelKey>
uuid:0e727db0-3e14-11d5-98bf-002035229c64
</tModelKey>
get_tModelDetail>
</Body>
</Envelope>
The registry server replies with a tModelDetail object.
<?xml version="1.0" encoding="utf-8" ?>
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Body>
<tModelDetail
generic="1.0"
operator="Microsoft Corporation"
truncated="false"
xmlns="urn:uddi-org:api">
<tModel
tModelKey="uuid:0e727db0-3e14-11d5-98bf-002035229c64"
operator="www.ibm.com/services/uddi"
authorizedName="0100001QS1">
<name>
XMethods Simple Stock Quote
</name>
<description xml:lang="en">
Simple stock quote interface
</description>
<overviewDoc>
<description xml:lang="en">
wsdl link
</description>
<overviewURL>
http://www.xmethods.net/tmodels/SimpleStokeQuote.wsdl
</overviewURL>
</overviewDoc>
<categoryBag>
<keyedReference
tModelKey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4"
keyName="uddi-org:types"
keyValue="wsdlSpec" />
</categoryBag>
</tModel>
</tModelDetail>
</soap:Body>
</soap:Envelope>i
The tModelDetail object contains an overViewURL object. This is the URL of a WSDL document. It describes the client/server interface for the XMethods Delayed Stock Quotes service.
Description
The discovery procedures have allowed a client to search a directory of web services for the service he requires. It has given him the service access point, the web address of the service. It has also given him the location of a WSDL file that describes service interface.A simple HTTP GET request will provide the WSDL file. The file contains:
<?xml version = "1.0"?>
<definitions
name = "XMethods Simple Stock Quotes"
targetNamespace = "http://www.xmethods.net/tmodels/SimpleStockQuotes.wsdl"
xmlns:tns = "http://www.xmethods.net/tmodels/SimpleStockQuotes.wsdl"
xmlns:xsd = "http://www.w3.org/2001/XMLSchema"
xmlns:soap = "http://schemas.xmlsoap.org/wsdl/soap/"
xmlns = "http://schemas.xmlsoap.org/wsdl/">
<message name = "getQuoteRequest">
<part name = "symbol" type = "xsd:string"/>
</message>
<message name = "getQuoteResponse">
<part name = "Result" type = "xsd:float"/>
</message>
<portType name = "StockQuotePortType">
<operation name = "getQuote">
<input message = "tns:getQuoteRequest" />
<output message = "tns:getQuoteResponse" />
</operation>
</portType>
<binding name = "StockQuoteBinding" type = "tns:StockQuotePortType">
<soap:binding
style = "rpc"
transport = "http://schemas.xmlsoap.org/soap/http"/>
<operation name = "getQuote">
<soap:operation
soapAction="http://xmethods.net/SimpleStockQuote/#getQuote"/>
<input>
<soap:body
use = "encoded"
namespace = "http://xmethods.net/SimpleStockQuote/"
encodingStyle = "http://schemas.xmlsoap.org/soap/encoding/"/>
</input>
<output>
<soap:body
use = "encoded"
namespace = "http://xmethods.net/SimpleStockQuote/"
encodingStyle = "http://schemas.xmlsoap.org/soap/encoding/"/>
</output>
</operation>
</binding>
</definitions>
The WSDL file for the XMethods Stock Quote service describes two messages. The getQuoteRequest message contains a stock symbol parameter. The getQuoteResponse message contains a result value. The getQuote operation consists of a getQuoteRequest/ getQuoteResponse message exchange between the client and the server. The symbol value in the request identifies the stock to be queried. The result value in the response is the price of the stock identified by the symbol.
Invocation
The discovery procedures have allowed a client to search a directory of web services for the service he requires. It has given him the service access point, the web address of the service.The discovery procedures have described the interface that client should use in order to make use of the service.
In order to use the service the client composes a getQuoteRequest as shown below. He sends the request to the service at the access point obtained by the discovery process, that is http://services.xmethods.net:80/soap. In this example, the client is requesting the price of Riverstone Networks’ stock, identified by the symbol: RSTN.
<?xml version="1.0" encoding="UTF-8" standalone="no" ?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:tns= "http://www.xmethods.net/tmodels/SimpleStockQuotes.wsdl"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<mns:getQuote
xmlns:mns="http://xmethods.net/SimpleStockQuote/"
SOAP-ENV:encodingStyle ="http://schemas.xmlsoap.org/soap/encoding/">
<symbol xsi:type="xsd:string">
RSTN
</symbol>
</mns:getQuote>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
The price of Riverstone Networks’ stock is $2.26.
The server returns this information as the Result in a
getQuoteResponse.
<?xml version="1.0" encoding="UTF-8" ?>
<soap:Envelope
xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<soap:Body>
<n:getQuoteResponse
xmlns:n="http://xmethods.net/SimpleStockQuote/">
<Result xsi:type="xsd:float">
2.26
</Result>
</n:getQuoteResponse>
</soap:Body>
</soap:Envelope>
Client Development
The previous sub-sections show how clients can send XML messages to the web service registries in order to discover web services. The registries currently provided by IBM and Microsoft also have web browser interfaces. This means that a developer of client software can query the registries without having to write the code to generate the registry requests and parse the responses.The first step in writing client software might be to write a simple client that communicates with only one server. The software developer would use a web browser to discover the server, make a note of the access point and study the WSDL description. He would configure and code these details into the new client.
A more sophisticated client might respond to any problems with the client/server interaction by revisiting the registry and checking whether the access point had moved or whether the service description had changed.
A fully functional client might visit the registry on a regular basis, looking for new services making use of the same interface. The client could make use of the new service immediately or inform the system administrators that a new service is available.
Server Development
Web service registries can be updated by service providers. Again both XML and browser based updates can be performed.Summary
Web service standards are used to develop client/server applications on the Internet.The standards recognise the service provider and client components central to the client server model. The standards also identify additional servers. Registry servers contain details about available services. These details are published by service providers and discovered by clients. Security servers provide authenticity assertions about clients.
Web service protocols are based on XML messaging. The SOAP protocol allows clients to execute methods on remote servers. This applies to the client/server application, the registry interface (UDDI) and the security server interface (SAML).
Before the web service standards were available, the client/server interfaces were developed on an ad-hoc basis. The use of XML and SOAP provides reusable libraries of code for building and parsing messages. The provision of UDDI servers encourages the reuse of application interfaces, allowing for the development of application standards and reducing the amount of client software that needs to be developed.
References
- E. Cerami (2002). Web Services Essentials. O’Reilly.
- www.xmethods.net
- www-3.ibm.com/services/uddi
- uddi.microsoft.com
- www.capescience.com
- www.soapclient.com