web services description language cs409 application services even semester 2007
TRANSCRIPT
Web Services Description Language
CS409 Application ServicesEven Semester 2007
2
Web Service Requirements
• An industry standard web service :– Provide a service description, at least, a
WSDL document.– Capable of transporting XML documents using
SOAP over HTTP.– Be registered with a discovery agent.– Able to act as both the requestor and provider
of a service (optional).• e.g: provider asking for status information.
3
Service Description
• Description structure– Abstract: service interface definition.– Concrete: service implementation definition.– Supplementary definition.
• Service Definition = Abstract + Concrete.
• Service Description = Service Definition + Supplementary Definition.
4
Service Description (2)
abstract
concrete
Service Definition
supplementarydefinitions
Service Description
Fig 1. Description Structure
5
WSDL is …
• A format to precisely describe web service.
• Explain the syntax for the invocation of a web service.
• Explicate the expected response from a web service.
• An XML document adheres to the WSDL XML schema.
6
Role of WSDL
Integration Layer
BusinessRules
Data
Presentation Inte
grat
ion
Laye
r
BusinessRules
Data
Presentation
WSDLDocument
forApplication B
Application A Application B
WSDLDocument
forApplication A
Fig 2. WSDL Standpoint
7
WSDL Structure
• Abstract:
• Concrete:
• Supplemental:
portType import
message types
binding service
operation
documentation
8
WSDL Structure (2)
abstract
concrete
Service Definition
Fig 3. Relation of WSDL content and service definition
WSDL Document
<definition>
<portType name=“PriceCheck”>
. . .
</portType>
<message name=“PriceRequest”>
. . .
</message>
<service>
. . .
</service>
<binding name=“Bind1”>
. . .
</binding>
</definition>
9
WSDL Structure (3)
• Sample definitions and import:
<?xml version=“1.0” ?>
<definitions name=“PriceCheck”>
targetNamespace=“http://www.doddystore.com/services/PriceCheck”
xmlns:soap=“http://schemas.xmlsoap.org/wsdl/soap/”
xmlns:pcheck=“http://www.doddystore.com/services/PriceCheck”
xmlns:avail=“http://www.doddystore.com/ns/availability”
xmlns:wsi=“http://ws-i.org/schemas/conformanceClaim”
<import namespace=“http://www.amazon.com/BookPriceCheck”
location=“http://www.amazon.com/BookPrice/BookPriceCheck.wsdl” />
. . .
</definitions>
10
WSDL Structure (4)
• definition is the root element of WSDL.• Normally contains some XML namespace
declarations.• import makes available the definitions in
another WSDL document.• Useful for modularization of your WSDL
document– Separate abstract from concrete.– Maintain separate WSDL by its function but
present a complete definition all at once.
11
WSDL Structure (5)
• Sample portType and operation:
<portType name=“PriceCheckPortType>
<operation name=“checkPrice”>
<input message=“pcheck:PriceCheckRequest”>
<output message=“pcheck:PriceCheckResponse”>
<fault message=“pcheck:PriceCheckFaultMessage”>
</operation>
</portType>
12
WSDL Structure (6)
• A WSDL can contain zero or more portType.
• Each portType must have unique name.• Operation element define a combination
of input, output, and fault message.
13
WSDL Structure (7)
• Sample message:
<message name=“PriceCheckRequest”>
<part name=“sku” element=“avail:sku” />
</message>
<message name=“PriceCheckResponse”>
<part name=“result” element=“avail:StockAvailability” />
</message>
14
WSDL Structure (8)
• Message is the construct that describes the form of operation.
• WSDL can contain zero or more message elements.
• Each message must have unique name.
15
WSDL Structure (9)
• Sample types:<types>
<xsd:schema targetNamespace=“http://www.doddystore.com/ns/availability”
<xsd:element name=“StockAvailability” type=“avail:availabilityType”>
<xsd:element name=“sku” type=“xsd:string”>
<xsd:element name=“PriceCheckFaultMessage”>
<xsd:complexType>
<xsd:sequence>
<xsd:element name=“offending-value” type=“xsd:string” />
<xsd:element name=“conformance-rules” type=“xsd:string” />
</xsd:sequence>
</xsd:sequence>
</xsd:complexType>
</xsd:schema>
</types>
16
WSDL Structure (10)
• The types element is used to define user-defined XML types and elements, e.g.: any data types that are not described by XML schema built-in types (simple and complex).
• A WSDL document can have at most one types element.
17
WSDL Structure (11)
• Sample binding:<binding name=“PriceCheckSOAPBinding” type=“pcheck:PriceCheckPortType”>
<soap:binding style=“document” transport=“http://schemas.xmlsoap.org/soap” />
<operation name=“checkPrice”>
<soap:operation
soapAction=“http://www.doddystore.com/services/PriceCheck/checkPrice” />
<input>
<soap:body use=“literal” />
</input>
</output>
<soap:body use=“literal” />
</output>
</operation>
</binding>
18
WSDL Structure (12)
• The binding assigns portType and its operation into specific protocol and encoding style.
• It informs the service requestor how to format the message.
• Each portType can have more than one binding (so it could be invoked by several messaging/transport protocol).
19
WSDL Structure (13)
• Sample service:<service name=“PriceCheck”>
<port name=“PriceCheck” binding=“pcheck:PriceCheckSOAPBinding”>
. . .
<soap:address location=“http://www.doddystore.com/services/PriceCheck” />
</port>
</service>
20
WSDL Structure (14)
• Purpose of service is to group a set of related port.
• Group the port that related to the same portType but different binding.
• Group the port that related but different portType (not recommended).
21
WSDL Structure (15)
• Sample documentation:<service name=“PriceCheck”>
<port name=“PriceCheck” binding=“pcheck:PriceCheckSOAPBinding”>
<documentation>
<wsi:Claim conformsTo=“http://ws-i.org/profiles/basic/1.0” />
</documentation>
<soap:address location=“http://www.doddystore.com/services/PriceCheck” />
</port>
</service>
22
WSDL Structure (16)
• documentation provide useful human-readable information about the web service description.
• For example: to declare that the WSDL file is compliant with the WS-I basic profile, thus it is an interoperable description.
23
Web Service Interaction
• Roles in web service:– Service provider.– Service requestor.– Intermediary
• Receives request then forwards it to the provider.
– Initial sender.– Ultimate receiver.
24
Web Service Interaction (2)
• Message path:– The route along with a message travels.– Can be simple or dynamic.– Consist of: one initial sender, one ultimate
receiver, and zero or more intermediaries.
25
Web Service Interaction (3)
ServiceRequestor
Initial Sender
IntermediaryService
IntermediaryService
ServiceProvider
Ultimate Receiver
Message path
Fig 4. Simple Message Path
26
Web Service Interaction (4)• Correlation:
– Technique to match message sent along its paths.
– Normally used in request and response message exchange patterns.
• Choreography:– Rules in how a group of web services interact.– Including: sequence, condition for sequence,
usage patterns, etc.– Orchestration: implementation of choreography
in the business process context.
27
Web Service Interaction (5)
ServiceRequestor
Initial Sender
IntermediaryService
IntermediaryService
ServiceProvider
Ultimate Receiver
Correlation ID = 1001
Fig 5. Correlation
Correlation ID = 1001
28
Web Service Interaction (6)
ServiceRequestor
Initial Sender
IntermediaryService
ServiceProvider
Ultimate Receiver
Fig 6. Choreography
IntermediaryService
IntermediaryService
IntermediaryService
1 2
3a
3b
4 5
29
Message Exchange Patterns
• Categories:– Synchronous, request and response.– Asynchronous, fire and forget
• one-to-one and one-to-many (broadcast).
• Types of MEP:– Request/Response *.– One-Way *.– Notification.– Solicit/Response.* supported by J2EE
30
Message Exchange Patterns (2)
• Request/Response:– Client initiate by sending request message.– Provider replies with a response.– In WSDL, identified by operation section
that is declared with a single input element followed by a single output.
31
Message Exchange Patterns (3)
• One-Way Messaging:– Client sends a message but does not expect a
reply.– Also known as asynchronous messaging.– In WSDL, identified by operation section that
is declared with a single input but no output.
Example: <portType name=“SubmitPurchaseOrder_portType”>
<operation name=“SubmitPurchaseOrder”>
<input name=“order” message=“mh:SubmitPurchaseOrderMessage” />
</operation>
</portType>
32
Message Exchange Patterns (4)
• Notification:– Provider sends a message but doesn’t expect
a reply from the client.– Follows the push model of distributed
computing.– Client must register with the service to receive
the message (subscriber).– In WSDL, identified by operation section
that is declared with a single output but no input.
33
Message Exchange Patterns (5)
• Solicit/Response:– Similar to Notification, but the provider expects
a reply from the client.– Client must register with the service to receive
the message (subscriber).– In WSDL, identified by operation section
that is declared with a single output element followed by a single input (reverse of Request/Response).
34
Further Development
• WSDL 2.0– Consistency.– Better naming – Simplification– New functionality, e.g. interface extension.– Functionality removal.– Changes in interface, operation, binding, types,
service, import, and definitions.
35
WSDL 2.0
• Sample of changes:– portType becomes interface.– port becomes endPoint.– fault becomes inFault and outFault.– Interface could be extended.– Operation overloading has been removed.– New attribute: style and styleDefault to
define the MEP.– etc.
* Read “Building Web Services with Java” page 224 to 230 for more details about comparison between WSDL 1.1 and WSDL 2.0.
36
Some WSDL Resources
• WSDL 1.1: www.w3.org/TR/wsdl
• WSDL 2.0: www.w3.org/2002/ws/desc/wsdl20
• WS-Policy: www-106.ibm.com/developerworks/library/ws-polfram/
