1. 1 WSDL Web Services Description Language

2. 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. 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. 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. 5 Example <operation name = “getQuoteOp” pattern=“http://www.w3.org/2003/06/wsdl/in-out”> <outfault name = “invalidSymbolFault” messageReference=“gs:getQuoteOpResp” message = “gs:invalidSymbolFaultMsg”/> gs is the target namespace of the document containing this declaration and the message declarations

6. 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. 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 <outfault name = “invalidSymbolFault” messageReference=“gs:getQuoteOpResp” message = “gs:invalidSymbolFaultMsg”/>

8. 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. 9 Example – Message Definitions

10. 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. 11 Example <element name = “faultDetail” type = “string” minOccurs = “0” maxOccurs = “1”/>

12. 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. 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. 14 Example – Service and Endpoint identifies binding

15. 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> introduce SOAP namespace

16. 16 Example – RPC/encoded SOAP Binding <soap:binding style = “rpc” transport = “ http://schemas.xmlsoap.org/soap/http/”/> <soap:body use = “encoded” namespace =“ http://www.shearson.com/quoteservice” encodingStyle =“ http://schemas.xmlsoap.org/soap/encoding”/> Continued on next slide identifies interface SOAP extensions rpc style msg encode parameters encoding rules for tags used in messsage

17. 17 Binding Example - Continued <soap:body use = “encoded” namespace =“ http://www.shearson.com/quoteservice” encodingStyle =“ http://schemas.xmlsoap.org/soap/encoding/”/>

18. 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”> IBM

19. 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. 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. 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. 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. 23 Example – RPC/literal SOAP Binding <soap:binding style = “rpc” transport = “ http://schemas.xmlsoap.org/soap/http/”/> <soap:body use = “literal” namespace =“http://www.shearson.com/quoteservice”/> …. identifies interface rpc style msg don’t encode parameters

24. 24 RPC/literal SOAP Binding … …instance of comptyp…

25. 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. 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. 27 Document Style Messaging <operation name = “sendInvoiceOp” pattern = “http://www.w3.org/2003/06/wsdl/in-only”> one-way message

28. 28 Document/literal Binding <binding name = “sendInvBinding” type = “ing:invoiceIf> <soap:binding style = “document” transport = “http://schemas.xmlsoap.org/soap/http”/> <soap:body use = “literal” namespace = “http://www.invoicesource.com/invoice”/> SOAP body contains XML documents body is an instance of part type

29. 29 Document/literal SOAP Binding … …instance of comptyp… Alternative 1 – one part specified by a type message can have only one part in this case since the schema of the body can have only one type specification n is target namespace of this document

30. 30 Document/literal SOAP Binding … …instance of comptyp… Alternative 2 – part specified by an element Part is identified as an element. An instance of element is a child of body, named with element’s name, typed with element’s type

31. 31 Sending Multiple Documents element specification must be used since message has multiple parts

32. 32 Sending Messages By Email: Simple Mail Transfer Prototol <endpoint name = GetQuoteSMTP” binding=“gq:GetQuoteSMTPBinding”/> <soap:address location = “mailto:stockquote@shearson.com”/>

33. 33 Mail Example (continued) <binding name = “GetQuoteSMTPBinding” type = “tns:GetQuoteIf”> <soap:binding style = “document” transport=“http://schemas.xmlsoap.org/soap/smtp ”/>

34. 34 Complete WSDL Document <definitions targetNamespace=“….” xmlns=“ …” > … … … …

35. 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