web services - concepts, architecture and applications part 6: service description (wsdl) gustavo...

Web Services - Concepts, Architecture and ApplicationsPart 6: Service Description (WSDL)Gustavo Alonso and Cesare PautassoComputer Science DepartmentETH Zü[email protected]://www.inf.ethz.ch/~alonso

Some slides were modified or added by: Nilufer OnderComputer Science DepartmentMichigan Technological Universityhttp://www.cs.mtu.edu/~nilufer

http://www.inf.ethz.ch/~alonso

©ETH Zürich Part 6: WSDL 2

What is WSDL? Web Services Description Language (WSDL) is an XML format for describing

network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented communication.(www.w3.org/TR/wsdl)

The original document was prepared by Ariba, IBM, and Microsoft. The Web Services Description Language specification is in working draft 2.0

(November 2003, June 2007) WSDL discusses how to describe the different parts that comprise a Web

service. A WSDL document defines services as collections of network endpoints, or

ports. The general framework is to store WSDL descriptions where potential clients

can find the services they need


WSDL definitions In WSDL, abstract definition of endpoints and messages is separated from their

concrete network deployment or data format bindings Abstract definition

Types: a container for data type definitions (e.g., using XSD) Message: a typed definition of the data being communicated Operation: description of an action supported by the service Port type: set of operations supported by one or more endpoints

Concrete description Binding: protocol and data format specification for a particular port type Port: a single endpoint defined as a combination of a binding and a network

address Service: a collection of related endpoints


Elements of WSDLWSDL document

Types (type information for the document, e.g., XML Schema)

Message 1 Message 4Message 3Message 2

Operation 1 Operation 3Operation 2

Message 6Message 5

Interface (abstract service)

binding 1

endpoint 1

binding 2

endpoint 2

binding 3

endpoint 3

binding 4

endpoint 4

Service (the interface in all its available implementations)

Ab

stra

ct d

escr

ipti

on o

f th

e se

rvic

eC

oncr

ete

des

crip

tion

of

th

e se

rvic

e


WSDL ExampleF

r om

: Web

Ser

vice

s D

esc r

ipti

on L

a ngu

age

(WS

DL

) 1.1

. © W

3 C N

ote

15 M

arch

20 0

1 <?xml version=“1.0”?><definitions name=“StockQuote”

Targetnamespace=“http://example.com/stockquote.wsdl” Xmlns:tns=“http://example.com/stockquote.wsdl” Xmlns:xsdl=“http://example.com/stockquote.xsd” Xmlns:soap=“http://schemas.xmlsoap.org/wsdl/soap/” Xmlns=“http://schemas.xmlsoap.org/wsdl”/>


WSDL Example - TypesF

r om

: Web

Ser

vice

s D

esc r

ipti

on L

a ngu

age

(WS

DL

) 1.1

. © W

3 C N

ote

15 M

arch

20 0

1 <types> <schema targetNamespace=http://example.com/stockquote.xsd xmlns=http://www.w3.org/2000/10/XMLSchema> <element name=“TradePriceRequest”> <complexType> <all> <element name=“tickerSymbol” type=“string”/> </all> </complexType> </element><element name=“TradePrice”> <complexType> <all> <element name=“price” type=“float”/> </all> </complexType> </element> </schema></types>


Types in WSDL

The types in WSDL are used to specify the contents of the messages (normal messages and fault messages) that will be exchanged as part of the interactions with the Web service

The type system is typically based on XML Schema (structures and data types) - support is mandatory for all WSDL processors

An extensibility element can be used to define a schema definition language other than XML Schema


WSDL Example - MessagesF

r om

: Web

Ser

vice

s D

esc r

ipti

on L

a ngu

age

(WS

DL

) 1.1

. © W

3 C N

ote

15 M

arch

20 0

1 <message name=“GetLastTradePriceInput”> <part name=“body” element=“wsdl:TradePriceRequest”/></message>

<message name=“GetLastTradePriceOutput”> <part name=“body” element=“wsdl:TradePrice”/></message>


Messages and Faults Called “message reference

component”, it contains three elements: message reference: indicating

the message pattern used for this message

direction: whether it is an inbound or outbound message

message: the actual contents of the message expressed in terms of the types previously defined

Messages are divided into parts, each of them being a data structure represented in XML. Each part must have a type (basic or complex types, previously declared in the WSDL document).

If a SOAP binding is used, a WSDL message element is meant to match the contents of the body of a SOAP message. By looking at the types and looking at the message, it is possible to build a SOAP message that matches the WSDL description (and this can be done automatically since the description is XML based and the types also supported by SOAP)

