1. Introduction
Web Services Description Language Version 2.0 (WSDL 2.0)
provides a model and an XML format for describing Web services.
WSDL 2.0 enables one to separate the description of the abstract
functionality offered by a service from concrete details of a
service description such as “how” and “where” that functionality is
offered.
This specification defines a language for describing the
abstract functionality of a service as well as a framework for
describing the concrete details of a service description. It also
defines the conformance criteria for documents in this
language.
The companion specification, Web Services Description
Language (WSDL) Version 2.0 Part 2: Adjuncts [WSDL 2.0 Adjuncts] describes extensions
for message exchange patterns, operation safety, operation styles
and binding extensions (for SOAP [SOAP 1.2 Part 1: Messaging Framework (Second
Edition)] and HTTP [IETF RFC
2616]).
1.1 Service
Description
WSDL 2.0 describes a Web service in two fundamental stages: one
abstract and one concrete. Within each stage, the description uses
a number of constructs to promote reusability of the description
and to separate independent design concerns.
At an abstract level, WSDL 2.0 describes a Web service in terms
of the messages it sends and receives; messages are described
independent of a specific wire format using a type system,
typically XML Schema.
An operation associates a message exchange pattern with
one or more messages. A message exchange pattern
identifies the sequence and cardinality of messages sent and/or
received as well as who they are logically sent to and/or received
from. An interface groups together operations without any
commitment to transport or wire format.
At a concrete level, a binding specifies transport and
wire format details for one or more interfaces. An
endpoint associates a network address with a binding. And
finally, a service groups together endpoints that
implement a common interface.
1.2 The Meaning of a Service
Description
A WSDL 2.0 service description indicates how potential clients
are intended to interact with the described service. It represents
an assertion that the described service fully implements and
conforms to what the WSDL 2.0 document describes. For example, as
further explained in section 6.1.1
Mandatory extensions, if the WSDL 2.0 document
specifies a particular optional extension, the functionality
implied by that extension is only optional to the client. It must
be supported by the Web service.
A WSDL 2.0 interface describes potential interactions with a Web
service, not required interactions. The declaration of an operation
in a WSDL 2.0 interface is not an assertion that the interaction
described by the operation must occur. Rather it is an assertion
that if such an interaction is (somehow) initiated, then the
declared operation describes how that interaction is intended to
occur.
1.3 Document Conformance
An element information item (as defined in
[XML Information Set]) whose
namespace name is "http://www.w3.org/ns/wsdl" and whose local part
is description conforms to this specification if it is
valid according to the XML Schema for that element as defined by
this specification (http://www.w3.org/2007/06/wsdl/wsdl20.xsd)
and additionally adheres to all the constraints contained in this
specification and conforms to the specifications of any extensions
contained in it. Such a conformant element information
item constitutes a WSDL 2.0 document.
The definition of the WSDL 2.0 language is based on the XML
Information Set [XML Information
Set] but also imposes many semantic constraints over and
above structural conformance to this XML Infoset. In order to
precisely describe these constraints, and as an aid in precisely
defining the meaning of each WSDL 2.0 document, the WSDL 2.0
specification defines a component model 2. Component Model as an
additional layer of abstraction above the XML Infoset. Constraints
and meaning are defined in terms of this component model, and the
definition of each component includes a mapping that specifies how
values in the component model are derived from corresponding items
in the XML Infoset.
An XML 1.0 document that is valid with respect to the WSDL 2.0
XML Schema and that maps to a valid WSDL 2.0 Component Model is
conformant to the WSDL 2.0 specification.
1.4 Notational
Conventions
All parts of this specification are normative, with the
EXCEPTION of notes, pseudo-schemas, examples, and sections
explicitly marked as “Non-Normative”.
1.4.1 RFC
2119 Keywords
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
[IETF RFC 2119].
1.4.2
RFC 3986 Namespaces
Namespace names of the general form:
represent application or context-dependent URIs [IETF RFC 3986].
1.4.3 XML
Schema anyURI
This specification uses the XML Schema type
xs:anyURI (see [XML
Schema: Datatypes]). It is defined so that
xs:anyURI values are essentially IRIs (see
[IETF RFC 3987]). The
conversion from xs:anyURI values to an actual URI is
via an escaping procedure defined by (see [XLink 1.0]), which is identical in most
respects to IRI Section 3.1 (see [IETF RFC
3987]).
For interoperability, WSDL authors are advised to avoid the
US-ASCII characters: "<", ">", '"', space, "{", "}", "|",
"\", "^", and "`", which are allowed by the xs:anyURI
type, but disallowed in IRIs.
1.4.4 Prefixes and
Namespaces Used in This Specification
This specification uses predefined namespace prefixes
throughout; they are given in the following list. Note that the
choice of any namespace prefix is arbitrary and not semantically
significant (see [XML
Namespaces]).
1.4.5 Terms Used in
This Specification
This section describes the terms and concepts introduced in Part
1 of the WSDL Version 2.0 specification (this document).
- Actual Value
-
As in [XML Schema:
Structures], the expression "actual value" is used to
refer to the member of the value space of the simple type
definition associated with an attribute information item which
corresponds to its normalized value. This will often be a string,
but may also be an integer, a boolean, an IRI-reference, etc.
- Inlined Schema
-
An XML schema that is defined in the wsdl:types
element information item of a WSDL 2.0 description. For
example, an XML Schema defined in an xs:schema
element information item 3.1.2 Inlining XML Schema.
1.4.6 XML Information Set
Properties
This specification refers to properties in the XML Information
Set [XML Information Set].
Such properties are denoted by square brackets, e.g. [children],
[attributes].
1.4.7 WSDL 2.0 Component Model
Properties
This specification defines and refers to properties in the WSDL
2.0 Component Model 2. Component
Model. Such properties are denoted by curly brackets,
e.g. {name}, {interfaces}.
This specification uses a consistent naming convention for
component model properties that refer to components. If a property
refers to a required or optional component, then the property name
is the same as the component name. If a property refers to a set of
components, then the property name is the pluralized form of the
component name.
1.4.8 Z Notation
Z Notation [Z Notation
Reference Manual] was used in the development of this
specification. Z Notation is a formal specification language that
is based on standard mathematical notation. The Z Notation for this
specification has been verified using the Fuzz 2000 type-checker
[Fuzz 2000].
Since Z Notation is not widely known, it is not included the
normative version of this specification. However, it is included in
a non-normative version which allows to
dynamically hide and show the Z Notation. Browsers correctly
display the mathematical Unicode characters, provided that the
required fonts are installed. Mathematical fonts for Mozilla
Firefox can be downloaded from the Mozilla Web
site.
The Z Notation was used to improve the quality of the normative
text that defines the Component Model, and to help ensure that the
test suite covered all important rules implied by the Component
Model. However, the Z Notation is non-normative, so any conflict
between it and the normative text is an error in the Z Notation.
Readers and implementers may nevertheless find the Z Notation
useful in cases where the normative text is unclear.
There are two elements of Z Notation syntax that conflict with
the notational conventions described in the preceding sections. In
Z Notation, square brackets are used to introduce basic sets, e.g.
[ID], which conflicts with the use of
square brackets to denote XML Information Set properties 1.4.6 XML Information Set
Properties. Also, in Z Notation, curly brackets are
used to denote set display and set comprehension, e.g.
{1, 2,
3}, which conflicts with the use of curly brackets to denote WSDL
2.0 Component Model properties 1.4.7 WSDL 2.0 Component
Model Properties. However, the intended meaning of
square and curly brackets should be clear from their context and
this minor notational conflict should not cause any confusion.
1.4.9 BNF
Pseudo-Schemas
Pseudo-schemas are provided for each component, before the
description of the component. They use BNF-style conventions for
attributes and elements: "?" denotes optionality (i.e. zero or one
occurrences), "*" denotes zero or more occurrences, "+" one or more
occurrences, "[" and "]" are used to form groups, and "|"
represents choice. Attributes are conventionally assigned a value
which corresponds to their type, as defined in the normative
schema. Elements with simple content are conventionally assigned a
value which corresponds to the type of their content, as defined in
the normative schema. Pseudo schemas do not include extension
points for brevity.
<!-- sample pseudo-schema -->
<defined_element
required_attribute_of_type_string="xs:string"
optional_attribute_of_type_int="xs:int"? >
<required_element />
<optional_element />?
<one_or_more_of_these_elements />+
[ <choice_1 /> | <choice_2 /> ]*
</defined_element>
1.4.10 Assertions
Assertions about WSDL 2.0 documents and components that are not
enforced by the normative XML schema for WSDL 2.0 are marked by a
dagger symbol (†) at the end of a sentence. Each assertion has been
assigned a unique identifier that consists of a descriptive textual
prefix and a unique numeric suffix. The numeric suffixes are
assigned sequentially and never reused so there may be gaps in the
sequence. The assertion identifiers MAY be used by implementations
of this specification for any purpose, e.g. error reporting.
The assertions and their identifiers are summarized in section
E. Assertion
Summary.
2. Component
Model
This section describes the conceptual model of WSDL 2.0 as a set
of components with attached properties, which collectively describe
a Web service. This model is called the Component Model of
WSDL 2.0. A valid WSDL 2.0 component model is a set of
WSDL 2.0 components and properties that satisfy all the
requirements given in this specification as indicated by keywords
whose interpretation is defined by RFC 2119 [IETF RFC 2119].
ComponentModel [
show all ] [
hide all ]
A WSDL 2.0 document, and its related documents, defines a set of
components that together form an instance of a Component Model.
This specification defines the structure and constraints on the
components in a valid component model instance.
Let ComponentModel be the set of valid
component model instances:
| ComponentModel |
|
| DescriptionCM |
| ElementDeclarationCM |
| TypeDefinitionCM |
| InterfaceCM |
| InterfaceFaultCM |
| InterfaceOperationCM |
| InterfaceMessageReferenceCM |
| InterfaceFaultReferenceCM |
| BindingCM |
| BindingFaultCM |
| BindingOperationCM |
| BindingMessageReferenceCM |
| BindingFaultReferenceCM |
| ServiceCM |
| EndpointCM |
|
|
|
See DescriptionCM, ElementDeclarationCM, TypeDefinitionCM, InterfaceCM, InterfaceFaultCM, InterfaceOperationCM, InterfaceMessageReferenceCM,
InterfaceFaultReferenceCM,
BindingCM, BindingFaultCM, BindingOperationCM, BindingMessageReferenceCM,
BindingFaultReferenceCM,
ServiceCM, EndpointCM.
The definition of ComponentModel is
built up from definitions for each of the component types. A
component model instance is valid if and only if the constraints on
each of the component types are satisfied. The component type
definitions are given in the following sections.
Components are typed collections of properties that correspond
to different aspects of Web services. Each subsection herein
describes a different type of component, its defined properties,
and its representation as an XML Infoset [XML Information Set].
Component [
show
all ] [
hide all ]
Let Component be the union of each of
the component types that appear in the WSDL 2.0 component
model:
| Component ::= |
| description<<Description>>| |
| elementDecl<<ElementDeclaration>>| |
| typeDef<<TypeDefinition>>| |
| interface<<Interface>>| |
| interfaceFault<<InterfaceFault>>| |
| interfaceOp<<InterfaceOperation>>| |
| interfaceMessageRef<<InterfaceMessageReference>>| |
| interfaceFaultRef<<InterfaceFaultReference>>| |
| binding<<Binding>>| |
| bindingFault<<BindingFault>>| |
| bindingOp<<BindingOperation>>| |
| bindingMessageRef<<BindingMessageReference>>| |
| bindingFaultRef<<BindingFaultReference>>| |
| service<<Service>>| |
| endpoint<<Endpoint>> |
See Description, ElementDeclaration, TypeDefinition, Interface, InterfaceFault, InterfaceOperation, InterfaceMessageReference,
InterfaceFaultReference,
Binding, BindingFault, BindingOperation, BindingMessageReference,
BindingFaultReference,
Service, Endpoint.
The Component type is an example of a Z
Notation free type. The structure of a free type is
similar to that of a variant record or discriminated union datatype
that are found in some common programming languages. Each of the
members of this union is formally defined in the following
sections.
ID [
show all ] [
hide all ]
When a component property is said to contain another component
or a set of other components, the intended meaning is that the
component property contains a reference to another component or a
set of references to other components. Every component contains an
unique identifier that is used to express references.
Let ID be the set of all component
identifier values:
The ID type is an example of a Z
Notation basic set. The structure of a basic set is
immaterial. The only relevant aspect of ID
is that it contains enough members to uniquely identify each
component, and that these identifiers can be compared for equality.
These identifiers are similar to XML element ids or object
identifiers that are found in common object-oriented programming
languages.
Identifier [
show
all ] [
hide all ]
Every component has an identifier which uniquely identifies it
within a component model instance.
Let Identifier be the set of component
identifier properties:
The Identifier set is a an example of Z
Notation schema. The structure of a Z schema is similar to
that of a record or struct datatype that are found in many common
programming languages. The fields of an instance of a Z schema are
selected using the usual dot notation, e.g. x.id selects the id field of the instance x.
All component properties that contain an ID, except for Identifier,
refer to other components. Every ID value
that appears in a component reference corresponds to a unique
component in the component model with that identifier.
Id [
show all ] [
hide all ]
Let Id map components to their
identifiers:
| Id : Component→ID |
|
|
| ∀x : Description • Id(description(x)) = x.id |
| ∀x : ElementDeclaration
• Id(elementDecl(x)) = x.id |
| ∀x : TypeDefinition
• Id(typeDef(x)) = x.id |
| ∀x : Interface • Id(interface(x)) = x.id |
| ∀x : InterfaceFault
• Id(interfaceFault(x)) = x.id |
| ∀x : InterfaceOperation
• Id(interfaceOp(x)) = x.id |
| ∀x : InterfaceMessageReference
• Id(interfaceMessageRef(x))
= x.id |
| ∀x : InterfaceFaultReference
• Id(interfaceFaultRef(x))
= x.id |
| ∀x : Binding • Id(binding(x)) = x.id |
| ∀x : BindingFault • Id(bindingFault(x)) = x.id |
| ∀x : BindingOperation
• Id(bindingOp(x)) = x.id |
| ∀x : BindingMessageReference
• Id(bindingMessageRef(x))
= x.id |
| ∀x : BindingFaultReference
• Id(bindingFaultRef(x)) = x.id |
| ∀x : Service • Id(service(x)) = x.id |
| ∀x : Endpoint • Id(endpoint(x)) = x.id |
See Component, ID, Description,
ElementDeclaration, TypeDefinition, Interface, InterfaceFault, InterfaceOperation, InterfaceMessageReference,
InterfaceFaultReference,
Binding, BindingFault, BindingOperation, BindingMessageReference,
BindingFaultReference,
Service, Endpoint.
The Id function is an example of a Z
Notation axiomatic definition. An axiomatic definition
declares an object and then characterizes it with a set of axioms
or logical constraints that it satisfies. In this case, the
Id function is constrained by giving its
value on each possible type of component, which uniquely defines
it.
ComponentModel1 [
show all ] [
hide all ]
A component model is a set of uniquely identified components
that satisfy a set of validity constraints which are described in
the following sections.
Let ComponentModel1 be the base set of
component models. This set will be further constrained in the
following sections:
| ComponentModel1 |
|
| components :ℙComponent |
| componentIds :ℙID |
|
|
|
| ∀x, y : components • |
| Id(x) = Id(y)⇒x = y |
|
|
|
| componentIds = { x : components • Id(x) } |
|
|
|
IdentifierValid [
show all ] [
hide all ]
An identifier is valid if it is the identifier of a component in
the component model.
Let IdentifierValid express this
validity constraint:
| IdentifierValid |
|
| ComponentModel1 |
| Identifier |
|
|
|
| id∈componentIds |
|
|
|
InterfaceComponents [
show all ] [
hide all ]
In order to express the additional constraints on the component
model, it is convenient to define the subsets of components of each
type and their corresponding subsets of identifiers.
Let InterfaceComponents define the
subsets of components that are related to the Interface component:
| InterfaceComponents |
|
| ComponentModel1 |
| interfaceComps :ℙInterface |
| interfaceFaultComps
:ℙInterfaceFault |
| interfaceOpComps :ℙInterfaceOperation |
| interfaceMessageRefComps
:ℙInterfaceMessageReference |
| interfaceFaultRefComps
:ℙInterfaceFaultReference |
|
|
|
|
| interfaceComps = { x : Interface | |
| interface(x)∈components } |
|
|
|
| interfaceFaultComps
= { x
: InterfaceFault | |
| interfaceFault(x)∈components } |
|
|
|
| interfaceOpComps = { x : InterfaceOperation
| |
| interfaceOp(x)∈components } |
|
|
|
| interfaceMessageRefComps
= { x
: InterfaceMessageReference | |
| interfaceMessageRef(x)∈components } |
|
|
|
| interfaceFaultRefComps
= { x
: InterfaceFaultReference | |
| interfaceFaultRef(x)∈components } |
|
|
|
The definition of InterfaceComponents is
an example of Z Notation schema inclusion. In Z schema
inclusion all the fields and constraints of the included Z schema,
e.g. ComponentModel1 are added to the
including Z schema, e.g. InterfaceComponents.
InterfaceComponentIds [
show all ] [
hide
all ]
Let InterfaceComponentIds define the
subsets of component identifiers that are related to the Interface component:
| InterfaceComponentIds |
|
| InterfaceComponents |
| interfaceIds :ℙID |
| interfaceFaultIds
:ℙID |
| interfaceOpIds :ℙID |
| interfaceMessageRefIds
:ℙID |
| interfaceFaultRefIds
:ℙID |
|
|
|
| interfaceIds = { x : interfaceComps
• x.id } |
| interfaceFaultIds
= { x
: interfaceFaultComps •
x.id } |
| interfaceOpIds = { x : interfaceOpComps
• x.id } |
| interfaceMessageRefIds
= { x
: interfaceMessageRefComps •
x.id } |
| interfaceFaultRefIds
= { x
: interfaceFaultRefComps •
x.id } |
|
|
|
|
BindingComponents [
show all ] [
hide all ]
Let BindingComponents define the subsets
of components that are related to the Binding component:
| BindingComponents |
|
| ComponentModel1 |
| bindingComps :ℙBinding |
| bindingFaultComps
:ℙBindingFault |
| bindingOpComps :ℙBindingOperation |
| bindingMessageRefComps
:ℙBindingMessageReference |
| bindingFaultRefComps
:ℙBindingFaultReference |
|
|
|
|
| bindingComps = { x : Binding | |
| binding(x)∈components } |
|
|
|
| bindingFaultComps
= { x
: BindingFault
| |
| bindingFault(x)∈components } |
|
|
|
| bindingOpComps = { x : BindingOperation
| |
| bindingOp(x)∈components } |
|
|
|
| bindingMessageRefComps
= { x
: BindingMessageReference | |
| bindingMessageRef(x)∈components } |
|
|
|
| bindingFaultRefComps
= { x
: BindingFaultReference | |
| bindingFaultRef(x)∈components } |
|
|
|
BindingComponentIds [
show all ] [
hide all ]
Let BindingComponentIds define the
subsets of component identifiers that are related to the Binding component:
| BindingComponentIds |
|
| BindingComponents |
| bindingIds :ℙID |
| bindingFaultIds :ℙID |
| bindingOpIds :ℙID |
| bindingMessageRefIds
:ℙID |
| bindingFaultRefIds
:ℙID |
|
|
|
| bindingIds = { x : bindingComps • x.id } |
| bindingFaultIds = { x : bindingFaultComps
• x.id } |
| bindingOpIds = { x : bindingOpComps
• x.id } |
| bindingMessageRefIds
= { x
: bindingMessageRefComps •
x.id } |
| bindingFaultRefIds
= { x
: bindingFaultRefComps •
x.id } |
|
|
|
ServiceComponents [
show all ] [
hide all ]
Let ServiceComponents define the subsets
of components that are related to the Service component:
| ServiceComponents |
|
| ComponentModel1 |
| serviceComps :ℙService |
| endpointComps :ℙEndpoint |
|
|
|
| serviceComps = { x : Service | |
| service(x)∈components } |
|
|
|
| endpointComps = { x : Endpoint | |
| endpoint(x)∈components } |
|
|
|
ServiceComponentIds [
show all ] [
hide all ]
Let ServiceComponentIds define the
subsets of component identifiers that are related to the Service component:
| ServiceComponentIds |
|
| ServiceComponents |
| serviceIds :ℙID |
| endpointIds :ℙID |
|
|
|
| serviceIds = { x : serviceComps • x.id } |
| endpointIds = { x : endpointComps
• x.id } |
|
|
|
OtherComponents [
show all ] [
hide all ]
Let OtherComponents define the subsets
of the other component types:
| OtherComponents |
|
| ComponentModel1 |
| descriptionComps :ℙDescription |
| elementDeclComps :ℙElementDeclaration |
| typeDefComps :ℙTypeDefinition |
|
|
|
| descriptionComps = { x : Description | |
| description(x)∈components } |
|
|
|
| elementDeclComps = { x : ElementDeclaration
| |
| elementDecl(x)∈components } |
|
|
|
| typeDefComps = { x : TypeDefinition
| |
| typeDef(x)∈components } |
|
|
|
OtherComponentIds [
show all ] [
hide all ]
Let OtherComponentIds define the subsets
of other component identifiers:
| OtherComponentIds |
|
| OtherComponents |
| descriptionIds :ℙID |
| elementDeclIds :ℙID |
| typeDefIds :ℙID |
|
|
|
| descriptionIds = { x : descriptionComps
• x.id } |
| elementDeclIds = { x : elementDeclComps
• x.id } |
| typeDefIds = { x : typeDefComps • x.id } |
|
|
|
ComponentModel2 [
show all ] [
hide all ]
Let ComponentModel2 be the basic
component model, augmented with the definitions of the subsets of
each component type and their corresponding identifiers:
| ComponentModel2≙ |
| InterfaceComponentIds∧ |
| BindingComponentIds∧ |
| ServiceComponentIds∧ |
| OtherComponentIds |
The definition of ComponentModel2 is an
example of Z Notation schema conjunction. In Z schema
conjunction, the resulting Z schema, e.g. ComponentModel2, contains all the fields of the
conjoined Z schemas, e.g. InterfaceComponentIds, BindingComponentIds, ServiceComponentIds, and OtherComponentIds, and its constraint is the
conjunction (logical and) of their constraints.
Base [
show all ] [
hide all ]
The component types in the component model have an identifier.
It is convenient to put this field into a base Z schema that can be
included in other component schemas.
Let Base be the common base Z schema for
all component types that have an identifier:
BaseValid [
show
all ] [
hide all ]
The base properties of a component are valid when the
identifiers are valid:
Let BaseValid be this validity
constraint on the base fields of a component:
| BaseValid |
|
| IdentifierValid |
|
|
|
NestedBase [
show
all ] [
hide all ]
Nested components have an additional {parent} property.
Let NestedBase be the common base schema
for all nested component types:
NestedBaseValid [
show all ] [
hide all ]
The properties of a nested base component are valid when the
base properties are valid and the {parent} property is valid.
Let NestedBaseValid be the validity
constraints for nested components:
| NestedBaseValid |
|
| BaseValid |
| ParentValid |
|
|
|
Properties are unordered and unique with respect to the
component they are associated with. Individual properties'
definitions may constrain their content (e.g., to a typed value,
another component, or a set of typed values or components), and
components may require the presence of a property to be considered
conformant. Such properties are marked as REQUIRED, whereas those
that are not required to be present are marked as OPTIONAL. By
convention, when specifying the mapping rules from the XML Infoset
representation of a component to the component itself, an optional
property that is absent in the component in question is described
as being “empty”. Unless otherwise specified, when a property is
identified as being a collection (a set or a list), its value may
be a 0-element (empty) collection. In order to simplify the
presentation of the rules that deal with sets of components, for
all OPTIONAL properties whose type is a set, the absence of such a
property from a component MUST be treated as semantically
equivalent to the presence of a property with the same name and
whose value is the empty set. In other words, every OPTIONAL
set-valued property MUST be assumed to have the empty set as its
default value, to be used in case the property is absent.
OPTIONAL [
show
all ] [
hide all ]
An OPTIONAL simple property type is treated as a set-valued type
that contains at most one member. If the property is absent then
its value is the empty set. If the property is present then its
value is the singleton set that contains the actual value of the
property.
Let OPTIONAL[X]
be the OPTIONAL values of type X where X is a property type:
