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