This document describes extensions for the Web Services Description Language (WSDL) Version 2.0 . These extensions include Message Exchange Patterns (MEPs), features, SOAP modules, and bindings of features. The Working Group has discussed and approved these extensions, and recommends their use with the Web Services Description Language (WSDL).
This is a
Three formal objections from Working Group participants have been received against portions of the WSDL 2.0 specification. Feedback is specifically encouraged on these topics:
Compositors (see
Feature and properties (see
Requiring unique GEDs or required feature to
distinguish operations (see
A
This document has been produced as part of the
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document has been produced under the
Last Modified: $Date: 2004/08/03 17:10:41 $
Web Services Description Language provides a number of opportunities to extend the syntax and component model, as mandated by the needs of an application. This document defines and describes a number of these extensions, particularly message exchange patterns and features.
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119
Web Services Description Language (WSDL) message exchange patterns (hereafter simply 'patterns') define the sequence and cardinality of abstract messages listed in an operation. Message exchange patterns also define which other nodes send messages to, and receive messages from, the service implementing the operation. WSDL message exchange patterns describe the interaction at the abstract (interface) level, which may be distinct from the pattern used by the underlying protocol binding (e.g. SOAP Message Exchange Patterns).
By design, WSDL message exchange patterns abstract out specific message types. Patterns identify placeholders for messages, and placeholders are associated with specific message types by the operation using the pattern.
Unless explicitly stated otherwise, WSDL message exchange patterns also abstract out binding-specific information like timing between messages, whether the pattern is synchronous or asynchronous, and whether the message are sent over a single or multiple channels.
Like interfaces and operations, WSDL message exchange patterns do not exhaustively describe the set of messages exchanged between a service and other nodes; by some prior agreement, another node and/or the service may send other messages (to each other or to other nodes) that are not described by the pattern. For instance, even though a pattern may define a single message sent from a service to one other node, the Web Service may multicast that message to other nodes.
To maximize reuse, WSDL message exchange patterns identify a minimal contract between other parties and Web Services, and contain only information that is relevant to both the Web Service and another party.
This specification defines several message exchange patterns for
use with
WSDL patterns specify their fault propagation model using standard rulesets to indicate where faults may occur. The most common patterns for fault propagation are defined here, and referenced by patterns later in the document.
Generation of a fault, regardless of ruleset, terminates the exchange.
Any message after the first in the pattern MAY be replaced with a fault message, which MUST have identical cardinality and direction. The fault message MUST be delivered to the same target node as the message it replaces. If there is no path to this node, the fault MUST be discarded.
Any message, including the first, MAY trigger a fault message in response. Each recipient MAY propagate a fault message, and MUST propagate no more than one fault for each triggering message. Each fault message has direction the reverse of its triggering message. The fault message MUST be delivered to the originator of the message which triggered it. If there is no path to this node, the fault MUST be discarded.
No faults may be propagated.
WSDL patterns are described in terms of the WSDL component model, specifically the Message Label and Fault Reference components.
This pattern consists of exactly one message as follows:
A message:
indicated by a Message Label component whose {message label} is 'In' and {direction} is 'in'
received from some node N
This pattern uses the rule
An operation using this message exchange pattern has a {pattern} property with the value 'http://www.w3.org/2004/08/wsdl/in-only'.
This pattern consists of exactly one message as follows:
A message:
indicated by a Message Label component whose {message label} is 'In' and {direction} is 'in'
received from some node N
This pattern uses the rule
An operation using this message exchange pattern has a {pattern} property with the value 'http://www.w3.org/2004/08/wsdl/robust-in-only'.
This pattern consists of exactly two messages, in order, as follows:
A message:
indicated by a Message Label component whose {message label} is 'In' and {direction} is 'in'
received from some node N
A message:
indicated by a Message Label component whose {message label} is 'Out' and {direction} is 'out'
sent to node N
This pattern uses the rule
An operation using this message exchange pattern has a {pattern} property with the value 'http://www.w3.org/2004/08/wsdl/in-out'.
This pattern consists of one or two messages, in order, as follows:
A message:
indicated by a Message Label component whose {message label} is 'In' and {direction} is 'in'
received from some node N
An optional message:
indicated by a Message Label component whose {message label} is 'Out' and {direction} is 'out'
sent to node N
This pattern uses the rule
An operation using this message exchange pattern has a {pattern} property with the value 'http://www.w3.org/2004/08/wsdl/in-opt-out'.
This pattern consists of exactly one message as follows:
A message:
indicated by a Message Label component whose {message label} is 'Out' and {direction} is 'out'
sent to some node N
This pattern uses the rule
An operation using this message exchange pattern has a {pattern} property with the value 'http://www.w3.org/2004/08/wsdl/out-only'.
This pattern consists of exactly one message as follows:
message:
indicated by a Message Label component whose {message label} is 'Out' and {direction} is 'out'
sent to some node N
This pattern uses the rule
An operation using this message exchange pattern has a {pattern} property with the value 'http://www.w3.org/2004/08/wsdl/robust-out-only'.
This pattern consists of exactly two messages, in order, as follows:
A message:
indicated by a Message Label component whose {message label} is 'Out' and {direction} is 'out'
sent to some node N
A message:
indicated by a Message Label component whose {message label} is 'In' and {direction} is 'in'
sent from node N
This pattern uses the rule
An operation using this message exchange pattern has a {pattern} property with the value 'http://www.w3.org/2004/08/wsdl/out-in'.
This pattern consists of one or two messages, in order, as follows:
A message:
indicated by a Message Label component whose {message label} is 'Out' and {direction} is 'out'
sent to some node N
An optional message:
indicated by a MessageLabel component whose {message label} is 'In' and {direction} is 'in'
sent from node N
This pattern uses the rule
An operation using this message exchange pattern has a {pattern} property with the value 'http://www.w3.org/2004/08/wsdl/out-opt-in'.
Web Services Description Language (WSDL) features (hereafter 'features') define pieces of extended functionality which typically affect message exchanges. Examples may include "reliability", "security", or "correlation", among others. Features may be self-contained, or may be abstract, and thus expressed via bindings or SOAP modules. These components may expose settable properties, named variables which affect the behavior of one or more features, bindings or SOAP modules.
Features may change the behavior described for other components. In particular, note that a feature (or any other extension) may change the semantics of a message exchange pattern in some fashion, such as nominating an address for the delivery of faults, etc.
The Web Services Description Working Group provides the following predefined features and SOAP modules for two reasons - first, we encourage implementors to support these features as we believe they offer important functionality. Second, these specifications act as a model of how to write feature/module specs. Some further (SOAP-specific) examples can be found in the SOAP 1.2 spec, part 2.
This feature is identified with the URI 'http://www.w3.org/2004/08/wsdl/feature/AD'
This feature exists in order to enable the description of application-defined additional data declarations outside of the normal data channel (e.g. the SOAP body). The senders takes the value of the property 'http://www.w3.org/2004/08/wsdl/feature/AD/data', which is defined below, and passes it to the receiver in a manner to be defined by the particular bindings/modules implementing this specification.
This property is identified with the URI 'http://www.w3.org/2004/08/wsdl/feature/AD/data'.
The data property consists of a sequence of elements, each of which represents an individual piece of application data. Implementations of this feature must ensure that the runtime value of this property is correctly transferred from the sender to the receiver.
Here is an example of using the data property in a WSDL:
This example defines two pieces of application data, and associates them with the input message of the "reserveCar" operation. Notice that the "promotionalCode" element is optional (minOccurs="0").
You may choose to decorate your application data element declarations
with an attribute with the namespace
'http://www.w3.org/2004/08/wsdl/feature/AD' and the local name
"mustUnderstand". This indicates at the abstract level that the
particular element thus decorated is mandatory, and implementations of
this feature which support expression of mandatory data (i.e. the
Application Data SOAP Module, see
This module is identified with the URI 'http://www.w3.org/2004/08/wsdl/module/AD'
This module implements the feature
'http://www.w3.org/2004/08/wsdl/feature/AD' (see
This module specifies how to transmit "out of band" application data, as
defined in the Application Data feature (see
As a SOAP sender, if the property 'http://www.w3.org/2004/08/wsdl/feature/AD/data' has a value then each of the top-level child element information items in the value MUST be turned into a SOAP header. The elements are serialized according to their schemas, and if the "ad:mustUnderstand" attribute exists with the value "true" on any given element declaration, that particular SOAP header should be marked as "mustUnderstand='true'" or "mustUnderstand='1'" as per the SOAP specification. SOAP senders SHOULD also add an additional header, with namespace 'http://www.w3.org/2004/08/wsdl/module/AD' and local name "dataHeaders" - this header contains a list of element QNames, one for each application data header created in the first step.
It is the responsibility of the receiving node to determine which, if any, SOAP headers will populate the 'http://www.w3.org/2004/08/wsdl/feature/AD/data' property. Typically this will be accomplished via using some metadata, such as an understanding of a constraint specified in WSDL, or out-of-band agreements. If the "dataHeaders" SOAP header (described above) is present, the QNames inside that header indicate which other headers are application data. The contents of each SOAP header identified as application data will be placed in a child element of the data property.
This feature-binding is identified with the URI 'http://www.w3.org/2004/08/wsdl/feature/AD-HTTP'
This module implements the feature
'http://www.w3.org/2004/08/wsdl/feature/AD' (see
This section specifies how to transmit "out of band"
application data, defined in the
Application Data Feature (see
If the property 'http://www.w3.org/2004/08/wsdl/feature/AD/data' has a
value for a message to be serialized as an HTTP message, then
each of the top-level child
Only
Each such
The HTTP header name used is the
The HTTP header content is serialized from the
It is the responsibility of the receiving node to determine
which, if any, HTTP headers will populate the
'http://www.w3.org/2004/08/wsdl/feature/AD/data' property. Typically this
will be accomplished via some metadata, such as a
{property constraint} specified in
The local name of the
This document is the work of the
Members of the Working Group are (at the time of writing, and by alphabetical order): David Booth (W3C), Allen Brookes (Rogue Wave Softwave), Helen Chen (Agfa-Gevaert N. V.), Roberto Chinnici (Sun Microsystems), Ugo Corda (SeeBeyond), Glen Daniels (Sonic Software), Paul Downey (British Telecommunications), Youenn Fablet (Canon), Martin Gudgin (Microsoft Corporation), Hugo Haas (W3C), Hao He (The Thomson Corporation), Tom Jordahl (Macromedia), Jacek Kopecky (Digital Enterprise Research Institute (DERI)), Amelia Lewis (TIBCO Software, Inc.), Kevin Canyang Liu (SAP), Jonathan Marsh (Microsoft Corporation), Peter Madziak (Agfa-Gevaert N. V.), Josephine Micallef (SAIC - Telcordia Technologies), Jeff Mischkinsky (Oracle Corporation), Dale Moberg (Cyclone Commerce), Jean-Jacques Moreau (Canon), Mark Nottingham (BEA Systems, Inc.), David Orchard (BEA Systems, Inc.), Bijan Parsia (University of Maryland), Arthur Ryman (IBM), Adi Sakala (IONA Technologies), Jeffrey Schlimmer (Microsoft Corporation), Igor Sedukhin (Computer Associates), Jerry Thrasher (Lexmark), William Vambenepe (Hewlett-Packard Company), Asir Vedamuthu (webMethods, Inc.), Sanjiva Weerawarana (IBM), Ümit Yalçınalp (Oracle Corporation), Prasad Yendluri (webMethods, Inc.).
Previous members were: Lily Liu (webMethods, Inc.), Don Wright (Lexmark), Joyce Yang (Oracle Corporation), Daniel Schutzer (Citigroup), Dave Solo (Citigroup), Stefano Pogliani (Sun Microsystems), William Stumbo (Xerox), Stephen White (SeeBeyond), Barbara Zengler (DaimlerChrysler Research and Technology), Tim Finin (University of Maryland), Laurent De Teneuille (L'Echangeur), Johan Pauhlsson (L'Echangeur), Mark Jones (AT&T), Steve Lind (AT&T), Sandra Swearingen (U.S. Department of Defense, U.S. Air Force), Philippe Le Hégaret (W3C), Jim Hendler (University of Maryland), Dietmar Gaertner (Software AG), Michael Champion (Software AG), Don Mullen (TIBCO Software, Inc.), Steve Graham (Global Grid Forum), Steve Tuecke (Global Grid Forum), Michael Mahan (Nokia), Bryan Thompson (Hicks & Associates), Ingo Melzer (DaimlerChrysler Research and Technology), Sandeep Kumar (Cisco Systems), Alan Davies (SeeBeyond), Jacek Kopecky (Systinet), Mike Ballantyne (Electronic Data Systems), Mike Davoren (W. W. Grainger), Dan Kulp (IONA Technologies), Mike McHugh (W. W. Grainger), Michael Mealling (Verisign), Waqar Sadiq (Electronic Data Systems), Yaron Goland (BEA Systems, Inc.).
The people who have contributed to
Date | Author | Description |
---|---|---|
20040713 | aal | implement editorial changes requested after review by GlenD, in application data feature and module. |
20040713 | aal | address issues 233 & 112 all at once, by increasing level of all divs, adding new intro div, adding new div to contain features, renaming spec. Lotsa changes, what fun. |
20040713 | aal | s/Label/Message Label/g and s/{label}/{message label}/g. issue 230. |
20040713 | aal | replace "fault generation" with "fault propagation" (in almost all cases; one case of "generate" remains to indicate that it ends an exchange). issue 234. |
20040713 | aal | add language to introduction describing relationship between these MEPs and the MEPs defined by SOAP 1.2 (issue 232). This replaces the language found two items down (issue 191). |
20040713 | aal | add (hereafter, simply 'patterns') to intro (issue 231). |
20040610 | aal | add language to introduction describing relationship between these MEPs and the MEPs defined by SOAP 1.2 (issue 191). |
20040225 | aal | add in-optional-out per minutes of 20 feb 2004 telecon |
20040212 | aal | change {messageReference} to {label} and "Message Reference component" to "Label component" per 20040212 teleconference |
20040205 | aal | change all 'A' and 'B' message labels into 'Out' or 'In', depending upon direction. |
20040205 | aal | s/message pattern/message exchange pattern/gi |
20031204 | jcs | Removed change marks; note that some were on div2 tag and did not show when transformed into HTML. |
20031204 | jcs | Per 4 Dec 2003 telecon, decided to rename 'Asynchronous Out-In' pattern to 'Output-Optional-Input'. |
20031105 | aal | Fix titles of added patterns. Move them to be in conjunction with similar patterns. |
20031022 | aal | Per action item from October 16 teleconference, added the three patterns using message-triggers-fault as published on the mailing list (robust-in-only, robust-out-only, asynch-out-in). |
20031022 | aal | Added internal linkage (using specref) from patterns to the fault rulesets which they use. |
20031022 | aal | Per 9 and 16 Oct 2003 teleconferences, marked in-multi-out and out-multi-in patterns deleted. |
20031022 | aal | Per 16 Oct 2003 teleconference, added a paragraph/sentence stating that generation of a fault terminates an exchange. |
20031007 | JCS | Per 2 Oct 2003 teleconference, changed "broadcast" to "multicast" in the introduction. |
20030922 | JCS | Per 22 Sep 2003 meeting in Palo Alto, CA, removed "Pattern Review" editorial note; added specific editorial notes for In-Multi-Out and Out-Multi-In. |
20030911 | RRC | Changed the "name" property of the message reference component to "messageReference". |
20030904 | JCS | Incorporated clarifications suggested by W3C\David Booth. |
20030801 | JCS | Per 30 July meeting, added recommendations from patterns task force. |
20030612 | AAL | Added fault generation rulesets and references to them from patterns. |
20030313 | MJG | Changed to Part 2 ( from Part 3 ) |
20030306 | JCS | Proposed name for MEP7. |
20030305 | JCS | Per 4 Mar 03 meeting, renamed 'message exchange pattern' to 'message pattern' or 'pattern', added pattern for request-response, added ednote about review of patterns. |
20030217 | MJG | Fixed some issues with entities and validity errors WRT ulists |
20030212 | JCS | Initial draft |