Conception of Information Systems

Part 7: Web Services

©2004, Karl Aberer, EPFL-SSC, Laboratoire de systèmes d'informations rèpartis

1
PART VII – Web Services

1. Web Services Overview

2. SOAP
3. WSDL
4. UDDI

©2004, Karl Aberer, EPFL-SSC, Laboratoire de systèmes d'informations rèpartis

2
 7.1 Web Services

• "Web services are a new breed of Web application. They are self-contained,
self-describing, modular applications that can be published, located, and
invoked across the Web. Web services perform functions, which can be
anything from simple requests to complicated business processes. … Once
a Web service is deployed, other applications (and other Web services) can
discover and invoke the deployed service.” IBM web service tutorial

• "Comparing CORBA with the ongoing work on Web service technologies, we

are forced to ask the question: are we reinventing the wheel ? A. Gokhale,
B. Kumar, A. Sahuguet; Reinventing the Wheel ? CORBA vs. Web Services

• Distributed computing model based on asynchronous messaging (XML)

– Support dynamic application integration over the Web
– Web Services connect computers and devices with each other using the Internet
to exchange data and access services
– On-the-fly software creation through the use of loosely coupled, reusable
software components
– Software can be delivered and paid per-use as opposed to packaged products.
– Business services can be distributed over the Internet

©2004, Karl Aberer, EPFL-SSC, Laboratoire de systèmes d'informations rèpartis

The notion of web services captures a recent technological development that aims at the
possibility to access services (i.e. applications) through the Internet infrastructure (i.e. Web
standards). Technologically they represent only a small change as compared to earlier
distributed computing standards, but the impact of this new technology is considered as
being very high as it facilitates automated distributed computing and information access by
taking advantage of the ubiquitously available Web infrastructure. In particular on-demand
use of software is considered as one of the important developments Web service technology
is going to support.

3
 Web Services Design Principles

• Web-based Protocols
– Web-services based on HTTP
– protocols can traverse firewalls, can work in a heterogeneous environment
• Interoperability
– SOAP defines a common standard that allows different systems to interoperate
• XML-based (XML schema)
– machine-readable documents
• Modularity
– Service Components are useful in themselves, reusable, composable
• Availability
– Services are available to systems that wish to use them
– Services must be exposed outside of the particular system they are available in
• Machine-readable description
– used to identify the interface, the location and access information
• Implementation-independence
– Service interface available independent of the ultimate implementation
• Published
– Searchable service repositories of service descriptions

©2004, Karl Aberer, EPFL-SSC, Laboratoire de systèmes d'informations rèpartis

Here we summarize some of the design principles that underlie Web service technology.
Note that many of this principles also hold for other distributed computing technologies,
such as CORBA, but that the use of ubiquitously available Web technology makes the
infrastructure easier accessible and wider available.

4
 Web Services Architecture

• Service-oriented architecture

"server"

Service provider

publish bind
(WSDL) (SOAP)

Service broker Service requestor

find
"naming service" (UDDI) "client"

©2004, Karl Aberer, EPFL-SSC, Laboratoire de systèmes d'informations rèpartis Part 7 - 5

The Web architecture consists of three components

• The service providers that publish available services and offer bindings for
services
• The service brokers that allow service providers to publish their services
(register and categorize). They provide also mechanisms to locate services and
their providers
• The service requestor that uses the service broker to find a service and then
invokes (or binds) the service offered by a service provider.
Note that this architecture corresponds 1:1 to the CORBA model of server-naming
service-client.
For each of the three activities the Web services architecture provides specific
standards, namely SOAP, WSDL, and UDDI. SOAP and WSDL are W3C
standards, whereas UDDI is an OASIS standard.

5
 Web Service Stack

• A set of standards for implementing web services

Publication and Discovery: UDDI extends URI

Service Description: WSDL extends HTML

Messaging: SOAP extends HTTP

Transport: HTTP, SMTP, FTTP, …