Called the “fault reference component”, it contains: a name message reference: the message

to which the fault refers to direction: whether the fault is

inbound or outbound message: the actual contents


WSDL Example – Operation and PortF

r om

: Web

Ser

vice

s D

esc r

ipti

on L

a ngu

age

(WS

DL

) 1.1

. © W

3 C N

ote

15 M

arch

20 0

1 <portType name=“StockQuotePortType”> <operation name=“GetLastTradePrice”> <input message=“tns:GetLastTradePriceInput”/> <output message=“tns:GetLastTradePriceOutput”/> </operation></portType>


Operations An operation is a set of messages

and faults. The sequencing and number of messages in the operation is determined by the message exchange pattern (would add a line containing <fault message=… to the operation)

An operation has: name message exchange pattern message references: the

messages involved (input, output)

fault references: the faults involved (infault, outfault)

style (optional): RPC, set-attribute or get-attribute

features and properties

Style: RPC = implies interactions

mirroring the behavior of RPC set- and get- attribute = implies

interactions of the type commonly found in object oriented languages

Features and properties: used to specified characteristics of the message exchange implied by an operation. Examples include reliability, security, routing, etc


WSDL Example – BindingF

r om

: Web

Ser

vice

s D

esc r

ipti

on L

a ngu

age

(WS

DL

) 1.1

. © W

3 C N

ote

15 M

arch

20 0

1 <binding name=“StockQuoteSoapBinding” type=“tns:StockQuotePortType”> <soap:binding style=“document”

transport=“http://schemas/xmlsoap.org/soap/http”/> <operation name=“GetLastTradePrice”> <soap:operation soapAction=“http://example.com/GetLastTradePrice”/> <input> <soap:body use=“literal”/> </input> <output> <soap:body use=“literal”/> </output> </operation></binding>


Bindings and ports A binding defines message formats

and protocol details for the operations and messages of a given Port Type

A binding corresponds to a single Port Type (obvious since it needs to refer to the operations and messages of the Port Type)

A Port Type can have several bindings (thereby providing several access channels to the same abstract service)

The binding is extensible with elements that allow to specify mappings of the messages and operations to any format or transport protocol. In this way WSDL is not protocol specific.

A port specifies the address of a binding, i.e., how to access the service using a particular protocol and format

Ports can only specify one address and they should not contain any binding information

The port is often specified as part of a service rather than on its own


WSDL Example – ServiceF

r om

: Web

Ser

vice

s D

esc r

ipti

on L

a ngu

age

(WS

DL

) 1.1

. © W

3 C N

ote

15 M

arch

20 0

1 <service name=“StockQuoteService”> <documentation>My first service</documentation> <port name=“StockQuotePort” binding=“tns:StockQuoteBinding”> <soap:address location=“http://example.com/stockquote”/> </port></service>

</definitions>


Bindings, endpoints, and services A binding describes a concrete

message format and transmission protocol for a given endpoint

A binding can be generic or refer to a concrete interface

A binding can be defined for an entire interface or on an operation basis

A binding has: name interface: the interface to which

this binding applies operations: a set of binding

operation components features and properties

A binding operation component specifies the binding for a given operation: name: the operation for which

the binding applies message references fault references

The binding operation component contains message and fault bindings for all messages and faults of an operation

An endpoint associates an address to a given binding

A service groups together all the endpoints for a given interface

The specification includes bindings for HHTP, SOAP and MIME (the latter may eventually be dropped)


Message exchange patterns IN-ONLY

a single incoming message (A) with no faults

ROBUST IN-ONLY an inbound message (A) that

might trigger a fault message IN-OUT

An incoming message (A) received from node N

An outgoing message (B) sent to node N

Faults, if any, replace message B

IN-MULTI-OUT Like IN-OUT but with zero or

more outbound messages and “fault replaces message” behavior

OUT-ONLY An outbound message (A) that

expects no faults ROBUST OUT-ONLY

An outbound message (A) that might trigger a fault

OUT-IN An outbound message (A) to

node N An inbound message (B) from

node N Faults, if any, replace message

B ASYNCHRONOUS OUT-IN

Like OUT-IN but with trigger behavior for messages

OUT-MULTI-IN reverse of IN-MULTI-OUT


Interfaces in WSDL 2.0 An interface defines the messages a

service sends or receives by grouping the messages into operations

An interface can extend the operations of other interfaces (inheritance)

An interface has: name extended interfaces: other

interfaces that this one extends style default: default style for

