WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. Web Services Description Language (WSDL) Version 2.0 Part 2: Adjuncts defines predefined extensions for use in WSDL 2.0:
Message exchange patterns
Operation styles
Bindings
This
specification depends on WSDL Version 2.0
This is a
This document is the result of the merge of WSDL 2.0 Part 2 Predefined Extensions and 3 Bindings.
The Working Group is in the process of addressing the comments
it has received on WSDL 2.0 Part 1, 2 and 3 during its Last Call
period. This document reflects the current state of this
work. The latest status of the last call issues received by the
Working Group can be found in the
Comments on this document are to be sent to the public
For a
detailed list of changes since the last publication of this
document, please refer to appendix
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: 2005/05/11 15:21:44 $ CET
The Web Services Description Language WSDL Version 2.0 (WSDL)
Message exchange patterns:
Operation styles:
Bindings:
A SOAP 1.2
An HTTP/1.1
WSDL 2.0 Primer
The Core Language
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 RFC2119
This specification uses a number of namespace prefixes throughout;
they are listed in
| Prefix | Namespace | Notes |
|---|---|---|
| wsdl |
|
A normative XML Schema |
| wsoap |
|
A normative XML Schema |
| whttp |
|
A normative XML Schema |
| xs |
|
Defined in the W3C XML Schema
specification |
Namespace names of the general form
All parts of this specification are normative, with the EXCEPTION
of pseudo-schemas, examples, and sections explicitly marked as
"Non-Normative". Pseudo-schemas are provided for each component,
before the description of this component. They provide visual help for
the XML
A
A node may be accessible via more than one physical address or transport.
Web Services Description Language (WSDL) message exchange patterns (hereafter simply
'patterns') define the sequence and 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; section
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. "Propagation" is defined as a best-effort attempt to transmit the fault message to its designated recipient.
WSDL patterns specify propagation of faults, not their generation. Nodes which generate a fault MUST attempt to propagate the faults in accordance with the governing ruleset, but it is understood that any delivery of a network message is best effort, not guaranteed. The rulesets establish the direction of the fault message and the fault recipient, they do not provide reliability or other delivery guarantees. When a fault is generated, the generating node MUST attempt to propagate the fault, and MUST do so in the direction and to to the recipient specified by the ruleset. However, extensions or bindings may modify these rulesets. For example, WS-Addressing defines a "FaultTo" address for messages, which is used in lieu of the recipient nominated by the ruleset.
Generation of a fault, regardless of ruleset, terminates the exchange.
Bindings, features, or extension specifications may override the semantics of a fault propagation ruleset, but this practice is strongly discouraged.
Any message after the first in the pattern MAY be replaced with a fault message, which MUST have identical 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/2005/05/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/2005/05/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/2005/05/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/2005/05/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/2005/05/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/2005/05/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/2005/05/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/2005/05/wsdl/out-opt-in'.
This section defines
The RPC style is selected by assigning to an Interface
Operation component's
In order to conform with the specification for the RPC style,
an Interface Operation Component MUST obey the constraints listed
below. Furthermore, if the
The RPC style MUST NOT be used for Interface Operation
components whose
The RPC style places restrictions for Remote Procedure
Call-types of interactions. When this value is used, the
associated messages MUST conform to the rules below,
described using XML Schema
If the Interface Operation component uses a
The content model of input and output
The input sequence MUST only contain elements and element wildcards. It MUST NOT contain other structures such as xs:choice. The input sequence MUST NOT contain more than one element wildcard. The element wildcard, if present, MUST appear after any elements.
The output sequence MUST only contain elements. It MUST NOT contain other structures such as xs:choice.
The sequence MUST contain only local element children. Note that these child elements MAY contain the following attributes: nillable, minOccurs and maxOccurs.
The local name of input element's QName MUST be the same as the Interface operation component's name.
Input and output elements MUST both be in the same namespace.
The complex type that defines the body of an input or an output element MUST NOT contain any attributes.
If elements with the same qualified name appear as children of both the input and output elements, then they MUST both be declared using the same named type.
The input or output sequence MUST NOT contain multiple children elements declared with the same name.
The
When present, the
{rpc-signature} REQUIRED. A list of pairs
The value of the {rpc-signature} property MUST satisfy the following conditions:
The value of the first component of each pair
For each child element of the input and output messages of the operation,
a pair
For each pair
For each pair
For each pair
For each pair
The function signature defined by a
Start with the value of the {rpc-signature} property, a (possibly empty) list of pairs of this form:
Filter the elements of this list into two lists, the first one
For ease of visualization, let's denote the two lists as
(L1)
and
(L2)
respectively.
Then, if the input sequence ends with an element wildcard, the formal signature of the function is
where
Otherwise the formal signature of the function is
i.e.
the list of formal arguments to the function is the direction the list of formal return parameters of the function is
each formal argument and formal return parameter is typed
according to the type of the child element identified by it
(unique per the conditions given above).
The
The XML representation for the RPC signature extension is an
A [local name] of
A [namespace name] of "http://www.w3.org/2005/05/wsdl/rpc"
The type of the
Additionally, each even-numbered item (0, 2, 4, ...) in the list
MUST be of type
A
| Property | Value |
|---|---|
| {rpc-signature} | A list of |
The URI style may be used for Interface Operation components using a message exchange pattern with an initial message.
The URI style is selected by assigning the Interface
Operation component's
Use of this value indicates that XML Schema
The content model of this element is defined using a complex type that contains a sequence from XML Schema.
The sequence MUST only contain elements. It MUST NOT contain other structures such as xs:choice.
The sequence MUST contain only local element
children. These child elements MAY contain the
0 or 1.
The localPart of the element's QName MUST be the same as the Interface operation component's name.
The complex type that defines the body of the element or its children elements MUST NOT contain any attributes.
The sequence MUST NOT contain multiple children element declared with the same local name.
If the children elements of the sequence are
defined using an XML Schema type, they MUST derive from
xs:simpleType, and MUST NOT be of the type
or derive from xs:QName,
xs:NOTATION, xs:hexBinary or
xs:base64Binary.
The Multipart style may be used for Interface Operation components using a message exchange pattern with an initial message.
The Multipart style is selected by assigning the Interface
Operation component's
Use of this value indicates that XML Schema
The content model of this element is defined using a complex type that contains a sequence from XML Schema.
The sequence MUST only contain elements. It MUST NOT contain other structures such as xs:choice.
The sequence MUST contain only local element
children. These child elements MAY contain the
1.
The localPart of the element's QName MUST be the same as the Interface operation component's name.
The complex type that defines the body of the element or its children elements MUST NOT contain any attributes.
The sequence MUST NOT contain multiple children element declared with the same local name.
The SOAP binding described in this section is SOAP version
independent ("1.2" as well as other versions) and an extension
for
As allowed in
The SOAP binding is designed with the objective of minimizing
what needs to be explicitly declared for common cases. This is
achieved by defining a set of default rules which apply for all
Interface Operation components of an Interface component, unless
specifically overidden on a per Interface Operation basis. Thus,
if a given Interface Operation component is not referred to
specifically, then all the default rules apply for that
component. That is, per the requirements of
Notice that there are no default binding rules defined for
A subset of the HTTP properties specified in the HTTP binding
defined in section
{http version} as defined in
{http location} as defined in
{http headers} as defined in
{http transfer coding} as defined in
{http cookies} as defined in
{http authentication scheme} and {http authentication
realm} as defined in
The double question marks ("??") after the
attributes in the
A Binding component (defined in
If the value of the
If the value is
If the value is
If the Interface Message Reference component is declared
using a non-XML type system (as considered in the Types
section of
This SOAP binding only allows one single element in SOAP body.
And, if the SOAP Header Block component's {mustUnderstand} property
is present and its value is
SOAP header blocks other than the ones declared in the
{soap headers} property may be present at run-time, such as
the SOAP header blocks resulting from SOAP modules declared
as explained in section
Every SOAP binding MUST indicate what version of SOAP is in use for the operations of the interface that this binding applies to.
By default, SOAP 1.2
The SOAP protocol specification adds the following
property to the WSDL component model (as defined in
{soap version}, a
The XML representation for specifying the SOAP version
is an optional
A [local name] of
A [namespace name] of
A type of
See
| Property | Value |
|---|---|
| {soap version} | The actual value of the |
Every SOAP binding MUST indicate what underlying protocol is in use.
The SOAP protocol specification adds the following
property to the WSDL component model (as defined in
{soap underlying protocol}, a
The XML representation for specifying the SOAP protocol
is a REQUIRED
A [local name] of
A [namespace name] of
A type of
See
| Property | Value |
|---|---|
| {soap underlying protocol} | The actual value of the |
Every Binding Operation component of a SOAP binding MUST indicate the SOAP Message Exchange Pattern (MEP) to be used for that operation. This binding specification allows the user to indicate a default SOAP MEP to be used for all Binding Operation components of this Binding component.
The default SOAP MEP specification is a syntactic convenience and does not affect the underlying component model.
The XML representation for specifying the default SOAP
MEP is an OPTIONAL
A [local name] of
A [namespace name] of
A type of
For every Interface Fault component contained in an Interface component, a mapping to a SOAP Fault must be described. This binding specification allows the user to indicate the SOAP fault code and subcodes that are transmitted for a given Interface Fault component.
The SOAP Fault binding adds the following
properties to the WSDL component model (as defined in
{soap fault code}, a
{soap fault subcodes}, a list of
The XML representation for binding a SOAP Fault are two
wsoap:code REQUIRED
A [local name] of
A [namespace name] of
A type of
wsoap:subcodes OPTIONAL
A [local name] of
A [namespace name] of
A type of list of
See
| Property | Value |
|---|---|
| {soap fault code} | The actual value of the |
| {soap fault subcodes} | The actual value of the |
For every Interface Operation component contained in an Interface
component, in addition to the default binding rules (for SOAP 1.2,
see
The SOAP Operation binding specification adds the
following property to the WSDL component model (as defined
in
{soap mep}, a
{soap action}, a
The XML representation for binding an Operation are two
wsoap:mep OPTIONAL
A [local name] of
A [namespace name] of
A type of
wsoap:action OPTIONAL
A [local name] of
A [namespace name] of
A type of
See
| Property | Value |
|---|---|
| {soap mep} | The actual value of the
|
| {soap action} | The actual value of the
|
In SOAP, it is permissible for specification interaction
to engage one or more additional features (typically
implemented as one or more SOAP header blocks), as defined
by SOAP Modules (see
The SOAP Module component adds the following
property to the WSDL component model (as defined in
{soap modules}, a set of SOAP Module components
as defined in
The SOAP modules applicable for a particular operation of any service consists of all modules specified in the input or output Binding Message reference components, the infault or outfault Binding Fault reference components, those specified within the Binding Fault components, those specified within the Binding Operation components and those specified within the Binding component. If any module is declared in multiple components, then the requiredness of that module is defined by the closest declaration, where closeness is defined by whether it is specified directly at the Binding Message Reference component or Binding Fault Reference component level, the Binding Fault level or the Binding Operation component level or the Binding component level, respectively.
The SOAP Module component identifies a SOAP module that is in use. The properties of the SOAP Module component are as follows:
{uri} REQUIRED. A
{required} REQUIRED. A
The XML representation for a SOAP Module component is an
A [local name] of
A [namespace name] of
One or more
A REQUIRED
A [local name] of
A [namespace name] which has no value
A type of
An OPTIONAL
A [local name] of
A [namespace name] which has no value
A type of
Zero or more namespace qualified
Zero or more
An OPTIONAL
Zero or more namespace-qualified
See
| Property | Value |
|---|---|
| {soap modules} | The set of SOAP Modules
components corresponding to all the |
| {uri} | The actual value of the |
| {required} | The actual value of the |
SOAP allows the use of header blocks in the header part of the message. This binding allows users to declare the SOAP header blocks in use on a per message ond on a per fault basis.
The SOAP Header Blocks binding specification adds the
following property to the WSDL component model (as defined
in
{soap headers}, OPTIONAL, a set of SOAP Header
Block components as defined in
A SOAP Header Block component describes an abstract piece of header data (message headers) that is associated with the exchange of messages between the communicating parties. The presence of a SOAP Header Block component in a WSDL description indicates that the service supports headers and MAY require a Web service consumer/client that interacts with the service to use the described header. Zero or more such headers may be used.
The properties of the SOAP Header Block component are as follows:
{element} REQUIRED. A
{mustUnderstand} REQUIRED. A
The XML representation for a SOAP Header Block component is an
A [local name] of
A [namespace name] of
One or more
A REQUIRED
A [local name] of
A [namespace name] which has no value
A type of
An OPTIONAL
A [local name] of
A [namespace name] which has no value
A type of
Zero or more namespace qualified
Zero or more
An OPTIONAL
Zero or more namespace-qualified
See
| Property | Value |
|---|---|
| {soap headers} | The set of SOAP Header
Block components corresponding to all the
|
| {element} | The element declaration
from the |
| {mustUnderstand} | The actual value of the |
A SOAP Binding is identified as a SOAP 1.2 binding by assigning the value "1.2" to the {soap version} property of the Binding component.
The SOAP 1.2 binding defined in this section is an extension of the
The SOAP 1.2 binding supports
the SOAP 1.2 HTTP binding defined by the
Default rules in section
When the SOAP Message Exchange Pattern is the SOAP 1.2 Response
MEP and the underlying protocol is HTTP, the Binding Operation may use the {http location} property
defined in
These default binding rules are applicable to SOAP 1.2 binding.
x-www-form-urlencoded is the only supported
serialization format for HTTP GET in the SOAP Response
Message Exchange Pattern.
x-www-form-urlencoded serialization
format (see An
The HTTP binding described in this section is an extension for
As allowed in
The HTTP binding is designed with the objective of minimizing what
needs to be explicitly declared for common cases. This is achieved by
defining a set of default rules which apply for all Interface
Operation components of an Interface component, unless specifically
overidden on a per Interface Operation basis. Thus, if a given
Interface Operation component is not referred to specifically, then
all the default rules apply for that component. That is, per the
requirements of
Notice that there are no default binding rules defined for Fault components by this binding, as no HTTP fault code is suitable as a default for all possible cases. Thus, if a given Interface component has any Fault components, then such Interface components MUST be bound via Binding components which indicate a specific interface and contain as many Binding Fault components as there are Fault components in the Interface Fault component.
A Binding component (defined in
Interface Message Reference component: if the value of the
Interface Fault component: the payload will be the
If the Interface Message Reference component or the Interface Fault
component is declared using a non-XML type system (as
considered in the Types section of
Section
| HTTP Method | Default Input Serialization | Default Output Serialization |
|---|---|---|
| {http method} | {http input serialization} | {http output serialization} |
| GET |
application/x-www-form-urlencoded
|
application/xml
|
| POST |
application/xml
|
application/xml
|
| PUT |
application/xml
|
application/xml |
| DELETE |
application/x-www-form-urlencoded
|
application/xml |
The
application/x-www-form-urlencoded serialization
format places constraints on the stype of the interface
operation bound (see
The default values for the {http input serialization} and
{http output serialization} properties for any other value of
the {http method} method is application/xml.
Mechanisms other than setting the serialization properties
MAY modify the serialization format of the application/x-www-form-urlencoded. Other
examples of such mechanisms are other message exchange
patterns or bindings.
Accept header, the HTTP client MAY take into
account the
Only
Each such
The HTTP header name used is the
The HTTP header content is serialized from the
corresponding
Every Binding component MUST indicate what version of HTTP is in use for the operations of the interface that this binding applies to.
By default, HTTP/1.1
The HTTP binding specification adds the following
property to the WSDL component model (as defined in
{http version}, a
The XML representation for specifying the HTTP version
is an optional
A [local name] of
A [namespace name] of
A type of
A default value of
See
| Property | Value |
|---|---|
| {http version} | The actual value of the |
Every Binding Operation component MUST indicate what HTTP method is in use for the operations of the interface that this binding applies to. This binding specification allows the user to indicate a default HTTP method to be used for all Binding Operation components of this Binding component.
The default HTTP method specification is a syntactic convenience and does not affect the underlying component model.
The XML representation for specifying the default HTTP method
is an optional
A [local name] of
A [namespace name] of
A type of
No default value
This binding specification provides a binding to HTTP of
Interface Operation components whose
Each of the supported message exchange patterns involves one to two messages or faults being exchanged. The first is transmitted using an HTTP request, and the second is transmitted using the corresponding HTTP response. In cases where only one message is being sent, the message body of the HTTP response MUST be empty.
For every Binding operation component corresponding to such Interface Operation components, this binding specification allows the user to indicate the HTTP method to use, the input, output and fault serialization, and the location of the bound operation.
The HTTP binding adds the following property
to the Binding Operation component of the WSDL component model (as defined in
{http location}, REQUIRED. A
If the resulting URI uses the https
scheme, then HTTP over TLS
{http method} REQUIRED. A
{http input serialization} REQUIRED. A
{http output serialization} REQUIRED. A
{http fault serialization} REQUIRED. A
{http query parameter separator} REQUIRED. A
The XML representation for binding an Operation are four
An OPTIONAL
A [local name] of
A [namespace name] of
A type of
No default value
An OPTIONAL
A [local name] of
A [namespace name] of
A type of
No default value
An OPTIONAL
A [local name] of
A [namespace name] of
A type of
No default value
An OPTIONAL
A [local name] of
A [namespace name] of
A type of
No default value
An OPTIONAL
A [local name] of
A [namespace name] of
A type of
A default value of
An OPTIONAL
A [local name] of
A [namespace name] of
A type of
An OPTIONAL
A [local name] of
A [namespace name] of
A type of
See
| Property | Value |
|---|---|
| {http location} | The actual value of the
|
| {http method} | The actual value of the
|
| {http input serialization} | The actual value of the |
| {http output serialization} | The actual value of the |
| {http fault serialization} | The actual value of the |
| {http query parameter separator} | The actual value of the
|
HTTP allows the use of headers in messages. This binding allows users to declare the HTTP headers in use on a per message ond on a per fault basis.
The HTTP Header binding specification adds the
following property to the WSDL component model (as defined
in
{http headers}, OPTIONAL, a set of HTTP Header
components as defined in
A HTTP Header component describes an abstract piece of header data (message headers) that is associated with the exchange of messages between the communicating parties. The presence of a HTTP Header component in a WSDL description indicates that the service supports headers and MAY require a Web service consumer/client that interacts with the service to use the described header. Zero or more such headers may be used.
The properties of the HTTP Header component are as follows:
{element}, REQUIRED. A
The XML representation for a HTTP Header component is an
A [local name] of
A [namespace name] of
One or more
A REQUIRED
A [local name] of
A [namespace name] which has no value
A type of
Zero or more namespace qualified
Zero or more
An OPTIONAL
Zero or more namespace-qualified
See
| Property | Value |
|---|---|
| {http headers} | The set of HTTP Header
components corresponding to all the |
| {element} | The element declaration
from the |
For every Interface Fault component contained in an Interface component, an HTTP error code and error reason MAY be defined. They represents the error code and reason phrase that will be used by the service in case the fault needs to be returned.
The fault definition SHOULD NOT go against the definition
of the HTTP error codes, as specified in section 8 of
The HTTP Fault binding adds the following
property to the WSDL component model (as defined in
{http error status code}, OPTIONAL. A
{http error reason phrase}, OPTIONAL. A
The XML representation for binding an HTTP Fault are two
a
A [local name] of
A [namespace name] of
A type of
a
A [local name] of
A [namespace name] of
A type of
See
| Property | Value |
|---|---|
| {http error status code} | The actual value of the |
| {http error reason phrase} | The actual value of the |
The following serialization formats can be used to encode the
Other serialization formats may be used. Those MAY place restrictions on the style of the Interface Operation bound.
This serialization format is designed to allow a Web service
to produce a URI based on the
Elements from the instance data can be inserted into the path of the request URI, or a query parameter, as shown in the example below:
The following instance data of an input message
with the following
and the following
will serialize the message in the URI as follow:
Element name and element content MUST be URI escaped when
inserted into the request, as defined in "
In this serialization, the value of the {http location}
property is used as a template which is combined with the
The {http location} property MAY cite elements
When constructing the request URI, each pair of
curly braces (and enclosed element name) is replaced
by the possibly empty single value of the
corresponding element. It is an error for this element
to carry an
A double curly brace (i.e.
An element MUST NOT be cited more than once within the {http location} property.
An element name MAY be followed by a slash (i.e. "/")
inside curly braces
(e.g.
Strings enclosed within single curly braces MUST be
element names from the
If not all elements from the
If an element name appears in the
{http location} property followed by a slash, then
the instance data must be serialized in the message body
(see
Non-nil
elements with a possibly empty single value of the
It is an error for the
If the value of the {http location} property does not contain a "?" (question mark) character, one is appended. If it does already contain a question mark character, then the value of the {http query parameter separator} property is appended. Each parameter pair is separated by the value of the {http query parameter separator} property.
Uncited elements with single values (non-list) are serialized as a single name-value parameter pair. The name of the parameter is the name of the uncited element, and the value of the parameter is the value of the uncited element.
Uncited elements with list values are serialized as one name-value parameter pair per list value. The name of each parameter is the name of the uncited element, and the value of each parameter is the corresponding value in the list. The order of the list values is preserved.
In addition to the serialization in the request URI
of the elements cited in the {http location} property,
the entire
The following instance data of an input message
with the following
and the following
will serialize the message in the URI as follow:
and in the message as follow:
The
The Content-Type HTTP header MUST have the value
application/xml, or a media type compatible with
application/xml. Other HTTP headers, such as
Content-Encoding or
Transfer-Encoding, MAY be used.
This format is for legacy compatibility to permit the use of
XForms clients with
Each element in the sequence is serialized into a part as follow:
The Content-Disposition header MUST have the
value form-data, and its name
parameter is the local name of the element.
The Content-Type header MUST have the value:
application/xml (or a media type
compatible with application/xml) if the
element has a complex type;
application/octet-stream if the element
is of type
xs:base64Binary,
xs:hexBinary, or a derived type;
text/plain if the element has a simple
type; The charset MUST be set appropriately. UTF-8 or
UTF-16 MUST be at least supported.
If the type is xs:base64Binary,
xs:hexBinary, xs:anySimpleType
or a derived type, the content of the part is the content
of the element. If the type is a complex type, the element
is serialized following the rules defined in the
It is an error for the
The following instance data of an input message:
with the following
will serialize the message as follow:
Every Binding Message Reference and Fault Message Reference
component MAY indicate which
transfer codings, as defined in section 3.6 of
The HTTP binding provides a mechanism for indicating a default value at the Binding component and Binding Operation levels.
If no value is specified, no claim is being made.
The HTTP binding specification adds the following
property to the WSDL component model (as defined in
{http transfer coding}, a
The XML representation for specifying the default
transfer coding is an OPTIONAL
A [local name] of
A [namespace name] of
A type of
No default value
The XML representation for specifying the
transfer coding is an OPTIONAL
A [local name] of
A [namespace name] of
A type of
No default value
See
| Property | Value |
|---|---|
| {http transfer coding} | The actual value of the
|
Every Binding component MAY indicate whether HTTP cookies
(as defined by
The HTTP binding specification adds the following
property to the WSDL component model (as defined in
{http cookies}, a
The XML representation for specifying the use of HTTP cookies
is an OPTIONAL
A [local name] of
A [namespace name] of
A type of
A default value of
See
| Property | Value |
|---|---|
| {http cookies} | The actual value of the |
Every Endpoint component MAY indicate the use of an HTTP
access authentication mechanism (as defined by
This binding specification allows the authentication scheme and realm to be specified.
The HTTP binding specification adds the following
property to the WSDL component model (as defined in
{http authentication scheme}, a
{http authentication realm}, a
The XML representation for specifying the use of HTTP
access authentication
is two OPTIONAL
An OPTIONAL
A [local name] of
A [namespace name] of
A type of
A default value of
An OPTIONAL
A [local name] of
A [namespace name] of
A type of
A default value of
See
| Property | Value |
|---|---|
| {http authentication scheme} | The actual value of the |
| {http authentication realm} | The actual value of the |
An
This document is the work of the
Previous editors of this document were:
Martin Gudgin, Microsoft Philippe Le Hégaret, W3C Jeffrey Schlimmer, Microsoft
Members of the Working Group are (at the time of writing, and by alphabetical order): Rebecca Bergersen (IONA Technologies), Allen Brookes (Rogue Wave Softwave), Dave Chappell (Sonic Software), Helen Chen (Agfa-Gevaert N. V.), Roberto Chinnici (Sun Microsystems), Kendall Clark (University of Maryland), Ugo Corda (SeeBeyond), Glen Daniels (Sonic Software), Paul Downey (British Telecommunications), Youenn Fablet (Canon), Martin Gudgin (Microsoft Corporation), Hugo Haas (W3C), Tom Jordahl (Macromedia), Anish Karmarkar (Oracle Corporation), Jacek Kopecky (DERI Innsbruck at the Leopold-Franzens-Universität Innsbruck, Austria), Amelia Lewis (TIBCO Software, Inc.), Michael Liddy (Education.au Ltd.), Kevin Canyang Liu (SAP AG), Jonathan Marsh (Microsoft Corporation), 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), Tony Rogers (Computer Associates), Arthur Ryman (IBM), Adi Sakala (IONA Technologies), Igor Sedukhin (Computer Associates), Asir Vedamuthu (webMethods, Inc.), Sanjiva Weerawarana (Independent), Ümit Yalçınalp (SAP AG).
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.), Ümit Yalçınalp (Oracle Corporation), Peter Madziak (Agfa-Gevaert N. V.), Jeffrey Schlimmer (Microsoft Corporation), Hao He (The Thomson Corporation), Erik Ackerman (Lexmark), Jerry Thrasher (Lexmark), Prasad Yendluri (webMethods, Inc.), William Vambenepe (Hewlett-Packard Company), David Booth (W3C), Sanjiva Weerawarana (IBM).
The people who have contributed to
| Date | Author | Description |
|---|---|---|
| 20050509 | RRC | |
| 20050509 | RRC | |
| 20050429 | RRC | |
| 20050429 | RRC | |
| 20050422 | HH | |
| 20050420 | JJM | Fixed typos in RPC section (part of LC78). |
| 20050413 | AV | wsoap:header and whttp:header (removed required and changed default binding rules) |
| 20050412 | RRC | LC75h: added note on multiple return values in rpc style |
| 20050415 | HH | |
| 20050408 | HH | application/x-www-url-encoded serialization |
| 20050408 | HH | |
| 20050408 | HH | |
| 20050408 | HH | |
| 20050408 | HH |
Added |
| 20050407 | HH | |
| 20050406 | HH | |
| 20050331 | HH | |
| 20050331 | HH | |
| 20050321 | HH | |
| 20050321 | HH | |
| 20050321 | HH | |
| 20050321 | HH | |
| 20050317 | HH | |
| 20050316 | HH |
| Date | Author | Description |
|---|---|---|
| 20050222 | aal | Implement editorial changes for LC39, LC40, LC48c. |
| 20050220 | AGR |
|
| 20041209 | aal | add clarifying language for fault propagation, per LC54/76. |
| 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 |
| Date | Author | Description |
|---|---|---|
| 20050505 | aal | LC52c: state that soap faults have no reasonable default. |
| 20050505 | aal | LC76a: allow extensions to override faults in rulesets; LC76b: define "propagate" in rulesets. |
| 20050310 | JJM | Replaced <definitions> with <description>. |
| 20050310 | JJM | Fixed missing fault pseudo-schema. |
| 20050301 | RRC | |
| 20050301 | RRC | |
| 20050221 | HH | |
| 20050211 | HH | |
| 20050120 | HH | |
| 20050120 | HH | |
| 20041209 | HH | |
| 20041209 | HH | |
| 20041209 | HH | |
| 20041209 | HH | |
| 20041208 | AV | Introduced SOAP version independent WSDL SOAP Binding. Added two new sections, "Specifying the SOAP Version" and "SOAP 1.2 Binding". Plus, lots of shuffling. |
| 20041027 | HH | |
| 20041027 | HH | |
| 20041027 | HH | |
| 20041027 | HH | |
| 20041027 | HH | |
| 20041001 | HH | |
| 20041001 | HH | |
| 20041001 | HH | |
| 20041001 | HH | |
| 20040920 | HH | |
| 20040920 | HH | |
| 20040920 | HH | |
| 20040920 | HH | |
| 20040920 | HH | |
| 20040920 | HH | |
| 20040920 | HH | |
| 20040909 | HH | |
| 20040909 | HH | |
| 20040730 | HH | Removed |
| 20040730 | HH | Removed AD Feature HTTP serialization. |
| 20040729 | HH | Added AD Feature support in HTTP binding. |
| 20040727 | HH | Clarified interaction between SOAP binding and HTTP binding properties |
| 20040727 | HH | Renamed http prefix whttp |
| 20040727 | SW | Implemented Umit's proposal to mark MTOM as one optimization mechanism. |
| 20040726 | HH | Restricted URI style with regards to QNames and added trailing / in URL-encoded syntax |
| 20040723 | HH | Addressed issue 246: limited MEP to In-Out, In-Only and Robust In-Only |
| 20040723 | HH | Addressed issue 226. |
| 20040723 | HH | Addressed 249: major reorganization of the HTTP binding to be presented in a functional way like the SOAP binding rather than in a syntactical way. |
| 20040722 | SW | Moved SOAP binding syntax summary to the top per request. Also fixed the value of the binding/@type property in the pseudo-schema to show that its a SOAP binding. |
| 20040722 | HH | Added HTTP error code attribute on fault binding. Added relationship between instance data and properties in the component model. Addresses issue 166. |
| 20040722 | HH | Renamed SOAP protocol into underlying protocol. |
| 20040721 | HH | Set the {type} property of binding for HTTP binding. |
| 20040721 | HH | Fixes for issue 177. |
| 20040720 | HH | Cross-referenced Part 1 properties. |
| 20040720 | HH | Specified default serialization format for HTTP binding, as well as made clear how the defined serialization formats apply constraints on interface operation styles |
| 20040705 | JJM | Added note to indicate only one element per SOAP body. |
| 20040702 | SW | Corrected how the SOAP binding is indicated .. I had forgotten about binding/@type! |
| 20040625 | SW | Made pseudo-syntax consistent with part1 |
| 20040624 | SW | Update the rest of the SOAP binding stuff and consistified everything. |
| 20040624 | SW | Cleaned up how SOAP modules were described. Added default SOAP MEP stuff. |
| 20040623 | SW | Added default binding rules about HTTP URI generation. |
| 20040623 | SW | Added default binding rules about SOAP MEP selection and HTTP Method selection. |
| 20040623 | SW | Fixed up soapaction default rules |
| 20040623 | SW | Allowed use of MTOM for payload serialization |
| 20040623 | SW | Fixed up the wsoap:protocol section |
| 20040618 | SW | Re-introduced AII and EII entity refs. |
| 20040618 | SW | Made soap:module compose with nearest-wins rule. |
| 20040606 | DO | Cleanup on http binding section - had missed some properties. completed removal of @separator |
| 20040604 | DO | Major rewrite of http binding. Moved to component model, added http properties, added input/output serialization, removed @separator, added self as editor |
| 20040526 | SW | Removed wsoap:address |
| 20040526 | SW | Editorial/small corrections per F2F decisions |
| 20040526 | SW | Made soap binding be mostly attribute based per F2F decision |
| 20040519 | SW | removed spurious fault element inside binding/operation/{in,out}put from syntax summary |
| 20040519 | SW | Put in wsoap:module at operation level in the syntax summary (was missing) |
| 20040519 | SW | Removed old SOAP binding text |
| 20040519 | SW | Removed wsoap:header |
| 20040519 | JJM | Added SOAP Address section |
| 20040519 | JJM | Added SOAP Operation section |
| 20040519 | JJM | Replace reference to "XML" by "XML1.0" |
| 20040519 | JJM | Added SOAP Fault section |
| 20040519 | JJM | Added SOAP Header section |
| 20040519 | JJM | Added SOAP Module section |
| 20040516 | SW | Finished writing up soap:binding |
| 20040516 | SW | Added myself as an editor. |
| 20040514 | SW | Added default binding rules. |
| 20040514 | SW | Commented out old totally out of date SOAP binding. |
| 20040514 | JJM | Rework the binding and module sections. Reindent to match the structure of the HTTP binding. |
| 20040511 | JJM | Updated SOAP binding pseudo-schema, according to telcon 20040506. |
| 20040511 | JJM | Updated SOAP binding introduction. |
| 20040401 | JJM | Fixed one remaining occurrence of "verb" (instead of "method"). |
| 20040326 | JJM | Sanitized ednotes. Added new ednotes indicating the SOAP binding needs work and the HTTP binding is (mostly) OK. |
| 20040326 | JJM | Added Philippe's note on URIPath, as per telcon 20040325. |
| 20040305 | JJM | Removed the archaic MIME binding, now superseeded by the HTTP binding anyway. |
| 20040305 | JJM | Included Philippe's changes to the HTTP binding. |
| 20031103 | JJM | Fix new non-normative SOAP binding pseudo-schema. |
| 20031102 | SW | Updated SOAP binding. |
| 20031102 | SW | Change 1.2 to 2.0 per WG decision to rename. |
| 20030606 | JJM | Replaced <kw/> by <b/>. Indicated that pseudo-schemas are not normative |
| 20030604 | JJM | Reformated pseudo-syntax elements to match Part 1 layout |
| 20030529 | JCS | Incorporated text to resolve Issue 6e |
| 20030523 | JJM | Commented out MIME binding example; this is primer stuff. |
| 20030523 | JJM | Added pseudo-syntax to all sections. |
| 20030523 | JJM | Started converting the fault and headerfault sections to component model. |
| 20030523 | JJM | Complete the Multipart and x-www-form-urlencoded sections. |
| 20030523 | JJM | Fixed typos in HTTP binding (in particular added NOT in some section headers). |
| 20030522 | JCS | Added rules for serializing HTTP response |
| 20030522 | JCS | Added cardinality to pseudo schema for HTTP binding |
| 20030522 | JCS | Changes @transport to @protocol for SOAP binding |
| 20030522 | JJM | Incorporated remaining text from Philippe into the HTTP binding. |
| 20030522 | JJM | Polished the HTTP binding, split into subsections, added double curly brace escape mechanism, removed pseudo-schema. |
| 20030521 | JCS | Added rules for @verbDefault/@verb and @location. |
| 20030514 | JJM | Start converting the HTTP binding to the component model. The next thing to do will be to remove http:urlReplacement, etc. and incorporate instead Philippe's text. |
| 20030313 | MJG | Changed to Part 3 ( from Part 2 ) |
| 20030117 | JCS | Incorporated resolution for Issue 5 (@encodingStyle). Referenced (rather than in-lined XML Schema). |
| 20030117 | JJM | Various editorial fixes. |
| 20030116 | JCS | Updated pseudo and XML Schema. |
| 20030116 | JJM | Added propertyConstraint section. |
| 20030116 | JJM | Added soap:module section. |
| 20030115 | JCS | Incorporated resolutions for Issue 25 (drop @use and @encoding), Issue 51 (headers reference element/type), and attribute roll up into text and schema. Began reworking SOAP HTTP binding to use Infoset model. Removed informative appendices 'Notes on URIs' and example WSDL documents; expect them to appear in the primer. Updated SOAP 1.2 references to CR. |
| 20030114 | JJM | Removed ednote saying Part 2 is out of synch with Part 1. |
| 20030111 | JJM | Incorporated resolution for issue 17 (role AII). |
| 20030109 | JJM | Incorporated resolution for issue 4 (Namespaces). |
| 20020702 | JJM | Added summary to prefix table. |
| 20020628 | JJM | Added out-of-synch-with-Part2 and not-soap12-yet ednote. |
| 20020621 | JJM | Commented out the link to the previous version. There is no previous version for 1.2 right now. |
| 20020621 | JJM | Rewrote the Notation Conventions section. |
| 20020621 | JJM | Added reference to part 0 in introduction. Renumbered references. |
| 20020621 | JJM | Simplified abstract and introduction. |
| 20020621 | JJM | Obtain the list of WG members from a separate file. |
| 20020621 | JJM | Updated stylesheet and DTDs to latest XMLP stylesheet and DTDs. |
| 20020621 | JJM | Deleted placeholder for appendix C "Location of Extensibility Elements", since this is part 1 stuff and extensibility has been reworked anyway. |
| 20020621 | JJM | Corrected link to issues lists |
| 20020621 | JJM | Updated title from "WSDL" to "Web Services Description Language". Now refer to part 1 as "Web Services... Part 1: Framework |
| 20020621 | JJM | Added Jeffrey as an editor :-). Removed Gudge (now on Part 2) :-( |
| 20020411 | JJM | Fixed typos noticed by Kevin Liu |
| 20020301 | JJM | Converted the "Schemas" sections |
| 20020301 | JJM | Converted the "Wire WSDL examples" sections |
| 20020301 | JJM | Converted the "Notes on URIs" sections |
| 20020301 | JJM | Converted the "Notational Conventions" sections |
| 20020301 | JJM | Converted the "References" sections |
| 20020301 | JJM | Converted the "MIME Binding" section to XML |
| 20020221 | JJM | Converted the "HTTP Binding" section to XML |
| 20020221 | JJM | Added placeholders for the "Wire examples" and "Schema" sections |
| 20020221 | JJM | Converted the "SOAP Binding" section to XML |
| 20020221 | JJM | Added the Change Log |
| 20020221 | JJM | Added the Status section |
| 20020221 | JJM | Simplified the introduction; referred to Part1 for a longer introduction |
| 20020221 | JJM | Renamed to "Part 2: Bindings" |
| 20020221 | JJM | Created from http://www.w3.org/TR/2001/NOTE-wsdl-20010315 |