PWS Lecture 4. WSDL

Programming Web Services - Lec. 4 WSDL!
DarkSwitch 2010
WSDL (Web Services Description Language)

http://www.w3schools.com/wsdl/default.asp
1. Introduction
WSDL is written in XML

WSDL is used to describe Web services
WSDL is also used to locate Web services
WSDL is a document written in XML. The document describes a Web service. It specifies
the location of the service and the operations (or methods) the service exposes
2. WSDL Documents
It contains set of definitions to describe a web service
Elements of WSDL documents:
• <types>: The data types used by the web service

• <message>: The messages used by the web service
• <portType>: The operations performed by the web service
• <binding>: The communication protocols used by the web service
Main structure of a WSDL document:
! <definitions>
! <types>
! ! definition of types ......
! </types>
! <message>
! ! definition of a message ....
! </message>
! <portType>
! ! definition of a port ...
! </portType>
! <binding>
! ! definition of a binding .....
! </binding>
!
! </definitions>
2.1 WSDL Ports <portType>
The <portType> element can be compared to a function library (or a module, or a class) in
a traditional programming language.
It describes a web service, the operations that can be performed, and the messages that
are involved.
V 1.1 Last modification: 28/05/2010! Page 1

Programming Web Services - Lec. 4 WSDL! DarkSwitch 2010
2.2 WSDL Messages <message>
The <message> element defines the data elements of an operation.
Each message can consist of one or more parts.
The parts can be compared to the parameters of a function call in a traditional

programming language.
2.3 WSDL Types <types>
The <types> element defines the data types that are used by the web service.
For maximum platform neutrality, WSDL uses XML Schema syntax to define data types.
2.4 WSDL Bindings <binding>
The <binding> element defines the message format and protocol details for each port.
2.5 An Example
! <message name=”getTermRequest”>
! ! <part name=”term” type=”xs:string”/>
! </message>
! <message name=”getTermResponse”>
! ! <part name=”value” type=”xs:string”/>
! </message>
! <portType name=”glossaryTerms”>
! ! <operation name=”getTerm”>
! ! ! <input message=”getTermRequest”/>
! ! ! <output message=”getTermResponse” />
! ! </operation>
! </portType>
GlossaryTerms: The name of a port

GetTerm; The name of an operation
Compared to traditional programming

• GlossaryTerm is a function library
• GetTerm is a function with
• getTermRequest as the input parameter
• getTermResponse as the return parameter
3. Ports
A WSDL port describes the interfaces (legal operations) exposed by a web service:
• The operations that can be performed
• the message that are involved
3.1 Operation Types

• One-way: The operation <- message
• Request-response: The operation <- request

! ! ! ! The operation -> response
• Solicit-response: The operation -> request

! ! ! ! The operation <- Response
• Notification: The operation -> message
3.2 One-way Operation
Example:
! <message name=”newTermValues”>
! ! <part name=”term” type=”xs:string” />
! ! <part name=”value” type=”xs:string” />
! </message>
! ! <operation name=”setTerm”>
! ! ! <input name=”newTerm” message=”newTermValues” />
! ! </operation>
! </portType>
In this example above, the port “glossaryTerms” defines a one-way operation called
“setTerm”
Itʼs one-way cause it just defined the input parameters, and no output is defined for the
operation.
3.3 Request-Response Operation
Example:
! </message>
! </message>
! ! ! <input message=”getTermRequest” />
! ! </operation>
! </portType>
4. Binding
WSDL binding defines the message format and protocol details for a web service.
Example:
! </message>
! </message>
! ! ! <input message=”getTermRequest” />
! ! </operation>
! </portType>
! <binding type=”glossaryTerms” name=”b1”>

! ! <soap:binding style=”document”
! ! transport=”http://schemas.xmlsoap.org/soap/http” />
! ! <operation>
! ! ! <soap:operation soapAction=”http://wxample.com/getTerm” />
! ! ! <input><soap:body use=”literal” /> </input>
! ! ! <output><soap:body use=”literal” /></output>
! ! </operation>
! </binding>
The binding element has two attributes:

• name: The name you want to call the port
• type: the port you want to binding.
The soap:binding element has two attributes:

• Style: it can be “rpc” or “document”.
• Transport: Defines the SOAP protocol to use.
The soap:operation element defines each operation that the port exposes
for each operation the corresponding SOAP action has to be defined. You must also
specify how the input and output are encoded.
5. WSDL and UDDI

