Table of Contents
Abstract
The purpose of the World Wide Web resources stored in server agents. repositories is to offer information services to communities. In order for a community to offer information services, the interaction between server agents and user agents must be programmed. Such interaction involves the reference of resources via URIs and the reference of any program with a URI in order to process the information contained in the set of accessed resources. The access of a referenced resource via URIs is known as dereferencing a URI. Dereferencing a URI involves the interaction of a set of standard network specifications and World Wide Web specifications. The scenario presented in Chapter 3 section 3.1.3 represents an example of dereferencing a URI. Chapter 3 also explains the main constructs implemented in the World Wide Web technology to reference resources using URIs., to access World Wide Web information services, URIs are the main explicit interaction mechanism utilized by users. As a result, the World Wide Web technology designers faced the necessity of implementing a set of specifications that describe, identify, and define World Wide Web information services. This set is known as Web Services specifications.
A web service is a programmed interaction of exchange messages between server agents and user agents. The community that programs a server agent in order to offer services to users is known as a Provider Entity and users that use a user agent to consume the services offered by a provider entity are known as a Requester Entity. When a provider entity offers to requester entities an explicit programmed interaction definition of resources, a web service is considered explicit. Therefore, requester entities have the necessary interface parameters to program an agent to use the services offered by provider entities.
Figure 4.1 represents the design space tree of Web services. Such design space tree is composed of the following design aspects: message, resource, service, and policy. The interaction between provider entities and requester entities is based on the exchange of messages. Therefore, the role of the message design aspect is to define the structure of a message and on the other hand, the purpose of the resource design aspect is to reference resources with URIs. As a result, requester entities are able to locate and identify the services offered by provider entities[25] . Once messages are defined and identified, the service design aspect defines the way messages are exchanged between provider entities and requester entities and the role of the policy design aspect is to define the behavior of provider entities and requester entities applying policies to the service, message, and resource components.
The message design aspect defines the structure of messages. The structure of a message involves the representation format of the information contained in the message. In order to comply with interoperability, evolution, and decentralization design principles, the World Wide Web technology designers created the Simple Object Access Protocol specifications (SOAP). SOAP is a XML application language used to define the structure of messages. Due to the fact, that SOAP is an XML application language, SOAP provides the necessary mechanisms to communicate between applications running on different platforms (Unix, Linux, MS Windows, etc.)[26] . The general structure of an XML SOAP message is the following:
-----------------------------Section 1------------------------------------------ <?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"> ----------------------------------Section 2------------------------------------------ <soap:Header> ... </soap:Header> ----------------------------------End Section 2-------------------------------------- ----------------------------------Section 3------------------------------------------ <soap:Body> ... <soap:Fault> ... </soap:Fault> </soap:Body> ----------------------------------End Section 3------------------------------------- </soap:Envelope> ----------------------------------End Section 1-------------------------------------
The first section of the document defines the XML version number and the require Envelope XML element which is used by the XML processor to identify the XML document as a SOAP message.
The second section defines and optional Header element whose purpose is to define application specific information. The namespace "http://www.w3.org/2001/12/soap-envelope" defines the following set of attributes that can be implemented in the section header of a SOAP message: actor, mustUnderstand, and encodingStyle. The actor attribute is used to define the route of a SOAP message. This is due to the fact that a SOAP message may pass through from a requester entity to a provider entity by passing different providers entities. The mustUnderstand attribute is used to indicate whether a header entry is mandatory or optional. If it is mandatory .1. the provider entity in order to process the SOAP message must understand the content of the header element that contains the attribute mustUnderstand. Finally, the attribute encodingStyle is used to define encoding rules that can be implemented in any XML SOAP element.
The third section defines the payload of the message. Such payload is represented by the Body and Fault elements. The Body element contains the payload of the message which represents the reason of the message including any remote procedure call. All the error messages caused by an unexpected behavior during the exchange of messages between provider entities and requester entities are defined by the Fault element.
Once an XML SOAP message has been created, user agents can use any transport protocol to send the SOAP message to the server agent (e.g., Hypertext Transfer Protocol HTTP). The following example represents an XML SOAP message sent to the following server agent: http://api.google.com/search/beta2.
POST /search/beta2 HTTP/1.1 Content-Type: text/xml User-Agent: XML Spy SOAPAction: "urn:GoogleSearchAction" Host: api.google.com Content-Length: 564 Connection: Keep-Alive Cache-Control: no-cache <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Body> <m:doGetCachedPage xmlns:m="urn:GoogleSearch"> <key xsi:type="xsd:string">tYuM1RtQFHL++kQmdKgANoPGl2nXmlwW</key> <url xsi:type="xsd:string">www.newdevices.com</url> </m:doGetCachedPage> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
Such message is used by requester entities to consume the service "Cache Requests" offered by the provider entity Google. The Web service is identified and located by the following URL: "http://api.google.com/search/beta2". The functionality of the service is to submit a URL as an input parameter of the function doGetCachedPage and receive as output parameter the Web resource referenced by the submitted URL. The payload is composed by two XML elements: key and URL. The key element is a string data type whose value is given by the Provider entity in order to allow requester entities to use the Web service, and the URL part is also a string data type whose value is a URL. The function implemented in the server agent "doGetCachePage" will return the referenced Web resource, if, and only if, Google crawled the Web resource. The encoding type of the output parameter of the function DoGetCachePage is base64 encoded text. As you could see such XML SOAP element does not have any header element and it represents a remote procedure call (RPC). Once the SOAP message was received and processed by the serve agent, the server agent replies back with the following XML SOAP message:
HTTP/1.0 200 OK Content-Type: text/xml; charset=utf-8 Cache-Control: private Date: Tue, 13 Apr 2004 18:55:16 GMT Server: GFE/1.3 X-Cache: MISS from bol.co.tz Connection: close <?xml version='1.0' encoding='UTF-8'?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema"> <SOAP-ENV:Body> <ns1:doGetCachedPageResponse xmlns:ns1="urn:GoogleSearch" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <return xmlns:ns2="http://schemas.xmlsoap.org/soap/encoding/" xsi:type="ns2:base64"> PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9SVNPLTg4NTktMSI+CjxCQVNFIEhSRUY9Imh0 /////...Content removed intentionally too long ;-)...///// </return> </ns1:doGetCachedPageResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
Such SOAP message represents the return value of the function doGetCachePage.
XML SOAP specifications offer to communities the necessary constructs to structure Web services message. Such XML SOAP messages are necessary in order to define in the service design aspect the programmed interaction of exchange of messages between server agents and user agents.
Once messages are defined and identified, the service design aspect is used to define the exchange of messages between provider entities and requester entities. Basically, there are four ways to define the exchange of messages between provider entities and requester entities:
One-way: The provider entity receives a message.
Request-response: The provider entity receives a message and sends back a reply message.
Solicit-response: The provider entity sends a message and receives a reply-back message.
Notification: The provider entity sends a message.
The programmed interaction of exchanged messages between server agents and user agents can be categorized as follows: safe interaction and unsafe interaction. A safe interaction is one that presents three characteristics: 1) requester entities do not incur in any responsibility further than the interaction defined by the information contained in the Web service; 2) the provider entity does not alter the information provided by the requester entity; and 3) such information is not used for other purposes, given to third parties or altered. On the other hand, an unsafe interaction is one where provider entities alter, use or share information taken from requester entities without the explicit permission of the requester entity. Safe interactions are essentials for any Web service so that communities can consume with confidence the information services offered by provider entities[27].
Based on these premises the World Wide Web technology designers created the Web Services Description Language (WSDL) specifications. WSDL will be the main recommendations in the World Wide Web technology to describe and define the programmed interaction definition of resources offered by provider entities. WSDL is an XML application language designed to specify the location of a Web service and describe the programmed interaction of exchanged messages between provider and requester entities. As a result, requester entities have the necessary interface parameters to program an agent in order to consume the services offered by a provider entity. However, the WSDL specification is not yet a W3C standard recommendation, it is in working draft process.[28]
The basic structure of an XML WSDL document is composed by the following array of WSDL components:
<definitions namespaces> <types> Definition of types </types> <message> Definition of message <message> <portType> Definition of portType </portType> <binding> Definition of Binding </binding> <service> Definition of service </service> </definitions>
A WSDL document is just a set of definitions whose XML root element is the element <definitions>. This WSDL component is used to define all the XML namespaces used in the WSDL document.
The XML element <types> is used to define the data type used by the input, output, and fault messages of the Web service.
A Web service can be seen as a process. A process can be defined as a software entity that requires input variables .input message. to generate output variables .Output message.. The XML element <message> is used to define the input, output, and fault messages of a Web service. The information contained in each message can be normalized based on the data type specified in the XML element <types> [29].
The XML element <portType> defines: the operations a Web service can execute and the messages that are involved. Such element can be compared to the function of a process, whose input and output messages have been defined in the XML element .<message>..
The <binding> XML element defines the message format and message transport used by each portType.
The XML element <service> groups a set of related portTypes together and identifies the location of the provider entity with a URL.
Based on these premises let us analyze the following XML WSDL document:
---------------------Section 1 Definition component--------------------------- <wsdl:definitions xmlns:typens="urn:GoogleSearch" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns="http://schemas.xmlsoap.org/wsdl/" targetNamespace="urn:GoogleSearch" name="GoogleSearch"> ---------------------Section 2 Types component--------------------------- <wsdl:types> <xsd:schema/> </wsdl:types> ---------------------End Section 2------------------------------------------ ---------------------Section 3 Message Component--------------------- <message name="doGetCachedPage"> <part name="key" type="xsd:string"/> <part name="url" type="xsd:string"/> </message> <message name="doGetCachedPageResponse"> <part name="return" type="xsd:base64Binary"/> </message> ---------------------End Section 3------------------------------------------ ---------------------Section 4 PortType Component--------------------- <portType name="GoogleSearchPort"> <operation name="doGetCachedPage"> <input message="typens:doGetCachedPage"/> <output message="typens:doGetCachedPageResponse"/> </operation> </portType> ---------------------End Section 4----------------------------------------- ---------------------Section 5 Binding Component---------------------- <binding name="GoogleSearchBinding" type="typens:GoogleSearchPort"> <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="doGetCachedPage"> <soap:operation soapAction="urn:GoogleSearchAction"/> <input> <soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:GoogleSearch"/> </input> <output> <soap:body use="encoded" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:GoogleSearch"/> </output> </operation> </binding> ---------------------End Section 5----------------------------------------- ---------------------Section 6 Service Component---------------------- <service name="GoogleSearchService"> <port name="GoogleSearchPort" binding="typens:GoogleSearchBinding"> <soap:address location="http://api.google.com/search/beta2"/> </port> </service> ---------------------End Section 6----------------------------------------- </wsdl:definitions> ---------------------End Section 1-----------------------------------------
Such XML WSDL document describes and identifies the service "Cache Requests" offered by the provider entity Google whose Web service is identified and located by the following URL: "http://api.google.com/search/beta2". The functionality of the service was explained in the previous section. Hence, the first section of the XML WSDL document defines the root element of the XML document "<definitions>". In this element is where all the necessary xml namespaces are defined. In the second section no data type elements are defined.
The third section contains the input message and the expected output message of the Web service. The element <portType> defined in the fourth section identifies a port named GoogleSearchPort that includes the definition of an operation "doGetCachedPage" which is actually the name of the Web service. Such operation includes the name of the messages defined in the third section. As you can see, the exchange of messages between the provider and requester entities for this Web service is Request and Response.
The fifth section defines the message format and message transport. The message format for this Web service is the XML SOAP document explained already. The message transport for this Web services is the Hypertext Transfer Protocol. The sixth section identifies the location and Web service of the provider entity with the following URL "http://api.google.com/search/beta2" and groups the related portTypes name and bindings of the Web service.
If the presented WSDL document is processed by a user agent that supports the WSDL and SOAP specifications it will generate the same XML SOAP input and output messages explained previously.
Web services specifications provides to users the necessary parameter interface in order to access the application logic of the provider entities. Web site. Web services can be viewed as a new programming model where enterprises are using it in order to exchange, process, and share information based on World Wide Web technology recommendations.
[25] The resource design aspect has been explained in chapter 3.
[26] SOAP is not the only option to define the structure of a message. There are other choices like HTTP Get, HTTP Post, XML-RPC. However, SOAP is the main specification in the World Wide Web technology to define the structure of a message.
[27] It is important to mention that in this chapter we will discuss only the interaction bases between provider entities and requester entities, and we will not discuss other requirements to satisfy safe interactions such as network and computer security, and transaction accountability.