Chapter 2 Literature Review
2.1 Web service
The major differences between traditional Web applications and Web services is that the former are designed to be read and used by human and the latter are designed to increase the interoperability among machines by providing a machine-processable format which can help Web services to be searched and utilized autonomously. A W3C definition for Web services is: “A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-relatedstandards.” [20]
In other words, Web services are self-contained, self-describing and modular applications which can be published, located, and invoked across the web [22]. At the initial stage, Web service is just a concept, but with the efforts contributed by the worldwide researchers and developers, many standards [1],[5],[6],[10],[13],[14],[15] have been proposed to support the implementation of Web services. Up to now, Web services are treated as the basic components of the Service Oriented Architecture (SOA) shown in Figure 2-1.
Figure 2-1 Service Oriented Architecture [23]
Three different roles are identified within a SOA which are Service Broker, Service Provider and Service Requestor. A Service Provider is the one who actually builds Web services and provides services for Service Requestors to consume. The Service Provider can choose either actively or passively to advertise its Web services with detail descriptions on the Web. A Service Requestor is the service consumer which seeks the Web services it needs.
A Service Broker acts as the mediator for Web services. It provides Service Providers the ability to advertise their services in a registry and provides Service Requestors a channel to find the suitable Web services. A Service Broker helps Service Providers and Service Requestors find each other, but it is not necessarily for the broker to deal with the subsequent contracts and executions.
There are several technologies that contribute to the realization of a SOA such as:
Universal Description, Discovery and Integration (UDDI) [5]: Web Services Description Language (WSDL) [6]: Simple Object Access Protocol (SOAP) [10]: and, Web Ontology Language for Services (OWL-S or formerly DAML-S) [15]. The detail of these technologies will be explained in the following sections.
2.1.1 Universal Description, Discovery and Integration (UDDI)
Web services can be registered (advertised) and queried (searched) by using Universal Description, Discovery and Integration (UDDI) [5]. It is provided by the OASIS Standard and consists of an XML schema for defining its data structures and APIs. Microsoft and IBM made considerable efforts to develop the UDDI specifications to support more complicated business logic and to promote UDDI as a public standard [23].
Table 2-1 Four core data structures in UDDI Registry [5],[23]
Categories Type Description
White pages businessEntity
Containing descriptive information about a business or organization such as the name, address, telephone number, and other contact information of a given business.
Yellow pages businessService
Describing a service belong to a businessEntity. Representing a logical service and containing descriptive information in business terms such as the names and categories of the services.
bindingTemplate
Providing technical information necessary to invoke a Web service, typically given in the form of a URL and information about method names, argument types, and so on.
Green pages
tModel
Service Specification Detail: This is metadata about the various specifications implemented by a given Web service.
Human and programs can discover how to interact with Web services they do not know much about.
UDDI acts as a directory service. A Service Provider implements its Web services and registers them along with their detail descriptions at an UDDI server. When a Service Requestor seeks for a service from UDDI, the UDDI server looks up the database for the suitable services by searching the detail descriptions from a list of the registered services.
Once a matched service is found, UDDI returns the identified service and its related information to the Service Requestor. These descriptions are classified into four core data types which are shown in Table 2-1.
One businessEntity (business company) could have many businessServices. Besides, one businessService contains a list of binding Templates that in turn contain a tModel. The bindingTemplate and the tModel represent the technical information about how to access and exploit Web services. As mentioned above UDDI acts as a directory service, Service Requestors use SOAP (detail at 2.1.3) as the communication protocol to negotiate with a UDDI server to obtain the WSDL (detail at 2.1.2) information of any suitable Web services.
Figure 2-2 shows the necessary detailed descriptions when a Service Provider advertises its services in a UDDI registry server.
Figure 2-2 The UDDI registry information model [24]
2.1.2 Simple Object Access Protocol (SOAP)
Simple Object Access Protocol (SOAP) [10] is a text-based (specifically XML-based) communication protocol which can be conveyed by other underlying transmission protocols such as HTTP, SMTP, FTP or any other proprietary messaging protocol. SOAP messages
increase the interoperability of different executable components of Web services when these components are distributed in the heterogeneous environment.
In other words, SOAP is a tool used to exchange data. SOAP uses XML documents to package and exchange messages among diverse counterparts. A SOAP message is composed of four major elements which are briefly in Table 2-2.
Table 2-2 SOAP elements [10][26]
Element Descriptions
<Envolope>
The root element of a SOAP message. Specify the encodingStyle and namespace xmlns:soap=
http://www.w3.org/2001/12/soap-envelope
<Header> The application specific information (like authentication, paymentand etc…)
<Body> Actual SOAP message (transmitted data)
<Fault> Fault handling information and rules when a identified error occurs
Figure 2-3 and Figure 2-4 are two simple examples to illustrate how SOAP messages are used to carry data. The former one shows that a name-value pair for a parameter is Item-Apples which is a query request to a Web service and the response name-value pair is price-1.90 that indicates that the price for item Apples is 1.90.
<?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:Body>
<m:GetPrice xmlns:m="http://www.w3schools.com/prices">
<m:Item>Apples</m:Item>
</m:GetPrice>
</soap:Body>
</soap:Envelope>
Figure 2-3 An example for SOAP message to request an inquiry [26]
SOAP was created by Microsoft for the data exchange in Microsoft .Net framework and SOAP 1.1 was proposed to W3C in May 2000 [26] which means that SOAP is widely accepted by the community. The architecture proposed by this dissertation is also powered by SOAP due to its convenient referencing capabilities. In addition to the SOAP specification, some Web service APIs are also available for building Web services [21].
<?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:Body>
<m:GetPriceResponse xmlns:m="http://www.w3schools.com/prices">
<m:Price>1.90</m:Price>
</m:GetPriceResponse>
</soap:Body>
</soap:Envelope>
Figure 2-4 An example for SOAP message to response an inquiry [26]
2.1.3 Web Services Description Language (WSDL)
Web Services Description Language (WSDL) [6] provides a machine-processable interface through which components that contribute to a composite Web service can be executed automatically. WSDL is also based on XML technology (an XML document) and is used to define how to describe the details of a Web service, such as the location of the service and the operations (methods) the service exposes. Those messages themselves are described abstractly and then bound to a concrete network protocol and message format [20].
WSDL service definitions provide documentation for distributed systems and are used as recipes for automating operation invocation [22]. WSDL allows descriptions of Web services and their messages to be represented explicitly in a way that facilitates their communication no matter what message formats or network protocols used. WSDL is now used in conjunction with SOAP 1.1, HTTP GET/POST, and MIME [6].
The major elements with in a WSDL document are shown in Table 2-3. The element
<portType> is the most important WSDL element. It describes a Web service and its operation (like subroutine or function) which can be invoked and the messages involved.
The element <message> defines the name and type for a specific parameter. The <binding>
element defines the message format and protocol details for each <portType>.
Table 2-3 The basic WSDL document structure [25]
Element Descriptions
<portType> The operations performed by the Web service
<message> The messages used by the Web service
<types> The data types used by the Web service
<binding> The communication protocols used by the Web service
<definition>
<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>
<binding type="glossaryTerms" name="b1">
<soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
<operation>
<soap:operation soapAction="http://example.com/getTerm"/>
<input>
<soap:body use="literal"/>
</input>
<output>
<soap:body use="literal"/>
</output>
</operation>
</binding>
</definitions>
Figure 2-5 An example for WSDL document [25]
Figure 2-5 is a simple WSDL document. In this example, the Web service is glossaryTerms and it has only one operation (function) called getTerm which involved one input parameter getTermRequest and one output parameter getTermResponse. The
<binding> element shows that this Web service can use SOAP as communication protocol.
The messages are conveyed by HTTP and the operation (function) is located at the following URL: http://example.com/getTerm .
With the detailed abstract information provided by WSDL documents, one Web service can be invoked by the other programs (Web services, agents or applications) regardless of the environment in which the calling party exists.