UDDI means “Universal Description, Discovery and Integration”.
UDDI is a directory fo restoring information about web services.
UDDI is a directory of web service interfaces described by WSDL.
UDDI communicates via SOAP

Nonfunctional Description in WSDL (Building Web services with JAVA)

Page 214
1. Policies
No part of WSDL natively describes things like security headers, reliable messaging
capabilities, and so on. To complete a well-defined service, you augment WSDL with extra
information.
Another reason to associate a WSDL with this extra information is to help the requestor
make an appropriate choice of service.
WS-Policy is one common way to express policy information in a service description.
The WS-Policy family of specifications has three major components:

• The framework
• The assertions
• The attachment
The basic component of the policy framework is a policy assertion.

The policy assertion describe certain qualities of service such as reliability of messaging.
Example:
! <wsrm:DeliveryAssurance Value=”wsrm:ExactlyOnce” />
Youʼll also see policy assertions in security (e.g., digital signature in web service)
WS-Policy itself doesnʼt define any policy assertions.
Policy assertions are grouped together to form a policy.
A policy forms a named group of policy assertions.

The policy assertions can be referenced by other XML and Web services components.
They use standard XML mechanisms,
One common form of reference mechanism is the way by which a policy is associated
(attached) to a policy subject. The specification called WS-PolicyAttachments describes
how policies are associated with policy subjects.
2. WS-Policy
Definition framework is a named collection of policy assertions.

The framework is defined y the WS-Policy.
The framework can be referenced by other component.s
The framework has three pieces:

• An XML element: container of policy assertion(s)
• A set of XML elements: how the policy assertions grouped by the container are to be
combined
• A set of standard XML attributes: They may be associated with policy assertions.
There is two standard mechanisms by which a policy can be named:

• by XML QName (recommender if you are using WSDL)
• by URI
The general form of the policy container element appears as follows:
Syntaxis:
! <wsp:Policy ((Name=” ” TargetNamespace=” “?) | Id=” ”)>
! ! <policy specific assertion> *
! ! <policy-specific security> ?
! </wsp:Policy>
You need to name a policy using:

• Name and TargetNamespace attributes (QName) or
• id (a local name and is combined with the XML base of the document containing the
policy element to form a URI to the policy)
Policy assertions are normally added to the policy container as independent entities.
2.1 Policy Operators

There are four operators:
• All
• ExactlyOne
• OneOrMore
• Policy
2.1.1 All
Example:
! <wsp:Policy name=”PolicyExample1”
! ! TargetNamespace=”http://ww.skatestown.com/policies” >
! ! <wsp:all>
! ! ! <Assertion:A />
! ! ! <Assertion:B />
! ! ! <Assertion:C />
! ! </wsp:all>
! </wsp:Policy>
Defines a policy named PolicyExample in the http://www.skatestown.com/policies

namespace. This policy states that all of the assertions A, B, and C are in effect.
Definition: Policy assertion to be in effect: The policy assertion is entirely dependent on

the domain of each one and the policy subject to which the policy is attached.
2.1.2 ExactlyOne
Example:
! ! TargetNamespace=”http://www.skatestown.com/policies” >
! ! <wsp:ExactlyOne>
! ! ! <Assertion: A />
! ! ! <Assertion:B />
! ! ! <Assertion:C />
! ! </wsp:ExactlyOne>
! </wsp:Policy>
Defines a policy named PolicyExample2 in the http://www.skatestown.com/policies

namespace in which ONLY ONE of the assertions A, B and C is effect.
2.1.3 OneOrMore
The operator OneOrMore is a variation of the combination of ExactlyOne and ALL, where
some subset of the policy assertions listed as child element is in effect.
2.1.4 Others
The operators can nest. Any of the Assertion elements can be replaced by an operator.
2.2 Policy Usage and Preference
2.2.1 Usage
The usage attribute describes how the policy assertion is to be interpreted in the context of
the policy.
The usage attribute can take any of the following values:

• Required: Must apply. e.g., digital signature
• Rejected: must NOT apply. e.g., If you explicitly donʼt want to receive encrypted
messages
• Optional: May apply. e.g., the WS could accept digital signatures
• Observed: The usage is informational in nature. It just give some kind of information
• Ignored: Informal. If something happens, no error message nor other action be taken by
the Web service
2.2.2 Preference
This attribute is usually used in conjunction with the ExactlyOnce operator.

