 |
|
|
Abstract
The abstract was not available at the time the proceedings were created. Please check an updated version of the paper abstracts at the conference proceedings web site.
Table of Contents
Web Services provides the ability to exchange XML messages between Web Services actors across the Web. HTTP 1.1 and SOAP 1.2 gives a framework and a processing model to treat those messages and the meta information that come wit it (security, privacy, ...). However, an application cannot guess in advance what are the information going in and out of a Web service without having a prior description. The goal of WSDL is to provide the description of the XML messages to the developers and an extensible model to allow the addition of meta information to be described as well. This document introduces the reader to the major concept of WSDL 2.0.
Messages have been exchange on the Web for years and people have been able to build applications to use those information. However, embedding those informations into HTML/XHTML documents implies following the HTML/XHTML DTDs and people came up with rules to encode a specific information in lots of different ways.
<h1>Temperature</h1> <p>The current temperature in Cambridge MA is 57ºF.</p>
Figure 1. HTML fragment
The advantage of such approach is to provide a user interface to the human consumers. The goal of Web Services is to expose the information in a more convenient "machine processable" way:
<temperature xmlns='http://www.example.org/weatherforecast'>
<location>
<country>USA</country>
<state>MA</state>
<city>Cambridge</city>
</location>
<date>2003-10-01T15:35:28Z</date>
<value xsi:type='FahrenheitDegree'>57</value>
</temperature>
Figure 2. XML Message
The XML message makes the processing of the content more convenient. The information regarding the city and the temperature are embedded into separate markups, including the current date. Also, the information is typed: as long as the application knows about the schema associated with the document, it can validate its input using a schema processor:
<xs:schema targetNamespace="http://www.example.org/weatherforecast"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="http://www.example.org/weatherforecast"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<simpleType name="FahrenheitDegree">
<xs:restriction base='xs:decimal'/>
</simpleType>
<xs:element name="location">
<xs:complexType>
<xs:sequence>
<xs:element name="country" type="xs:string"/>
<xs:element name="state" type="xs:string"/>
<xs:element name="city" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="temperature">
<xs:complexType>
<xs:sequence>
<xs:element ref="location"/>
<xs:element name="date" type="xs:dateTime"/>
<xs:element name="value" type="FahrenheitDegree"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
Figure 3. XML Schema
[WSDL Version 2.0: Core] describe a service from the point of view of the service itself. Messages are going in (input message) and out (output message). A succession of messages going in and out is called an exchange and are classified using message patterns. Unlike WSDL 1.1, [WSDL Version 2.0: Message Patterns] carefully describe the sequence, direction (in or out) and cardinality of the messages that are involved in the exchange, as well as identifying the parties involved.
| In-Only |
There is only one input message sent from a node N to the service. No faults are allowed. |
| In-Out |
There is one input message sent from a node N to the service and, in order, one output message sent from the service to the node N. The output message can be replaced by a fault message going in the same direction. |
| Out-Only |
There is only one output message sent from the service to a node N. No faults are allowed. |
| Out-In |
There is one output message sent from a node N to the service and, in order, one input message sent from the service to the node N. The input message can be replaced by a fault message going in the same direction. |
A service can support more than one exchange of messages. You can set a temperature (In-Only) or get a temperature (In-Out). The description language regroups each exchange into a group, called operation. A set of operations are then logically regrouped into an interface:
<interface name="Temperature">
<operation name='set'>
<input element='temperature'/>
</operation>
<operation name='get'>
<input element='location'/>
<output element='temperature'/>
</operation>
</interface>
Figure 4. operations and interface
An interface can reuse the definitions of operations from other interfaces using the derivation mechanism, but operation overloading is not allowed.
To ensure the connection between the XML messages world and programming languages, WSDL 2.0 has the concept of operation style. Restrictions are applied to the operation when a style is in effect. Procedures are described using the RPC style, while attributes are described using the concept of Set-Attribute and Get-Attribute. As an example, an attribute is said to be read-write if it has corresponding set-attribute and get-attribute operations.
The introduction of this article brings up the concept of meta-information that go along with the XML message. Security or privacy are two examples of meta-information that can be attached along to the message:
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
...
<Reference>
<Transforms>
<Transform
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>MC0CFFrVLtRlk=...</SignatureValue>
</Signature>
Figure 5. XML Signature
Meta-information are usually treated separately in the protocols. Both HTTP/1.1 and SOAP/1.2 have the concepts of headers for example. WSDL operations represents this concept using the headers attribute:
[WSDL Version 2.0: Bindings] provides two ways to transport between the service and the nodes: SOAP 1.2 over HTTP 1.1 [SOAP Version 1.2 Part 1: Messaging Framework], and HTTP 1.1 only [IETF RFC 2616]. SOAP 1.2 defines a messaging framework along with a processing model. Like WSDL 2.0, it provides an extensible model and uses XML. HTTP 1.1, while having the concept of headers like SOAP 1.2, does not define a processing model and, more importantly, does not use an XML syntax even if there is an extensibility model. Therefore, when using extensions such as XML Signature or XML Encryption, using SOAP 1.2 is a requirement for a Web service. HTTP 1.1 only can still be used for other usage that don't require using complex extensions or when dealing with existing Web applications that cannot understand with SOAP 1.2.
WSDL 2.0 provides the necessary description of XML messages, simple exchanges between a service and a node, the transport in use, and the locations of the service. Its extensibility model provides the ability to include more descriptions related to the service, such as what security mechanisms or privacy requirements are in use. The next step is to define the constraints and capabilities of one or more Web services, beyond the scope of simply defining the definitions of XML messages.
[IETF RFC 2616] Hypertext Transfer Protocol -- HTTP/1.1, R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, Authors. Internet Engineering Task Force, June 1999. Available at http://www.ietf.org/rfc/rfc2616.txt
[SOAP Version 1.2 Part 1: Messaging Framework] SOAP Version 1.2 Part 1: Messaging Framework, M. Gudgin, M. Hadley, N. Mendelsohn, J-J. Moreau, H. Frystyk Nielsen, Editors. World Wide Web Consortium, 24 June 2003. Available at http://www.w3.org/TR/soap12-part1/
[WSDL Version 2.0: Core] Web Services Description Language Version 2.0 Part 1: Core, R. Chinnici, M. Gudgin, J.J. Moreau, J. Schlimmer, and S. Weerawarana, Editors. World Wide Web Consortium, October 2003. Available at http://www.w3.org/TR/wsdl20
  |
Design & Development by deepX Ltd. |