1

WSDLWeb Services Description

Language

2

Goals of WSDL

• Describes the formats and protocols of a Web Service in a standard way– The operations the service supports – The message(s) needed to invoke the operations– The binding of the messages to a communication

protocol– The address to which messages should be sent

• Serves the same function as an Interface Description Language (IDL)

3

WSDL Description

• A Web Service is described at both the abstract and concrete levels

• Abstract Level– What are the operations that are supported?– What messages are needed to invoke the operations?

• Concrete Level– How are the messages bound to a transport protocol?– What is the Web address to which the messages should

be sent?

4

WSDL Abstract Level

• At the abstract level, obtaining a service is like executing a method of an object

• WSDL defines the following elements– An interface is like an object; it consists of a set of

operations– An operation is like a method; it is invoked by messages– A message is composed of parts– A part is like a parameter and has an associated type

5

Example <interface name = “GetQuoteIf”> <operation name = “getQuoteOp” pattern=“http://www.w3.org/2003/06/wsdl/in-out”> <input message = “gs:getQuoteOpReq”/> <output message = “gs:getQuoteOpResp”/> <outfault name = “invalidSymbolFault”

messageReference=“gs:getQuoteOpResp” message = “gs:invalidSymbolFaultMsg”/> </operation> <!-- other operations go here --></interface>

gs is the target namespace of the document containingthis declaration and the message declarations

6

Patterns• The messages exchanged when an operation is

invoked conform to a pattern• WSDL is considering a number of patterns, each

identified by a URI. The most commonly used are:– In-Out

• Input sent by requestor, output produced by service• Might be synchronous (requestor waits for response

– e.g. RPC) or asynchronous– In-Only

• Input sent by requestor, no response expected

7

Faults

• In-Out pattern uses a Fault Replaces Message fault rule:– Server replaces the message referenced by

messageReference with message if it detects a fault– Server raises the named fault in the requestor

• In-Only pattern uses No Fault fault rule– No fault message is allowed

<output message = “gs:getQuoteOpResp”/><outfault name = “invalidSymbolFault”

messageReference=“gs:getQuoteOpResp” message = “gs:invalidSymbolFaultMsg”/>

8

Other Message Patterns (tentative)

– Robust In-Only• Same as In-Only except that a fault message is allowed using

Message Triggers Fault rule– Server responds to input message with a fault message

– In-Multi-Out• A single input message followed by 0 or more instances of

output message in response– Uses Fault Replaces Message Rule rule

– Out Only– Out-In– Out-Multi-In ……. – and users can define their own rule

9

Example – Message Definitions<message name = “getQuoteOpReq”> <part name = “stockSymbol” type = “xsd:string”/></message>

<message name = “getQuoteOpResp”> <part name = “stockSymbol” type = “xsd:string”/> <part name = “QuoteValue” type = “xsd:float”/></message>

<message name = “invalidSymbolFaultMsg”> <part name = “faultInfo” type = “gs:faultType”/></message>

10

Parts of a Message• A message can have many parts

– Each part can be bound to a different position within the physical message sent by the transport

• With SOAP parts can be distributed over body and header blocks

• Each part can have a simple or complex type defined in an XML schema

11

Example

<schema> <complexType name = “faultType”> <sequence> <element name = “faultCode” type = “string”/> <element name = “faultDetail” type = “string”

minOccurs = “0” maxOccurs = “1”/> </sequence> </complexType></schema>

12

Concrete Level• The concrete level defines how interfaces and

operations are bound to transports and addresses• A given interface can be bound to several different

transports and addresses– A Web Service might support an interface using several

different transports• For example, the operations can be invoked using SOAP over

either HTTP or SMTP– The same interface might be supported by several different

Web Services using the same or different transports– In all of these cases, semantically identical service should

be provided at each address

13

Concrete Level

• At the concrete level WSDL defines the following elements– A binding describes how the operations and

messages of an interface are mapped into the messages of a particular transport

– An endpoint maps a binding to a Web address– A service is a collection of endpoints that host

related interfaces

14

Example – Service and Endpoint

<service name = “GetQuoteService”> <endpoint name = “GetQuoteRPC”

binding=“gq:GetQuoteSOAPBinding”> <soap:address location =

“http://www.shearson.com/quoteservice”/> </endpoint>