If there is a choice between a set of policy assertions, this attribute can act as a hint to the
requestor.
The value of the Preference attribute is an integer value. The higher the number, the
stronger the preference.
Example:
! ! TargetNamespace=”http://www.skatestown.com/policies” >
! ! ! <Assertion:A wsp:Preference=”100” />
! ! ! <Assertion:B wsp:Preference=”50” />
! ! ! <Assertion:C wsp:Preference=”1” />
! </wsp:Policy>
Suggest to the requestor that it has a choice of assertion A, B or C, and that the service
provider would much prefer the requestor to choose assertion A.
3. Referencing Policies
WS-Policy defines an element called PolicyReference that allows you to include the
content of one policy into another.
The PolicyReference element can appear anywhere a policy assertion can.
The PolicyReference element refers (QName or URI) to another policy.
The included policy element are wrapped with an ALL operator element and inserted in
place of the PolicyReference element.
Example:
! <ws:Policy name=”PolicyExample4”
! ! TargetNamespace=”http://www.skatestown.com/policies”
! ! xmlns:tns=”http://www.skatestown.com/policies” >
! ! <wsp: ExactlyOne>
! ! ! <wsp:PolicyReference Ref=”tns_PolicyExample2” />
! ! ! <Assertion:D />
! ! ! <Assertion:E />
! </wsp:Policy>
is Equivalent to
! <wsp:Policy name=”PolicyExmaple4”
! ! TargetNamespace=”http://ww.skatestown.com/policies” >
! ! ! <wsp:All>
! ! ! ! <wsp:ExactlyOne>
! ! ! ! ! <Assertion:A />
! ! ! ! ! <Assertion:B />
! ! ! ! ! <Assertion:C />
! ! ! ! </wsp:ExactlyOne>
! ! ! </wsp:All>
! ! ! <Assertion:D />
! ! ! <Assertion:E />
! </wsp:Policy>
4. Policy Assertions
You choose from these standardized policy assertions, configure them, and combine them
into a policy document.
There are four standart policy assertions:

• Text Encoding: To declare the character set used for the text
• Language Assertion: To declare the human language expected in messages
• Spec assertion: To declare the version of a particular technical specification of a Web
service is compliant with. e.g., version of a security specification
• Message predicate: It let you be detailed about exact content of a message going into
or coming out of a Web service. The content of the message are described using a
pattern, typically using the XPath language.
5. Policy Attachments
A policy can be associated with a policy subject in one of two ways:

• As part of the subjectʼs definition. (for example, within a WSDL document) or
• external to the subjectʼs definition.
Example:
! <wsp:Policy name=”SkatestownLanguages”
! ! TargetNamespace=”http://www.skatestown.com/policies”>
! ! <wsp:OneOrMore>
! ! ! <wsp:Language Language=”en” />
! ! ! <wsp:Language Language=”es” />
! ! ! <wsp:Language Language=”fr” />
! ! </wsp:OneOrMore>
! </wsp:Policy>
In this example, the policy of the language expected with SkatesTownʼs services can be
English, Spanish, or French.
This policy could then be referenced from within the PriceCheck service declaration, using
a WS-PolicyAttachment attribute:
Example:
! <service name=”PriceCheck”
! ! wsp:PolicyRefs=”stp:SkatestownLanguages”
! ! xmlns:wsp=”http://schemas.xmlsoap.org/ws/2002/12/policy”
! ! xmlns:stp=”http://www.skatestown.com/policies” >
! ! <port name=”PriceCheck” binding=”pc:PriceCheckSOAPBinding”>
! ! ! <documentation>
! ! ! ! <wsi::Claim conformsTo=”http://ws-i.org/profiles/basic/1.0” />
! ! ! </documentation>
! ! ! <soap:address location=”http://www.skatestown.com/services/
PriceCheck” />
! ! </port>
! </service>
The policies can be inherited with a collection of WSDL elements. For example, a policy
attached to a portTYep would be inherited by its input, output, and fault child element.
Definition: Effective policy: It defines the policy associated with a WSDL.
The policyAttachment element is defined to allow you to express the attachment of one or
more policies to a policy subject.
WSDL (Web Services Description Language) by Matskin lecture 4
1. Introduction
For serve services between the server and the client, there are still few questions:
• How to know what kind of messages send to a service?

