WSDL Web Services Description Language

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 containing this 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 <output message = “gs:getQuoteOpResp”/> <outfault name = “invalidSymbolFault” messageReference=“gs:getQuoteOpResp” message = “gs:invalidSymbolFaultMsg”/> • 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

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> identifies binding

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 identifies interface <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 rpc style msg for tags used in messsage SOAP extensions encode parameters encoding rules

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 identifies interface <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> rpc style msg don’t encode parameters

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-way message

28. Document/literal Binding SOAP body contains XML documents <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> body is an instance of part type

29. Document/literal SOAP Binding Alternative 1 – one part specified by a type <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> n is target namespace of this document message can have only one part in this case since the schema of the body can have only one type specification

30. Document/literal SOAP Binding Alternative 2 – part specified by an element <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> 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. 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 used since 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