<!—Other endpoints go here --></service>

identifiesbinding

15

WSDL Extensibility• A binding maps an interface to a particular transport

– It must be capable of targeting a variety of transports– Each transport has its own idiosynchrosies

• WSDL is extended by introducing a different namespace for each transport

<definitions xmlns=“http://schemas.xmlsoap.org/wsdl/” xmlns:xsd=“http://www.w3.org/2001/XMLSchema” xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/ targetNamespace=http://www.shearson.com/quoteservice> <!-- WSDL declarations go here --></definitions>

introduce SOAP

namespace

16

Example – RPC/encoded SOAP Binding

<binding name = “GetQuoteSOAPBinding” type = “tns:GetQuoteIf”> <soap:binding style = “rpc” transport = “ http://schemas.xmlsoap.org/soap/http/”/> <operation name = “getQuoteOp”> <input> <soap:body use = “encoded” namespace =“ http://www.shearson.com/quoteservice” encodingStyle =“ http://schemas.xmlsoap.org/soap/encoding”/> </input>

Continued on next slide

identifiesinterface

SOAPextensions

rpc stylemsg

encodeparameters

encodingrules

for tags used inmesssage

17

Binding Example - Continued

<output> <soap:body use = “encoded” namespace =“ http://www.shearson.com/quoteservice” encodingStyle =“ http://schemas.xmlsoap.org/soap/encoding/”/> </output> </operation> <!-- other operations go here --></binding>

18

RPC/encoded Message<s:Envelope xmlns:s=“http://www.w3.org/2003/05/soap-envelope” xmlns:xsd=“http://www.w3.org/2001/XMLSchema” xmlns:xsi=“http://www.w3.org/2001/XMLSchema-instance”>

<s:Body><n:getQuoteOp xmlns:n=“http://www.shearson.com/quoteService”>

<n:stockSymbol xsi:type=“xsd:string”>IBM

</n:stockSymbol></n:getQuoteOp>

</s:Body></s:Envelope>

19

Encoding

• Problem: serializer serializes arguments in accordance with rules specified by encodingStyle attribute– Receiver can deserialize arguments since style is

specified in the message• But message has a declared type

– How can we be sure that the rules produce an instance of the type?

– In fact they might not!

20

Example – Encoding Style• Suppose there are n arguments of the same

type.– Serializer might produce a message containing

n instances of the type.• But suppose in a particular invocation all

arguments have same value.– Serializer might produce a message containing

n pointers to a single instance of the value– Then value of each parameter (a pointer) is not

an instance of the type

21

Encoded Vs. Literal

• If use=“encoded”, parameters are encoded in accordance with the specified encoding style

• If use=“literal”, parameters are instances of types specified in the message declaration

• Yields two distinct styles for invoking a remote procedure:– rpc/encoded– rpc/literal

22

Encoded Vs. Literal

• If use=“encoded”, parameters are encoded in accordance with the specified encoding style

• If use=“literal”, parameters are instances of types specified in the message declaration

• Yields two distinct styles for invoking a remote procedure:– rpc/encoded– rpc/literal

23

Example – RPC/literal SOAP Binding

<binding name = “GetQuoteSOAPBinding” type = “tns:GetQuoteIf”> <soap:binding style = “rpc” transport = “ http://schemas.xmlsoap.org/soap/http/”/> <operation name = “getQuoteOp”> <input> <soap:body use = “literal” namespace =“http://www.shearson.com/quoteservice”/> </input> <output> …. </output> </operation></binding>

identifiesinterface

rpc stylemsg

don’t encodeparameters

24

RPC/literal SOAP Binding<types> <schema> <complexType name=“comptyp”> … </complexType> <schema></types>

<message name=“msg”> <part name=“part1” type=“comptyp” /></message>

<soap:Envelope> <soap:Body> <n:myProc xmlns:n=“ “> <n:part1> …instance of comptyp… </n:part1> </n:myProc> </soap:Body></soap:Envelope>

25

RPC/encoded and RPC/literal

• RPC style specified for both bindings – There is no schema describing the message

body• Child of body uses name of procedure• Each grandchild corresponds to a parameter and uses

parameter name• Might be a grandchild for result returned

– Validation not possible

26

Sending Documents

• Increasingly, Web communication is– Asynchronous