• What XML to put into the body?
• What format the response message might come in?
• Where the response to be expected
• What message protocol to use?
• What network address to send message to?
2. What should service describe

The WSDL defines:
• Data type - Types
• How a service is accessible - portType
• Interface information - portType
• What service does - Operations
• Binding information - binding
• Address information - service
• Where a service is located - service
3. Web service description components
The WSDL has these components:

• Definitions: Root WSDL Element
• Types: What data types will be transmitted
• Message: What messages will be transmitted
• portType (interface in WSDL 2.0): What operations (functions) will be supported
• binding: How will the message be transmitted on the wire? What SOAP-specific details
are there?
• service:
• port (endPoint in WSDL 2.0): Where is the service located
Additional elements:
• Documentation: Used to provide human-readable documentation and can be included
inside any other WSDL element
• import: Used to import other WSDL documents or XML Schemas.
3.1 Definitions
The root element of WSDL document
Contains all other WSDL element
3.2 Message
Each message element can be used as an input, output or fault message
All message element must have a unique name in the WSDL document
Example
! <message name=”PriceCheckResponse”>
! ! <part name=”result” element=”avail:StockAvailability” />
! </message>
In the message we can use element cause WSDL can use any type.
In this case, element=”avail:StockAvailability” is putted as the body of the message
Example2:

! <message name=”StockAvailableExpirationNotification”>
! ! <part name=”timeStamp” type=”xsd:timeInstant” />
! ! <part name=”correlationID” type=”reg:correlationID” />
! ! <part name=”items” type=”reg:ArrayOfItem” />
! ! <part name=”clientArg” type=”xsd:string” />
! </message>
3.3 portType
Describes an interface to a Web service
Typically a WSDL document contains a single portType
3.4 Operations
Defines a method on a Web service
Names should be different with the names of portTypes
Example:
! <portType name=”Hello_PortType”>
! ! <operation name=”sayHello”>
! ! ! <input message=”tns:SayHelloRequest” />
! ! ! <output message=”tns:SayHelloResponse” />
! ! </operation>
! </portType>
3.5 Binding
The binding element itself specifies name and type attributes.
The type attribute references the portType defined earlier in the document.
3.5.1 SOAP binding
soap:binding: It specifies the style and the transport of the SOAP message
soap:operation: The binding of a specific operation to a specific SOAP implementation
soap:body: To specify the details of the input and output messages.
Example of soap:body
! <input>
! ! <soap:body use=”literal” />
! </input>
In this case, the use of literal will return the follow soap message:
<?xml version=”1.0” encoding=”UTF-8” ?>

<soapenv:Envelope
! xmlns:soapenv=”http://schemas.xmlsoap.org/soap/envelope/”
! xmlns:xsd=”http://www.w3.org/2001/XMLSchema”
! xmlns:xsd=”http://www.w3.org/2001/XMLSchema-instance”>
! <soapenv:body>
! ! <sku xmlsn=”http://www.skatestown.com/ns/availability”>
! ! ! 123
! ! </sku>
! </soapenv:body>
</soapenv:Envelope>
3.6 Service
Specifies location of a service
Example:
! <service name=”Hello_Service”>
! ! <documentation>
! ! ! WSDL File for HelloService
! ! </documentation>
! ! <port binding=”Hello_Binding” name=”tns:Hello_PortType”>
! ! ! <soap:address location=”http://localhost:8080/soap/servlet/rcrouter”>
! ! </port>
! </service>
4. WSDL Extensions
We can use “get” operations of HTTP to get the URL
Example:
! <binding name=”priceCheckHTTPGetBinding” type=”pc:priceCheckPortType”>
! ! <http:binding verb=”GET” />
! ! <operation name=”checkPrice”>
! ! ! <http:operation location=”checkPrice” />
! ! ! <input>
! ! ! ! <http:urlEncoded/>
! ! ! </input>
! ! ! <output>
! ! ! ! <mime:content type=”text/xml” />
! ! ! </output>
! ! </operation>
! </binding>
To use this method, we can use the URL:
http://www.skatetown.com/checkPrice?sku=xxx1234
5. WSDL and Java

PortType maps into Java interface and name of portType is typically name of interface.
Example:
! public interface PriceCheckPortType extends java.rmi.Remote {...}
Package named from targetNamespace of definitions element
Example:
! package com.skatestown.www.services.PriceCheck;
For each operation a public method is declared as a part of interface

