WSDL 1.

- Praveen Mukkala
History of WSDL
» WSDL 1.1 was co-submitted to W3C by
Microsoft, IBM, SAP and others in 2001

» WSDL 2.0 Draft version released in Nov 2003

Need for Service Description
Requestor of any service probably know to use a SOAP
message. However SOAP is just a format of the envelope.
It do not have the following details:

1. What constitutes the header and the body of the envelope

during a request and response.
2. What binding must be used
3. What is the end point of the service
Role of Service Description in SOA
Publish Find & Bind Approach

» Service provider publishes the service description in a

registry.
» Service requestor finds the description in the registry
» Service requestor binds to the service.

Service
Registry

Find Publish

Reque Provid
stor er
Bind
Service Description

A service description has two major components:

a) Functional Description
b) Non-Functional description
Functional Description
This component details the syntax of the message, end
point details, message style and use, operations available
for the client to invoke. It is further decomposed into two
sections:

Service Interface Definition

• What messages must be sent
• What encoding scheme to use

Service Implementation Definition

• Where the service implementation is located.
Nonfunctional Description
This component provides secondary details like security
policy,
SOAP headers etc. This component addresses:

1. Why should the requestor invoke the WebService. It

describes the functionality that it provides

2. Whether the service provide an auditing and ensure

privacy?

Non functional description is described using WS-Policy and

WS-policy Attachment
Service Description using WSDL
» WSDL is used to describe the message syntax
associated with invocation and response of a
WebService.

» WSDL service description is an XML Document

conformant to the WSDL schema definition.
WSDL Information Model
part type

abstract interface
portType
abstract
abstract operation
message

Concrete
implementation
binding
concrete
concrete operation
message

concrete endpoint
service
port
Structure of a WSDL
The root element of a WSDL Document is 'definitions' element.

A definitions element can contain the following:

» Zero or more documentation elements

» Zero or more import elements
» Optionally, one types element
» Zero or more message elements
» Zero or more portType elements
» Zero or more binding elements
» Zero or more service elements

A WSDL must conform to the XML Schema defined in

http://schemas.xmlsoap.org/wsdl/2003-02-11.xsd
portType element
» portType element describes the interface of a web service.
portType can contain a collection of operation elements.
This is similar to Java Interface which contain multiple
operations.

» Eg:
<portType name="PriceCheckPortType">
<operation name="checkPrice">
<input message="pc:PriceCheckRequest" />
<output message="pc:PriceCheckResponse" />
</operation>
</portType>

» A WSDL can contain zero or more portType definitons.

Typically WSDLs contain one portType definition.
operation element
Equivalent of a method in Programming languages. Operation
details the name of the method, input and output details
of the method. The above PriceCheckPortType defines a
method with corresponding input and output message
parameters.

Eg: <operation name="checkPrice">

<input message="pc:PriceCheckRequest" />
<output message="pc:PriceCheckResponse" />
</operation>
message element
1. A message describes the abstract form of an input, output or
fault message.

2. A WSDL can contain zero or more message elements. Each

message has a name which must be unique and contain a
collection of Part elements.

E.g.: <message name="PriceCheckRequest">

<part name="sku" element="avail:sku" />
</message>

<message name="PriceCheckResponse">
<part name="result" element="avail:StockAvailability" />
</message>
part element
Parts mechanism in WSDL allows a message to be
decomposed into smaller units.

A part is made up of a name and the kind of the part. Name

must be unique among all the other part child elements
of the message element. The kind property of the part
can be defined as either a type attribute or element
attribute.

Part contains two attributes:

name
type or element
part element
When an element attribute is
used, we're specifying that
the message should be
precisely of that XML
element. For eg,
PriceCheckResponse
example specifies that the
XML element named
StockAvailability from the
“http://thbs.com/ns/availab
ility" namespace must be
used as the body of the
message.
Also, when element attribute is
used, its value must refer
to a global XML element
declared in an XML Schema
(Example of ‘element’ attribtue in part)
...All the NS declarations..
<soapenv:Body>
<StockAvailability
xmlns="http://thbs.com/ns/availability">
<sku>123</sku>
<price>100.00</price>
<quantityAvailable>12</quantityAvailable>
</StockAvailability>
</soapenv:Body>
(Example of ‘type’ attribtue in part)
<soapenv:Body>
<ns1:checkPriceResponse
<result href="#id0" />
</ns1:checkPriceResponse>
<multiRef id="id0" soapenc:root="0" >
<sku xsi:type="xsd:string">123</sku>
<price xsi:type="xsd:double"> 100.01</price>
<quantityAvailable xsi:type="xsd:integer">
122</quantityAvailable>
</multiRef>
</soapenv:Body>
part element contd.
When a type attribute is used, we dont explicitly
indicate that a particular XML element is
required to be the sku in the PriceCheckRequest
message. Rather the element must have
xsd:string as its type
types element
» This section of the WSDL is a place to define user-defined
XML types and elements for later use in the parts
elements.

