Wsdl web services description language l.jpg
Sponsored Links
This presentation is the property of its rightful owner.
1 / 35

WSDL Web Services Description Language PowerPoint PPT Presentation


  • 96 Views
  • Updated On :
  • Presentation posted in: General

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

Related searches for WSDL Web Services Description Language

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


WSDLWeb 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

    • The address to which messages should be sent

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


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?


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


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


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


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


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


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>


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


Example

<schema>

<complexType name = “faultType”>

<sequence>

<element name = “faultCode” type = “string”/>

<element name = “faultDetail” type = “string”

minOccurs = “0” maxOccurs = “1”/>

</sequence>

</complexType>

</schema>


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


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


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


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


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


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>


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>


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!


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


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


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


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


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>


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


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


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


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


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


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


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>


Sending Messages By Email: Simple Mail Transfer Prototol

<service name = “GetQuoteSMTPService”>

<endpoint name = GetQuoteSMTP”

binding=“gq:GetQuoteSMTPBinding”/>

<soap:address

location = “mailto:[email protected]/>

</endpoint>

</service>


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>


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>


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


  • Login