The signatura is built from operation name, input, output and fault element (faults are
included as exceptions)
Example:
! public com.skatestown.www.ns.avualability.AvailableType
! ! checkPrice(java.lang.String sku) throws java.rmi.RemoteException;
For messages referred by parameters elements, for comlexTypes it will generate a

separate class. The name of class is taken from the name of type of element. The
package for the class from targetNamespace of XML Schema that defines the type or
element.
Binding generates a stub class. The name of binding will be uses as the name of the class;
the package will get from the targetNamespace of the definition element.
Service generates interface and class.
6. Non-functional description (page 48)

WSDL functional description:
• How? What? Service interface
• Where? Service implementation
WSDL non-functional description:

• WS-Security
• WS-Policy (Service policy)
7. WS-Policy (page 49)
The WS-Policy family of specifications has three major components

• The framework
• The assertions
• The attachment
Example of assertion:
!
! <wsrm: DeliveryAssurances Value=”wsrm:ExactOnce” />
! <wsrm: Integrity wsp:Usage=”wsp:Required”>
! ....
! </wsrm:Integrity>
The WS policy framework is an XML element.

The WS policy framework act as a container of policy assertions.
The WS policy framework describe how the policy assertions in the container to be
combined
The WS policy framework contain a set of standard XML attributes that may be associated
with policy assertions.
7.1 Policy operators (see “Building web services with Java”)

7.2 Usage (see “Building web services with Java”)
7.3 Preference (see “Building web services with Java”)
7.4 Referencing (see “Building web services with Java”)
7.5 WS-Policy document

The structure of the normal form of WS-Policy is this:
<wsp:Policy ...>
! <wsp: ExactlyOne>
! ! [<wsp:All> [ <assertion ...> ... </assertion> ] *
! ! </wsp:All> ]*
! </wsp:ExactlyOne>
</wsp:Policy>
Then, we can have some operations like Normalization, Merging and Intersection that
helps a document or documents to be normalized.
7.5.1 Normalization
Example:
! <wsp:Policy ...>
! ! <wsp:All>
! ! ! <wsp:ExactlyOne>
! ! ! ! <nsSecurityAssertion wsp:Optional=”true” />
! ! ! ! <nsReliableMessagingAssertion />
! ! ! </wsp:ExactlyOne>
! ! ! <nsTransactionAssertion />
! ! ! <nsAuditAssertion />
! ! </wsp:All>
! </wsp:Policy>
After the normalization, it will be like

!
! <wsp:Policy ...>
! ! ! <wsp:All>
! ! ! ! <nsSecurityAssertion/>
! ! ! ! <nsTransactionAssertion />
! ! ! ! <nsAuditAssertion />
! ! ! </wsp:All>
! ! ! <wsp:All>
! ! ! </wsp:All>
! ! ! <wsp:All>
! ! ! </wsp:All>
! </wsp:Policy>
7.5.2 Merge
With this operation we merge two document into one.

Example:
! Policy P1
! <wsp:Policy wsu:id="P1"...>
! ! ! <wsp:All>
! ! ! </wsp:All>
! ! ! <wsp:All>
! ! ! ! <nsReliableMessagingAssertion/>
! ! ! </wsp:All>
! </wsp:Policy>
! Policy P2
! <wsp:Policy wsu:id=”P2” ...>
! ! ! <wsp:All>
! ! ! </wsp:All>
! ! ! <wsp:All>
! ! ! </wsp:All>
! </wsp:Policy>
The result is:
! <wsp:Policy wsu:Id=”P1_Merged_with_P2” ...>

! ! ! <wsp:All>
! ! ! </wsp:All>
! ! ! <wsp:All>
! ! ! ! <nsSecurityAssertion />
! ! ! ! <nsAuditassertion />
! ! ! </wsp:All>
! ! ! <wsp:All>
! ! ! </wsp:All>
! ! ! <wsp:All>
! ! ! ! <nsReliablemessagingAssertion />
! ! ! </wsp:All>
! </wsp:Policy>
7.5.3 Intersection
Example:

! Service provider policy

