1 / 35

WSDL Web Services Description Language

WSDL Web Services Description Language. 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

oro
Download Presentation

WSDL Web Services Description Language

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related