M a s t e r ' s T h e s i s The Web Services Framework: A Survey - - PDF document

Technische Universität Wien

M a s t e r ' s T h e s i s The Web Services Framework: A Survey of WSDL, SOAP and UDDI

carried out at the Information Systems Institute Distributed Systems Group Vienna University of Technology under the guidance of Ao.Univ.Prof. Dr. Harald Gall and Univ.Ass. Dr. Schahram Dustdar by Günter Orth Neubaugasse 48-50/17 A-1070 Wien Vienna, 21. May 2002 ______________________________ Günter Orth

• 1. Introduction and Motivation

Page 1

• 1. INTRODUCTION AND MOTIVATION

1.1. Introduction

Previous attempts in distributed computing (such as CORBA, COM+ / DCOM, or Java RMI) have yielded systems of tightly coupled monolithic components [Iwsat00]. Some of the problems resulting from these approaches and application architectures are as follows:

• They are highly complex and require a huge infrastructure investment [Hess01].
• They are not designed to pass information through firewalls.
• The software infrastructure provided by a certain vendor is widely limited to a specific
• platform. For example, in a distributed COM+ / DCOM application, all participating

nodes would have to run on the Microsoft Windows platform. Moreover, interoperation between single components often requires that they are of the same vendor. For example, in the case of CORBA, every node in the application environment would need to run the same ORB product, or there would be at least interoperability limitations for nodes with different products and any vendor specific

• ptimizations would be lost in this situation. [Gis01]
• They depend on a closely administered environment. Performing a successful call from
• utside of this environment is quite impossible or at least improbable.
• They use complex and proprietary communication protocols, each with specific message