! <wsp:Policy wsu:Id=”Provider_Policy” ...>
! ! ! <wsp:All>
! ! ! ! <nsSecurityAssertion level=”high” />
! ! ! </wsp:All>
! ! ! <wsp:All>
! ! ! ! <nsSecurityAssertion level=”medium” />
! ! ! </wsp:All>
! </wsp:Policy>
! Service requestor policy

! <wsp:Policy wsu:Id=”Requester_Policy” ...>
! ! ! <wsp:All>
! ! ! ! <nsSecurityAssertion />
! ! ! ! <nsReliableMessagingAssertion timeout=”100” />
! ! ! ! <nsReliableMessagingAssertion retries=”3” />
! ! ! </wsp:All>
! </wsp:Policy>
Result:
! <wsp:All>
! ! <nsSecurityAssertion level=”high” />
! ! <nsSecurityAssertion />
! ! <nsReliableMessagingAssertion timeout=”100” />
! ! <nsReliableMessagingAssertion retries=”3” />
! ! <nsReliableMessagingAssertion />
! </wsp:All>
7.6 Special Policy
7.6.1 Empty policy:
! <wsp:Policy ...>
! ! ! <wsp:All />
! </wsp:Policy>
7.6.2 Null policy
! <wsp:Policy ...>
! ! <wsp:ExactlyOne />
! </wsp:Policy>
7.7 Standard Assertions (see “Building web services with Java”)

7.8 Attachments (see “Building web services with Java”)
8. WSDL 2.0 vs WSDL 1.1 (page 69)
The new version of WSDL:

• has remove ambiguity
• is more simply
• has new functions
• has remove unnecessary functionality
8.1 Interface
Interface replaces portType
Now the interface could be extended:
Example:
! <interface name=”StockAvailableNotification” extends=”sa:Notification ” ...>

! ! <operation name=”unregistration” ...>
New attribute: styleDefault. Applied to all the child operations in interface.
8.2 Operation
Now itʼs possible define message exchange pattern

The message exchange pattern can be specified in the style attribute. (in-out, in-only, ...)
Example:
! <interface name=”PriceCheck”>
! ! <operation name=”checkPrice”
! ! ! style=”http://www.w3.org/2003/11/wsdl/in-out”>
! ! ! ....
! ! </operation>
! </interface>
The message and part elements are eliminated.
Example:
! Using:
! <input message=”avail:sku” />
! instead of
! <input message=”pc:priceCheckRequest” />
! <message name=”PriceCheckRequest”>
! ! <part name=”result” element=”avail:sku” />
The fault element is divided into infault and outfault
With WSDL 2.0, the interface will look like this:

Example:
! ! <operation name=”checkPrice”
! ! ! ! style=”http://www.w3.org/2003/11/wsdl/in-out” >
! ! ! <input message=”avail:sku” />
! ! ! <output message=”avail:StockAvailability” />
! ! </operation>
! </interface>
! ! !
8.3 Types
Clarifies contents of types as either XML schema element or XML import element
8.4 Binding
Replace SOAP 1.1 binding type with SOAP 1.2 type
The binding is also used to bind features and properties that are specified for an interface.
For example, if an interface specified that an authentication features is being used, a
binding can specify that this feature is realized by some form of Kerberos ticket that must
be presented as proof of identity of authenticate the requestor.
The binding of operations changed due to changes in operations at the interface level.
8.5 endpoint and service
Renaming port by endpoint.
Added interface attribute specifying which interface is implemented by the service.
Example:
! <service name=”PriceCheck” interface=”pc:PriceCheck”>

! ! <endpoint name=”PriceCheck” binding=”pc:PriceCheckSOAPBinding”>
! ! ! <soap:address
! ! ! ! location=”http://www.skatestown.com/services/PriceCheck” />
! ! </endpoint>
! </service>
All endpoints (was port) child elements must refer (via binding) to the same interface
8.6 Definitions
The name attribute is removed from definitions
8.7 import and include
The import in WSDL 1.1 now is divided into import and include.
The import element is used to import WSDL definitions from other WSDL namespaces.
The include element is used to include elements defined in import and include, but with
the same namespace.
8.8 Example of WSDL 2.0

<?xml version=”1.0” encoding=”UTF-8”?>