• Web Services are loosely coupled (as opposed to tightly coupled, object-oriented systems that are developed in a more integrated fashion and are more oriented towards rpc)

• More appropriate for delay prone/failure prone environments

– Messages contain XML documents (instead of procedure arguments)

– A wide variety of communication patterns (as opposed to simply in-out) are useful

27

Document Style Messaging

<message name = “sendInvoiceMsg”> <part name = “invoice” type = “inv:invoiceType/></message>

<interface name = “invoiceIf”> <operation name = “sendInvoiceOp” pattern = “http://www.w3.org/2003/06/wsdl/in-only”> <input message = “inv:sendInvoiceMsg”/> </operation></interface>

one-waymessage

28

Document/literal Binding

<binding name = “sendInvBinding” type = “ing:invoiceIf> <soap:binding style = “document” transport = “http://schemas.xmlsoap.org/soap/http”/> <operation name = “inv:sendInvoiceOp”> <input> <soap:body use = “literal” namespace = “http://www.invoicesource.com/invoice”/> </input> </operation></binding>

SOAP bodycontains XML

documents

body is aninstance ofpart type

29

Document/literal SOAP Binding

<types> <schema> <complexType name=“comptyp”> … </complexType> <schema></types>

<message name=“msg”> <part name=“part1” type=“n:comptyp” /></message>

<soap:Envelope> <soap:Body>

…instance of comptyp… </soap:Body></soap:Envelope>

Alternative 1 – one part specified by a type

message can have only onepart in this case since theschema of the body can haveonly one type specification

n is targetnamespace ofthis document

30

Document/literal SOAP Binding

<types> <schema> <element name=“elem” type=“n:comptyp” /> <complexType name=“comptyp”> … </complexType> <schema></types>

<message name=“msg”> <part name=“part1” element=“n:elem” /></message>

<soap:Envelope> <soap:Body> <n:elem xmlns=“ …target ns of WSDL doc… “> …instance of comptyp… </n:elem> </soap:Body></soap:Envelope>

Alternative 2 – part specified by an element

Part is identified as anelement. An instance ofelement is a child of body, named with element’s name, typed with element’s type

31

Sending Multiple Documents<element name=“firstInvoice” type=“inv:invoiceType” /><element name=“secondInvoice” type=“inv:invoiceType” /><complexType name=“invoiceType”> <!-- the complex type definition goes here --></complexType>

<message name = “sendInvoiceMsg”> <part name = “invoicei” element = “inv:firstInvoice” /> <part name = “invoice2” element = “inv:secondInvoice” /></message>

element specification must be usedsince message has multiple parts

<soap:Body> <inv:firstInvoice> <!-- instance of invoiceType goes here --> </inv:firstInvoice> <inv:secondInvoice> <!-- instance of invoiceType goes here --> </inv:secondInvoice></soap:Body>

32

Sending Messages By Email: Simple Mail Transfer Prototol

<service name = “GetQuoteSMTPService”> <endpoint name = GetQuoteSMTP” binding=“gq:GetQuoteSMTPBinding”/> <soap:address location = “mailto:stockquote@shearson.com”/> </endpoint></service>

33

Mail Example (continued)<binding name = “GetQuoteSMTPBinding” type = “tns:GetQuoteIf”> <soap:binding style = “document” transport=“http://schemas.xmlsoap.org/soap/smtp ”/> <operation name = “getQuoteOp”> <input> <soap:body use=“literal”/> </input> <output> <soap:body use=“literal”/> </output> </operation></binding>

34

Complete WSDL Document<definitions targetNamespace=“….” xmlns=“ …” > <types> <!– specification of XML Schema types used in this document --> </types> <messsage> … </messsage> <!– specification of other messages goes here--> <interface> … </interface> <!– specification of other interfaces goes here--> <binding> … </binding> <!– specification of other bindings goes here--> <service> <endpoint> … </endpoint> <!– specification of other endpoints goes here--> </service></definitions>

35

What WSDL Cannot Do

• WSDL describes how one operation can be invoked– getQuoteOp

• Many services require a sequence of operations– Send this message, receive that message, if this happens send

this other message to another endpoint, etc– Cannot be described in WSDL

• BPEL describes the logic of a Web Service– How it is impemented– How it communicates with other busienss processes– Sometimes called an orchestration language