» The default type system in WSDL is XML Schema.

» A WSDL document contains at most one types element.

» A types element contain schema element.

» All the schema related features like import, include can be

used under the schema element.

» types section in WSDL allows you the flexibility to describe

a completely different type system for eg Java type
system. Disadvantage of extending type system is that
more requestors will be unable to invoke your web service.
types element contd.
E.g.
<types>
<xsd:schema targetNamespace="http://thbs.com/ns/availability"
<xsd:element name="sku" type="xsd:string" />
<xsd:complexType name="availabilityType">
<xsd:sequence>
<xsd:element ref="avail:sku"/>
<xsd:element name="price" type="xsd:double" />
<xsd:element name="quantityAvailable"
type="xsd:integer" />
</xsd:sequence>
</xsd:complexType>
<xsd:element name="StockAvailability"
type="avail:availabilityType" />
</xsd:schema>
</types>
binding element
Binding element in WSDL tells the service requestor how to format the
message in a protocol specific manner. It addresses the following
questions:

» Is the service invoked by a SOAP message or a simple HTTP POST of

an XML payload ?
» Is this an RPC or Document style invocation ?

Each portType is associated with one or more bindings. For a given

portType, a binding describes how to invoke operations using a
particular messaging/transport protocol like SOAP over HTTP, SOAP
over SMTP etc.

A binding can have a name attribute which must be unique in WSDL.

Naming convention is to combine portType name with the protocol.

A binding can have a type attribute which identifies the portType.

binding element contd.
E.g.:
<binding name="PriceCheckSOAPBinding"
type="pc:PriceCheckPortType">
<soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http" />

<operation name="checkPrice">
<soap:operation
soapAction="http://thbs.com/services/PriceCheck/checkP
rice" />
<input><soap:body use="literal" /></input>
<output><soap:body use="literal" /></output>
</operation>
</binding>
Determining the Protocol details
» Examine the namespace of the first child
element. In the above example, binding is
related to the SOAP messaging protocol.

» WSDL spec defines three standard binding

extensions for SOAP/HTTP, HTTP GET/POST and
SOAP with MIME attachments.
binding element contd.
Binding element decorates the portType in four
ways:
1. Invocation Style
2. SOAPAction
3. Input message appearance
4. Output message appearance
Invocation Style
Document or RPC invocation style to use is mentioned in the
<soap:binding> tag. Style mentioned here applies to the
entire binding.
Eg: <soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>

When the style is Document, the body of the SOAP Messsage

must be interpreted as XML whose contents can be
validated against the Schema.

Restricton: Document style can be mentioned if the portType

references message elements whose part uses element
attribute. If type is used, then we cannot use Document
style.
binding element contd.
» Transport Attribute tells that the requestor must send the
SOAP message using HTTP. Other values include
http://schemas.xmlsoap.org/soap/SMTP,
http://schemas.xmlsoap.org/soap/ftp/

» For interoperability resasons, each portType should have

one SOAP/HTTP binding defined.
SOAPAction
The second use of SOAP binding extension is to mention
SOAPAction detail.

<operation name="checkPrice" >

<soap:operation
soapAction="http://www.skatestown.com/services/PriceC
heck/checkPrice" />
</operation>

When the SOAP message is constructed, a SOAPAction HTTP

header is constructed.
Input Message Appearance:
SOAP Binding extensions provides a way to specify how the
message look like including the SOAP body and header
components of the message. In the example given,
PriceCheckRequest is declared to have exactly one
component and the content of that SOAP body is literally
a single XML element.
<input>
<soap:body use="literal" />
</input>
Output Message Appearance
SOAP Binding extension provides a way to describe how the
output message should appear

<output>
<soap:body use="literal" />
</output>
port element
» Used for specifying the network address or end point
details where the WebService is running

» Port elements are named and the name must be unique