! <definitions
! ! targetNamespace=”http://www.skatestown.com/services/PriceCheck”
! ! xmlns:pc=”http://www.skatestown.com/services/PriceCheck”
! ! xmlns:avail=”http://www.skatestown.com/ns/availability”
! ! xmlns:xsd=”http://www.w3.org/2001/XMLSchema”
! ! xmlns:soap=”http://www.w3.org/2003/11/wsdl/soap12”
! ! xmlns:wsdl2=”http://www.w3.org/2003/11/wsdl”
! ! xmlns=”http://www.w3.org/2003/11/wsdl”>
! !
! ! 
! ! <types>
! ! <xsd:schema
! ! ! targetNamespace=”http://www.skatestown.com/ns/availability”
! ! ! xmlns:xsd=”http://www.w3.org/2001/XMLSchema”>
! ! ! <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>
! ! <operation name=”checkPrice”>
! ! ! style=”http://www.w3.org/2003/11/wsdl/in-out”>
! ! ! <input message=”avail:sku”/>
! ! ! <output message=”avail:StockAvailability”/>
! ! </operation>
! </interface>
! <binding name=”PriceCheckSOAPBinding” type=”pc:PriceCheck”>

! ! <soap:binding
! ! ! protocol=”http://www.w3.org/2003/05/soap/bindings/HTTP/” />
! </binding>
! <service name=”PriceCheck” interface=”pc:PriceCheck”>

! ! <endpoint name=”PriceCheck” binding=”pc:PriceCheckSOAPBinding”>
! ! ! <soap:address
! ! ! ! location=”http://www.skatestown.com/services/PriceCheck”/>
! ! </endpoint>
! </service>
</definitions>

PWS Lecture 4. WSDL

Încărcat de

Informații document

Descriere originală:

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

PWS Lecture 4. WSDL

Încărcat de

Drepturi de autor:

Formate disponibile

Programming Web Services - Lec. 4 WSDL!

WSDL (Web Services Description Language)

WSDL is written in XML

• <types>: The data types used by the web service

Main structure of a WSDL document:

2.1 WSDL Ports <portType>

V 1.1 Last modification: 28/05/2010! Page 1

2.2 WSDL Messages <message>

The <message> element defines the data elements of an operation.

Each message can consist of one or more parts.

The parts can be compared to the parameters of a function call in a traditional

2.3 WSDL Types <types>

2.4 WSDL Bindings <binding>

GlossaryTerms: The name of a port

Compared to traditional programming

3.1 Operation Types

• One-way: The operation <- message

• Request-response: The operation <- request

• Solicit-response: The operation -> request

• Notification: The operation -> message

3.2 One-way Operation

3.3 Request-Response Operation

! <binding type=”glossaryTerms” name=”b1”>

The binding element has two attributes:

The soap:binding element has two attributes:

5. WSDL and UDDI

V 1.1 Last modification: 28/05/2010! Page 4

Nonfunctional Description in WSDL (Building Web services with JAVA)

WS-Policy is one common way to express policy information in a service description.

The WS-Policy family of specifications has three major components:

The basic component of the policy framework is a policy assertion.

! <wsrm:DeliveryAssurance Value=”wsrm:ExactlyOnce” />

WS-Policy itself doesnʼt define any policy assertions.

Policy assertions are grouped together to form a policy.

A policy forms a named group of policy assertions.

Definition framework is a named collection of policy assertions.

The framework has three pieces:

There is two standard mechanisms by which a policy can be named:

The general form of the policy container element appears as follows:

You need to name a policy using:

2.1 Policy Operators

Defines a policy named PolicyExample in the http://www.skatestown.com/policies

Definition: Policy assertion to be in effect: The policy assertion is entirely dependent on

Defines a policy named PolicyExample2 in the http://www.skatestown.com/policies

2.2 Policy Usage and Preference

The usage attribute can take any of the following values:

This attribute is usually used in conjunction with the ExactlyOnce operator.

The PolicyReference element can appear anywhere a policy assertion can.

The PolicyReference element refers (QName or URI) to another policy.

There are four standart policy assertions:

A policy can be associated with a policy subject in one of two ways:

Definition: Effective policy: It defines the policy associated with a WSDL.

WSDL (Web Services Description Language) by Matskin lecture 4

• How to know what kind of messages send to a service?

2. What should service describe

3. Web service description components

The WSDL has these components:

V 1.1 Last modification: 28/05/2010! Page 10

3.5.1 SOAP binding

<?xml version=”1.0” encoding=”UTF-8” ?>

To use this method, we can use the URL:

5. WSDL and Java

Package named from targetNamespace of definitions element