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

WSDL Web Services Description Language PowerPoint PPT Presentation


  • 90 Views
  • Uploaded 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

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


Wsdl web services description language l.jpg

WSDLWeb Services Description Language


Goals of wsdl l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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


Example11 l.jpg

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 l.jpg

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 level13 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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 literal22 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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 binding30 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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 l.jpg

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