operations operations features and properties

An interface corresponds to the abstract description of the Web service, it does not contain any information about where the service resides or what protocols are used to invoke the Web service


WSDL 1.1 vs WSDL 2.0

WSDL 2.0 Endpoints Interfaces Support for Interface inheritance

Removed operation overloading

Messages defined through Types Operations nested inside Interfaces Endpoints nested inside Bindings

9 Message Exchange Patterns

New: Features and Properties

WSDL 1.1 Ports PortTypes

Supported operation overloading

Messages composed of Parts 6 Top level elements: Messages,

Operations, PortTypes, Bindings, Ports and Services.

4 Transmission Primitives (One-way, Request-Response, Solicit-Response, Notification)


On the use of WSDL


Potential Uses of WSDL Traditional service description language: a contract that a Web service

implements Input to stub compilers: will generate required stubs and additional information

for developing both the service and the clients (allow designers to reason about the semantics of a Web service. However,

semantics is outside the scope of current WSDL specifications.)


Conversations WSDL is in its current version an extension of the IDL model to support

interaction through the Internet: XML as syntax and type system possibility of grouping operations into a service different options for accessing the service (addresses and protocols)

This is its great advantage … it is straightforward to adapt existing middleware platforms to use or

support WSDL automatic translation from existing IDLs to WSDL is trivial

… but also the disadvantage electronic commerce and B2B interactions are not single service calls WSDL does not reflect the structure of the procedures to follow to correctly

interact with a service (conversations)• business protocol = set of valid conversations

Without a business protocol, most of the development work is still manual


Conversations (example)

“The xCBL 3.5 ChangeOrder document is a buyer-initiated document that can be used to

change an existing Order already received and responded to by a seller. The document

can be used to make changes to header level information, change line items, cancel line

items, add line items, etc. Note that if an OrderResponse has not been received for a

given Order, a ChangeOrder is not necessary (an Order with a purpose of “Replace”

should be used). Similarly, if an entire order is to be cancelled (regardless of whether a

response has been received or not) an Order with a purpose of “Cancellation” should be

used.”xCBL 3.5 Order Management Recommended Use, Version 1.0 November 19, 2001


Other standards ebXML shows here again what

could be a possible evolution path for WSDL (or the type of technology that is being built on top of WSDL)

ebXML does not consider a client/ server model but an interaction between partners (peer-to-peer)

Consequently, the service description model for ebXML is the description of how two business processes interact with each other: partners publish their processes

(an external view over them) a collaboration agreement is

drawn based on those processes the collaboration agreement

describes the business protocol between those partners

Multiple standards will continue to coexist

VIEW OF BUSINESS PROCESSPARTNER 1

VIEW OF BUSINESS PROCESSPARTNER 2

CO

LL

AB

OR

AT

ION

A

GR

EE

ME

NT

serv

ice

serv

ice


Automatic development The ultimate goal of WSDL is to

provide support for automating as much as possible for the development process for Web services: given the WSDL description, a

WSDL compiler generates the stubs or skeletons necessary to develop clients that can interact with the service

for that purpose, WSDL must rely on a standard protocol so that generic stubs can be created, this is where SOAP comes into the picture

WSDL is meant as a bridge between internal services and external (Web) services

Similarly, the ultimate goal in ebXML is to automate the process of developing a collaboration agreement, deploying it and enforcing its rules: given a collaboration agreement

(possibly a standard one), one should be able to automatically generate a stub or skeleton for the individual business processes at the ends of the agreement

partners need only to extend the stub process with their own internal logic

this is why ebXML needs more than SOAP as the agreement is used to control and direct the flow of messages between partners at the platform level


WSDL Summary The goal of WSDL is to describe Web services, in particular describe service

interfaces. The WSDL data structure has interesting implications on how services are

described and how they interact Services can initiate operations like a client (blurred notion of client and

service provider) WSDL does not presume a particular form of communication (first defines

the abstract interface, then the location and protocol) Abstract interfaces are reusable: different services could combine different

interfaces using different bindings, and could make them available at different addresses

WSDL documents can import other WSDL documents The WSDL description is correlated with SOAP. If the messages defined in

WSDL are exchanged using SOAP, then the InterfaceBindings contain all the information needed to infer or automatically construct SOAP messages (interaction style, XML encoding, transport bindings)

web services - concepts, architecture and applications part 6: service description (wsdl) gustavo...

Documents

o wsdl

wsdl o

wsdl definitions o

wsdl processors o

wsdl descriptions

wsdl example messages

wsdl example types

web service o