among all the ports within a WSDL

» Ports associate binding to the end point details.

E.g.
<port name="PriceCheck"
binding="pc:PriceCheckSOAPBinding">
<soap:address
location="http://thbs.com/services/PriceCheck" />
</port>
service element
» The purpose of the Service is to contain a set of related ports.

» A WSDL can contain multiple service elements, however only one service
element will be specified in a given WSDL.

<service name="PriceCheck">
<port name="PriceCheck" binding="pc:PriceCheckSOAPBinding">
<soap:address location="http://thbs.com/services/PriceCheck" />
</port>
</service>

Need for service element:

There could be different bindings for a given portType. For eg one binding for a
portType could be a combination of SOAP/HTTP, Document and Literal.
Another binding for the same portType could be a combination of
SOAP/SMTP, RPC and Literal.
documentation element
» This element is used to provide human readable information about the
WebService description.

» Usually the first element of any WSDL element will start with
documentation tag.

E.g.:
<service name="PriceCheck">
<port name="PriceCheck" binding="pc:PriceCheckSOAPBinding">
<documentation>
<wsi:Claim conformsTo=http://ws-I.org/profiles/basic/1.0 />
</documentation>
<soap:address location="http://thbs.com/services/PriceCheck" />
</port>
</service>
import element
» WSDL defines import element that allows WSDL
documents to be linked together.

» Used to import other WSDLs into the current WSDL. This

is similar to XSD imports.

E.g.: <import namespace="thbs.com"

location="c:\Other.wsdl" />

Need for import element:

Abstract parts of the WSDL like messages, types, portType
and binding elements appear in one WSDL. These are the
reusable parts of the Service description and is called the
Service Interface definition. Concrete parts i.e. Service
Implementation definition details like Port and Service
details are present in a different WSDL.
Transmission Primitives
WSDL 1.1 defines the following four transmission
primitives:

» Request-Response Operations
» One-Way Operations
» Notification Operations
» Solicit-Response Operations
Request-Response Operations
» This is the most commonly used operations which have an input
message to the service provider followed by an output message
with an optional collection of fault messages.

» These operations normally send the message, modify the state

of service provider and include the changed state into response.
E.g.: <portType name="PriceCheckPortType">
<operation name="checkPrice">
<input message="pc:PriceCheckRequest" />
<output message="pc:PriceCheckResponse" />
<fault name=“fault1” message=“ProductNotFound”/>
<fault name=“fault2” message=“ProductExpired”/>
</operation>
</portType>
One-Way operations
» A one way operation do not have an output message. It is
similar to a data sink.

<operation name=“cancellation”>
<input message=“myNs:CancelOrder”/>
</operation>

» Since many web services are SOAP over HTTP, many one way
operations using HTTP end up being req-res messages at the
network transport level with the response being an HTTP level
acknowledgement.

» For one-way operation, the HTTP response must not contain a

SOAP Message and the clients do not expect it or ignore it if
present.
Notification Operations
» These operations are like one-way push from the Service
Provider.

» Output messages are pushed to the service requestor as a result

of an event on the service provider side such as time out
operation.
E.g: <operation name=“shipOrder”>
<output message=“DispatchDetails”/>
</operation>

Challenges to Implement:
Implementation Challenges
» WSDL do not mention any mechanism to implement
notification operations. One solution to address this
problem is to have a network address or a service
address (where the client would listen to)as a parameter
in another message. So clients should initiate that
request-reply or one-way operation first and then invoke
this operation.

» The semantics of notification style operations haven't

been agreed on in the industry. Therefore to ensure
interoperability of WebService, this operation style must
not be used.
Solicit Respose Operations
A solicit response operations models a push operation similar to a
notification operation. However, unlike the notificatin style of
operation, the solicit-response operation expects an input from the
service requestor
as the response in a solicit response exchange.

E.g.: <operation name=“solicitExample” >

<output message=“myNs:outInfo” />
<input message=“myNs:inInfo” />
<fault name=“fault1” message=“myNs:faultDetails”/>
</operation>
Notice the order of elements in operation tag. Output comes first, then
input which means service pushes the details to the requestor and
expects an input from the requestor.

This kind of operations face the same challenges as Notification style

operations and hence usage is discouraged.
References

1. WSDL 1.1 – http://www.w3.org/TR/wsdl

2. WSDL 2.0 –
http://www.w3.org/2002/ws/desc/wsdl20
Thank You