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 © 2009 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, how metadata can be embedded
in [WS-Addressing] endpoint references, and how
metadata could be retrieved from a Web service endpoint.
This document is an editors' copy that
has no official standing.
1 Composable Architecture
2 Introduction
2.1 Requirements
2.2 Example
3 Notation
3.1 XML Namespaces
3.2 Notational Conventions
3.3 Considerations on the Use of
Extensibility Points
3.4 Compliance
4 Metadata Resources
5 Web Services Metadata
6 Retrieving Metadata
6.1 WS-Transfer Get
6.2 Get Metadata
7 Metadata in Endpoint References
8 Bootstrapping Metadata Retrieval
9 Exposing WSDL for Operations Implicitly Defined by a
Policy Assertion
10 Security Considerations
11 WS-Metadata Exchange Metadata
11.1 MetadataExchange
Assertion
12 Acknowledgements
13 References
13.1 Normative References
13.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 [WS-Transfer] resources
for retrieval purposes, how metadata can be embedded in Web service 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 an encapsulation format for metadata.
·
Treat the metadata about a Web service
endpoint as [WS-Transfer] resources.
·
Define an OPTIONAL bootstrap mechanism for
metadata-driven [XMLSchema -
Part 1], [WSDL11], [WS-Policy]
message exchange.
·
Support future versions of known metadata
formats.
·
Allow new metadata formats to be added.
·
Leverage other Web service specifications for
secure, reliable, transacted message delivery.
·
Support both [SOAP11]
and [SOAP12] Envelopes.
·
Enable description in [WSDL11]
of the OPTIONAL request-response interaction.
Example 2-1 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/2009/09/ws-tra'>
(05) <s11:Header>
(06)
<wsa:Action>
(07)
http://www.w3.org/2009/09/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-1 is a [WS-Transfer]
request for the retrieval of a resource's representation. In this case, the
requested representation is the WS-Metadata Exchange 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-2 illustrates a sample response to the
request of 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:mex='http://www.w3.org/2009/09/ws-mex'
(05) xmlns:wsp='http://www.w3.org/ns/ws-policy'
(06) xmlns:wst='http://www.w3.org/2009/09/ws-tra'
(07) xmlns:wsdl='http://schemas.xmlsoap.org/wsdl/'>
(08) <s11:Header>
(09)
<wsa:Action>
(10) http://www.w3.org/2009/09/ws-tra/GetResponse
(11)
</wsa:Action>
(12)
<wsa:To>http://client.example.org</wsa:To>
(13)
<wsa:RelatesTo>
(14) urn:uuid:1cec121a-82fe-41da-87e1-3b23f254f128
(15)
</wsa:RelatesTo>
(16) </s11:Header>
(17) <s11:Body>
(18)
<wst:GetResponse>
(19) <mex:Metadata>
(20)
<mex:MetadataSection
Dialect='http://schemas.xmlsoap.org/wsdl/'>
(21)
<wsdl:definitions
(22)
name='StockQuote'
(23)
targetNamespace='http://services.example.org/stockquote'
(24)
xmlns:tns='http://services.example.org/stockquote'
(25)
xmlns:msgs='http://services.example.org/stockquote/schemas'
(26)
xmlns:wsoap='http://schemas.xmlsoap.org/wsdl/soap/'
(27)
xmlns:xs='http://www.w3.org/2001/XMLSchema'>
(28)
<wsdl:import
(29)
namespace='http://services.example.org/stockquote'
(30)
location='http://services.example.org/stockquote/schemas'
/>
(31)
<wsdl:portType
name='StockQuotePortType'>
(32)
<wsdl:operation
name='GetLastTradePrice'>
(33)
<wsdl:input
message='msgs:GetLastTradePriceInput'
(34)
name='GetLastTradePriceInput'/>
(35)
<wsdl:output
message='msgs:GetLastTradePriceOutput'
(36)
name='GetLastTradePriceOutput'/>
(37)
</wsdl:operation>
(38)
</wsdl:portType>
(39) <wsdl:binding name='StockQuoteBinding'
(40)
type='tns:StockQuotePortType'>
(41)
<wsp:PolicyReference
(42)
URI='http://services.example.org/stockquote/policy'
/>
(43)
<wsoap:binding style='document'
(44)
transport='http://schemas.xmlsoap.org/soap/http'/>
(45)
<wsdl:operation
name='GetLastTradePrice'>
(46)
<wsoap:operation
soapAction='http://services.example.org/stockquote/GetLastTradePrice' />
(47)
<wsdl:input name='GetLastTradePriceInput'>
(48)
<wsoap:body
use='literal'/>
(49)
</wsdl:input>
(50)
<wsdl:output
name='GetLastTradePriceOutput'>
(51)
<wsoap:body
use='literal'/>
(52)
</wsdl:output>
(53)
</wsdl:operation>
(54)
</wsdl:binding>
(55)
<wsdl:service
name='StockQuoteService'>
(56)
<wsdl:port name='StockQuotePort'
(57) binding='tns:StockQuoteBinding'
>
(58)
<wsoap:address
(59)
location='http://services.example.org/stockquote'
/>
(60)
</wsdl:port>
(61)
</wsdl:service>
(62)
</wsdl:definitions>
(63)
</mex:MetadataSection>
(64)
<mex:MetadataSection
(65)
Dialect='http://www.w3.org/2001/XMLSchema'
(66)
Identifier='http://services.example.org/stockquote/schemas'>
(67)
<mex:Location>
(68)
http://services.example.org/stockquote/schemas
(69)
</mex:Location>
(70)
</mex:MetadataSection>
(71)
<mex:MetadataSection
(72)
Dialect='http://www.w3.org/ns/ws-policy'
(73)
Identifier='http://services.example.org/stockquote/policy'>
(74)
<mex:MetadataReference>
(75)
<wsa:Address>
(76)
http://services.example.org/stockquote/policy
(77)
</wsa:Address>
(78)
</mex:MetadataReference>
(79)
</mex:MetadataSection>
(80)
</mex:Metadata>
(81)
</wst:GetResponse>
(82) </s11:Body>
(83) </s11:Envelope>
The message of Example 2-2 is a [WS-Transfer]
response message to the request of Example 2-1. The
content of the [Body] (lines 17-82) is a mex:Metadata element with metadata about the Web service
endpoint (lines 19-80). The mex:Metadata
contains three Metadata Sections. The first Metadata Section (lines 20-63)
contains the [WSDL11] of the Web service endpoint. The
second Metadata Section (lines 64-70) 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 67-69). The third Metadata Section (lines 71-79)
contains the [WS-Addressing] endpoint reference (lines
74-77) of a [WS-Transfer] resource the
representation of which is a [WS-Policy] document as
indicated by the Dialect attribute (line 70). The WS-Policy document is the
same as the one indicated in the WSDL document (lines 41-42).
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 74-78 of Example 2-2, some endpoints MAY support explicit
requests for metadata via the GetMetadata operation. Example 2-3 illustrates a sample GetMetadata
request for the [WS-Policy].
Example 2-3: Sample GetMetadata request message
(01) <s11:Envelope
(02) xmlns:s11='http://schemas.xmlsoap.org/soap/envelope/'
(03) xmlns:wsa='http://www.w3.org/2005/08/addressing'
(04) xmlns:mex='http://www.w3.org/2009/09/ws-mex'
>
(05) <s11:Header>
(06)
<wsa:To>http://services.example.org/stockquote</wsa:To>
(07)
<wsa:Action>
(08)
http://www.w3.org/2009/09/ws-mex/GetMetadata
(09)
</wsa:Action>
(10)
<wsa:MessageID>
(11) urn:uuid:73d7edfc-5c3c-49b9-ba46-2480caee43e9
(12)
</wsa:MessageID>
(13)
<wsa:ReplyTo>
(14) <wsa:Address>http://client.example.org</wsa:Address>
(15)
</wsa:ReplyTo>
(16) </s11:Header>
(17) <s11:Body>
(18)
<mex:GetMetadata>
(19) <mex:Dialect
URI='http://www.w3.org/ns/ws-policy'
(20)
Identifier='http://services.example.org/stockquote/policy'/>
(21)
</mex:GetMetadata>
(22) </s11:Body>
(23) </s11:Envelope>
Lines 7-9 in Example
2-3 indicate this is a GetMetadata request. As
lines 18-21 indicate, this request is for the policy of the Web service
endpoint (line 6).
Example 2-4 lists a sample response to the request in Example 2-3.
Example 2-4: Sample GetMetadataResponse message
(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/2009/09/ws-mex'>
(06) <s11:Header>
(07)
<wsa:To>http://client.example.org</wsa:To>
(08)
<wsa:Action>
(09)
http://www.w3.org/2009/09/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='http://www.w3.org/ns/ws-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-4 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-3. Lines 17-26 contain a single Metadata
Section (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-3 was directed.
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/2009/09/ws-mex
|
This
specification |
|
xs |
http://www.w3.org/2001/XMLSchema
|
|
|
wst |
http://www.w3.org/2009/09/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
.
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.
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.1
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 Metadata
Reference, which is a [WS-Addressing]
endpoint reference, then the Metadata Reference MUST refer to a [WS-Transfer] resource. The referred resource MAY also
support other resource management and access specifications (e.g. HTTP, WS-ResourceFramework).
A resource is a Web
service that is addressable by an endpoint reference [WS-Addressing] and can be represented by an XML Infoset. The resource's representation can be retrieved
using the Get operation defined in [WS-Transfer].
When
the representation of a resource is mex:Metadata,
as defined in 5 Web Services Metadata,
or any other document format (e.g. [XMLSchema
- Part 1],[XMLSchema - Part
2], [WSDL11], [WS-Policy])
for which a mex:MetadataSection/@Dialect has been
defined, then the resource is referred as 'metadata resource'. The
representation of a metadata resource MAY be retrieved and/or updated as any
other [WS-Transfer] resource. Specifically, the
representation of a metadata resource MUST be retrievable through a [WS-Transfer] Get operation.
A
Web service endpoint MAY have one or more associated metadata resources. A Web
service endpoint MAY also support direct retrieval of metadata by requesters
using a GetMetadata operation directed to the Web
service endpoint itself, as described in 6.2 Get Metadata.
A
metadata resource MAY support other operations defined by [WS-Transfer],
such as Put (e.g. to allow update of non-static metadata by authorized agents),
or other resource management and access specifications (e.g. HTTP, WS-ResourceFramework).
The Web service
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 Metadata Section elements.
To
facilitate processing, Metadata Sections are tagged with a @Dialect and
(OPTIONALLY) @Identifier of the metadata unit. To ensure scalability,
a unit of metadata MAY be included in-line within its Metadata Section or MAY
be included by reference, either an endpoint reference [WS-Addressing]
(Metadata Reference) or a URL (Location).
The
outline for the Metadata element is:
<mex:Metadata
...>
<mex:MetadataSection
Dialect='xs:anyURI'
Identifier='xs:anyURI'?
...>
(
<mex:MetadataReference ...>
endpoint-reference-type
</mex:MetadataReference>
|
<mex:Location> xs:anyURI </mex:Location>
|
DialectSpecificElement
)
</mex:MetadataSection>
*
xs:any*
</mex:Metadata>
The
following describes additional constraints on the outline listed above:
/mex:Metadata
This contains one Metadata Section child for each
distinct unit of metadata. When there is a large amount of metadata, the
children SHOULD contain Metadata References or Locations 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
Metadata Section 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 format and version of the metadata
unit contained in this Metadata Section (e.g., WSDL version 1.1). Dialect is an
absolute IRI.
This
specification defines the following values for Dialect; other specifications
SHOULD define values for Dialect for their metadata format(s).
|
Dialect IRI
|
Metadata
Format |
|
http://www.w3.org/2001/XMLSchema
|
xs:schema [XMLSchema -
Part 1] |
|
http://schemas.xmlsoap.org/wsdl/
|
wsdl:definitions [WSDL11] |
|
http://www.w3.org/ns/ws-policy
|
wsp:Policy [WS-Policy] |
|
http://www.w3.org/TR/ws-policy-attach
|
wsp:PolicyAttachment [WS-PolicyAttachment] |
|
http://www.w3.org/2009/09/ws-mex/Dialects/ws-mex
|
mex:Metadata [Defined in this specification] |
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 Metadata Section, is
explicitly encouraged.
/mex:Metadata/mex:MetadataSection/@Dialect='http://www.w3.org/2009/09/ws-mex/Dialects/ws-mex'
This Dialect value indicates that the type of the
metadata contained within the Metadata Section is itself a mex:Metadata element. When the Dialect value is used in
conjunction with mex:MetadataReference
or mex:Location, the Dialect value provides the
ability to include metadata by reference (an endpoint reference or a URL). Example 7-2 illustrates the use of this Dialect.
/mex:Metadata/mex:MetadataSection/@Identifier
This indicates the Identifier for the metadata unit in
this Metadata Section. Identifier is an absolute IRI. If omitted, there is no
implied value.
The interpretation of Identifier is Dialect-specific.
While the Dialect attribute indicates the metadata format and version of the
metadata in the Metadata Section, the Identifier attribute MAY be used to
identify a Metadata Section or to just differentiate between Metadata Sections
containing the same type of metadata. The value of the Identifier MAY be the
same as the value of one of the attributes or elements of the metadata in the
Metadata Section (if the metadata is included by value) or in the
representation of a metadata resource (if the metadata is included by reference
through Metadata Reference or Location). A metadata publisher MAY choose any
value for the Identifier. The values of Identifier attributes in multiple
Metadata Section elements in the same Metadata element MAY be the same. For
well-known metadata formats, it is RECOMMENDED that the value of the Identifier
comes from the metadata when that is possible, as the table below shows.
|
Dialect IRI
|
@Identifier
value |
|
http://www.w3.org/2001/XMLSchema
|
xs:schema/@targetNamespace |
|
http://schemas.xmlsoap.org/wsdl/
|
wsdl:definitions/@targetNamespace |
|
http://www.w3.org/ns/ws-policy
|
wsp:Policy/@Name |
|
http://www.w3.org/TR/ws-policy-attach
|
Not defined |
|
http://www.w3.org/2009/09/ws-mex/Dialects/ws-mex
|
Not defined |
If
there is more than one metadata section with the same identifier, e.g., more
than one XML Schema in the same target namespace, including them all, one per
metadata section, 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 resource MUST support the Get
operation [WS-Transfer] to allow the retrieval of
the metadata unit for the Metadata Section's Dialect and Identifier (if any).
When this element is present, it MUST have no element siblings.
/mex:Metadata/mex:MetadataSection/mex:Location
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 Metadata Reference or
Location is present, the element is to be interpreted as the representation of
the metadata unit associated with the Metadata Section's Dialect and
Identifier.
To retrieve the representation of a
metadata resource, a requester MAY send a [WS-Transfer] Get request message to the metadata
resource's endpoint. The WS-Transfer Get request fetches 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.
The
representation of a metadata resource MAY also be any other document format
(e.g. [XMLSchema - Part 1],
[XMLSchema - Part 2], [WSDL11], [WS-Policy]) for which a
Dialect value is defined.
A requester MAY send a GetMetadata request message to an service endpoint to
retrieve the metadata associated with that endpoint. This operation MAY be
supported by 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/2009/09/ws-mex/GetMetadata
[Body]
<mex:GetMetadata
... >
<mex:Dialect URI='xs:anyURI'
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 Metadata Sections corresponding to metadata
specified by the combination of the URI, 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 Metadata Sections for that Dialect element.
When this element is not present, the endpoint MUST
return all available metadata.
[Body]/mex:GetMetadata/mex:Dialect@URI
This REQUIRED attribute specifies the Metadata Dialect.
The response MUST only include Metadata Sections corresponding to the Dialect
specified by this IRI. If the receiver does not have any Metadata Sections of
this indicated Dialect, the response MUST include zero Metadata Sections for
this IRI.
[Body]/mex:GetMetadata/mex:Dialect@Identifier
When this OPTIONAL attribute is present, the response
MUST include only Metadata Sections with the indicated identifier; if the
receiver does not have any Metadata Sections of the indicated identifier, the
response MUST include zero Metadata Sections for this IRI/Identifier pair. When
this attribute is not present, the implied value is any identifier. If multiple
Metadata Sections 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 Metadata Sections of this specified content form. If the
specified content form is not available, or not known, then the response MUST
include zero Metadata Sections of the specified form for this IRI/Identifier
pair. This specification defines the following content form IRIs:
|
Content
Form IRI |
Form |
|
http://www.w3.org/2009/09/ws-mex/Content/EPR
|
A MetadataReference element is returned |
|
http://www.w3.org/2009/09/ws-mex/Content/URI
|
A Location
element is returned |
|
http://www.w3.org/2009/09/ws-mex/Content/Metadata
|
The metadata
is inlined |
|
http://www.w3.org/2009/09/ws-mex/Content/Any
|
The service is
free to chose any content form |
|
http://www.w3.org/2009/09/ws-mex/Content/All
|
The service
MUST return all available content forms |
When not present the default value is "http://www.w3.org/2009/09/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/2009/09/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
5 Web Services Metadata.
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.
6 Retrieving Metadata
describes two mechanisms that allow requesters to retrieve ("pull
metadata") Web services metadata from an endpoint (GetMetadata)
or a metadata resource (WS-Transfer Get).
In
addition to these mechanisms, tThe issuer of a
service endpoint reference MAY include Web services metadata
for that service inside the endpoint reference itself. This mechanism ("push
metadata") simplifies the bootstrapping of the service interaction
on the requester side by avoiding additional calls to retrieve (pull) the Web service
metadata for the service endpoint.
Embedding
a mex:Metadata element
inside an endpoint reference allows the issuer of the endpoint reference to
include metadata by value or by reference, according to the options described
in 5 Web Services Metadata. 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* lt;/wsa:ReferenceParameters> ?
<wsa:Metadata>
<mex:Metadata ...> ... </mex:Metadata>?
xs:any*
</wsa:Metadata> ?
xs:any*
</wsa:EndpointReference>
/wsa:EndpointReference/wsa:Metadata/mex:Metadata
A unique mex:Metadata
element appearing as a direct child of the wsa:Metadata
endpoint reference element.
In
example Example 7-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)
<mex:Metadata xmlns:mex='http://www.w3.org/2009/09/ws-mex'>
(06) <mex:MetadataSection
Dialect='http://schemas.xmlsoap.org/wsdl/'>
(07)
<wsdl:definitions
(08)
name='StockQuote'
(09)
targetNamespace='http://services.example.org/stockquote'
(10)
xmlns:tns='http://services.example.org/stockquote'
(11)
xmlns:wsoap='http://schemas.xmlsoap.org/wsdl/soap/'
(12) xmlns:wsdl='http://schemas.xmlsoap.org/wsdl/'
(13)
xmlns:wsp='http://www.w3.org/ns/ws-policy'
(14)
xmlns:msgs='http://services.example.org/stockquote/schemas
(15)
xmlns:xs='http://www.w3.org/2001/XMLSchema'>
(16)
<wsdl:import
(17)
namespace='http://services.example.org/stockquote'
(18)
location='http://services.example.org/stockquote/schemas'
/>
(19)
<wsdl:portType
name='StockQuotePortType'>
(20)
<wsdl:operation name='GetLastTradePrice'>
(21)
<wsdl:input
message='msgs:GetLastTradePriceInput'
(22)
name='GetLastTradePriceInput'/>
(23)
<wsdl:output
message='msgs:GetLastTradePriceOutput'
(24) name='GetLastTradePriceOutput'/>
(25)
</wsdl:operation>
(26)
</wsdl:portType>
(27)
<wsdl:binding
name='StockQuoteBinding'
(28)
type='tns:StockQuotePortType'>
(29)
<wsp:PolicyReference
(30)
URI='http://services.example.org/stockquote/policy'
/>
(31)
<wsoap:binding style='document'
(32)
transport='http://schemas.xmlsoap.org/soap/http'/>
(33)
<wsdl:operation
name='GetLastTradePrice'>
(34)
<wsoap:operation
soapAction='http://services.example.org/stockquote/GetLastTradePrice' />
(35)
<wsdl:input name='GetLastTradePriceInput'>
(36)
<wsoap:body
use='literal'/>
(37)
</wsdl:input>
(38)
<wsdl:output
name='GetLastTradePriceOutput'>
(39)
<wsoap:body
use='literal'/>
(40)
</wsdl:output>
(41)
</wsdl:operation>
(42)
</wsdl:binding>
(43)
<wsdl:service
name='StockQuoteService'>
(44)
<wsdl:port name='StockQuotePort'
(45)
binding='tns:StockQuoteBinding'
>
(46)
<wsoap:address
(47)
location='http://services.example.org/stockquote'
/>
(48)
</wsdl:port>
(49)
</wsdl:service>
(50)
</wsdl:definitions>
(51)
</mex:MetadataSection>
(52) <mex:MetadataSection
(53)
Dialect='http://www.w3.org/2001/XMLSchema'
(54)
Identifier='http://services.example.org/stockquote/schemas'>
(55)
<mex:MetadataReference>
(56)
<wsa:Address>
(57)
http://services.example.org/stockquote/schemas
(58)
</wsa:Address>
(59)
</mex:MetadataReference>
(60)
</mex:MetadataSection>
(61)
</mex:Metadata>
(62) </wsa:Metadata>
(63) </wsa:EndpointReference>
Lines 4-62 in Example
7-1 show the way a Metadata element can be embedded in the endpoint reference
of a service. The Metadata element contains two Metadata Sections. In the first
one (lines 6-51) the WSDL of the Web service endpoint is included 'by value'.
In the second Metadata Section (lines 52-60) an endpoint reference to a
metadata resource is shown. The representation of the metadata resource is an
XML Schema as hinted by the Dialect attribute (line 53) and is distinguished
from other XML Schemas for that Web service endpoint by the value of Identifier
attribute (line 54) which in this case happens to be the same as the value of
the targetNamespace attribute of the XML Schema. The [WS-Transfer] Get operation can be used to retrieve the
referred XML Schema. Since no metadata is available about the metadata
resource, it is assumed that binding-related information was communicated
out-of-band (e.g. an application domain-specific specification has defined a
binding for that domain) so that the requester could send a [WS-Transfer] Get request to the metadata resource's
endpoint, as defined in 8
Bootstrapping Metadata Retrieval.
(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)
<mex:Metadata xmlns:mex='http://www.w3.org/2009/09/ws-mex'>
(06) <mex:MetadataSection
(07)
Dialect='http://www.w3.org/2009/09/ws-mex'>
(08)
<mex:MetadataReference>
(09)
<wsa:Address>
(10)
http://services.example.org/stockquote/metadata
(11)
</wsa:Address>
(12)
<wsa:Metadata>
(13)
<mex:Metadata>
(14)
<mex:MetadataSection
(15)
Dialect='http://schemas.xmlsoap.org/wsdl/'>
(16)
<!-- Reference to WS-Transfer WSDL wst:Resource portType
(17) plus binding -->
(18)
</mex:MetadataSection>
(19)
</mex:Metadata>
(20)
</wsa:Metadata>
(21)
</mex:MetadataReference>
(22)
</mex:MetadataSection>
(23)
</mex:Metadata>
(24) </wsa:Metadata>
(25) </wsa:EndpointReference>
Example 7-2 shows an example of a Web service endpoint
reference in which the Metadata element contains a single Metadata Reference
element to a metadata resource (lines 8-21) the representation of which is mex:Metadata as hinted by the value of the Dialect
attribute (line 7). The Metadata Reference contains a Metadata element (lines
13-19) which contains the necessary metadata for interacting with the metadata
resource through [WS-Transfer] operations. Since the
Metadata 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.
This specification
provides several mechanisms to aid service endpoints and service requesters in
bootstrapping the interaction. In particular, the mechanisms described in 7 Metadata in Endpoint References
allow issuers of endpoint references to include sufficient protocol binding
information to allow requesters to issue a Get request against a metadata
resource, or a GetMetadata request against a service
endpoint, in order to retrieve all the information needed to use the service.
When
that information is not available, however, requesters will rely on contextual
or out-of-band information in order to choose the protocol binding most
appropriate to use in retrieving Web service metadata. Furthermore, specific
protocol bindings for metadata retrieval MAY be defined by communities within
the context of particular application domains.
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 corresponding operations
(if any) are supported by that endpoint even though they 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 wstrp:TransferResource
WS-Policy [WS-Policy] assertion.
An
endpoint MAY choose to expose the WSDL of the policy defined feature by using
the http://schemas.xmlsoap.org/wsdl/ dialect and the dialect identifier of the
target namespace of the feature.
|
Dialect IRI
|
@Identifier Value |
Metadata Returned |
|
http://schemas.xmlsoap.org/wsdl/
|
target
namespace of endpoint |
Endpoint WSDL |
|
http://schemas.xmlsoap.org/wsdl/
|
target
namespace of feature supported by the endpoint |
Feature WSDL |
The
Feature WSDL, the WSDL associated with these implicit operations, 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.
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 required.
·
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 that it supports WS-MetadataExchange, or its features, by including the WS-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 do not explicitly
appear in its WSDL (i.e. the WSDL that MAY be retrievable by using a WS-MetadataExchange GetMetadata with
a Dialect IRI of http://schemas.xmlsoap.org/wsdl/).
An endpoint MAY choose to expose the WS-MetadataExchange WSDL by using the following WS-MetadataExchange Dialect:
|
Dialect IRI |
@Identifier
value |
|
http://www.w3.org/2009/02/ws-mex/MetadataExchangeWSDL
|
Not defined |
The WS-MetadataExchange
WSDL can be annotated to indicate any endpoint specific metadata that might be
needed by clients interacting with this service. 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.
The mechanism for indicating that a
binding or endpoint conforms to the WS-MetadataExchange
specification is 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 mex:MetadataExchange policy assertion applies to the
endpoint policy subject.
For
WSDL 1.1, these assertions MAY be attached to wsdl11:port
or wsdl11:binding. For WSDL 2.0, they MAY be attached to wsdl20:endpoint or wsdl20:binding. A policy expression containing
the mex:MetadataExchange
policy assertion MUST NOT be attached to a wsdl:portType
or wsdl20:interface.
The
mex:MetadataExchange policy
assertion is a nested policy container assertion. The meaning of this
assertion, when present in a policy alternative, is that WS-MetadataExchange
is required to communicate with the subject and that the subject supports WS-MetadataExchange.
In
order to indicate that the subject supports WS-MetadataExchange
but does not require its use, an additional policy alternative SHOULD be
provided which does not contain this assertion. The compact authoring style for
an OPTIONAL policy assertion (the wsp:Optional
attribute) provided by WS-Policy MAY be used to indicate two policy
alternatives, one which contains the policy assertion, and another which does
not.
The
normative outline of this assertion is:
<mex:MetadataExchange
...>
<mex:MetadataExchangeDialect
value='xs:anyURI'
...>
<mex:MetadataContent ...> xs:anyURI </mex:MetadataContent> *
</mex:MetadataExchangeDialect>
*
...
</mex:MetadataExchange>
The
following describes additional, normative constraints on the outline listed
above:
/mex:MetadataExchange
This policy assertion specifies that WS-Exchange protocol
MUST be used when communicating with this endpoint. This assertion has Endpoint
Policy Subject.
/mex:MetadataExchange/mex:MetadataExchangeDialect@value
When present, this OPTIONAL parameter indicates support
for the specified MetadataExchange Dialect IRI.
/mex:MetadataExchange/mex:MetadataExchangeDialect/mex:MetadataContent
When present, this OPTIONAL parameter indicates support
for the specified MetadataExchange content IRI.
Note:
Metadata resources use the corresponding policy assertions for the WS-Transfer
operation that they support.
This specification has been developed
as a result of joint work with many individuals and teams, including: Ashok Malhotra (Oracle Corp.), Asir Vedamuthu (Microsoft Corp.), Bob Freund (Hitachi, 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), Prasad Yendluri (Software AG), Ram Jeyaraman
(Microsoft Corp.), Sreedhara Narayanaswamy
(CA), Sumeet Vij (Software
AG), Vikas Varma (Software
AG), Wu Chou (Avaya Communications), Yves Lafon
(W3C).
Key words for use in RFCs to Indicate Requirement
Levels ,
A non-normative
copy of the XML Schema description is listed below for convenience.
targetNamespace='http://www.w3.org/2009/09/ws-mex'
xmlns:tns='http://www.w3.org/2009/09/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: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='URI' type='xs:anyURI' 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 ref='tns:Location'/>
<xs:attribute name='Dialect' type='xs:anyURI' use='required'/>
<xs:attribute name='Identifier'
type='xs:anyURI'/>
<xs:anyAttribute
namespace='##other' processContents='lax'/>
<xs:element name='Location' type='xs:anyURI'/>
<xs:extension base='xs:anyURI'>
<xs:anyAttribute
namespace='##other' processContents='lax'/>
<xs:element name='MetadataExchange'>
<xs:element name='MetadataExchangeDialect'>
<xs:element name='MetadataContent' type='tns:URI' minOccurs='0'
<xs:attribute
name='value' type='xs:anyURI' use='required'/>
<xs:anyAttribute
namespace='##other' processContents='lax'/>
<xs:any namespace='##other' processContents='lax' minOccurs='0'
<xs:anyAttribute
namespace='##other' processContents='lax' />
A non-normative
copy of the WSDL description is listed below for convenience.
targetNamespace='http://www.w3.org/2009/09/ws-mex'
xmlns:tns='http://www.w3.org/2009/09/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/2009/09/ws-mex'>
<xs:include
schemaLocation='metadataexchange.xsd'/>
<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='GetMetadata'>
'http://www.w3.org/2009/09/ws-mex/GetMetadata'/>
message='tns:GetMetadataResponseMsg'