formats and data representation the developers have to deal with (e.g. CORBA's IIOP).

• They require too much agreement and shared context among business systems from

different organizations to be reliable for open business-to-business (B2B) communication.

• A cross-platform application-to-application (A2A) integration is time consuming and

expensive [Ches01] or even impossible. Looking for an alternative approach capable of avoiding these shortcomings, the concepts of the Web can be regarded. It is based on a set of simple, open standards. Communication between the participants uses HTTP, an inexpensive and easy-to-use network transport protocol [Ches01] which is available on almost every system platform. Additionally, many firewalls today are configured to allow HTTP traffic [Sho01]. The transmitted information is represented in HTML, which is also widely accepted on the Web [Pred01]. All that leads the Web to be an open system, across enterprise and platform boundaries. And that is exactly what would be desirable also for distributed computing in general. However, the WWW is currently mainly designed for human-readable interfaces, the semantic interpretation of the content is left to human users [Pred01]. It is primarily suited for human access [Max02], not for A2A interoperation. The Web Services concept aims to adopt the principles of the WWW for its vision of seamless A2A integration, regardless of differences in programming languages and platforms, featuring the same level of openness between loosely coupled systems. The key for the broad acceptance of the WWW is that it is based on open standards. Consequently, Web Services are also founded on the basis of such standards. On the one hand, they use well-established standards already known from the WWW, for example in the way that HTTP is intended to be the most favourite transport protocol for Web Services communication. On the other hand, new standards are defined under supervision of independent and accepted authorities, such as the World Wide Web Consortium (W3C). These new emerging standards will be examined later in this work. XML is one of the most

• 1. Introduction and Motivation

Page 2 important fundamental technologies for Web Services and the basis for rising other standards. XML is simple to use, offers a flexible easy-to-extend data format, and is supported on almost every computing platform [Gis01]. Using XML as its foundation makes the Web Services concept robust and independent from platforms, vendors, applications, and programming languages ([Ches01] and [Sho01]). Despite these promising characteristics, the Web Services concept is not designed to replace current approaches for distributed computing. It is rather designated to link existing systems and to enable a higher level of integration and interoperability.

1.2. Problem Definition

Web Services are essentially based upon three major technologies and standards [Roy01]:

• The "Web Services Description Language" (WSDL) which is used to describe the

interfaces of a service.

• The "Simple Object Access Protocol" (SOAP) that provides the means for communication

between Web Services and Client Applications.

• "Universal Description, Discovery and Integration" (UDDI) that is used to register and

publish Web Services and their characteristics so that they can be found from potential clients. The focus of this master's thesis is to provide a description of these core Web Services technologies, and show how they work together to meet the expectations of this new emerging concept in distributed computing. For that purpose, this thesis is limited to a technical perspective of the Web Services concept. The new strategic opportunities related to this concept from a business view (e.g. in e-business) are beyond the scope of this work.

• 1. Introduction and Motivation

Page 3

1.3. A guided tour on Web Services

As an introduction to the area of Web Services, this section provides a sample scenario for that new approach in distributed computing. For that purpose, a documented application case

• f a travel service is demonstrated, taken from [Curb02].

1.3.1. The Web Services Framework

The Web Services approach is emerging to provide a systematic and extensible framework for application-to-application (A2A) interaction, built on top of existing Web protocols and based

• n open XML standards.

For our travel service example, consider that someone intends to purchase a vacation package using an online travel agent. To locate the best prices on airline tickets, hotels, and rental cars, the travel agency will have to poll multiple companies, each of which likely uses different, incompatible applications for pricing and reservations. Web Services aim to simplify this process by defining a standardized mechanism to describe, locate, and communicate with

• nline applications. Essentially, each application becomes an accessible Web Service

component that is described using open standards. The Web Services framework is divided into three areas – communication protocol, service description, and service discovery – and specifications are being developed for each:

• the "Simple Object Access Protocol" (SOAP), which enables communication among Web

Services;

• the "Web Services Description Language" (WSDL), which provides a formal, computer-

readable description of Web Services; and

• "Universal Description, Discovery and Integration" (UDDI), which is a registry of Web

Services descriptions.

1.3.2. Communication: SOAP

Given the Web's distributed and heterogeneous nature, communication mechanisms must be platform-independent, international, and as lightweight as possible. XML is now firmly established as the language for information and data encoding for platform independence and

• internationalization. Building a communication protocol using XML is thus a natural answer

for Web Services. SOAP is an XML-based protocol for messaging and remote procedure calls (RPCs). Rather than define a new transport protocol, SOAP works on existing transports, such as HTTP, or SMTP. At its core, a SOAP message has a very simple structure: an XML element (the <Envelope>) with two child elements, one of which contains the optional <Header> and the other the <Body>. The <Header> contents and the <Body> elements are themselves arbitrary XML.

1.3.2.1. SOAP Messaging

At the basic functionality, SOAP can be used as a simple messaging protocol. Throughout this section, the Web Services specifications are illustrated using a simple example drawn again from the travel services industry. An example traveller is scheduled for a flight and wants to check in electronically. We will assume that he knows of a Web Service with an electronic CheckIn method and that he knows the format for encoding the eTicket. Given this, he could simply create and send a SOAP message to that service for processing.

• 1. Introduction and Motivation

Page 4 Listing 1-1 shows such a SOAP message, carried by HTTP. The HTTP headers are above the SOAP <Envelope> element. The POST header shows that the message uses HTTP POST, which browsers also use to submit forms. The Content-Type header declares text/xml as the type of the message. If there were a response, the HTTP response would be of the same content-type, and could contain a SOAP message with the response data. The SOAPAction header indicates the message's intended purpose.

Listing 1-1: Sample SOAP Message

Note that the message in Listing 1-1 has no SOAP <Header> element. The <Body> simply contains an XML representation of an e-ticket with the person's name and flight details. Any realistic business-to-business (B2B) scenario would possibly have some <Header> entries indicating further information.

1.3.2.2. SOAP Remote Procedure Calls

To use SOAP for RPCs, an RPC protocol must be defined. This includes:

• how typed values can be transported back and forth between the SOAP representation

(XML) and the application's representation (such as a Java class for a ticket), and

• where the various RPC parts are carried (object identity, operation name, and parameters).

The XML Schema specification [XSD] provides a standard language for defining the document structure and the XML structures' data types. That is, given a primitive type like integer or a complex type, such as a record with two fields (for example an integer and a string), XML Schema offers a standard way to write the type in XML. To enable transmission

• f the typed values, SOAP assumes a type system based on the one in XML Schema and

defines its canonical encoding in XML. Using this encoding style, an XML encoding for any type of structured data can be produced. RPC arguments and responses are also represented using this encoding.

POST /travelservice HTTP/1.0 Host: xxx.xxx.xxx.xxx Content-Type: text/xml; charset=utf-8 Content-Length: n SOAPAction: "urn:travelservice-checkin" <?xml version='1.0' encoding='UTF-8'?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <et:eTicket xmlns:et="http://www.acme-travel.com/eticket/schema"> <et:passengerName first="Joe" last="Smith"/> <et:flightInfo airlineName="AA" flightNumber="1111" departureDate="2002-01-01" departureTime="1905"/> </et:eTicket> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

• 1. Introduction and Motivation

Page 5 Now, let's consider our sample traveller wants to know whether his flight has been delayed. He knows that the Web Service has a function GetFlightInfo which takes two arguments – a string containing the airline name and an integer with the flight number – and returns a structured value (a record) with two fields – the gate number and flight status. In this case, the traveller can get flight status by sending the service an HTTP POST carrying a SOAP

<Envelope> as shown in Listing 1-2.

Listing 1-2: Sample SOAP RPC Call

In this SOAP <Envelope>, the call to GetFlightInfo is an XML element with attributes that include information about the encoding (note the references to XML Schema). The child elements are the method call's arguments: airlineName and flightNumber. Their types are defined in the type attribute, where "xsd" refers to the XML Schema definitions. When the SOAP implementation receives the message, it converts the XML text for airlineName (UL) and flightNumber (506) into the appropriate string and integer based on the service's

• implementation. It then calls the GetFlightInfo method with those parameters.

Listing 1-3 shows the response to this request. In this case, the response contains a structured value with the subvalues for gate number and flight status. SOAP implementations exist for several programming languages, including Java and C, which automatically generate and process the SOAP messages. Assuming the messages conform to the SOAP specification, they can thus be exchanged by services implemented in different languages.

POST /travelservice HTTP/1.0 Host: xxx.xxx.xxx.xxx Content-Type: text/xml; charset=utf-8 Content-Length: n SOAPAction: "urn:travelservice-flightinfo" <?xml version='1.0' encoding='UTF-8'?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/1999/XMLSchema" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"> <SOAP-ENV:Body> <m:GetFlightInfo xmlns:m="http://www.acme-travel.com/flightinfo"> SOAP-ENV:encodingStyle= "http://schemas.xmlsoap.org/soap/encoding/"> <airlineName xsi:type="xsd:string">UL</airlineName> <flightNumber xsi:type="xsd:int">506</flightNumber> </m:GetFlightInfo> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

• 1. Introduction and Motivation

Page 6

Listing 1-3: Sample SOAP RPC Response

1.3.3. Description: WSDL

For Web Services, SOAP offers basic communication, but it does not inform about what messages must be exchanged to successfully interact with a service. That role is filled by WSDL, an XML format to describe Web Services as collections of communication endpoints that can exchange certain messages. For developers and users, WSDL provides a formalized description of client-service

• interaction. During development, developers use WSDL documents as the input to a proxy

generator tool that produces client code according to the service requirements. For example, travel service users need only obtain the WSDL description of that service, and use it as input to the tooling and runtime infrastructure to exchange correct SOAP message types with the service. This subsection provides examples of WSDL documents that describe our travel Web Service, which can process the two types of interactions from the above SOAP examples. The first interaction, GetFlightInfo, is accessed using the SOAP RPC model; it takes an airline name and a flight number and returns a complex (or structured) type with flight

• information. The second interaction, CheckIn, uses pure SOAP messaging; it expects to

receive an XML representation of an electronic ticket, and returns no information. A complete WSDL service description provides two pieces of information: an application-level service description, or abstract interface, and the specific protocol-dependent details that users must follow to access the service at a specified concrete service endpoint.

HTTP/1.0 200 OK Content-Type: text/xml; charset=utf-8 Content-Length: n <?xml version='1.0' encoding='UTF-8'?> <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/1999/XMLSchema" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"> <SOAP-ENV:Body> <m:GetFlightInfoResponse xmlns:m="http://www.acme-travel.com/flightinfo"> SOAP-ENV:encodingStyle= "http://schemas.xmlsoap.org/soap/encoding/"> <flighInfo> <gate xsi:type="xsd:int">10</gate> <status xsi:type="xsd:string">ON TIME</status> </flightInfo> </m:GetFlightInfoResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

• 1. Introduction and Motivation

Page 7

1.3.3.1. Abstract Description

WSDL defines a service's abstract description in terms of messages exchanged in a service

• interaction. There are three main components of this abstract interface: the vocabulary, the

message, and the interaction. Agreement on a vocabulary is the foundation of any type of

• communication. WSDL uses external type systems to provide data-type definitions for the

information exchange. Although WSDL can support any type system, [XSD] is preferred. For our travel service example, Listing 1-4 shows two data types defined in [XSD] (string and int), and two data types defined in external schema (FlightInfoType and

TicketType). WSDL can import such external definitions using an "import" element

specifying their location.

Listing 1-4: Sample WSDL abstract description

WSDL defines <message> elements as aggregations of parts, each of which is described by [XSD] types, or by elements from a predefined vocabulary. Messages provide an abstract, typed data definition sent to and from the services. The example in Listing 1-4 shows the three messages that might appear during a Web Services interaction. The message GetFlightInfoInput has two parts: airlineName, which is an [XSD] string, and flightNumber, which is an [XSD] integer. The other two messages,

GetFlightInfoOutput and CheckInInput, have only one part each.

The <portType> element and its <operation> subelements combine messages to define

• interactions. Each operation represents a message exchange pattern that the Web Service

supports, giving users access to a certain basic piece of service functionality. An operation is simply a combination of messages labeled as input, output, or fault to indicate what part a particular message plays in the interaction. A <portType> is a collection of operations that are collectively supported by an endpoint. In

• ur example, AirportService_PortType describes two operations: a single request-

response operation GetFlightInfo, which expects the GetFlightInfoInput message as input and returns a GetFlightInfoOutput message as the response; and a one-way

• peration CheckIn, which just takes the CheckInInput message.

<wsdl:message name="GetFlightInfoInput"> <part name="airlineName" type="xsd:string"/> <part name="flightNumber" type="xsd:int"/> </wsdl:message> <wsdl:message name="GetFlightInfoOutput"> <part name="flightInfo" type="flightinfoxsd:FlightInfoType"/> </wsdl:message> <wsdl:message name="CheckInInput"> <part name="eTicket" element="eticketxsd:TicketType"/> </wsdl:message> <wsdl:portType name="AirportService_PortType"> <wsdl:operation name="GetFlightInfo"> <wsdl:input message="tns:GetFlightInfoInput"/> <wsdl:output message="tns:GetFlightInfoOutput"/> </wsdl:operation> <wsdl:operation name="CheckIn"> <wsdl:input message="tns:CheckInInput"/> </wsdl:operation> </wsdl:portType>

• 1. Introduction and Motivation

Page 8

1.3.3.2. Concrete Binding Information

So far, all the elements that we have discussed describe the service's application level

• functionality. To complete the description of a client-service interaction, three more pieces of

information are required:

• what communication protocol to use (such as SOAP over HTTP),
• how to accomplish individual service interactions over this protocol, and
• where to terminate communication (the network address).

WSDL's <binding> element provides the "what" and "how" parts of this information, including the communication protocol and data format specification for a complete

<portType>. The <binding> element tells how a given interaction occurs over the

specified protocol. Listing 1-5 shows a WSDL fragment for the travel example. The binding describes how to use SOAP to access the travelservice Web Service.

Listing 1-5: Sample WSDL concrete binding information <wsdl:binding name="AirportService_SoapBinding" type="tns:AirportService_PortType"> <soap:binding transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="GetFlightInfo"> <soap:operation style="rpc" soapAction="urn:travelservice-flightinfo"/> <wsdl:input> <soap:body encodingStyle= "http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:travelservice-flightinfo" use="encoded"/> </wsdl:input> <wsdl:output> <soap:body encodingStyle= "http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:travelservice-flightinfo" use="encoded"/> </wsdl:output> </wsdl:operation> <wsdl:operation name="CheckIn"> <soap:operation style="document" soapAction="urn:travelservice-checkin"/> <wsdl:input> <soap:body encodingStyle= "http://schemas.xmlsoap.org/soap/encoding/" namespace="urn:travelservice-checkin" use="encoded"/> </wsdl:input> </wsdl:operation> </wsdl:binding> <wsdl:service name="travelservice"> <wsdl:port name="travelservice_Port" binding="tns:AirportService_SoapBinding"> <soap:address location= "http://www.acme-travel.com/travelservice"/> </wsdl:port> </wsdl:service>

• 1. Introduction and Motivation

Page 9 In particular, the WSDL document shows that

• GetFlightInfo will be a SOAP-RPC-style interaction, in which all message eschanges

use standard SOAP encoding, and

• CheckIn is a pure messaging interaction (called "document-oriented" in WSDL terms), in

which the SOAP message's body contains the encoded message with no additional type encodings; that is, it uses [XSD] to literally describe the transmitted XML. All that remains now is to define "where" to access this combination of abstract interface, protocol, and data marshalling details (the "binding"). A WSDL <port> element describes a single endpoint as a combination of a binding and a network address. Consequently, a

<service> element groups a set of related ports.

In our travel service example, a single port (travelservice_Port) describes an endpoint that processes SOAP requests for the travelservice Web Service.

1.3.4. Discovery: UDDI

The UDDI specifications offer users a unified and systematic way to find Service Providers through a centralized registry of services that is roughly equivalent to an automated online "phone directory" of Web Services. On the one hand, there are browser-accessible global UDDI Registries available for "public" access and, on the other hand, individual companies and industry groups are starting to use "private" UDDI Registries to integrate and access to their internal services. UDDI provides two basic specifications that define a Service Registry's structure and

• peration:
• a definition of the information to provide about each service and how to encode it (the

"UDDI Data Structure"); and

• a publish and query API for the registry that describes how this information can be

published and accessed (the "UDDI Programmer's API"). Registry access can be programmatically accomplished using a standard SOAP API for both publishing and querying. This section focuses to the UDDI Data Structure, which provides a good idea of how the registry operates.

1.3.4.1. Organizing Structure

UDDI encodes three types of information about Web Services:

• "white pages" information includes, for example, name and contact details about the

Service Provider's business or company, respectively;

• "yellow pages" information provides a categorization based on business and service types;

and

• "green pages" information includes technical data about the service.

The UDDI Registry is organized around two fundamental entities that describe businesses and the services they provide. The businessEntity element shown in Listing 1-6 provides standard white pages information, including identifiers, contact information, and a simple business description. Each business entity might include one or more businessService elements, shown in Listing 1-7, that represent the services it provides.

• 1. Introduction and Motivation

Page 10

Listing 1-6: Sample UDDI businessEntity structure

Both business and service entities can specify a categoryBag to categorize the business or service (the representation of this categorization information is described later). Each data entity (e.g. businesses or services) is identified by a unique key that might be cross-referenced. These assigned keys are generated when the entity is registered. The keys are guaranteed to be universally unique identifiers (UUIDs). For example, a businessKey attribute uniquely identifies a business entity, and a serviceKey attribute identifies a service. In addition to a human-readable description, name, and categorization, the service entity contains a list of bindingTemplates that encode the technical service-access information. Each binding template represents an access point to the service. The assumption is that the same service can be provided at different endpoints, each of which might have different technical characteristics. Binding templates enable service descriptions using arbitrary external information (i.e. information that is not defined by UDDI itself). The information in a binding template contains its unique key (bindingKey), a cross-reference to the service key, and the endpoint where the Web Service can be accessed.

<businessEntity businessKey= "A687FG00-56NM-EFT1-3456-098765432124"> <name>Acme Travel Incorporated</name> <description xml:lang="en"> Acme is a world wide leader in online travel services </description> <contacts> <contact useType="US general"> <personName>Acme Inc.</personName> <phone>1 800 CALL ACME</phone> <email useType="">acme@acme-travel.com</email> <address> <addressLine>Acme</addressLine> <addressLine>12 Maple Avenue</addressLine> <addressLine>Springfield, CT 06785</addressLine> </address> </contact> </contacts> <businessServices> ... </businessSerivices> <identifierBag> ... </identifierBag> <categoryBag> <keyedReference tModelKey= "UUID:DB77450D-9FA8-45D4-A7BC-04411D14E384" keyName="Electronic check-in" keyValue="84121801"> </categoryBag> </businessEntity>

• 1. Introduction and Motivation

Page 11

Listing 1-7: Sample UDDI businessService structure

1.3.4.2. Technical Descriptions and tModels

A very interesting information covered by a binding template is tModelInstanceDetails, which provides the service's technical description. It contains a list of references to the technical specifications with which the service complies. The Service Provider first registers the required technical specification in the UDDI Registry, which assigns a corresponding unique identifier key (tModelKey). UDDI represents each registered technical specification using the tModel information entity. Service endpoints that support the specification can then simply add the corresponding reference to their tModelInstanceDetails list. As an example, the UDDI registration of a WSDL document as a tModel will now be

• examined. Assuming that the travel industry has defined the standard WSDL interfaces and

bindings for electronic check-in and retrieval of flight information, a tModel as shown in Listing 1-8 is created first to represent these WSDL definitions. Service endpoints that implement those interfaces can then include the corresponding tModel in their

tModelInstanceDetails list.

The idea behind the tModel mechansim is simple and powerful: To adequately describe a service, we often have to reference information whose type or format cannot (or should not) be anticipated. Replacing the information itself with a unique key provides a reference to arbitrary information types.

<businessService serviceKey= "894B5100-3AAF-11D5-80DC-002035229C64" businessKey= "A687FG00-56NM-EFT1-3456-098765432124"> <name>ElectronicTravelService</name> <description xml:lang="en">Electronic Travel Service</description> <bindingTemplates> <bindingTemplate bindingKey= "6D665B10-3AAF-115D-80DC-002035229C64" serviceKey= "894B5100-3AAF-11D5-80DC-002035229C64"> <description> SOAP-based e-checkin and flight info </description> <accessPoint URLType="http"> http://www.acme-travel.com/travelservice </accessPoint> <tModelInstanceDetails> <tModelInstanceInfo tModelKey= "D2033110-3BGF-1KJH-234C-09873909802"> ... </tModelInstanceDetails> </bindingTemplate> </bindingTemplates> <categoryBag> ... </categoryBag> </businessService>

• 1. Introduction and Motivation

Page 12

Listing 1-8: Sample UDDI tModel structure

1.3.4.3. Categorization

Effectively locating particular types of businesses and services depends on the ability to qualify the UDDI Registry's business and service entries according to a categorization scheme

• r taxonomy. In fact, in any realistic situation, we typically need multiple information bits,

such as geographical location or type of industry or product, to characterize the services we are seeking. To identify taxonomy systems, each classification system itself is registered as a tModel in the UDDI Registry. Taxonomy information is then encoded in name-value pairs, qualified by a tModel key reference that identifies which taxonomy each pair belongs to. Using categorization, queries to the UDDI Registry can be performed to locate very specific types of services. In our example case, we might search for travel services that provide electronic checkin and operate in our metropolitan area. Once we find the service in UDDI, we can retrieve the WSDL description it complies with to learn how to interact with it using SOAP messaging and SOAP RPC calls.

<tModel tModelKey="D2033110-3BGF-1KJH-234C-09873909802"> <name>http://www.travel.org/e-checkin-interface</name> <description xml:lang="en"> Standard service interface definition for travel services </description> <overviewDoc> <description xml:lang="en"> WSDL Service Interface Document </description> <overviewURL> http://www.travel.org/services/e-checkin.wsdl </overviewURL> </overviewDoc> <identifierBag> ... </identifierBag> <categoryBag> ... </categoryBag> </tModel>

• 1. Introduction and Motivation

Page 13

1.4. Organization of this work

This master's thesis is organized as follows: Chapter 2 provides a definition of Web Services and introduces the Web Services Model. Chapter 3 discusses the development of Web Services both from the view of the "Service Provider" and the "Service Requestor". Chapter 4 describes the two base technologies that make the Web Services concept possible: the "Web Service Description Language" (WSDL) and the "Simple Object Access Protocol" (SOAP). Chapter 5 introduces "Universal Description, Discovery and Integration" (UDDI) as standardized service registry for publishing Web Services. Chapter 6 provides a case study that illustrates all tasks concerned with Web Services: development, description, deployment, publication, discovery, and invocation from a client application. Chapter 7 presents an evaluation of the Web Services concept and its related technologies. Chapter 8 gives an estimation about the importance of Web Services today and in future, and a presumption about the further evolution of this concept. The Appendix provides an overview description of a Web Services development tools that was used to support certain tasks from the case study shown in Chapter 6.

• 2. Web Services Characterization

Page 14

• 2. WEB SERVICES CHARACTERIZATION

2.1. Definition and Overview

Web Services are collections of operations covered in modular, self-contained applications that are, through standardized XML messaging, accessible over a network, generally the Internet, based on its standard transport protocols [Sne01], [Kreg01], [Iwsat00]. In [Kreg01], Web Services are defined only as interfaces for these applications and these services, respectively. [Sne01], [SneIWDT23], [Iwsat00] and many other publications and articles designate the applications themselves as the Web Services. The explanations in this thesis favour the interpretation of Web Services as the applications accessible over a network. Nevertheless, the different interpretations should be considered when reading this document. The activities performed in the scope of Web Services can be summarized as follows (see [Sne01], [SneIWDT23]): Web Services can be (or have to be):

• Developed according to their planned functionality.
• Described in the so-called service description, a standard and formal XML notation (Web

Service Description Language, WSDL). It covers all details necessary to interact with the service, including message formats that detail the operations, transport protocols and location.

• Published by registering their descriptions in a – for the potential users – well-known
• registry. The currently propagated and widely supported declaration for a standardized

service registry is UDDI (Universal Description Discovery and Integration). Therefore, this work focuses on UDDI in all publishing concerns.

• Found by sending queries to that registry and receiving the details of the service that fit

the parameters of the query.

• Bound to the endpoint that provides the Web Service by using the information contained

in the service description.

• Invoked over a network by using the information contained in the binding details of the

service description. The invocation of the services occurs over a standard network transport protocol. Therefore, the XML based Simple Object Access Protocol (SOAP) was established from leading IT companies.

• Composed with other services into new services and applications.

2.2. The Web Services Model

The Web Services architecture covers three elements: roles, operations and artefacts [Kreg01]. Figure 2-1 illustrates these elements [SneIWDT23]. The architecture is based upon the interaction of three roles: Service Provider, Service Registry and Service Requestor. The interactions involve the Publish, Find and Bind

• perations. Together, these roles and operations act upon the Web Services artefacts: the Web

Service software module, its description (also including a description of the Service Provider) and the Client Application.

• 2. Web Services Characterization

Page 15

Figure 2-1: Web Service roles, operations and artefacts

2.2.1. Roles in the Web Services Model

The actors in the Web Services model are as follows. Their roles can be described from a business view, or from an architectural perspective:

• Service Provider:

° From a business perspective, this is the owner of the service. ° From an architectural perspective, this is the platform that provides access to the service.

• Service Requestor:

° From a business perspective, this is the business that requires certain functions that are covered by the corresponding service. ° From an architectural perspective, this is the client application that is looking for and then invoking the service.

• Service Registry:

° From a business perspective, this is the owner of a registry service. ° From an architectural perspective, this is a platform that provides access to registered service information. The Service Registry is a searchable repository of service descriptions. Service Providers can publish their service descriptions, including a description of the provider's business. Service Requestors can find services and obtain binding information (from the service descriptions). This information is used during development for static binding or during execution for dynamic binding. Dynamically bound Service Requestors access the Service Registry on every execution. For statically bound Service Requestors, access to the Service Registry is performed only one time to get the information. On static binding, the role of the Service Registry is even optional – the Service Requestor could obtain the service description directly from the Service Provider or from other sources besides a Service Registry (e.g. WWW site or FTP site).

Bind Find Publish Service Registry Service Requestor Service Provider Provider Description Service Description Service Description Service Client Application

• 2. Web Services Characterization

Page 16

2.2.2. Operations in the Web Services Model

The Web Services model comprises the following operations:

• Publish: To make it possible for a Service Requestor to find a Web Service and access it,

the Service Provider has to publish it to a Service Registry.

• Find: In the find operation, the Service Requestor retrieves a service description by

inquiring the Service Registry. The find operation can occur in two different lifecycle phases for the Service Requestor: at design time to retrieve the service interface description for the client application development (static binding), or at runtime to get the service's binding and location description for invocation (dynamic binding).

• Bind: In the bind operation, the Service Requestor invokes the service at runtime using

the binding details in the service description to locate, contact and invoke the service.

2.2.3. Artefacts of a Web Service

The artefacts in the Web Services model are the objects that are produced and dealt with in the context of Web Services. These are as follows:

• Service: This is the implementation of a software module deployed on a network-

accessible platform provided by the Service Provider to be invoked by a Service Requestor.

• Service Description: The service description contains the details of the interface and

implementation of the service. The service interface description comprises information about the operations provided by a service, as well as their parameters. It can be compared with the signature of a method. Additionally, the protocol used for communication with the Web Service is described. The service implementation description contains information about the location where the service is exposed, i.e. the network address of the endpoint providing the service. The complete service description is published to a Service Registry by the Service Provider to make the service accessible to Service Requestors. It includes the service's data types, operations, binding information and network location, as provided by the service interface and implementation descriptions. It could also include information about the Service Provider, service and provider categorization and other metadata to facilitate discovery and utilization by the Service Requestor.

• Client Application: This is the application implemented by the Service Requestor that

uses the functionality of the Web Service and invokes it at runtime.

• 3. Web Services Development

Page 17

• 3. WEB SERVICES DEVELOPMENT

3.1. Web Services Development Lifecycle

As described in Section "2.2. The Web Services Model", there are three component roles within Web Services: Service Registry, Service Provider and Service Requestor. This section describes the phases of the development lifecycle which each of these roles has to follow – certainly according to its specific requirements. The development lifecycle encompasses the following phases: build, deploy, run and manage (see [Brit01] and [Kreg01]).

• Build

The build phase includes development and testing of the Web Service implementation and the definition of the service description. The Web Services implementations can be provided by creating new Web Services, transforming existing applications into Web Services and composing new Web Services from other Web Services and applications.

• Deploy

The deploy phase includes the publication of the service description into a Service Registry, deployment and provision of the executables for the service into the execution environment and the integration with the back-end systems involved with the service functionality.

• Run

During the run lifecycle phase, the Web Service is fully available for invocation. At this point, it is fully deployed, operational and network-accessible at the Service Provider. The Service Requestor can now find the service description and invoke all defined operations

• f the Web Service.
• Manage

The manage phase covers permanent management and administration of the Web Service

• application. Security, availability, performance, quality of service, and so on, all has to be

addressed. In the scope of Web Services, this phase does not differ from the usual management and maintenance for other applications, and there is nothing in this phase that is specific for Web Services. Therefore, this phase is not covered in more detail within this thesis.

3.2. The Development Process

This section describes the development process related with the lifecycle phases mentioned in Section "3.1. Web Services Development Lifecycle" for the Web Service component roles Service Registry, Service Provider and Service Requestor [Brit01].

3.2.1. The Service Registry side

The Service Registry provides a role in the Web Services development, but it is only a passive

• participant. For this reason, there is no particular information about the development lifecycle

for the Service Registry and this subject is not described in this work. It is assumed that the registry has been built and deployed before Service Provider and Service Provider can use it.

• 3. Web Services Development

Page 18 However, Chapter "5. Universal Description, Discovery and Integration (UDDI)" provides detailed information about the concepts of UDDI registries.

3.2.2. The Service Provider side

There are four basic methods for a Service Provider to develop a Web Service [Brit01]. Which method to use depends on whether an application/service or service interface that will become a Web Service already exists. Table 3-1 provides an overview of these development methods. New Service Interface Existing Service Interface New Web Service Green-field Top-down Existing Application/Service Bottom-up Meet-in-the-middle

Table 3-1: Service Provider methods for Web Service development

The scenarios for the use of the mentioned methods and the related development processes are described in the following subsections (based upon [Sne01], [Brit01]). Some tasks within the processes repeat or are very similar between the different methods and scenarios. So the tasks that are repeated are described in detail only when they are listed for the first time.

3.2.2.1. The "Green-field" scenario

In this scenario, the developers start with a completely new

• implementation. A new Web Service with its functionality and

a new interface for that service has to be created. The sequence of the development work is as follows (Figure 3-1):

• Creation of the functionality for the service, e.g. in the

form of a Java class.

• Creation/generation of the Web Service Interface

Description (WSDL documents) that describes how the functionality is to be exposed as a Web Service and how to call the service.

• The functionality and the interface description are now

combined into the Service Deployment.

• Creation of the Web Service Implementation Description

(WSDL document) that contains the information about the service deployment, i.e. the network location where the service is deployed.

• Finally, the Web Service can be published within a

Service Registry (UDDI).

Figure 3-1: Web Services Development in the "Green-field" scenario

New Service (e.g. Java Class) New Web Service Interface (WSDL description) New Service Deployment Publish Service (UDDI) New Web Service Implementation Description (WSDL)

• 3. Web Services Development

Page 19 The build, deploy and run phases of the development lifecycle for the Green-field scenario are now described in more detail. Build Phase

• 1. Development of the new Web Service:

The first step is to design and implement the application that represents the Web

• Service. This includes the design and coding required to implement the service,

and the testing to validate that all of its functionality work correctly.

• 2. Defining a new Service Interface:

After the new Web Service has been developed, the Service Interface Description can be created – or generated by adequate development tools – based on the implementation of the service. See Section "4.1. Web Services Description Language (WSDL)" for detailed information about describing Web Services with the WSDL. The service interface should not be created until the Web Service development is complete because the interface must match exactly the implementation of the service. Deploy Phase

• 1. Publishing of the Service Interface:

The Service Interface Description can now be published to a Service Registry. It is used by a Service Requestor to determine how to use the service and how to bind to it (i.e. which network protocol is used). See Chapter "5. Universal Description, Discovery and Integration (UDDI)" for more information about publishing to a UDDI Service Registry.

• 2. Deployment of the Web Service:

The executable code for the service has to be provided into the runtime

• environment. The runtime environment is the platform for running the service. It

also consists of a server running on this platform, that is enabled with all technologies necessary to invoke the service (e.g. handling SOAP requests, XML parsing/processing) and perform its functionality (e.g. access to needed databases

• r other services). After the service has been deployed, it is ready for use by a

Service Requestor.

• 3. Creation of the Service Implementation Description:

The Service Implementation Description has to be created based on how and where the service was deployed. See Section "4.1. Web Services Description Language (WSDL)" for more information about describing Web Services with the WSDL.

• 4. Publishing the Service Implementation Description:

The Service Implementation Description is published to a Service Registry. It contains the definition of the network-accessible endpoint where the service can be

• invoked. See Chapter "5. Universal Description, Discovery and Integration

(UDDI)" for more information about publishing to a UDDI Service Registry. Run Phase Running the Web Service: The Web Service is now fully operational, deployed in the runtime environment and published into a Service Registry. So it can be found and invoked by Service Requestors.

• 3. Web Services Development

Page 20

Figure 3-2: Service Provider Side Development Process, Green-field

Figure 3-2 illustrates the development process related with the Green-field scenario. The new Web Service is built first, and then the Service Interface Description is created. After deployment, the Service Implementation Description is created. The two description files are linked together by referencing from one to the other (i.e. the Service Implementation Description "imports" the Service Interface Description). Both, the Interface and the Implementation Description, are owned by the Service Provider. The description files physically reside on the Service Provider's HTTP server. The description is published to the Service Registry and does exist there as a reference to the description files stored at the provider's server. So they are available for Service Requestors.

Describe Describe Service Registry Service Implementation Description Service Interface Description Service Provider Service Web Service Deploy Develop Service Implementation Description Service Interface Description Publish

• 3. Web Services Development

Page 21

3.2.2.2. The "Bottom-up" scenario

In the Bottom-up approach an already existing application functionality is exposed as a Web Service. The following steps in development can be identified (Figure 3-3):

• The developers start with an already existing functionality,

e.g. a Java Class.

• Creation/generation of the Web Service Interface

Description (WSDL documents).

• Deployment of the service based on the functionality and

the Interface Description.

• Creation of the Web Service Implementation description.
• Publishing of the Web Service within a Service Registry

(UDDI). The Bottom-up approach is probably one of the most relevant scenarios for enterprise developers because they are likely to have a relatively large variety of existing applications or services which contain a great deal of development efforts. Exposing existing application as Web Services means reuse of these components and continuing utilization

• f

the expenditures from the past.

Figure 3-3: Web Services Development in the "Bottom-up" scenario

The following more detailed development lifecycle phases are concerned with the Bottom-up scenario: Build Phase Creation of the Web Service Interface: The Service Interface can be described or generated from the implementation of the application that represents the Web Service. Deploy Phase

• 1. Deployment of the Web Service:

The executable of the service is provided into the runtime environment. The deployed service is ready to be used by a Service Requestor.

• 2. Creation of the Service Implementation Description:

The Service Implementation Description is created based on the location where the service has been deployed.

• 3. Publishing the Service Interface Description:

The Service Interface Description has to be published to a Service Registry before the Service Implementation Description can be published.

• 4. Publishing the Service Implementation Description:

The Service Implementation Description is now published to the Service Registry. As mentioned above, it specifies the endpoint where the service is deployed.

Existing Service (e.g. Java Class) New Web Service Interface (WSDL description) New Service Deployment Publish Service (UDDI) New Web Service Implementation Description (WSDL)

• 3. Web Services Development

Page 22 Run Phase Running the Web Service: The Web Service is fully operational, deployed, published and available for invocation by Service Requestors.

Figure 3-4: Service Provider Side Development Process, Bottom-up

Figure 3-4 shows the development process in the Bottom-up scenario. It is very similar to the Green-field scenario shown in Figure 3-2. The only difference to the Green-field scenario is that the Web Service does not have to be developed first but it is already started with an application that is intended to become a Web Service. At first the Service Interface Description for the application is created. After that, the Service has to be deployed and accordingly the deployment is described within the Service Implementation Description. Finally the service is published to the Service Registry.

Describe Describe Service Registry Service Implementation Description Service Interface Description Service Provider Service Web Service Deploy Service Implementation Description Service Interface Description Publish

• 3. Web Services Development

Page 23

3.2.2.3. The "Top-down" scenario

The issue in the Top-down scenario is that it starts with the specification of a projected Web Service in form of a given interface definition. The existing interface could also be part of an industry standard, which can be implemented by any number of Service Providers. The Top-down scenario looks very similar to the Bottom-up

• scenario. Only the service and the service interface or their

existence or newness, respectively, are inverted. Compared with Java, the Top-down approach is similar to creating a Java class that implements a given interface. The single steps for the Top-down scenario are illustrated in Figure 3-5. The detailed development lifecycle phases for the Top-down scenario are as follows. It is assumed that the existing Service Interface Description is poperly published within a Service Registry.

Figure 3-5: Web Services Development in the "Top-down" scenario

Build Phase

• 1. Finding the Service Interface:

The Service Interface Description that will be used to implement the Web Service has to be located by searching the Service Registry. See Chapter "5. Universal Description, Discovery and Integration (UDDI)" for more information about finding information from a UDDI Service Registry.

• 2. Creation of a service implementation template:

Using the Service Interface Description, an implementation template of the Web Service can be created or generated by a development tool. This template will contain all of the methods and parameters that must be implemented by the Web Service to correspond with the Service Interface.

• 3. Development of the new Web Service:

Using the service implementation template created in the previous step, the application that represents the Web Service can be designed and implemented. This step includes the design and coding required to implement the service, and the testing to verify that all of its defined interfaces work correctly. Deploy Phase The deployment steps in the Top-down scenario are the same as the deployment steps 2 to 4 for the Green-field scenario. The only difference is that the Service Interface Description has already been published earlier, probably by another entity.

Existing Web Service Interface (WSDL description) New Service (e.g. Java class) New Service Deployment Publish Service (UDDI) New Web Service Implementation Description (WSDL)

• 3. Web Services Development

Page 24

• 1. Deployment of the Web Service:

The executable code for the service has to be provided into the runtime environment to be ready to use for Service Requestors.

• 2. Creation of the Service Implementation Description:

The Service Implementation Description is created based on the location where the service has been deployed.

• 3. Publishing the Service Implementation Description:

The Service Implementation Description, that specifies the endpoint where the service is deployed, now has to be published to the Service Registry. Run Phase Running the Web Service: The Web Service is fully operational, deployed, published and available for invocation by Service Requestors.

Figure 3-6: Service Provider Side Development Process, Top-down

Figure 3-6 illustrates the Top-down development process. The new Web Service is developed corresponding to an existing Service Interface. The Service Provider has to find the Service Interface Description and implement the interface defined in this description. The Service Provider only gets a copy of the Interface Description via the Service Registry. Based on a created service implementation template the Web Service now has to be

• developed. After that, the new Web Service is deployed and the Service Implementation

Description is created. The new Implementation Description refers to the already existing Interface Description. Only the Implementation Description has to be published to the Service Registry by the Service Provider. And only the created Implementation Description is owned by the Service Provider. It resides on his HTTP server and the publication at the Service Registry refers to that location.

Describe Generate Service Registry Service Implementation Description Service Interface Description Service Provider Service Web Service Deploy Develop Service Implementation Description Service Interface Description Skeleton Publish Find

• 3. Web Services Development

Page 25

3.2.2.4. The "Meet-in-the-middle" scenario

The Meet-in-the-middle approach is a combination of the scenarios where an application already exists and there is also an existing Web Service Interface. These two elements now have to be joined into a new Service Deployment, as shown in Figure 3-7.

Figure 3-7: Web Services Development in the "Meet-in-the-middle" scenario

This is obviously the most difficult of the described scenarios, because the functionality of the existing application may not match the Interface description for the desired Web Service. In that case, it may be necessary to create a translation layer that is positioned between the given Web Service Interface and the existing application code. Correspondingly, the Meet-in-the-middle scenario looks very similar to the Top-down approach where now the translation layer, considering the existing service, has to implement the interface defined by the Web Service Interface Description. The following more detailed development lifecycle phases are concerned with the Bottom-up scenario: Build Phase The first two build steps are the same as those for the Top-down scenario.

• 1. Finding the Service Interface:

The Service Interface Description that will be used to implement the Web Service has to be located by searching the Service Registry.

• 2. Creation of a service implementation template:

Based on the Service Interface Description, an implementation template of the Web Service can be created or generated.

• 3. Development of the service wrapper:

Using the service implementation template created in the previous step, the service wrapper can be designed and implemented. This wrapper maps the given Service Interface to the existing application interface.

Existing Web Service Interface (WSDL description) Existing Service (e.g. Java class) New Service Deployment Publish Service (UDDI) New Web Service Implementation description (WSDL)

• 3. Web Services Development

Page 26 Deploy Phase The deployment steps for the Meet-in-the-middle scenario are similar to those for the Bottom-up scenario. The difference is that the Service Interface Description is already published.

• 1. Deployment of the Web Service:

The executable of the service wrapper and the existing application that implements the functionality of the service are provided into the runtime environment.

• 2. Creation of the Service Implementation Description:

The Service Implementation Description is created based on the location where the service has been deployed.

• 3. Publishing the Service Implementation Description:

The Service Implementation Description has to be published to the Service Registry. Run Phase Running the Web Service: The Web Service is fully operational, deployed, published and available for invocation by Service Requestors.

Figure 3-8: Service Provider Side Development Process, Meet-in-the-middle

Figure 3-8 shows the development process in the Meet-in-the-middle scenario. The issue in this method is to map the existing application interfaces to those defined in the existing Service Interface Description. After finding this description, the Service Provider can create a service implementation template and use it for development of a service wrapper. The wrapper contains an implementation that maps the service interface to the existing application

• interface. Now the complete service can be deployed and the Service Implementation

Description has to be created and published to the Service Registry.

Describe Generate Service Registry Service Implementation Description Service Interface Description Service Provider Service Web Service Deploy Develop Service Implementation Description Service Interface Description Skeleton Publish Find Service Wrapper

• 3. Web Services Development

Page 27

3.2.3. The Service Requestor side

When developing a Client Application that uses a Web Service, a Service Requestor basically goes through the same lifecycle phases as the Service Provider. However, the Service Requestor performs different tasks during each phase. The build-time tasks for the Service Requestor are determined based on the method of binding to the Web Service. There are two methods for binding to a specific service: static binding and dynamic binding. The following subsections describe the Service Requestor side development lifecycle phases and processes for static and dynamic binding (based upon [Brit01]).

3.2.3.1. Static Binding

A Service Requestor will use static binding when there is only one service implementation that can be used at runtime. The advantage of static binding is that the structure of a client application using this binding method would be less complex, because binding to a service implementation has only to be done once at build-time, and the client application (or the client-side service proxy, respectively) does not need to contain code for locating different service implementations. However, static binding causes that only one specific service implementation can be used at

• runtime. Hence, it is more difficult to – for any reason – replace one service implementation

by another. In that case, the implementation of the client application would have to be changed. The build, deploy and run phases of the development lifecycle for the Service Requestor for static binding are as follows. It is assumed that a Service Provider provides a corresponding,

• perational Web Service and did publish it to a Service Registry.

Build Phase

• 1. Finding the Service Implementation Description:

At build-time, the Service Requestor has to locate the Service Implementation Description for the Web Service from a Service Registry. See Chapter "5. Universal Description, Discovery and Integration (UDDI)" for more information about finding information from a UDDI Service Registry. The Implementation Description contains the location of the Service Provider where the Web Service can be accessed, and a reference to the Service Interface Description.

• 2. Creation of the service proxy:

Using the Service Implementation and Interface Descriptions, a service proxy can be created or generated by a development tool. The proxy implementation conforms to the service interface. On static binding, the proxy will always try to access the Web Service at the same location. This task also includes testing of the service proxy to verify that it can interact with the specified Web Service. The service proxy contains all the code that is required to access and invoke the Web Service. For the Service Requestor, the proxy acts as the local representative for the service. It encapsulates the operations of the service. A service method call to the proxy is delegated to the service implementation at the Service Provider side

• ver the network. Therefore, the proxy also implements the protocol specific

network communication to the Web Service. See Section "4.2. Simple Object

• 3. Web Services Development

Page 28 Access Protocol (SOAP)" for more information about XML messaging using

• SOAP. Correspondingly, the service proxy contains the SOAP client code that is

required to invoke a method on the SOAP based service.

• 3. Development of the Client Application:

The desired application at the Service Requestor side has to be designed, implemented and tested. This application needs the functionality of the Web Service to perform its requirements and therefore uses the service proxy to access the required operations of the Web Service. Deploy Phase Deployment of service proxy and Client Application: After the service proxy and the Client Application have been tested to verify that they work correctly, both can be deployed in the client runtime environment to be available for use. Run Phase Invocation of the Web Service: At the Service Requestor side the Client Application is executed using the service proxy to invoke the Web Service deployed at the Service Provider side.

Figure 3-9: Service Requestor Side Development Process, Static Binding

Generate Service Requestor Service Proxy Service Registry Service Implementation Description Service Interface Description Service Provider Service Interface Description Service Implementation Description Web Service Service Implementation Description Service Interface Description Bind Publish Client Application Develop Find

• 3. Web Services Development

Page 29 Figure 3-9 illustrates the development process for static binding. The required Web Service is available at the Service Provider side and its descriptions are published within a Service

• Registry. The Service Requestor now can find the Service Implementation Description and

get a copy of it via the Service Registry. Using the Implementation Description and the included reference to the Service Interface Description, the Service Requestor can create a service proxy. The developed Client Application uses this service proxy to access and invoke the Web Service.

3.2.3.2. Dynamic Binding

Dynamic binding is used when a Service Requestor wants to use a specific type of Web Service, but its implementation is not known until runtime or it can change at runtime. The type of service is defined in a Service Interface Description. The advantage of dynamic binding is that it is possible for the client application to use different service implementations. This would be profitable, for example, in the case that one service implementation is not available at a certain time. However, dynamic binding causes the client application (or the client-side service proxy, respectively) to become more complex, because it has to contain code for locating different service implementations. Moreover, locating service implementations entrails additional, time-consuming network activity at runtime. The development lifecycle phases when using dynamic binding are as follows. Build Phase

• 1. Finding the Service Interface Description:

The Service Requestor has to locate the Service Interface Description for the type

• f service that will be used within a Client Application.

Often there are more implementations of Web Services that provide the same

• perations and correspond with the Service Interface. Each of these existing Web

Service implementations has its own Service Implementation Description that refer to the same Interface Description.

• 2. Creation of a generic service proxy:

Using the Service Interface Description, a generic service can be created or

• generated. This proxy can be used to access any implementation of the same

Service Interface. The proxy also has to be tested to verify that it can interact with the specified type of Web Service. This can be accomplished by finding a particular implementation of the Service Interface. The difference between this proxy and that one for static binding is that on static binding it contains knowledge about a specific service implementation for the determined Service Interface. This means that the generic service proxy contains code to locate a service implementation by searching its Implementation Description from a Service Registry.

• 3. Development of the Client Application:

The required application that uses the Web Service has to be designed, implemented and tested.

• 3. Web Services Development

Page 30 Deploy Phase Deployment of service proxy and Client Application: After the service proxy and the Client Application have been tested to ensure that they work correctly, they have to be deployed within the runtime environment. This runtime environment needs to have access to the Service Registry that will be searched for an implementation of the Service Interface at runtime. Run Phase

• 1. Finding the Service Implementation Description:

On a request from the Client application for a service operation, the service proxy has to first locate a particular service implementation before it is able to invoke the Web Service. The created service proxy should contain all of the code that is required to search the Service Registry for an implementation of the specified Service Interface.

• 2. Invocation of the Web Service:

After the service implementation has been found, the service proxy can be used to invoke the Web Service.

Figure 3-10: Service Requestor Side Development Process, Dynamic Binding

The development process for dynamic binding is illustrated in Figure 3-10. The Service Requestor finds the Service Interface Description for the required type of service from the Service Registry. This Interface Description is used to create a generic service proxy that is

Generate Service Requestor Service Proxy Service Registry Service Implementation Description Service Interface Description Service Provider Service Interface Description Service Implementation Description Web Service Service Interface Description Bind Find (1) Publish Client Application Develop Find (2)

• 3. Web Services Development

Page 31 able to access any implementation of this interface. When the developed Client application at runtime requests for a service operation, the proxy has to locate an implementation of the service in the Service Registry before it can invoke the Web Service. Note: The described type of dynamic binding is called "build-time dynamic binding". There is also another method for dynamic binding: "runtime dynamic binding". This type is different in that both, the Service Implementation and Interface Descriptions, are found at runtime. Correspondingly, the service proxy code is also generated, compiled and deployed at runtime before it can be executed to invoke a Web Service. This type of dynamic binding typically requires a higher level of user interaction on execution for selecting from available Web Service Interfaces and Implementations – it is not possible for a machine-to-machine interaction to be truly dynamic. Therefore, the runtime dynamic binding method is not well suited for any kind of application using Web Services.