Web
Services Metadata Exchange (WS-MetadataExchange)
Latest version:
http://www.w3.org/TR/ws-metadata-exchange
Previous
version:
http://www.w3.org/TR/2009/WD-ws-metadata-exchange-20090317
Editors:
Doug Davis, IBM
Ashok Malhotra, Oracle
Katy Warr, IBM
Wu Chou, Avaya
Copyright © 2010 W3C®
(MIT,
ERCIM,
Keio), All Rights Reserved. W3C liability,
trademark
and document
use rules apply.
This specification defines how metadata
associated with a Web service endpoint can be represented as [WS-Transfer] resources or HTTP resources, how
metadata can be embedded in [WS-Addressing] endpoint
references, and how metadata could be retrieved from a metadata resource, and
how metadata associated with implicit features can be advertised.
This document is an
editors' copy that has no official standing.
1 Composable Architecture
2 Introduction
2.1 Requirements
2.2 Examples
3 Notations and Terminology
3.1 Notational Conventions
3.2 Considerations on the Use of
Extensibility Points
3.3 XML Namespaces
3.4 Terminology
3.5 Compliance
4 Web Services Metadata Collection
5 Metadata Resources
6 Retrieving Metadata about Service Endpoints
6.1 GetWSDL
6.2 GetMetadata
7 Metadata References
7.1 mex:Location
7.2 mex:Reference
7.3 Examples
8 Metadata in Endpoint References
8.1 Endpoint References Containing
Metadata
8.2 Associating Policies with Endpoint
References
9 Exposing Metadata for Implicitly Defined Features
10 Security Considerations
11 WS-MetadataExchange Metadata
11.1 MetadataExchange Assertion
12 Boostrapping Metadata Retrieval
13 Acknowledgements
14 References
14.1 Normative References
14.2 Informative References
A XML Schema
B WSDL
C Change Log
The Web services specifications (WS-*) are
designed to be composed with each other to provide a rich set of tools for the
Web services environment. This specification specifically relies on other Web
services specifications to provide secure, reliable, and/or transacted message
delivery and to express Web service metadata.
Web services use
metadata to describe what other endpoints need to know to interact with them.
Specifically, [WS-Policy] describes
the capabilities, requirements, and general characteristics of Web services; [WSDL11] describes abstract message operations, concrete
network protocols, and endpoint addresses used by Web services; XML Schema [XMLSchema - Part 1], [XMLSchema -
Part 2] describes the structure and contents of XML-based messages received
by and sent by Web services.
To bootstrap communication with Web services this
specification defines how metadata can be treated as a HTTP resources or as [WS-Transfer] resources for retrieval purposes, how
metadata can be embedded in WS-Addressing endpoint references, and how Web
service endpoints can OPTIONALLY support a request-response interaction for the
retrieval of metadata. When the type of metadata sought is clearly known, e.g.,
[WS-Policy], a requester MAY indicate that only that
type is to be returned; where additional types of metadata are being used, or
are expected, or when a requester needs to retrieve all of the metadata
relevant to subsequent interactions with an endpoint, a requester MAY indicate
that all available metadata, regardless of their types, are expected.
The mechanisms defined herein are intended for the
retrieval of metadata (i.e., Web service description information) only. They
are not intended to provide a general purpose query or retrieval mechanism for
other types of data associated with a Web service, such as state data,
properties and attribute values, etc.
This specification
intends to meet the following requirements:
·
Define a mechanism for retrieving metadata
about a Web service endpoint.
·
Define an encapsulation format for metadata.
·
Treat the metadata about a Web service
endpoint as [WS-Transfer]
resources, or as an HTTP reachable resource.
·
Define a bootstrap mechanism for retrieving
metadata.
·
Support future versions of known metadata
formats.
·
Allow new metadata formats to be added.
Example 2-1 illustrates a
sample GetWSDL request for the WSDL metadata document of a service.
(01) <s11:Envelope
(02) xmlns:s11='http://schemas.xmlsoap.org/soap/envelope/'
(03) xmlns:wsa='http://www.w3.org/2005/08/addressing'>
(04) xmlns:wst='http://www.w3.org/2002/ws/ra/edcopies/ws-tra'>
(05) <s11:Header>
(06)
<wsa:Action>
(07)
http://www.w3.org/2002/ws/ra/edcopies/ws-mex/GetWSDL
(08)
</wsa:Action>
(09)
<wsa:To>http://services.example.org/stockquote</wsa:To>
(10)
<wsa:ReplyTo>
(11)
<wsa:Address>http://client.example.org</wsa:Address>
(12)
</wsa:ReplyTo>
(13)
<wsa:MessageID>
(14) urn:uuid:1cec121a-82fe-41da-87e1-3b23f254f128
(15)
</wsa:MessageID>
(16) </s11:Header>
(17) <s11:Body>
(18)
<mex:GetWSDL/>
(19) </s11:Body>
(20) </s11:Envelope>
Example 2-2 lists a sample
response to the request in Example 2-1.
(01) <s11:Envelope
(02) xmlns:s11='http://schemas.xmlsoap.org/soap/envelope/'
(03) xmlns:wsa='http://www.w3.org/2005/08/addressing'
(04) xmlns:wsp='http://www.w3.org/ns/ws-policy'
(05) xmlns:mex='http://www.w3.org/2002/ws/ra/edcopies/ws-mex'>
(06) <s11:Header>
(07)
<wsa:To>http://client.example.org</wsa:To>
(08)
<wsa:Action>
(09) http://www.w3.org/2002/ws/ra/edcopies/ws-mex/GetWSDLResponse
(10)
</wsa:Action>
(11)
<wsa:RelatesTo>
(12) urn:uuid:73d7edfc-5c3c-49b9-ba46-2480caee43e9
(13)
</wsa:RelatesTo>
(14) </s11:Header>
(15) <s11:Body>
(16)
<mex:GetWSDLResponse>
(17)
<wsdl:definitions ...>
(18)
<!-- WSDL data removed for brevity -->
(19)
</wsdl:definitions>
(18)
</mex:GetWSDLResponse>
(19) </s11:Body>
(20) </s11:Envelope>
Lines
17-19 in Example 2-2 is the
WSDL of the service.
Example 2-3 illustrates a
sample [WS-Transfer] Get request for a resource' s representation.
(01) <s11:Envelope
(02) xmlns:s11='http://schemas.xmlsoap.org/soap/envelope/'
(03) xmlns:wsa='http://www.w3.org/2005/08/addressing'>
(04) xmlns:wst='http://www.w3.org/2002/ws/ra/edcopies/ws-tra'>
(05) <s11:Header>
(06)
<wsa:Action>
(07)
http://www.w3.org/2002/ws/ra/edcopies/ws-tra/Get
(08)
</wsa:Action>
(09)
<wsa:To>http://services.example.org/stockquote/metadata</wsa:To>
(10)
<wsa:ReplyTo>
(11)
<wsa:Address>http://client.example.org</wsa:Address>
(12) </wsa:ReplyTo>
(13)
<wsa:MessageID>
(14) urn:uuid:1cec121a-82fe-41da-87e1-3b23f254f128
(15)
</wsa:MessageID>
(16) </s11:Header>
(17) <s11:Body>
(18)
<wst:Get/>
(19) </s11:Body>
(20) </s11:Envelope>
The sample request message of Example 2-3 is a [WS-Transfer]
request for the retrieval of a resource's representation. In this case, the
requested representation is the WS-MetadataExchange Metadata element about a Web
service endpoint. The fact that the resource's representation is a mex:Metadata element might be known to the requestor but is not
explicitly encoded in the request message.
Example 2-4 illustrates a
sample response to the request of Example 2-3.
(01) <s11:Envelope
(02) xmlns:s11='http://schemas.xmlsoap.org/soap/envelope/'
(03) xmlns:xs='http://www.w3.org/2001/XMLSchema'
(04) xmlns:wsa='http://www.w3.org/2005/08/addressing'
(05) xmlns:mex='http://www.w3.org/2002/ws/ra/edcopies/ws-mex'
(06) xmlns:wsp='http://www.w3.org/ns/ws-policy'
(07) xmlns:wst='http://www.w3.org/2002/ws/ra/edcopies/ws-tra'
(08) xmlns:wsdl='http://schemas.xmlsoap.org/wsdl/'>
(09) <s11:Header>
(10)
<wsa:Action>
(11)
http://www.w3.org/2002/ws/ra/edcopies/ws-tra/GetResponse
(12)
</wsa:Action>
(13)
<wsa:To>http://client.example.org</wsa:To>
(14)
<wsa:RelatesTo>
(15) urn:uuid:1cec121a-82fe-41da-87e1-3b23f254f128
(16)
</wsa:RelatesTo>
(17) </s11:Header>
(18) <s11:Body>
(19)
<wst:GetResponse>
(20)
<mex:Metadata>
(21)
<mex:MetadataSection
Dialect='wsdl:definitions'>
(22)
<wsdl:definitions>
(23)
<!-- WSDL data removed for brevity -->
(24)
</wsdl:definitions>
(25)
</mex:MetadataSection>
(26)
<mex:MetadataSection
(27)
Dialect='xs:schema'
(28)
Identifier='http://services.example.org/stockquote/schemas'>
(29)
<mex:MetadataLocation>
(30)
http://services.example.org/stockquote/schemas
(31)
</mex:MetadataLocation>
(32)
</mex:MetadataSection>
(33)
<mex:MetadataSection
(34)
Dialect='wsp:Policy'
(35)
Identifier='http://services.example.org/stockquote/policy'>
(36)
<mex:MetadataReference>
(37)
<wsa:Address>
(38)
http://services.example.org/stockquote/policy
(39)
</wsa:Address>
(40)
</mex:MetadataReference>
(41)
</mex:MetadataSection>
(42)
</mex:Metadata>
(43)
</wst:GetResponse>
(44) </s11:Body>
(45) </s11:Envelope>
The message of Example 2-4 is a [WS-Transfer]
response message to the request of Example 2-3. The
content of the [Body] (lines 18-44) is a mex:Metadata
element with metadata about the Web service endpoint (lines 20-42). The mex:Metadata contains three MetadataSections. The first
MetadataSection (lines 21-25) contains the [WSDL11] of
the Web service endpoint. The second MetadataSection (lines 26-32) contains the
location of the XML Schemas [XMLSchema - Part 1], [XMLSchema - Part 2] used by the WSDL document. The
schemas can be retrieved through an HTTP GET request at the identified URL
(lines 29-31). The third MetadataSection (lines 33-41) contains the [WS-Addressing] endpoint reference (lines 36-40) of a [WS-Transfer] resource the representation of which is a
[WS-Policy] document as indicated by the Dialect
attribute (line 34).
While the WS-Policy of the Web service endpoint could be
retrieved using a WS-Transfer Get request directed to the endpoint identified
by the mex:MetadataReference element in lines 36-40 of Example
2-4, some endpoints MAY support explicit requests for metadata via the
GetMetadata operation. Example 2-5 illustrates a
sample GetMetadata request for the [WS-Policy].
(01) <s11:Envelope
(02) xmlns:s11='http://schemas.xmlsoap.org/soap/envelope/'
(03) xmlns:wsa='http://www.w3.org/2005/08/addressing'
(04) xmlns:wsp='http://www.w3.org/ns/ws-policy'
(05) xmlns:mex='http://www.w3.org/2002/ws/ra/edcopies/ws-mex'
>
(06) <s11:Header>
(07)
<wsa:To>http://services.example.org/stockquote</wsa:To>
(08)
<wsa:Action>
(09)
http://www.w3.org/2002/ws/ra/edcopies/ws-mex/GetMetadata
(10)
</wsa:Action>
(11)
<wsa:MessageID>
(12) urn:uuid:73d7edfc-5c3c-49b9-ba46-2480caee43e9
(13)
</wsa:MessageID>
(14)
<wsa:ReplyTo>
(15)
<wsa:Address>http://client.example.org</wsa:Address>
(16)
</wsa:ReplyTo>
(17) </s11:Header>
(18) <s11:Body>
(19)
<mex:GetMetadata>
(20)
<mex:Dialect Type='wsp:Policy'
(21)
Identifier='http://services.example.org/stockquote/policy'/>
(22)
</mex:GetMetadata>
(23) </s11:Body>
(24) </s11:Envelope>
Lines 8-10 in Example 2-5 indicate this is a GetMetadata request. As
lines 19-22 indicate, this request is for the policy of the Web service
endpoint (line 7).
Example 2-6 lists a sample
response to the request in Example 2-5.
(01) <s11:Envelope
(02) xmlns:s11='http://schemas.xmlsoap.org/soap/envelope/'
(03) xmlns:wsa='http://www.w3.org/2005/08/addressing'
(04) xmlns:wsp='http://www.w3.org/ns/ws-policy'
(05) xmlns:mex='http://www.w3.org/2002/ws/ra/edcopies/ws-mex'>
(06) <s11:Header>
(07)
<wsa:To>http://client.example.org</wsa:To>
(08)
<wsa:Action>
(09)
http://www.w3.org/2002/ws/ra/edcopies/ws-mex/GetMetadataResponse
(10)
</wsa:Action>
(11)
<wsa:RelatesTo>
(12) urn:uuid:73d7edfc-5c3c-49b9-ba46-2480caee43e9
(13)
</wsa:RelatesTo>
(14) </s11:Header>
(15) <s11:Body>
(16)
<mex:GetMetadataResponse>
(17)
<mex:Metadata>
(18)
<mex:MetadataSection
(19)
Dialect='wsp:Policy'
(20)
Identifier='http://services.example.org/stockquote/policy'>
(21)
<wsp:Policy>
(22)
<wsp:ExactlyOne>
(23)
<!-- Policy alternatives -->
(24)
</wsp:ExactlyOne>
(25)
</wsp:Policy>
(26)
</mex:MetadataSection>
(27)
</mex:Metadata>
(28)
</mex:GetMetadataResponse>
(29) </s11:Body>
(30) </s11:Envelope>
Lines 8-10 in Example 2-6 indicate this message is a response to a
GetMetadata request, and lines 11-13 indicate that it is a response to the
request in Example 2-5. Lines 17-26 contain a single
MetadataSection (lines 18-26); line 19 indicates that the metadata in this
section is of type, or Dialect, WS-Policy while line 20 identifies a specific
policy document. Line 23 would have contained the policy expressions for the
Web service endpoint to which the GetMetadata request of Example
2-5 was directed.
This section specifies the notations,
namespaces, and terminology used in this specification.
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 [RFC 2119].
This specification uses the following syntax to define
outlines for messages:
·
The syntax appears as an XML instance, but
values in italics indicate data types instead of literal values.
·
Characters are appended to elements and
attributes to indicate cardinality:
o "?" (0 or 1)
o "*" (0 or more)
o "+" (1 or more)
·
The character "|" is used to
indicate a choice between alternatives.
·
The characters "(" and
")" are used to indicate that contained items are to be treated as a
group with respect to cardinality or choice.
·
The characters "[" and
"]" are used to call out references and property names.
·
Ellipses (i.e., "...") indicate
points of extensibility.
·
XML namespace prefixes (see Table
3-1) are used to indicate the namespace of the element being defined.
In addition to Message Information Header properties [WS-Addressing], this specification uses the following
properties to define messages:
[Headers]
Unordered message headers.
[Action]
The value to be used for the wsa:Action IRI.
[Body]
A message body.
These properties bind to a SOAP Envelope as follows:
<s:Envelope>
<s:Header>
[Headers]
<wsa:Action>[Action]</wsa:Action>
...
</s:Header>
<s:Body>[Body]</s:Body>
</s:Envelope>
This specification can be used in terms of XML
Information Set (Infoset) [XML Infoset], even though
the specification uses XML 1.0 terminology. Valid Infoset for this
specification is the one serializable in XML 1.0, hence the use of XML 1.0.
The elements defined in this specification
MAY be extended at the points indicated by their outlines and schema.
Implementations MAY add child elements and/or attributes at the indicated
extension points but MUST NOT contradict the semantics of the parent and/or
owner, respectively. If a receiver does not recognize an extension, the
receiver SHOULD ignore that extension. Senders MAY indicate the presence of an
extension that has to be understood through the use of a corresponding SOAP
Header with a soap:mustUnderstand attribute with the
value "1".
In cases where it is either desirable or
necessary for the receiver of a request that has been extended to indicate that
it has recognized and accepted the semantics associated with that extension, it
is RECOMMENDED that the receiver add a corresponding extension to the response
message. The definition of an extension SHOULD clearly specify how the
extension that appears in the response correlates with that in the
corresponding request.
Extension elements and attributes MUST NOT
use the Web Services Metadata Exchange namespace URI.
The XML namespace URI that MUST be used by
implementations of this specification is:
Table 3-1 lists XML namespaces that
are used in this specification. The choice of any namespace prefix is arbitrary
and not semantically significant.
|
Table 3-1: Prefixes and XML namespaces used in
this specification |
||
|
Prefix |
XML Namespaces |
Specification(s) |
|
s
|
(Either
SOAP 1.1 or 1.2) |
(Either
SOAP 1.1 or 1.2) |
|
s11
|
http://schemas.xmlsoap.org/soap/envelope/
|
|
|
s12 |
http://www.w3.org/2003/05/soap-envelope |
|
|
wsa |
http://www.w3.org/2005/08/addressing |
|
|
wsdl |
http://schemas.xmlsoap.org/wsdl/ |
|
|
wsp |
http://www.w3.org/ns/ws-policy |
|
|
mex |
http://www.w3.org/2002/ws/ra/edcopies/ws-mex |
This specification |
|
xs |
http://www.w3.org/2001/XMLSchema |
|
|
wst |
http://www.w3.org/2002/ws/ra/edcopies/ws-tra |
|
The working group intends to update the value of the Web
Services Metadata Exchange namespace URI each time a new version of this
document is published until such time that the document reaches Candidate
Recommendation status. Once it has reached Candidate Recommendation status, the
working group intends to maintain the value of the Web Services Metadata
Exchange namespace URI that was assigned in the Candidate Recommendation unless
significant changes are made that impact the implementation or break post-CR
implementations of the specification. Also see http://www.w3.org/2001/tag/doc/namespaceState.html
and http://www.w3.org/2005/07/13-nsuri
.
Service Endpoint
A Web service that is addressable using a WS-Addressing endpoint reference. Within the context of this specification, it
is assumed that the consumer's primary goal is to interact with this service.
Metadata Resource
A
specialized Web service that is addressable using either a WS-Addressing
endpoint reference or a URL and whose main purpose is to expose the XML
representation of a piece of metadata associated with a Service Endpoint.
While technically a single Web service can be
both a 'Service Endpoint' as well as a 'Metadata Resource', for the purposes of
clarifying the various expectations of these two types Web services, this
specification will discuss these two concepts (or roles) as distinct entities.
An implementation is not compliant with this
specification if it fails to satisfy one or more of the MUST or REQUIRED level
requirements defined herein. A SOAP Node MUST NOT use the XML namespace
identifier for this specification (listed in 3.3 XML Namespaces) within SOAP Envelopes unless
it is compliant with this specification.
Normative text within this specification takes precedence
over the XML Schema and WSDL descriptions, which in turn take precedence over
outlines, which in turn take precedence over examples.
All messages defined by this specification MUST be sent
to a Web service that is addressable by an EPR (see [WS-Addressing]).
Unless otherwise noted, all IRIs are absolute IRIs and
IRI comparison MUST be performed according to [RFC 3987]
section 5.3.1.
For any message defined by this
specification, any OPTIONAL elements or attributes in the message MAY be used
by senders of the message; however receivers of those messages MUST support
those OPTIONAL elements and attributes, unless other behavior is explicitly
defined by this specification.
Support for the GetMetadata operation by a Web service is
OPTIONAL. If metadata about a Web service endpoint is referenced by a
MetadataReference, which is a [WS-Addressing]
endpoint reference, then the MetadataReference MUST refer to a [WS-Transfer] resource. The referred resource MAY also
support other resource management and access specifications (e.g. HTTP,
WS-ResourceFramework).
The
WS-MetadataExchange Metadata element is a collection of metadata units such as [WSDL11] definitions, [XMLSchema
- Part 1] documents, [WS-Policy] expressions, etc.
Each unit corresponds to metadata for a given scope, domain, or namespace. The
collection of units is represented by a Metadata element, and units within the
collection are represented by MetadataSection elements.
To facilitate processing, MetadataSections are tagged
with a @Dialect and (OPTIONALLY) @Identifier of the metadata unit. To ensure
scalability, a unit of metadata MAY be embedded within its MetadataSection or
MAY be included by reference, either an endpoint reference [WS-Addressing]
(MetadataReference) or a URL (MetadataLocation).
The outline for the Metadata element is:
<mex:Metadata
...>
<mex:MetadataSection Dialect='xs:QName'
Identifier='xs:anyURI'?
...>
(
<mex:MetadataReference
...>
endpoint-reference-type
</mex:MetadataReference>
|
<mex:MetadataLocation
...> xs:anyURI
</mex:MetadataLocation>
|
DialectSpecificElement
)
</mex:MetadataSection> *
xs:any*
</mex:Metadata>
The following describes additional constraints on the
outline listed above:
/mex:Metadata
This contains one MetadataSection child for
each distinct unit of metadata. When there is a large amount of metadata, the
children SHOULD contain MetadataReferences or MetadataLocations instead of the
actual information.
/mex:Metadata/mex:MetadataSection
This represents a single unit of metadata
(e.g., a WSDL definitions, an XML Schema document) for a given scope, domain,
or namespace. A MetadataSection contains exactly one child element, either the
embedded XML for the metadata unit, an endpoint reference to a Metadata
Resource for the metadata unit, or a URL to metadata unit.
/mex:Metadata/mex:MetadataSection/@Dialect
This indicates the type and version of the
metadata unit contained in this MetadataSection (e.g., WSDL version 1.1). This
MUST be the QName of the root element of the metadata.
If there is more than one metadata unit with
the same Dialect, e.g., more than one XML Schema document, including them all,
one per MetadataSection, is explicitly encouraged.
/mex:Metadata/mex:MetadataSection/@Dialect='mex:Metadata'
This Dialect value indicates that the type of
the metadata contained within the MetadataSection is itself a mex:Metadata element. When the Dialect value is used in
conjunction with mex:MetadataReference or
mex:MetadataLocation, the Dialect value provides the ability to include
metadata by reference (an endpoint reference or a URL). Example
8-2 illustrates the use of this Dialect.
/mex:Metadata/mex:MetadataSection/@Identifier
This indicates the Identifier for the
metadata unit in this MetadataSection. Identifier is an absolute IRI. If
omitted, there is no implied value.
The interpretation of Identifier is
Dialect-specific. If the Identifier attribute is present, and the value of the
Dialect attribute of the MetadataSection is one of the values in the table
below, the Identifier attribute MUST have the indicated, corresponding value.
In other cases the value of the Identifier attribute is not constrained.
|
Dialect QName |
@Identifier value |
|
xs:schema |
xs:schema/@targetNamespace |
|
wsdl:definitions |
wsdl:definitions/@targetNamespace |
|
wsp:Policy |
wsp:Policy/@Name |
If there is more than one MetadataSection
with the same identifier, e.g., more than one XML Schema in the same target
namespace, including them all, one per MetadataSection, is explicitly
encouraged.
/mex:Metadata/mex:MetadataSection/mex:MetadataReference
This is an endpoint reference to a metadata
resource and is of type EndpointReferenceType as defined by [WS-Addressing].
The metadata resource MUST support the Get operation [WS-Transfer]
to allow the retrieval of the metadata unit for the MetadataSection's Dialect
and Identifier (if any). When this element is present, it MUST have no element
siblings.
/mex:Metadata/mex:MetadataSection/mex:MetadataLocation
This contains a URL to metadata, and the
metadata MUST be retrievable from that URL using the primary access mechanism
for the scheme of the URL. For example, for an HTTP URL, the metadata MUST be
retrievable by sending an HTTP GET request to the URL. When this element is
present, it MUST have no element siblings.
/mex:Metadata/mex:MetadataSection/DialectSpecificElement
When any element other than MetadataReference
or MetadataLocation is present, the element is to be interpreted as the
representation of the metadata unit associated with the MetadataSection's
Dialect and Identifier.
A
resource is referred to as a 'metadata resource' when its representation is of
type mex:Metadata, as defined in 4 Web Services Metadata Collection,
or any other document format (e.g. [XMLSchema - Part 1],[XMLSchema - Part 2], [WSDL11], [WS-Policy]) that is used to describe some aspect of a
service.
When a metadata resource is addressable by an endpoint reference
the resource's representation MUST be retrievable using the Get operation
defined in [WS-Transfer] and MAY be updated as any
other [WS-Transfer] resource. When the resource is
addressed by a URL the resource's representation MUST be retrievable using an
HTTP GET and MAY be updated as any other HTTP resource.
To retrieve the representation of a metadata resource, a
requester MAY send a [WS-Transfer] Get request
message to the metadata resource's endpoint reference, or it MAY send an HTTP
GET to the metadata resource's IRI. These will fetch a one-time snapshot of the
metadata. The metadata associated with a service endpoint MAY be available as
multiple metadata resources.
The representation of a metadata resource MAY be a mex:Metadata element which MAY contain one or more
mex:MetadataSection children. Each MetadataSection is identified by a specific
Dialect and contains information whose format and content depend on the
Dialect.
A Web service endpoint MAY have one or more associated
metadata resources.
It is important to note that metadata resources are
themselves services. In other words, a metadata resource can still accept
GetWSDL or GetMetadata requests, but such requests would apply to the metadata
about the metadata resource and not the original service that the metadata
resource describes.
This
specification defines two mechanism by which a requester can ask a
WS-MetadataExchange compliant 'service endpoint' for its metadata: the GetWSDL
operation and the GetMetadata operation.
GetWSDL
provides the means to obtain a starting point for constructing the
relationships between the metadata documents that apply to a service. It is
useful in situations when the requester has no prior knowledge of these
relationships. The GetMetadata operation is useful in cases where the requester
is already aware of these relationships or when it wishes to obtain a specific
metadata document.
A requester MAY send a GetWSDL request
message to an endpoint to retrieve the service's WSDL metadata document. This
operation MUST be supported by compliant WS-MetadataExchange service endpoints.
Note, the GetWSDL operation is a SOAP-based equivalent feature to the commonly
supported HTTP GET targeted at an endpoint's URL appended with "?wsdl".
Through examination of this WSDL document,
and by following any references within it, a requester MUST be able to retrieve
any metadata needed to interact with the service. For example, the schema used
by the service might be embedded within the WSDL or could be available by
following a xs:import element. Likewise, as discussed
in 9 Exposing Metadata
for Implicitly Defined Features through the inclusion of policy
assertions and nested metadata (or metadata references) within those policy
assertions, a requester MUST be able to determine the set of implicit features
available and any related metadata associated with those features.
The normative outline for a GetWSDL request is:
[Action]
http://www.w3.org/2002/ws/ra/edcopies/ws-mex/GetWSDL
[Body]
<mex:GetWSDL ...>
xs:any*
</mex:GetWSDL>
If the endpoint accepts a GetWSDL request, it MUST reply
with a GetWSDLResponse message. The normative outline for a GetWSDLResponse is:
[Action]
http://www.w3.org/2002/ws/ra/edcopies/ws-mex/GetWSDLResponse
[Body]
<mex:GetWSDLResponse ...>
xs:any*
</mex:GetWSDLResponse>
The following describes additional, normative constraints
on the outline listed above:
[Body]/mex:GetWSDLResponse/wsdl:definitions
When present this OPTIONAL element contains
the WSDL metadata document of the endpoint. The absence of this element
indicates that the endpoint does not have any WSDL document, or additional
metadata, associated with it.
This operation is safe; it will not result in any side
effect imputable to the requester. This means that in case of an underlying
protocol error that might get unnoticed, resending the same request can be done
automatically.
A requester MAY send a
GetMetadata request message to an endpoint to retrieve the metadata associated
with that endpoint. This operation MAY be supported by WS-MetadataExchange
compliant service endpoints. Observe that, in the case where a service endpoint
is also a [WS-Transfer]
resource, the [WS-Transfer] Get operation allows requesters
to retrieve the resource representation associated with that endpoint (i.e. the
"data"), while the GetMetadata operation can be used to retrieve that
endpoint's metadata. The normative outline for a GetMetadata request is:
[Action]
http://www.w3.org/2002/ws/ra/edcopies/ws-mex/GetMetadata
[Body]
<mex:GetMetadata ...>
<mex:Dialect
Type='xs:QName'
Identifier='xs:anyURI'
?
Content='xs:anyURI'
? .../> *
xs:any*
</mex:GetMetadata>
The following describes additional, normative constraints
on the outline listed above:
[Body]/mex:GetMetadata/mex:Dialect
When this repeating OPTIONAL element is
present, the response MUST include only MetadataSections corresponding to
metadata specified by the combination of the QName, Identifier and Content
attributes of each of the Dialect elements. For each Dialect element if there
is no metadata for that combination of attributes then the response MUST NOT include any MetadataSections for that Dialect element.
When this element is not present, the
endpoint MUST return all available metadata.
[Body]/mex:GetMetadata/mex:Dialect@Type
This REQUIRED attribute specifies the
Metadata Dialect. The response MUST only include MetadataSections corresponding
to the Dialect specified by this QName. If the receiver does not have any
MetadataSections of this indicated Dialect, the response MUST include zero
MetadataSections for this QName.
[Body]/mex:GetMetadata/mex:Dialect@Identifier
When this OPTIONAL attribute is present, the
response MUST include only MetadataSections with the indicated identifier; if
the receiver does not have any MetadataSections of the indicated identifier,
the response MUST include zero MetadataSections for this QName/Identifier pair.
When this attribute is not present, the implied value is any identifier. If
multiple MetadataSections have the indicated Dialect and Identifier then all of
them MUST be returned.
[Body]/mex:GetMetadata/mex:Dialect@Content
When this OPTIONAL attribute is present, the
response MUST include only MetadataSections of this specified content form. If
the specified content form is not available, or not known, then the response
MUST include zero MetadataSections of the specified form for this
QName/Identifier pair. This specification defines the following content form
IRIs:
|
Content Form IRI |
Form |
|
http://www.w3.org/2002/ws/ra/edcopies/ws-mex/Content/EPR
|
A MetadataReference element is returned |
|
http://www.w3.org/2002/ws/ra/edcopies/ws-mex/Content/URI
|
A MetadataLocation element is returned |
|
http://www.w3.org/2002/ws/ra/edcopies/ws-mex/Content/Metadata
|
The metadata is embedded |
|
http://www.w3.org/2002/ws/ra/edcopies/ws-mex/Content/Any
|
The service is free to choose any content form
|
|
http://www.w3.org/2002/ws/ra/edcopies/ws-mex/Content/All
|
The service MUST return all available content
forms |
When not present the default value is
"http://www.w3.org/2002/ws/ra/edcopies/ws-mex/Content/Any".
If an endpoint accepts a GetMetadata request, it MUST
reply with a GetMetadataResponse message. The normative outline for a
GetMetadataResponse is:
[Action]
http://www.w3.org/2002/ws/ra/edcopies/ws-mex/GetMetadataResponse
[Body]
<mex:GetMetadataResponse>
<mex:Metadata
...> ... </mex:Metadata>
xs:any*
</mex:GetMetadataResponse>
The following describes additional, normative constraints
on the outline listed above:
[Body]/mex:GetMetadataResponse/mex:Metadata
The body of the response message MUST contain
one mex:Metadata element as defined in 4 Web Services Metadata Collection.
This operation is safe; it will not result in any side
effect imputable to the requester. This means that in case of an underlying
protocol error that might get unnoticed, resending the same request can be done
automatically.
While
a service's metadata can be embedded in many different places (for example,
within an EPR, or within a feature's policy assertion), it might be more
convenient to include a reference to the metadata rather than include the
actual metadata itself. This might be simply for brevity's sake or so the same
copy of metadata can be used in many different locations without the overhead
of duplicating it.
This
specification defines two mechanisms by which a metadata reference can be used
in place of metadata. These mechanisms do not modify any semantic meaning that
might be associated with the presence of the metadata at any particular
location - they are simply a syntactical alternative to embedding the
referenced metadata.
The mex:Location element MAY be used to specify a reference to an
HTTP metadata resource. A requester MAY use an HTTP GET to the indicated URL to
retrieve the metadata.
The outline for the mex:Location element is:
<mex:Location URL="xs:anyURI" Type="xs:QName"
Identifier="xs:anyURI"? ...>
xs:any*
<mex:Location>
The following describes
additional constraints on the outline listed above:
/mex:Location
This element contains a reference to an HTTP metadata resource.
/mex:Location@URL
This REQUIRED attribute contains the URL of an HTTP metadata resource. This
resource MUST support retrieval of the metadata via an HTTP GET request.
/mex:Location@Type
This REQUIRED attribute indicates the QName of the referenced metadata.
This can be used in deciding whether or not to retrieve the metadata.
/mex:Location@Identifier
This OPTIONAL attribute indicates the Identifier for the metadata being
referenced. Identifier is an absolute IRI. If omitted, there is no implied
value.
The mex:Reference element MAY be used to specify a reference to a
WS-Transfer metadata resource. A requester MAY use a WS-Transfer Get to the
indicated EPR to retrieve the metadata
The outline for the mex:Reference element is:
<mex:Reference Type="xs:QName"
Identifier="xs:anyURI"? ...>
endpoint-reference-type
<mex:Reference>
The following describes
additional constraints on the outline listed above:
/mex:Reference
This element is an endpoint reference to a metadata resource. This resource
MUST support retrieval of the metadata via a WS-Transfer Get request.
/mex:Reference@Type
This REQUIRED attribute indicates the QName of the referenced metadata.
This can be used in deciding whether or not to retrieve the metadata.
/mex:Reference@Identifier
This OPTIONAL attribute indicates the Identifier for the metadata being referenced.
Identifier is an absolute IRI. If omitted, there is no implied value.
The following examples
show how metadata might appear in various locations:
(01) <wsa:Endpoint ...>
(02) <wsa:Address> http://example.com </wsa:Address>
(03) <wsa:Metadata>
(04)
<wsdl:definitions>
(05) ...
(06)
</wsdl:definitions>
(07) </wsa:Metadata>
(08) </wsa:Endpoint>
Example 7-1 shows an endpoint
reference with the endpoint's WSDL embedded. This saves the user of this EPR
from having to retrieve the WSDL. This same endpoint reference might have been
constructed by using a metadata reference instead, as shown in Example 7-2:
(01) <wsa:Endpoint ...>
(02) <wsa:Address> http://example.com </wsa:Address>
(03) <wsa:Metadata>
(04) <mex:Location URL="http://example.com?wsdl"
(05)
Type="wsdl:definitions"/>
(06) </wsa:Metadata>
(07) </wsa:Endpoint>
Example 7-2 shows the same
endpoint reference but rather than embedding the endpoint's WSDL directly in
the EPR a mex:Location is used to indicate that if the
user of the EPR needs the service's WSDL then it can retrieve it from the
specified URL.
The following example WSDL shows how support for a
particular feature might be indicated:
(01) <wsdl:definitions>
(02) ...
(03) <wsdl:service name="stockQuote">
(04) <wsdl:port binding="..." name="...">
(05)
<soap:address
location="http://example.com"/>
(06)
</wsdl:port>
(07) <wsp:Policy>
(08)
<wse:EventSource>
(09)
<wse:FormatName
uri="http://www.w3.org/2002/ws/ra/edcopies/ws-evt/DeliveryFormats/Unwrap"/>
(10)
<wsdl:definitions>
(11)
...
(12)
<wsdl:service ...>
(13)
...
(14)
<wsp:Policy xmlns:wsp="..."
wmlns:sp="...">
(15)
<sp:SymmetricBinding>
(16)
<wsp:Policy>
(17)
<sp:ProtectionToken>
(18)
<wsp:Policy>
(19)
<sp:SecureConversationToken ...>
(20)
...
(21)
</sp:SecureConversationToken>
(22)
</wsp:Policy>
(23)
</sp:ProtectionToken>
(24)
</wsp:Policy>
(25)
</sp:SymmetricBinding>
(26)
</wsp:Policy>
(27)
</service>
(28)
</wsdl:definitions>
(29)
</wse:EventSource>
(30) </wsp:Policy>
(31) </wsdl:service>
(32) </wsdl:definitions>
This example shows the
WSDL for a stockQuote service. As indicated on lines (08) through (29), this
endpoint also acts as a WS-Eventing event source. The endpoint supports sending
notification in the "Unwrapped" format - line (09). Line (10) through
(28) provides the WSDL for the WS-Eventing features. In particular, lines (14)
through (26) indicates that the WS-Eventing messages need to be protected using
WS-SecureConversation.
This example could have
also been written by using metadata references:
(01) <wsdl:definitions>
(02) ...
(03) <wsdl:service name="stockQuote">
(04) <wsdl:port binding="..." name="...">
(05)
<soap:address
location="http://example.com"/>
(06)
</wsdl:port>
(07) <wsp:Policy>
(08)
<wse:EventSource>
(09)
<wse:FormatName
uri="http://www.w3.org/2002/ws/ra/edcopies/ws-evt/DeliveryFormats/Unwrap"/>
(10)
<mex:Location
URL="http://example.com/EventingWSDL"
(11)
Type="wsdl:definitions"/>
(12)
</wse:EventSource>
(13) </wsp:Policy>
(14) </wsdl:service>
(15) </wsdl:definitions>
In this case the
embedded WS-Eventing WSDL that is supported by the stockQuote service has been
replaced by a mex:Location element. The WSDL can now
be retrieved via an HTTP GET to the URL specified on line (10).
The issuer of a WS-Addressing endpoint
reference MAY include metadata for that service inside the endpoint reference
itself. This mechanism simplifies the bootstrapping of the service interaction
on the requester side by avoiding additional calls to retrieve the Web service
metadata for the service endpoint.
Embedding the metadata (including a
mex:Metadata element) inside an endpoint reference's wsa:Metadata element
allows the issuer of the endpoint reference to include metadata by value or by
reference, according to the options described in 4 Web Services Metadata Collection and
7 Metadata References. The outline of
a [WS-Addressing] endpoint reference which includes Web
services metadata is as follows:
<wsa:EndpointReference
...>
<wsa:Address>xs:anyURI</wsa:Address>
<wsa:ReferenceParameters> xs:any*
</wsa:ReferenceParameters> ?
<wsa:Metadata>
( <mex:Location .../> |
<mex:Reference ...> ...
</mex:Reference> |
<mex:Metadata ...> ...
</mex:Metadata> ) *
xs:any*
</wsa:Metadata> ?
xs:any*
</wsa:EndpointReference>
/wsa:EndpointReference/wsa:Metadata/mex:Location
This repeating OPTIONAL element MAY appear as
a direct child of the wsa:Metadata endpoint reference
element.
/wsa:EndpointReference/wsa:Metadata/mex:Reference
This repeating OPTIONAL element MAY appear as
a direct child of the wsa:Metadata endpoint reference
element.
/wsa:EndpointReference/wsa:Metadata/mex:Metadata
This repeating OPTIONAL element MAY appear as
a direct child of the wsa:Metadata endpoint reference
element. Note: It MAY also be possible to combine multiple mex:Metadata elements into one mex:Metadata element, however,
it is RECOMMENDED that multiple mex:Metadata elements be used.
/wsa:EndpointReference/wsa:Metadata/xs:any
This extensibility point, defined by
WS-Addressing, can be used for embedding additional metadata.
In example Example 8-1, a [WS-Addressing] endpoint reference contains WSDL metadata
by value that identifies the binding used to access the service endpoint:
(01) <wsa:EndpointReference
(02) xmlns:wsa='http://www.w3.org/2005/08/addressing'>
(03)
<wsa:Address>http://services.example.org/stockquote</wsa:Address>
(04) <wsa:Metadata>
(05) <wsdl:definitions
(06)
name='StockQuote'
(07)
targetNamespace='http://services.example.org/stockquote'
(08)
xmlns:tns='http://services.example.org/stockquote'
(09)
xmlns:wsoap='http://schemas.xmlsoap.org/wsdl/soap/'
(10)
xmlns:wsdl='http://schemas.xmlsoap.org/wsdl/'
(11)
xmlns:wsp='http://www.w3.org/ns/ws-policy'
(12)
xmlns:msgs='http://services.example.org/stockquote/schemas
(13)
xmlns:xs='http://www.w3.org/2001/XMLSchema'>
(14)
<wsdl:import
(15)
namespace='http://services.example.org/stockquote'
(16)
location='http://services.example.org/stockquote/schemas'/>
(17)
<wsdl:portType name='StockQuotePortType'>
(18)
<wsdl:operation name='GetLastTradePrice'>
(19)
<wsdl:input
message='msgs:GetLastTradePriceInput'
(20)
name='GetLastTradePriceInput'/>
(21)
<wsdl:output
message='msgs:GetLastTradePriceOutput'
(22) name='GetLastTradePriceOutput'/>
(23)
</wsdl:operation>
(24)
</wsdl:portType>
(25)
<wsdl:binding name='StockQuoteBinding'
(26)
type='tns:StockQuotePortType'>
(27)
<wsp:PolicyReference
(28)
URI='http://services.example.org/stockquote/policy' />
(29)
<wsoap:binding style='document'
(30)
transport='http://schemas.xmlsoap.org/soap/http'/>
(31)
<wsdl:operation name='GetLastTradePrice'>
(32)
<wsoap:operation
soapAction='http://services.example.org/stockquote/GetLastTradePrice' />
(33)
<wsdl:input
name='GetLastTradePriceInput'>
(34)
<wsoap:body use='literal'/>
(35)
</wsdl:input>
(36)
<wsdl:output name='GetLastTradePriceOutput'>
(37)
<wsoap:body use='literal'/>
(38)
</wsdl:output>
(39)
</wsdl:operation>
(40)
</wsdl:binding>
(41)
<wsdl:service name='StockQuoteService'>
(42)
<wsdl:port name='StockQuotePort'
(43)
binding='tns:StockQuoteBinding' >
(44)
<wsoap:address
(45)
location='http://services.example.org/stockquote'/>
(46)
</wsdl:port>
(47)
</wsdl:service>
(48)
</wsdl:definitions>
(49) </wsa:Metadata>
(50) </wsa:EndpointReference>
Lines 5-48 show the way the WSDL of the Web
service endpoint is included 'by value'.
(01) <wsa:EndpointReference ...>
(02) <wsa:Address>http://services.example.org/stockquote</wsa:Address>
(03) <wsa:Metadata>
(04) <mex:Reference Type="mex:Metadata" ...>
(05)
<wsa:Address>
(06)
http://services.example.org/stockquote/metadata
(07)
</wsa:Address>
(08) <wsa:Metadata>
(09)
<wsdl:definitions ...>
(10)
<!-- WS-Transfer WSDL portType plus binding
-->
(11)
</wsdl:definitions>
(12)
</wsa:Metadata>
(13) </mex:Reference>
(14) </wsa:Metadata>
(15) </wsa:EndpointReference>
Example 8-2 shows an example of a
Web service endpoint reference in which the Metadata element contains a single
mex:Reference element to a metadata resource (lines
4-13) the representation of which is mex:Metadata as hinted by the value of the
Type attribute (line 4). The metadata reference contains a Metadata element
(lines 8-12) which contains the necessary metadata for interacting with the
metadata resource through [WS-Transfer] operations. Since
the mex:Reference is an endpoint reference to a [WS-Transfer] resource, the embedded metadata includes
the [WS-Transfer] WSDL portType and the necessary
binding information for communicating with that resource.
(01) <wsa:EndpointReference ...>
(02)
<wsa:Address>http://services.example.org/stockquote</wsa:Address>
(03) <wsa:Metadata>
(04) <mex:Reference
Type='mex:Metadata'>
(05)
<wsa:Address>
(06)
http://services.example.org/stockquote/metadata
(07)
</wsa:Address>
(08)
<wsa:Metadata>
(09)
<!-- Ref to the WS-Transfer WSDL -->
(10)
<mex:Location
URL='http://example.org/sq/TransferWSDL'
(11)
Type='wsdl:definitions'/>
(12)
</wsa:Metadata>
(13) </mex:Reference>
(14) </wsa:Metadata>
(15) </wsa:EndpointReference>
Example 8-3 shows an
alternative way to represent Example 8-2. It shows an
example of a Web service endpoint reference in which the Metadata element
contains a single mex:Reference element to a metadata
resource (lines 4-13) the representation of which is mex:Metadata as hinted by
the value of the Type attribute (line 4). The metadata reference contains a
Metadata element (lines 8-12) which contains the necessary metadata for
interacting with the metadata resource through [WS-Transfer]
operations. Since the mex:Reference is an endpoint
reference to a [WS-Transfer] resource, the
mex:Location element is a reference to the [WS-Transfer]
WSDL which includes the portType and the necessary binding information for
communicating with that resource.
In example Example 8-4, an
endpoint reference to a service endpoint contains the metadata to allow
requesters to issue a GetWSDL request against it.
(01) <wsa:EndpointReference ...>
(02)
<wsa:Address>http://services.example.org/stockquote</wsa:Address>
(03) <wsa:Metadata>
(04) <wsp:PolicyAttachment>
(05)
<wsp:AppliesTo>
(06)
<!-- Following according to:
http://www.w3.org/TR/ws-policy-attach/#uri-domain-expression -->
(07)
<!-- with URI syntax from:
(08)
http://www.w3.org/TR/wsdl11elementidentifiers/ -->
(09)
<wsp:URI>
(10)
http://www.w3.org/2002/ws/ra/edcopies/ws-mex#wsdl1.PortTypeOperation(GetWSDL)
(11)
</wsp:URI>
(12)
</wsp:AppliesTo>
(13)
<wsp:Policy> ... </wsp:Policy>
(14) </wsp:PolicyAttachment>
(15) </wsa:Metadata>
(16) </wsa:EndpointReference>
Example 8-4 shows an example of an
endpoint reference to a service endpoint. The endpoint reference contains
metadata associated with the service endpoint (lines 3-15) and the Policy
metadata (lines 4-14) which contains the necessary metadata for interacting
with the endpoint through WS-MetadataExchange. The metadata for the
WS-MetadataExchange interaction is of policy attachment (line 4). The policy
attachment (lines 4-14) defines the policy (line 13) and the GetWSDL operation
to which the policy applies (lines 5-12).
Alternatively, Example 8-4 could
have been written with the WS-MetadataExchange Policy Assertion embedded
directly into the EPR along with the necessary Policy Assertions, as shown in Example 8-5:
(01) <wsa:EndpointReference ...>
(02)
<wsa:Address>http://services.example.org/stockquote</wsa:Address>
(03) <wsa:Metadata>
(04) <wsp:Policy>
(05)
<mex:MetadataExchange>
(06)
<wsp:Policy> ... </wsp:Policy>
(07)
</mex:MetadataExchange>
(08) </wsp:Policy>
(09) </wsa:Metadata>
(10) </wsa:EndpointReference>
Example 8-5 shows an
example of a endpoint reference to a service endpoint.
The endpoint reference contains Policy metadata that can be used to properly
interact with the service. In this case the Policy contains the mex:MetadataExchange Policy Assertion (lines 5-7) indicating
that it supports the WS-MetadataExchange specification. Line 6 contains a
Policy Assertion that further qualifies how a requester would invoke the
WS-MetadataExchange operations. For example, if the Policy
Assertion on line 6 might contains a security assertions to indicate how
then all WS-MetadataExchange messages are to be
constructed exchanges would need to be protected using the
specified security mechanism.
Note: The WS-RA WG is interested in Last Call feedback on
the use of nested policy expressions.
It is desirable for components that provide
EPRs to other components to be able to efficiently communicate the effective
policies of the endpoints referenced by those EPRs. For example, a subscriber
might wish to indicate to an event source that the notification messages sent
as part of a subscription needs to be digitally signed. Although the mechanisms
described in 8.1 Endpoint
References Containing Metadata can be used to communicate the complete
set of policies associated with an endpoint, the relationship of these policies
to specific bindings, operations, or messages cannot be determined without
additional information such as WSDL documents or wsp:PolicyAttachment
elements.
A single wsp:Policy or
wsp:PolicyReference element MAY appear as a child of the
/wsa:EndpointReference/wsa:Metadata element.
<wsa:EndpointReference>
<wsa:Address> xs:anyURI
</wsa:Address>
<wsa:ReferenceParameters> xs:any*
</wsa:ReferenceParameters>
<wsa:Metadata>
( <wsp:Policy
...> ... </wsp:Policy> |
<wsp:PolicyReference ...> ... </wsp:PolicyReference> )
?
</wsa:Metadata>
</wsa:EndpointReference>
If multiple alternatives are desired, the operators
defined in [WS-Policy] can be used to specify such
alternatives within the single wsp:Policy element or
the element referenced by the wsp:PolicyReference.
Policies that appear in an endpoint reference in this
manner have Endpoint Policy Subject. Endpoint Policy Subject is defined as
follows:
The wsp:Policy or
wsp:PolicyReference element, when present, represents the capabilities and
requirements of the endpoint referenced by the EPR as defined by Section 3,
"Policy Model", in the [WS-Policy]
specification. Policy attached to an EPR in this manner MUST be applicable to
all message exchanges using the endpoint referenced by that EPR.
(01) <wse:NotifyTo
xmlns:wsa="http://www.w3.org/2005/08/addressing"
(02)
xmlns:wse="http://www.w3.org/2002/ws/ra/edcopies/ws-evt">
(03)
<wsa:Address>http://www.example.com/EventSink/OnPriceChange</wsa:Address>
(04) <wsa:ReferenceParameters>
(05) ...
(06) </wsa:ReferenceParameters>
(07) <wsa:Metadata>
(08) <wsp:Policy xmlns:wsp="..."
wmlns:sp="...">
(09)
<sp:SymmetricBinding>
(10)
<wsp:Policy>
(11)
<sp:ProtectionToken>
(12)
<wsp:Policy>
(13)
<sp:SecureConversationToken ...>
(14)
...
(15)
</sp:SecureConversationToken>
(16)
</wsp:Policy>
(17)
</sp:ProtectionToken>
(18)
</wsp:Policy>
(19)
</sp:SymmetricBinding>
(20) </wsp:Policy>
(21) </wsa:Metadata>
(22) </wse:NotifyTo>
Example 8-6 shows a WS-Eventing
NotifyTo EPR that refers to the endpoint to which an event source sends notification
messages. Attached to this EPR is a Policy (lines 8-20) that indicates that
WS-SecureConversation needs to be used when sending messages to this endpoint.
Note that in some cases the context in which an EPR
appears might imply the version of SOAP that messages addressed to that EPR are
to use. In this example, without an
explicit use of the SOAP assertion, the Notifications will most likely be sent
using the same version of SOAP that was used to carry the Subscribe message.
The [WS-Addressing] specification
discusses caveats to the validity of Metadata information. These apply to
policies contained within the wsa:Metadata element as
discussed in this section.
The relationship, if any, between policies contained
within the wsa:Metadata element and any other policies that might apply to the
endpoint referred to by the containing EPR (e.g. policies that might appear in
a WSDL document that describes one or more of the services offered by that
endpoint) is not defined by this specification.
An endpoint MAY indicate
that it supports a specific feature by including the feature's policy assertion
within its WSDL. By doing so, the endpoint is indicating that feature
operations are supported by that endpoint even though they are implicit and do
not explicitly appear in its WSDL. An example of this is an endpoint that
indicates the use of WS-Transfer [WS-Transfer]
by the use of the wst:TransferResource WS-Policy [WS-Policy] assertion.
The Feature WSDL (the WSDL associated with these implicit
operations) MAY appear within a Feature Policy assertion and can be annotated
to indicate any endpoint specific metadata that might be needed by clients
interacting with this service. For example, the WSDL can have policy assertions
that indicate a particular security mechanism used to protect the feature's
operations supported by this endpoint. When a Feature WSDL does not provide a
concrete endpoint, the consumer MUST use the concrete aspects of the endpoint's
WSDL.
An endpoint MAY choose to expose additional metadata
about the feature by including the feature specific metadata within the
feature's policy assertion. For example, an endpoint that also supports
WS-Eventing might choose to have the following WS-Eventing Policy assertion
defined:
(01) <wsp:Policy>
(02) <wse:EventSource>
(03) <wse:FormatName
(04)
URI="http://www.w3.org/2002/ws/ra/edcopies/ws-evt/DeliveryFormats/Unwrap">
(05) </wse:FormatName>
(06) <wsevd:EventDescriptions>
(07) <wsevd:types>
(08) <xs:schema
targetNamespace="http://www.example.org/oceanwatch">
(09)
<xs:include
(10)
schemaLocation="http://www.example.org/schemas/oceanwatch.xsd"/>
(11)
<xs:element name="WindReport"
type="ow:WindReportType"/>
(12) </xs:schema>
(13) </wsevd:types>
(14) <wsevd:eventType name="sq" element="sq:Quote"
(15) actionURI="urn:Quote"/>
(16) </wsevd:EventDescriptions>
(17) <wsp:Policy> ...security policies... </wsp:Policy>
(18) </wse:EventSource>
(19) </wsp:Policy>
When this policy
assertion appears in a service's WSDL it indicates that the service supports
WS-Eventing, it supports sending notifications using the 'Unwrap' format, and
that it generates exactly one type of event - a <sq:Quote> event. The
Policy Assertion on line 17 indicates that the nested policy assertions apply
to the WS-Eventing operations. For example, if line 17 includes some security
related assertions then the WS-Eventing operations would need to be secured
using those security mechanisms.
When Feature Policy
Assertions contain nested Policy Assertions (as show above in line 17), those
assertions have Endpoint Policy Subject and apply to all message exchanges
related to the feature.
Note: The WS-RA WG is
interested in Last Call feedback on the use of nested policy expressions.
If there were additional
WS-Eventing metadata available, for example a specialized Feature WSDL
document, then they would appear as a child of the wse:EventSource
element as well.
The following shows the
same WS-Eventing Policy Assertion from Example 9-1 with an embedded copy of the WS-Eventing
WSDL. As discussed above, this WSDL might be annotated to specify additional
constrains on the WS-Eventing message exchanges.
(01) <wsp:Policy>
(02)
<wse:EventSource>
(03) <wse:FormatName
(04)
URI="http://www.w3.org/2002/ws/ra/edcopies/ws-evt/DeliveryFormats/Unwrap">
(05) </wse:FormatName>
(06) <wsevd:EventDescriptions>
(07) <wsevd:types>
(08) <xs:schema
targetNamespace="http://www.example.org/oceanwatch">
(09) <xs:include
(10) schemaLocation="http://www.example.org/schemas/oceanwatch.xsd"/>
(11) <xs:element name="WindReport"
type="ow:WindReportType"/>
(12) </xs:schema>
(13) </wsevd:types>
(14) <wsevd:eventType
name="sq" element="sq:Quote"
(15) actionURI="urn:Quote"/>
(16) </wsevd:EventDescriptions>
(17) <wsdl:definitions>
...ws-eventing wsdl... </wsdl:definitions>
(18)
</wse:EventSource>
The following shows a sample WS-Eventing wse:NotifyTo endpoint reference that might appear as part of a
Subscribe request. Lines 05-08 indicate that WS-ReliableMessaging is required
when sending notifications to this endpoint. The mex:Location
element, lines 06-07, is a reference to the WS-ReliableMessaging WSDL that the
event source will need to use when transmitting the WS-ReliableMessaging
protocol messages for those notifications. For example, this WSDL might include
security policy assertions or perhaps binding information that indicates there
is a specific endpoint to which those protocol messages are to be sent - if it
is different from the address specified on line 02.
(01) <wse:NotifyTo>
(02) <wsa:Address>
http://example.com </wsa:Address>
(03) <wsa:Metadata>
(04) <wsp:Policy>
(05) <wsrmp:RMAssertion>
(06)
<mex:Location URL='http://example.com/RMWSDL'
(07)
Type='wsdl:definitions'/>
(08) </wsrmp:RMAssertion>
(09) </wsp:Policy>
(10) </wsa:Metadata>
(11) </wse:Notify>
It is strongly RECOMMENDED that the
communication between Web services be secured using the mechanisms described in
WS-Security [WS-Security]. In
order to properly secure messages, the body and all relevant headers need to be
included in the signature. Specifically, any standard messaging headers, such
as those from WS-Addressing [WS-Addressing], need to be
signed with the body in order to "bind" the two together.
Different security mechanisms might be desired depending
on the frequency of messages. For example, for infrequent messages, public key
technologies might be adequate for integrity and confidentiality. However, for
high-frequency events, it might be more performant to establish a security
context for the events using the mechanisms described in [WS-Trust]
and [WS-SecureConversation]. Note that if a
shared secret is used it is RECOMMENDED that derived keys be used to strengthen
the secret as described in WS-SecureConversation.
Requests for metadata that are not available to anonymous
parties are strongly RECOMMENDED to require usage of WS-Security so that the
requester can be authenticated and authorized to access the indicated metadata.
Similarly, integrity and confidentiality SHOULD be used whenever metadata has
restricted access.
Recipients of metadata are RECOMMENDED to validate the
signature to authenticate and verify the integrity of the data. Specifically,
recipients SHOULD verify that the sender has the right to "speak" for
the metadata. This is important because some metadata, such as schemas, have
embedded target IRIs that might be outside the scope of the sender.
Additionally, some metadata formats, such as policies [WS-Policy], can have embedded security semantics. These
SHOULD be verified using the same considerations outlined in this section.
The following list summarizes common classes of attacks
that apply to this protocol and identifies the mechanism to prevent/mitigate
the attacks:
·
Message alteration -
Alteration is prevented by including signatures of the message information
using WS-Security.
·
Message disclosure -
Confidentiality is preserved by encrypting sensitive data using WS-Security.
·
Key integrity -
Key integrity is maintained by using the strongest algorithms possible (by
comparing secured policies - see [WS-Policy] and [WS-SecurityPolicy])
·
Authentication -
Authentication is established using the mechanisms described in WS-Security and
WS-Trust. Each message is authenticated using the mechanisms described in
WS-Security
·
Accountability -
Accountability is a function of the type of and strength of the key and
algorithms being used. In many cases, a strong symmetric key provides
sufficient accountability. However, in some environments, strong PKI signatures
are needed.
·
Availability -
Metadata services are subject to a variety of availability attacks such as
application-level denial of service. It is RECOMMENDED that the mechanisms
described in WS-Security be considered as mitigations for some forms of
attacks. Other attacks, such as network-level denial of service are harder to
avoid. Note that both of these classes of attack are outside the scope of this
specification.
·
Replay -
Messages can be replayed for a variety of reasons. To detect and eliminate this
attack, mechanisms SHOULD be used to identify replayed messages such as the
timestamp/nonce outlined in WS-Security. Alternatively, and OPTIONALLY, other
technologies, such as sequencing, can also be used to prevent replay of
application messages.
An endpoint MAY indicate its support of
WS-MetadataExchange, or its features, by including the MetadataExchange Policy
assertion within its WSDL. By doing so the endpoint is indicating that the
corresponding WS-MetadataExchange operations are supported by that endpoint
even though they are implicit and do not explicitly appear in its WSDL (i.e.
the WS-MetadataExchange operations do not appear in the WSDL that MAY be
retrievable by using a WS-MetadataExchange GetWSDL to that endpoint).
The WS-MetadataExchange WSDL containing the
operations indicated by the MetadataExchange Assertion MAY be exposed by
including the WSDL as a child of the MetadataExchange Policy assertion or by
including a reference to it using the mex:Location or
mex:Reference elements (as described in 7 Metadata References).
The WS-MetadataExchange WSDL can be annotated to indicate
any endpoint specific metadata that might be needed by clients interacting with
the WS-MetadataExchange operations. For example, the WSDL MAY have policy
assertions that indicate a particular security mechanism used to protect the
WS-MetadataExchange operations supported by this endpoint.
Services indicate
support for the WS-MetadataExchange specification through the use of the Web
Services Policy - Framework [WS-Policy]
and Web Services Policy - Attachment [WS-PolicyAttachment]
specifications.
This specification defines a policy assertion (mex:MetadataExchange). The normative outline of this assertion
is:
<mex:MetadataExchange
...>
<mex:GetMetadataSupported ...>
<mex:MetadataExchangeDialect
Type="xs:QName"
...>
<mex:MetadataContent URI="xs:anyURI" ...>
xs:any*
</mex:MetadataContent> *
</mex:MetadataExchangeDialect>
*
xs:any*
</mex:GetMetadataSupported> ?
xs:any*
</mex:MetadataExchange>
The following describes additional, normative constraints
on the outline listed above:
/mex:MetadataExchange
This policy assertion has Endpoint Policy
Subject. When present in a policy alternative, it indicates that the
WS-MetadataExchange protocol MUST be used when communicating with this
endpoint.
/mex:MetadataExchange/mex:GetMetadataSupported
When present, this OPTIONAL parameter
indicates that the GetMetadata operation is supported by this endpoint.
/mex:MetadataExchange/mex:GetMetadataSupported/mex:MetadataExchangeDialect@Type
When present, this OPTIONAL parameter
indicates support for the specified MetadataExchange Dialect QName.
/mex:MetadataExchange/mex:GetMetadataSupported/mex:MetadataExchangeDialect/mex:MetadataContent
When present, this OPTIONAL parameter
indicates support for the specified MetadataExchange content IRI.
/mex:MetadataExchange/mex:GetMetadataSupported/mex:MetadataExchangeDialect/mex:MetadataContent/xs:any
This extensibility point allows for
additional MetadataContent specific metadata to be included within the policy
assertion. Any metadata that appears is scoped to the use of the specified
MetadataContent URI.
/mex:MetadataExchange/mex:GetMetadataSupported/mex:MetadataExchangeDialect/xs:any
This extensibility point allows for
additional Metadata Dialect specific metadata to be included within the policy
assertion. Any metadata that appears is scoped to the use of the specified
Metadata Dialect QName.
/mex:MetadataExchange/mex:GetMetadataSupported/xs:any
This extensibility point allows for
additional metadata specific to the GetMetadata operation to be included within
the policy assertion. Any metadata that appears is scoped to the use of the
GetMetadata operation.
/mex:MetadataExchange/xs:any
This extensibility point allows for
additional WS-MetadataExchange specific metadata to be included within the
policy assertion - e.g. WS-MetadataExchange WSDL, or nested policy assertions
related to the WS-MetadataExchange message exchanges. Any metadata that appears
is scoped to the operations and features of the WS-MetadataExchange
specification.
Note: The WS-RA WG is interested in Last Call feedback on
the use of nested policy expressions.
Although the operations
described in 6
Retrieving Metadata about Service Endpoints can be used by a requester
to obtain the metadata about a particular Service Endpoint, there is the
'chicken and egg' problem of how the requester knows whether or not these
operations are supported in the first place. The facilities described in 8 Metadata in Endpoint References,
9 Exposing Metadata for Implicitly Defined Features,
and 11 WS-MetadataExchange Metadata can be used
to address this problem.
(01) <wsa:EndpointReference ...>
(02)
<wsa:Address>http://services.example.org/stockquote</wsa:Address>
(03) <wsa:Metadata>
(04) <wsp:Policy>
(05)
<mex:MetadataExchange/>
(06) <wssa:SOAP11/>
(076) </wsp:Policy>
(087) </wsa:Metadata>
(098)
</wsa:EndpointReference>
The policy assertion at line 05 in Example 12-1 indicates to consumers of this EPR
that the GetWSDL operation is supported by the referenced Service Endpoint. The
parameters described in 11 WS-MetadataExchange Metadata
could be added to the policy assertion at line 05 to indicate additional
capabilities such as support for the mex:GetMetadata
operation. The
assertion on line 06 indicates that SOAP 1.1 needs to be used when sending the GetWSDL message.
Alternatively the EPR for a Service Endpoint can contain
embedded metadata or references to Metadata Resources that describe the
referenced service. Example 8-1 illustrated an EPR with
embedded WSDL metadata. Example 7-2 shows an EPR
with a reference to a Metadata Resource. The representation of this resource
(retrievable via HTTP GET) is a WSDL document that describes the service at
"http://example.com". Example 8-3
illustrates a similar mechanism, except that the retrieval mechanism is
WS-Transfer and the representation will be a mex:Metadata
document.
Extra binding information (such as SOAP version) could
either be implied by the context in which the EPR was provided or could be
conveyed as in Example 12-2.
(01) <wsa:EndpointReference ...>
(02)
<wsa:Address>http://services.example.org/stockquote</wsa:Address>
(03) <wsa:Metadata>
(04) <wsp:Policy>
(05)
<mex:MetadataExchange/>
{06)
<wsdl:definitions ...>
(07)
<!- Binding information -->
(08)
<wsdl:binding ...>
(09)
...
(10) </wsdl:binding>
(1108)
</wsdl:definitions>
(1209) </mex:MetadataExchange>
(130) </wsp:Policy>
(141) </wsa:Metadata>
(152)
</wsa:EndpointReference>
When information about the availability of
metadata is not present in an EPR, requesters can use contextual or out-of-band
information to choose the mechanism most appropriate for retrieving the
metadata. Furthermore, specific mechanisms for metadata retrieval can be
defined by communities within the context of particular application domains.
This specification has been developed as a
result of joint work with many individuals and teams, including: Alessio
Soldano (Red Hat), Ashok Malhotra (Oracle Corp.), Asir Vedamuthu (Microsoft
Corp.), Bob Freund (Hitachi, Ltd.), Bob Natale (MITRE Corp.), David Snelling
(Fujitsu, Ltd.), Doug Davis (IBM), Fred Maciel (Hitachi, Ltd.), Geoff Bullen
(Microsoft Corp.), Gilbert Pilz (Oracle Corp.), Greg Carpenter (Microsoft
Corp.), Jeff Mischkinsky (Oracle Corp.), Katy Warr (IBM), Li Li (Avaya
Communications), Mark Little (Red Hat), Martin Chapman (Oracle Corp.), Paul
Fremantle (WSO2), Paul Nolan (IBM), Prasad Yendluri (Software AG), Ram
Jeyaraman (Microsoft Corp.), Sreedhara Narayanaswamy (CA), Sumeet Vij (Software
AG), Tom Rutt (Fujitsu, Ltd.), Vikas Varma (Software AG), Wu Chou (Avaya
Communications), Yves Lafon (W3C/ERCIM).
Key words for
use in RFCs to Indicate Requirement Levels , S. Bradner, Author. Internet Engineering Task Force, March
1997. Available at http://www.ietf.org/rfc/rfc2119.txt.
Uniform Resource Identifier (URI):
Generic Syntax , T. Berners-Lee, R. Fields and L. Masinter,
Authors. Network Working Group, January 2005. Available at http://www.ietf.org/rfc/rfc3986.txt.
Internationalized Resource Identifiers
(IRIs) , M. Duerst and M. Suignard, Authors. Internet
Engineering Task Force, January 2005. Available at http://www.ietf.org/rfc/rfc3987.txt.
W3C Note,
"Simple Object Access Protocol (SOAP) 1.1" , D. Box, et al, Editors. World Wide Web Consortium (W3C), 8
May 2000. Available at http://www.w3.org/TR/2000/NOTE-SOAP-20000508/.
W3C Recommendation, "SOAP Version
1.2 Part 1: Messaging Framework" , M. Gudgin, M. Hadley,
N. Mendelsohn, J-J. Moreau, H. Frystyk Nielson, Editors. World Wide Web
Consortium (W3C), 27 April 2007. Available at http://www.w3.org/TR/soap12-part1/.
W3C Recommendation, "Web Services
Addressing 1.0 (WS-Addressing)" , M. Gudgin, M. Hadley,
T. Rogers, Editors. World Wide Web Consortium (W3C), 9 May 2006. Available at http://www.w3.org/TR/ws-addr-core.
W3C
Recommendation, "Web Services Policy (WS-Policy) 1.5 - Framework" , A. Vedamuthu, et al., Editors. World Wide Web Consortium
(W3C), 4 September 2007. Available at http://www.w3.org/TR/ws-policy/.
W3C
Recommendation, "Web Services Policy (WS-Policy) 1.5 - Attachment" , A. Vedamuthu, et al., Editors. World Wide Web Consortium
(W3C), 4 September 2007. Available at http://www.w3.org/TR/ws-policy-attach/.
W3C Working Group Draft, "Web
Services Transfer (WS-Transfer)1.1" , D. Davis, et al.,
Editors. World Wide Web Consortium (W3C), 15 September 2009. Available
at http://www.w3.org/TR/ws-transfer.
W3C Note,
"Web Services Description Language (WSDL) 1.1" , E. Christensen, et al., Editors. World Wide Web Consortium
(W3C), 15 March 2001 Available at http://www.w3.org/TR/2001/NOTE-wsdl-20010315.
W3C Recommendation, "XML
Information Set (Second Edition)" , J. Cowan, R. Tobin,
Editors. World Wide Web Consortium (W3C), 4 February 2004. Available
at http://www.w3.org/TR/xml-infoset.
W3C Recommendation, "XML Schema
Part 1: Structures (Second Edition)" , H. Thompson, et
al., Editors. World Wide Web Consortium (W3C), 28 October 2004. Available at http://www.w3.org/TR/xmlschema-1/.
W3C Recommendation, "XML Schema Part 2: Datatypes (Second Edition)" , P. Biron, A. Malhotra, Editors. World Wide Web Consortium (W3C), 28 October 2004. Available at http://www.w3.org/TR/xmlschema-2/
.A non-normative
copy of the XML Schema description is listed below for convenience.
targetNamespace='http://www.w3.org/2002/ws/ra/edcopies/ws-mex'
xmlns:tns='http://www.w3.org/2002/ws/ra/edcopies/ws-mex'
xmlns:wsa='http://www.w3.org/2005/08/addressing'
xmlns:xs='http://www.w3.org/2001/XMLSchema'
elementFormDefault='qualified'
namespace='http://www.w3.org/2005/08/addressing'
schemaLocation='http://www.w3.org/2006/03/addressing/ws-addr.xsd'/>
<xs:any namespace='##other'
processContents='lax' minOccurs='0'
<xs:anyAttribute namespace='##other' processContents='lax'/>
<xs:element
name='GetWSDLResponse'>
<xs:any namespace='##other' processContents='lax' minOccurs='0'
<xs:anyAttribute namespace='##other' processContents='lax'/>
<xs:element
name='GetMetadata'>
<xs:element ref='tns:Dialect' minOccurs='0'
maxOccurs='unbounded'/>
<xs:any namespace='##other'
processContents='lax' minOccurs='0'
<xs:anyAttribute namespace='##other' processContents='lax'/>
<!-- Get
Metadata response -->
<xs:element
name='GetMetadataResponse'>
<xs:element ref='tns:Metadata'/>
<xs:any namespace='##other'
processContents='lax' minOccurs='0'
<xs:anyAttribute namespace='##other' processContents='lax'/>
<xs:attribute name='Type' type='xs:QName' use='required'/>
<xs:attribute name='Identifier' type='xs:anyURI'/>
<xs:attribute name='Content' type='xs:anyURI'/>
<xs:anyAttribute
namespace='##other' processContents='lax'/>
<xs:element ref='tns:MetadataSection'
<xs:any namespace='##other'
processContents='lax'
<xs:anyAttribute namespace='##other' processContents='lax'/>
<xs:element
name='MetadataSection'>
<xs:any namespace='##other'
processContents='lax'/>
<xs:element name='MetadataReference'
type='wsa:EndpointReferenceType' />
<xs:element name='MetadataLocation'
type='tns:URI'/>
<xs:attribute name='Dialect' type='xs:QName'
use='required'/>
<xs:attribute name='Identifier' type='xs:anyURI'/>
<xs:anyAttribute namespace='##other' processContents='lax'/>
<xs:complexType
name='LocationType'>
<xs:any namespace='##other' processContents='lax' minOccurs='0'
<xs:attribute
name='URL' type='xs:anyURI'
use='required'/>
<xs:attribute
name='Type' type='xs:QName'
use='required'/>
<xs:attribute
name='Identifier' type='xs:anyURI'/>
<xs:anyAttribute
namespace='##other' processContents='lax'/>
<xs:element
name='Location' type='tns:LocationType'/>
<xs:complexType
name='ReferenceType'>
<xs:extension base='wsa:EndpointReferenceType'>
<xs:attribute name='Type'
type='xs:QName' use='required'/>
<xs:attribute name='Identifier'
type='xs:anyURI'/>
<xs:anyAttribute processContents='lax'/>
<xs:element
name='Reference' type='tns:ReferenceType'/>
<xs:extension base='xs:anyURI'>
<xs:anyAttribute namespace='##other'
processContents='lax'/>
<xs:element
name='MetadataExchange'>
<xs:element name='GetMetadataSupported'
minOccurs='0'>
<xs:element name='MetadataExchangeDialect'
minOccurs='0' maxOccurs='unbounded'>
<xs:element name='MetadataContent'
minOccurs='0' maxOccurs='unbounded'>
<xs:any namespace='##other'
processContents='lax'
<xs:attribute name='URI' type='xs:anyURI'
<xs:anyAttribute
namespace="##other"
<xs:any namespace='##other'
processContents='lax'
minOccurs='0' maxOccurs='unbounded'/>
<xs:attribute name='URI' type='xs:anyURI'
<xs:anyAttribute namespace='##other'
<xs:any namespace='##other'
processContents='lax'
minOccurs='0' maxOccurs='unbounded'/>
<xs:anyAttribute namespace='##other'
processContents='lax' />
A non-normative
copy of the WSDL description is listed below for convenience.
targetNamespace='http://www.w3.org/2002/ws/ra/edcopies/ws-mex'
xmlns:tns='http://www.w3.org/2002/ws/ra/edcopies/ws-mex'
xmlns:wsa='http://www.w3.org/2005/08/addressing'
xmlns:wsam='http://www.w3.org/2007/05/addressing/metadata'
xmlns:wsdl='http://schemas.xmlsoap.org/wsdl/'
xmlns:xs='http://www.w3.org/2001/XMLSchema'>
targetNamespace='http://www.w3.org/2002/ws/ra/edcopies/ws-mex'>
<xs:include schemaLocation='metadataexchange.xsd'/>
<wsdl:message
name='GetWSDLMsg'>
<wsdl:part
name='body' element='tns:GetWSDL'/>
<wsdl:message
name='GetWSDLResponseMsg'>
<wsdl:part
name='body' element='tns:GetWSDLResponse'/>
<wsdl:message
name='GetMetadataMsg'>
<wsdl:part
name='body' element='tns:GetMetadata'/>
<wsdl:message
name='GetMetadataResponseMsg'>
<wsdl:part
name='body' element='tns:GetMetadataResponse'/>
<wsdl:portType
name='MetadataExchange'>
<wsdl:operation
name='GetWSDL'>
'http://www.w3.org/2002/ws/ra/edcopies/ws-mex/GetWSDL'/>
message='tns:GetWSDLResponseMsg'
'http://www.w3.org/2002/ws/ra/edcopies/ws-mex/GetWSDLResponse'/>
<wsdl:operation
name='GetMetadata'>
'http://www.w3.org/2002/ws/ra/edcopies/ws-mex/GetMetadata'/>
message='tns:GetMetadataResponseMsg'
'http://www.w3.org/2002/ws/ra/edcopies/ws-mex/GetMetadataResponse'/>