• UDDI provides a mechanism for clients to find web services
– UDDI registry is similar to a CORBA trader or a DNS for business applications.
• WSDL defines services as collections of network endpoints or ports
– A port is defined by associating a network address with a binding (servers)
– a collection of ports define a service
• SOAP is a message layout specification that defines a uniform way of
passing XML-encoded data and to bind to HTTP as the underlying
communication protocol
– SOAP is basically a technology to allow for “RPC over the Web"
©2004, Karl Aberer, EPFL-SSC, Laboratoire de systèmes d'informations rèpartis Part 7 - 6

The different standards of the web services architecture establish a communication

infrastructure that can be viewed as a high-level protocol stack, where each higher
level protocol builds on the lower level protocol:
•The web service transport layer is responsible for the basic communication
between web services and builds on existing Internet (application) protocol
standards
•The messaging layer uses the XML-based Simple Object access Protocol for
exchanging messages in a request/reply fashion in a distributed environment
•The description layer allows describing interfaces of web services – including
operations and their parameters. The descriptions are based on the XML-based
WSDL standard (Web Service Description Language)
•The publication and discovery layer provides the mechanisms for the service
brokers. This layer is based on the Universal Description, Discovery and Integration
(UDDI) standard, a standard that defines XML-based service AND business
descriptions, and a SOAP-based standard API to interact with the service broker.
On can view each of the three higher layers of this protocol stack as an extension of
existing WWW protocols for supporting services instead of simple document
access. SOAP extends HTTP allowing not only document requests but also service
requests. WSDL extends HTML by allowing to describe services instead of the
structure of documents. UDDI extends URI by allowing to locate services instead of
documents only.

6
 Basic Web Service Usage Scenario

2 http get
(manual) web
service lookup
Web Service
3 WSDL file Repository
(UDDI)

write client 1 register

application WSDL file
(manually)
publish web
service
4 SOAP request
write client
application Web Service
5 SOAP response Provider

©2004, Karl Aberer, EPFL-SSC, Laboratoire de systèmes d'informations rèpartis

This figure illustrates a (possible) basic Web service usage scenario. A Web service
provider registers it's web service at a UDDI repository. This could be done manually
through a Web interface or through a UDDI API. He registers the description of the web
service which is given in WSDL. A potential user may, for example, manually look up in
the UDDI repository the Web service through http and obtain the WSDL file. This file
contains all the information needed in order to access the Web service. Based on this
information he/she implements a client application that makes use of the web service. When
the client application is executed it accesses the web service by using the SOAP protocol for
service invocation.

7
 Web Services Implementation

Web Service Provider

(endpoint)

Requestor HTTP SOAP application

(SOAP client) server server server

SOAP
messages
(http transport)

• Application Server (web service-enabled)

– provides implementation of services and exposes it through WSDL/SOAP
– implementation in Java, as EJB, as .NET (C#) etc.
• SOAP server
– implements the SOAP protocol
• HTTP server
– standard Web server
• SOAP client
– implements the SOAP protocol on the client site

©2004, Karl Aberer, EPFL-SSC, Laboratoire de systèmes d'informations rèpartis

The implementation of web services (in runtime) requires in particular the support of the
SOAP protocol on the server and the client site. At the server this support is provided by a
SOAP server that uses the HTTP server for transporting SOAP messages. The applications
implementing the service can be implemented in any implementation platform, ranging
from simple programming languages to application services, that support a web service
front-end. It is irrelevant what exactly the interface between the SOAP server and
application server is and to which degree exposing applications as web services is
automated (e.g. whether web services can be automatically generated from application
server components such as EJBs). These solutions are vendor-specific.

8
 CORBA vs. Web Services

CORBA stack Web Services stack

IDL WSDL

CORBA (Naming) Services UDDI

CORBA Stubs/Skeletons SOAP Messaging

CDR binary encoding XML Unicode encoding

GIOP/IIOP HTTP

TCP/IP TCP/IP

©2004, Karl Aberer, EPFL-SSC, Laboratoire de systèmes d'informations rèpartis

It is interesting to compare the Web services stack with the CORBA stack. This clearly
shows that the two technologies address exactly the same problem using two different
approaches. Also observe that both technologies are based on TCP/IP thus are Internet-
based, but that they deviate already at the level of the transport protocol, where Web service
chose a WEB protocol, whereas CORBA is based on a protocol proprietary to the standard.

9
 CORBA vs. Web Services

Feature CORBA Web Services

Data Model Object Model SOAP message exchange
model
Client-Server Coupling Tight coupling (common Loose coupling
state)

Type system IDL XML

Location transparency Object references URL
Parameter passing By reference/value By value only
Type checking Static+runtime Runtime only
Service discovery Naming/Trading service UDDI

Serialization Built into ORB Chosen by user

©2004, Karl Aberer, EPFL-SSC, Laboratoire de systèmes d'informations rèpartis

It is also interesting to compare in more detail of how CORBA and Web services address
specific technical issues.
Data Model: Web services model applications using a message-based paradigm, i.e. an
asynchronous communication model, modeled as message exchanges among endpoints
(service providers), whereas CORBA is based on synchronous model or strong coupling
between clients and servers, modeled as method invocations among objects.
Parameter passing: since Web services have no notion of objects also no references can be
passed. All data is passed by value.
Type Checking: CORBA supports both static (which is the standard) and dynamic type
checking (supported by static stubs/skeletons resp. by using the DII)
State: Since CORBA uses a synchronous communication model during the interaction a
common state is established. Web services are a priori stateless. However, there exist
extensions to implement stateful Web processes based on Web services (more on that later
in the part on workflows)
Service Discovery: The UDDI of Web services provides a substantially more powerful
approach to model and search Web services, as compared to Naming services in CORBA.
Serialization: With Web service the serialization of application data (in XML) can be
chosen by the user.

10
 7.2 SOAP – Simple Object Access Protocol

• Lightweight messaging framework based on XML

• Supports simple messaging and RPC

• SOAP consists of
– Envelope construct: defines the overall structure of messages
– Encoding rules: define the serialization of application data types
– SOAP RPC: defines representation of remote procedure calls and responses
– Binding framework: binding to protocols such as HTTP, SMTP
– Fault handling

• Soap supports advanced message processing:

– forwarding intermediaries: route messages based on the semantics of message
– active intermediaries: do additional processing before forwarding messages, may
modify message

©2004, Karl Aberer, EPFL-SSC, Laboratoire de systèmes d'informations rèpartis Part 7 - 11

SOAP defines the protocol by which web services can be invoked. It supports both
simple messaging (as in message queuing approaches) and RPC-style
communication. It can be used over any transport protocol layer (such as HTTP,
SMTP). SOAP defines the basic structure of messages and encoding rules for data
types (used as parameters in procedure/method calls) and the encoding of procedure
calls and responses. SOAP also defines bindings to specific transport protocols most
notably to HTTP and SMTP.
SOAP is designed to also allow the implementation of advanced message
processing models, in particular the use of intermediaries. Intermediaries both can
just route messages, based on the content of the message, or do some additional
processing before routing the message.

11
 SOAP Message

• SOAP messages consist of

– Envelope: top element of XML message (required)
– Header: general information on message such as security (optional)
– Body: data exchanged (required)
• Header
– elements are application-specific
– may be processed and changed
envelope
by intermediaries or recipient
header
• Body
– elements are application-specific
– processed by recipient only

body

©2004, Karl Aberer, EPFL-SSC, Laboratoire de systèmes d'informations rèpartis

The basic structure of a SOAP message consists of a header and a body, both of which the
contents are application specific, i.e. not defined by SOAP. The differentiation is made to
distinguish information that is to be processed by all intermediaries (Header) and
information that is to be processed at the final destination (Body).

12
 Example: SOAP Message

<?xml version='1.0' ?> Envelope

<env:Envelope xmlns:env="http://www.w3.org/2002/12/soap-envelope">
<env:Header>
<m:reservation xmlns:m=http://travelcompany.example.org/reservation
env:role=http://www.w3.org/2002/12/soap-envelope/role/next
SOAP attributes env:mustUnderstand="true">
<m:dateAndTime>2001-11-29T13:20:00.000-05:00</m:dateAndTime>
</m:reservation>
<n:passenger xmlns:n=http://mycompany.example.com/employees
Header
env:role=http://www.w3.org/2002/12/soap-envelope/role/next
SOAP attributes env:mustUnderstand="true">
<n:name>Åke Jógvan Øyvind</n:name>
</n:passenger>
</env:Header>
<env:Body>
<p:itinerary xmlns:p="http://travelcompany.example.org/reservation/travel">
<p:departure>
<p:departing>New York</p:departing>
<p:arriving>Los Angeles</p:arriving>
<p:departureDate>2001-12-14</p:departureDate>
</p:departure> Body
<p:return>
<p:departing>Los Angeles</p:departing>
<p:arriving>New York</p:arriving>
<p:departureDate>2001-12-20</p:departureDate>
</p:return>
</p:itinerary>
</env:Body>
©2004, Karl Aberer, EPFL-SSC, Laboratoire de systèmes d'informations rèpartis
</env:Envelope> Part 7 - 13

We highlight some specificities of the SOAP message model for this example. The
envelope is the mandatory top-level element of any SOAP message.
The header relates to information on authentication, transaction management,
payment etc. needed for processing the message and during transport. Elements in
the header contain SOAP-specific attributes (recognizable as belonging to the env
namespace) which are used to determine which type of processing is expected by
intermediaries and endpoints. This example shows of how the header is used in
order transmit certain transactional properties that are required for the service
invocation.
The body contains the request, which consists of a travel itinerary in this case. That
is, this message is not corresponding to a method invocation but to a simple
message transfer.

13
 Conversational Message Exchanges in SOAP

travel agency customer

proposed
itinerary

alternatives

choice

©2004, Karl Aberer, EPFL-SSC, Laboratoire de systèmes d'informations rèpartis

Having simple informational messages as in the previous example, using SOAP, one can
implement conversational message exchanges such as illustrated in this example. Such
exchanges can for example be used to model a negotiation process between a seller and a
customer.

14
 SOAP RPC

• Encapsulate RPC into SOAP messages

– procedure name and arguments
– response (return value)
– processing instructions (transactional RPC!)
• Example: Request message
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2002/12/soap-envelope" > transaction information
<env:Header>
<t:transaction xmlns:t="http://thirdparty.example.org/transaction"
env:encodingStyle="http://example.com/encoding"
env:mustUnderstand="true" >5</t:transaction>
</env:Header>
<env:Body>
TID method invocation
<m:chargeReservation env:encodingStyle="http://www.w3.org/2002/12/soap-encoding"
xmlns:m="http://travelcompany.example.org/">
<m:reservation xmlns:m="http://travelcompany.example.org/reservation">
<m:code>FT35ZBQ</m:code>
</m:reservation> parameter 1
<o:creditCard xmlns:o="http://mycompany.example.com/financial">
<n:name xmlns:n="http://mycompany.example.com/employees">
Åke Jógvan Øyvind </n:name>
<o:number>123456789099999</o:number>
<o:expiration>2005-02</o:expiration>
</o:creditCard>
parameter 2
</m:chargeReservation>
</env:Body>
©2004, Karl Aberer, EPFL-SSC, Laboratoire de systèmes d'informations rèpartis
</env:Envelope>

SOAP also standardizes the way of how request/response interactions are to be represented
within a SOAP message. Note that this type of interaction does not exactly correspond to
the classical concept of RCP, since it is implemented asynchronously (no common state),
but is called RPC in the SOAP standard and is supposed to be used to access services in an
RPC style.
The example shows of a how a request is represented: the (application-specific) method
name (chargeReservations) occurs as top element in the message Body. The (application-
specific) parameters are then to be included as subelements of the method element. SOAP
also specifies of how to encode various data types. We will not go into these details of the
standard in the following.
The Header of the message can be used to include information that is necessary to properly
process the request: in this example it is used to state that the message is to be performed as
part of a transaction, with a given TID. Note that also the encoding of this processing
information is not standardized by SOAP but by the applications, resp. systems, using the
SOAP message format.

15
 SOAP RPC

• Example cntd.: Response message

<?xml version='1.0' ?>

<env:Envelope xmlns:env="http://www.w3.org/2002/12/soap-envelope" >
<env:Header>
<t:transaction xmlns:t=http://thirdparty.example.org/transaction
env:encodingStyle=http://example.com/encoding
env:mustUnderstand="true">5</t:transaction>
</env:Header>
<env:Body> method result
<m:chargeReservationResponse
env:encodingStyle=http://www.w3.org/2002/12/soap-encoding
xmlns:m="http://travelcompany.example.org/">
<m:code>FT35ZBQ</m:code>
<m:viewAt> http://travelcompany.example.org/reservations?code=FT35ZBQ
</m:viewAt> output parameters
</m:chargeReservationResponse>
</env:Body>
</env:Envelope>

©2004, Karl Aberer, EPFL-SSC, Laboratoire de systèmes d'informations rèpartis

Similarly as the request also the response is encoded. In the response the method result is
represented by an application specific top element in the message Body, which again
includes one or more output parameters as sub-elements. In order to model functions SOAP
provides an alternative representation of response messages allowing to distinguish a
function result value as a special element.

16
 SOAP Processing Model

• Elements in the Header may carry SOAP-specific attributes controlling the

message processing
– attributes from namespace http://www.w3.org/2002/12/soap-envelope
– role, mustUnderstand, relay
• "role" attribute
– if processing node matches role in header it must process the header
– special role "next": receiving node must be capable of processing header
– special role "ultimateRceiver: receiving node must be capable of processing body
• "mustUnderstand" attribute
– processing of header information is mandatory
• "relay" attribute
– header block must be relayed if it is not processed

©2004, Karl Aberer, EPFL-SSC, Laboratoire de systèmes d'informations rèpartis

We now explain in more detail the meaning of the SOAP-specific attributes that are used in
the elements occurring in the Header element. The role attribute is considered by the
receiver of the message and concerns the capability of the receiver to process the
(application-specific) information in the SOAP message. If its value is set to "next" this
implies the every receiving node must be capable of processing the header, whereas the
value "ultimateReceiver" implies the capability to also process the message body.
The "mustUnderstand" attributes can be used to control the processing of the header. Note
that being capable of processing the header does not necessarily imply that the header will
be processed. The "relay" attribute can in the case processing is not done, require to forward
the message to another SOAP node.

17
 Protocol Binding

• Bindings to different protocols possible: HTTP, SMTP

• Different HTTP bindings: HTTP POST, HTTP GET
– standard HTPP POST for request-response

POST /Reservations?code=FT35ZBQ HTTP/1.1

Host: travelcompany.example.org
Content-Type: application/soap+xml; charset="utf-8"
Content-Length: nnnn
HTTP POST
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2002/12/soap-envelope" > request
…SOAP request message…
</env:Envelope>

HTTP/1.1 200 OK
Content-Type: application/soap+xml; charset="utf-8"
Content-Length: nnnn
HTTP response
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2002/12/soap-envelope" >
… SOAP response message …
</env:Envelope>

©2004, Karl Aberer, EPFL-SSC, Laboratoire de systèmes d'informations rèpartis

SOAP also standardizes the binding of SOAP messages to specific transport protocols, in
particular to HTTP. Essentially it prescribes of how the transport protocols are to be used to
perform SOAP message exchanges. A possible way of how such a binding looks like for
HTTP is given in the example. Specifically this type of binding requires the use of HTTP
POST to transmit a request and to use the corresponding HTTP response to transmit the
response associated with the request.

18
 7.3 WSDL – Web Service Description Language

• Description of Web services in XML format

– abstract description of operations and their parameters (messages)
– binding to a concrete network protocol (e.g. SOAP)
– specification of endpoints for accessing the service

• Structure of a WSDL document Types: structure

of messages

Messages: used abstract

by operations

(abstract) PortType: operations

Operations supported by service

(protocol) Binding:
Operations concrete protocol
concrete
Port: Binding and Service: collection
a network address of related ports

©2004, Karl Aberer, EPFL-SSC, Laboratoire de systèmes d'informations rèpartis Part 7 - 19

WSDL describes web services in terms of the services offered and the endpoints
that offer the services. Using the WSDL specification of a web service a client is
able to construct the necessary SOAP messages in order to access the service, to
send the message to the required network location, as well as to correctly interpret
the responses.
WSDL distinguishes the abstract and concrete specification of a service. The
abstract part specifies the type of data used in the parameters, the types of messages
exchanged during an operation, and the operations themselves, which might require
the exchange of multiple messages. Since a Web service might consists of a set of
operations supported (e.g. a travel reservation service might offer operations to
check itineraries, book flights and payment) multiple operations can be bundled in
so-called portTypes.
The concrete specification of the service concerns the transport protocol used and
the necessary binding (e.g. to SOAP) and the network addresses where the service is
offered (called ports). Again the same service may be offered at multiple physical
sites, therefore a set of ports can be specified to define the service.
This organization is also reflected in the structure of a WSDL document. The
vertical arrows in the figure correspond to references made within a WSDL
document through a "name" attribute (thus they are "refersTo" relationship) whereas
the horizontal arrows correspond to sub-element relationships in the WSDL
document.

19
 Overview of Defining WSDL Services

1. Define in XML Schema the message types used when invoking the service:
MT1, MT2 etc.
2. Define (named) messages by using these types, e.g.
• message m1 has type MT1
• message m2 has type MT2 etc.
3. Define Services that consist of one or more operations; each operation is
implemented by the exchange of messages
• service S offers operation O1; for executing O1 first send a request message m1,
then a response message m2 is returned
4. Define a Binding B to a specific protocol, e.g. SOAP
• service S is implemented in SOAP; the SOAP messages are constructed from the
abstract messages m1 and m2 by, e.g. inlining the message as body of SOAP
messages
5. Service S is provided with binding B at the following URI's (called ports)

©2004, Karl Aberer, EPFL-SSC, Laboratoire de systèmes d'informations rèpartis

To better understand the role of the different parts of a WSDL document, we sketch here the
typical steps that would be taken in completely defining a Web service using WSDL.

20
 Example: Overall Document Structure

<?xml version="1.0">
<definitions name="StockQuote>
<types>
<schema>
definition of types in XML Schema …………
</schema>
</types>
<message name="GetTradePriceInput">
definition of a message....
</message>
<portType name="StockQuotePortType">
<operation name="GetLastTradePrice">
definition of an operation ………
</operation>
</portType>
<binding name="StockQuoteSoapBinding">
definition of a binding ………
</binding>
<service name="StockQuoteService">
<port name="StockQuotePort">
definition of a port ………
</port>
</service>
</definitions>
©2004, Karl Aberer, EPFL-SSC, Laboratoire de systèmes d'informations rèpartis

This is an overview of the syntactical representation of a service in WSDL. For each of the
main parts (data, messages, portTypes, Service) a separate top element is used (outer boxes).
Within this subelements represent collections of specifications, such as the set of operations
belonging to a portType. These are indicated by the inner boxes.

21
 Example: Definition of Types

©2004, Karl Aberer, EPFL-SSC, Laboratoire de systèmes d'informations rèpartis Part 7 - 22

This example shows the type definition of a WSDL specification. The types are
defined using the XML Schema language. In this example two data types are
defined as complex types. XML document (fragments) corresponding to these types
will be used as parameters of the web service.

22
 Example: Definition of Messages and PortType

Operation uses these messages

©2004, Karl Aberer, EPFL-SSC, Laboratoire de systèmes d'informations rèpartis Part 7 - 23

This (fragment of a) WSDL specification refers to the type definitions before. Two
messages are defined. The part elements of a message allow to associate with the
message one or more types that have been defined before in the type specification.
Each part obtains an individual name and refers to a type.
A portType consists of one or more operations. Each operation requires two
messages, one for the request (input) and one for the response. The messages are
referred to by their names.
This example illustrates of how a WSDL definition can be decomposed into
multiple documents: the type definitions from the previous slides are imported into
the document using the import element (rather directly inlined into the document,
which also would be possible).
Note that all element and attribute names in this example are WSDL-specific, i.e.
defined in the WSDL schema (which is given as an XML Schema)

23
 Example: Definition of Binding and Service

abstract operation GetLastTradePrice

of portType StockQuotePortType
implemented by these SOAP messages

Binding provided at this URI

©2004, Karl Aberer, EPFL-SSC, Laboratoire de systèmes d'informations rèpartis Part 7 - 24

This WSDL specification completes the example. It refers to the specification on the
previous slide. In the binding element it binds the port type GetLastTradePrice
(which is the abstract service) to a concrete protocol, namely the SOAP protocol and
thus defines the message format. In the service part the binding StockQuoteBinding
(which is the abstract service definition together with a concrete transport protocol)
is bound to a specific access point, given as URL, resulting in a port. This single
port then constitutes the concrete service.
We do not detail the rules of how the binding between the abstract operation
specification and its corresponding SOAP operations is established. Essentially
using the syntax given above the input/output messages are mapped to SOAP
request/response messages, and the SOAP message body is derived from the XML
types associated with the messages in the abstract specification.

24
 PortTypes

• WSDL supports 4 message patterns that an endpoint (=service provider!)

can support for an operation
– one-way: message is sent to service provider without expecting response
– request-response: request is sent to service provider expecting response
– solicit-response: provider sends a message and expects response
– notification: message is sent by service provider
• Message patterns are distinguished by the use of input/output elements
– one way:
<wsdl:definitions .... > <wsdl:portType .... > *
<wsdl:operation name="nmtoken">
<wsdl:input name="nmtoken"? message="qname"/>
</wsdl:operation>
</wsdl:portType >
</wsdl:definitions>

– request/response:
<wsdl:definitions .... >
<wsdl:portType .... > *
<wsdl:operation name="nmtoken" parameterOrder="nmtokens">
<wsdl:input name="nmtoken"? message="qname"/>
<wsdl:output name="nmtoken"? message="qname"/>
<wsdl:fault name="nmtoken" message="qname"/>*
</wsdl:operation
</wsdl:portType >
©2004, Karl </wsdl:definitions>
Aberer, EPFL-SSC, Laboratoire de systèmes d'informations rèpartis

WSDL foresees four different types of operations, corresponding to different message

exchange patterns. These patterns are considered as being the most frequently used in
practice. These different patterns are distinguished in the specification of the operation by
the different use of the input/output elements, as illustrated in the example.

25
 7.4 UDDI – Universal Description Discovery and
Integration
• Standard for describing, publishing and finding web services
– Still evolving
– Use XML-based description files for services

• Main components
– White pages: basic contact information about an organization
– Yellow pages: classification of organization based on industrial categorization
– Green pages: technical description of services offered by registered organizations

• Access to UDDI Registry

– Standard UDDI API (accessible via SOAP)
– Web browser

• Data Structures (XML)

– Business entity: general information + business services
– Business services: business level description + binding templates
– Binding templates: access point + tModel (service types)
– tModel: abstract definition of a web service

©2004, Karl Aberer, EPFL-SSC, Laboratoire de systèmes d'informations rèpartis Part 7 - 26

The UDDI standard contains a number of different components for describing

organizations, classifying them according to their general activities and allowing
them to offer registered web services. UDDI also standardizes an access protocol for
accessing a UDDI repository. First UDDI repositories are being made publicly or
commercially available. These can also be accessed through Web interfaces.
A business is described in UDDI by an XML document. UDDI introduces an
abstract model to specify web services, the tModel. This seems to be redundant with
WSDL, but the purpose is different: UDDI foresees that different abstract service
description mechanisms might be used in future. The tModel provides a common
framework to include these into UDDI registry entries.

26
 Registering a WSDL Service in UDDI

1. Register a business
2. Register the abstract service definition (tModel)
3. Register the service implementation definition (BusinessService)

• Step 1: Register a business

(see demo at https://uddi.ibm.com/testregistry/)

©2004, Karl Aberer, EPFL-SSC, Laboratoire de systèmes d'informations rèpartis

Registration of service can be performed interactively at UDDI repositories. The registration

of a business requires to capture basic information (like address, areas of activity). We will
give a demo of how this is interactively performed.

27
 Step 2: Registering a Abstract WSDL Service Definition

<?xml version="1.0">
tModel
<definitions name="StockQuote>
<types>
<schema> <?xml version="1.0">
definition of types <tModel tModelKey="…">
</schema> <name>StockQuote</name>
</types> …
<message name="GetTradePriceInput"> <overviewDoc>
definition of a message <overviewURL>
</message>
http//…
<portType name="StockQuotePortType">
<operation name="GetLastTradePrice"> </overviewURL>
definition of an operation ………
</operation> <categoryBag>
</portType> <keyedReference tmodelKey="…"
<binding name="StockQuoteSoapBinding">
keyName="uddi-org:types"
definition of a binding ………
</binding> keyValue="wsdlSpec">
<service name="StockQuoteService"> </categoryBag>
<port name="StockQuotePort"> </tModel>
definition of a port ………
</port>
</service>
</definitions>

service specified in WSDL

©2004, Karl Aberer, EPFL-SSC, Laboratoire de systèmes d'informations rèpartis

Registering a service requires two steps: the registration of the abstract description and the
registration of the service implementation-related information. The abstract definition is
captured by the so-called tModel (another XML document type). It allows to provide the
UDDI registry with the information on the service name (i.e. it's identification) and it's
abstract specification, by referring to a WSDL document. The figure illustrates of how this
association is syntactically represented in XML. UDDI provides for every service
representation standard a model for registering the description, though WSDL is apparently
the only relevant one at the given time.

28
 Step 3: Registering a Service Implementation

<?xml version="1.0">
<definitions name="StockQuote>
<?xml version="1.0">
<binding name="StockQuoteSoapBinding" <businessEntity businessKey="…">
type="tns:StockQuotePortType"> …
<soap:binding style="document" <businessService serviceKey"…"
transport="http://schemas.xmlsoap.org/soap/http"/> <name>StockQuote</name>
<operation name="GetLastTradePrice"> …
<soap:operation <bindingTemplates>
soapAction= <bindingTemplate>
"http://example.com/GetLastTradePrice"/> <accessPoint urlType="http">
<input> http://example.com/stockquote
<soap:body use="literal"/> </accessPoint>
</input>
<output> <tModelInstanceDetails>
<soap:body use="literal"/> …
</output> <overviewDoc>
</operation> <overviewURL>
</binding> http://...
</overviewURL>
<service name="StockQuoteService"> </overviewDoc>
<documentation>My first service</documentation> …
<port name="StockQuotePort" </tModelInstanceDetails>
binding="tns:StockQuoteBinding"> </bindingTemplate>
<soap:address </bindingTemplates>
location="http://example.com/stockquote"/>
</port> </businessService>
</service>
</definitions> </businessEntity>

©2004, Karl Aberer, EPFL-SSC, Laboratoire de systèmes d'informations rèpartis

Similarly, the concrete implementation of the service is registered (as part of the business
service description) by referring to a WSDL document. For the registration of the
implementation, in particular the physical address at which the service is accessed, which is
found in the port definition in the WSDL specification, is included in the UDDI service
description as shown in the example. Again the UDDI service description then refers for the
details of the service binding to the WSDL document.

29
Demo

https://uddi.ibm.com/testregistry/registry.html

©2004, Karl Aberer, EPFL-SSC, Laboratoire de systèmes d'informations rèpartis

30
Summary

• Web Services are becoming the predominant mechanism for distributed

computing on the WWW

• They implement a service stack comparable to earlier distributed

computing solutions such as CORBA, but are fully based on Web standards
and therefore can take advantage of the Web infrastructure

• The current standards include SOAP for communication, WSDL for service
specification, and UDDI for service discovery

• Higher level standards for service composition and semantic description of

web services are currently emerging

©2004, Karl Aberer, EPFL-SSC, Laboratoire de systèmes d'informations rèpartis

31
References

• Standard documents
– http://www.w3.org/2002/ws/
– http://www.w3.org/TR/2002/CR-soap12-part0-20021219/ (SOAP primer)
– http://www.w3.org/TR/SOAP/
– http://www.w3.org/TR/wsdl
– http://www.uddi.org

• Articles
– http://www2002.org/CDROM/alternate/395/ (Comparison to CORBA)

©2004, Karl Aberer, EPFL-SSC, Laboratoire de systèmes d'informations rèpartis

32