Metadata Specifications Index Page



WSDL provides an extensible mechanism for defining the base messaging description and metadata for a Web service.

The Web Services Policy Framework provides a general-purpose model and corresponding syntax to describe and communicate the policies of a Web service.

Web Services Metadata Exchange defines messages to retrieve specific types of metadata associated with an endpoint.



Web Services Description Language (WSDL) 1.1

WSDL defines an XML-based grammar for describing network services as a set of endpoints that accept messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly, which are bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services).
WSDL is extensible to allow the description of endpoints and their messages regardless of what message formats or network protocols are being used to communicate. However, this document only describes how to use WSDL in conjunction with SOAP 1.1, HTTP GET/POST, and MIME.

WSDL 1.1 Binding Extension for SOAP 1.2

WSDL 1.1 Binding Extension for SOAP 1.2 (PDF file)

Get the Adobe Reader here.

WSDL 1.1 Binding Extension for SOAP 1.2 describes how to indicate in a WSDL 1.1 document that a service uses SOAP 1.2.


Web Services Policy Framework (WS-Policy) (PDF file)

WS-Policy defines a base set of constructs that can be used and extended by other Web services specifications to describe a broad range of service requirements, preferences, and capabilities.

WS-Policy was submitted to the W3C in April 2006.

WS-Policy specification at the W3C


Web Services Policy Attachment (WS-PolicyAttachment) (PDF file)

WS-PolicyAttachment specifies three specific attachment mechanisms for using policy expressions with existing XML Web service technologies. Specifically, we define how to associate policy expressions with WSDL type definitions and UDDI entities. We also define how to associate implementation-specific policy with all or part of a WSDL portType when exposed from a specific implementation.

WS-PolicyAttachment was submitted to the W3C in April 2006.

WS-PolicyAttachment specification at the W3C


Web Services Metadata Exchange (WS-MetadataExchange) (PDF file)

Get the Adobe Reader here.

WS-MetadataExchange 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.


Web Services Dynamic Discovery (WS-Discovery) (PDF file)

Get the Adobe Reader here.

This specification defines a multicast discovery protocol to locate services. By default, probes are sent to a multicast group, and target services that match return a response directly to the requestor. To scale to a large number of endpoints, the protocol defines the multicast suppression behavior if a discovery proxy is available on the network. To minimize the need for polling, target services that wish to be discovered send an announcement when they join and leave the network.


MTOM Serialization Policy Assertion (PDF file)

Get the Adobe Reader here.

This specification describes a domain-specific policy assertion that indicates endpoint support of the optimized MIME multipart/related serialization of SOAP messages defined in section 3 of the SOAP Message Transmission Optimization Mechanism [MTOM] specification.


Feedback Workshops for the WS-Policy family of specifications have already been held, and Interoperability Workshops are being organized shortly.

WSDL 1.1 was submitted to the W3C and became a W3C Note 15 March 2001.

WS-Policy was published as a public specification on 9 March 2006. This is the third joint publication of the specification.

WS-PolicyAttachment was published as a public specification on 9 March 2006. This is the third joint publication of the specification.

WS-PolicyAssertions was published as a public specification on 18 December 2002. This is the first joint BEA/IBM/Microsoft/SAP publication of the specification.

WS-MetadataExchange was published as a public specification on 16 August 2006. This is the third joint publication of the specification.

WS-Discovery was published as a public specification on 22 April 2005. This is the third joint publication of the specification.

WSDL 1.1 Binding Extension for SOAP 1.2 was updated in March 2006 (previously titled: WSDL 1.1 Binding for SOAP 1.2). This is the second publication of the specification.

Interoperability testing for WSDL was conducted in the SoapBuilders group.

Web Service Metadata Implementation Details


WSDL Framework

WSDL SOAP binding

WSDL 1.1 Binding Extension for SOAP 1.2


WSDL MIME binding








Superseded Specifications

Web Services Policy Framework (WS-Policy) –September 2004

Web Services Policy Attachment (WS-PolicyAttachment) – September 2004

Web Services Policy Assertion Language (WS-PolicyAssertions) –May 2003

Web Services Metadata Exchange (WS-MetadataExchange) – September 2004

Web Services Dynamic Discovery (WS-Discovery) - October 2004

Web Services Dynamic Discovery (WS-Discovery) - February 2004

WSDL Binding for SOAP 1.2

Superseded Schemas

WS-Policy – September 2004

WS-MetadataExchange – September 2004

WS-Discovery - October 2004

WS-Discovery - February 2004

WSDL Binding for SOAP 1.2

Superseded WSDL

WS-MetadataExchange – September 2004

WS-Discovery - October 2004

WS-Discovery - February 2004



SOAP defines a message as an Envelope and allows users to define specific Headers and Body formats using XML. XML Schemas (XSD) provides a mechanism for describing an XML format, but cannot describe a message or endpoint. The Web Services Description Language (WSDL) is an XML-based document format that introduces an extensible grammar for describing message endpoints while leveraging XSD for defining message content.

Goals and Non-Goals


  • Transport and encoding extensibility: New transports and encodings can be added to the base specification without having to revise it.
  • Abstract definitions: Endpoints and messages can be described abstractly, and then mapped onto one or more concrete transports or encodings.
  • Reuse of definitions: Existing endpoint definitions can be used to create new definitions.


  • Flow language: WSDL describes four basic message flow patterns (one-way, request-response, solicit-response, and notification) and leaves description of more complex flows to other specifications that extend the base patterns.
  • Expose implementation details: WSDL focuses on describing wire formats, not on describing implementation details of an endpoint.
  • Exchange of documents: WSDL defines a document format for describing message endpoints but leaves the exchange of such documents to other specifications (such as UDDI).


The WSDL grammar contains the following elements that are used together to describe endpoints:

  • Message: References to XML Schemas defining the different parts of the message (for example, Headers and Body).
  • Operation: Lists the messages involved in one message flow of the endpoint. For example, a request-response operation would refer to two messages.
  • PortType: The set of message flows (operations) expected by a particular endpoint type, without any details relating to transport or encoding.
  • Binding: The transport and encoding particulars for a portType.
  • Port: The network address of an endpoint and the binding it adheres to.
  • Service: A collection of related endpoints.

Figure 1. How WSDL grammar elements are used to define endpoints


The following listings illustrate each of the WSDL definitions that make up a fictitious stock quote endpoint that implements a single request-response operation. The request is a stock name message, and the response is a stock price message.

A message is defined for the request and response. The format of the XML that appears in the body of the message is specified by linking to element definitions in an existing XSD schema:

<message name='quoteRequest'>
    <part name='body' element='quote-schema-ns:stockName'/>

<message name='quoteResponse'>
    <part name='body' element='quote-schema-ns:stockPrice'/>

A portType (abstract endpoint definition) specifies a single request-response operation and refers to the previously defined request and response message definitions.

<portType name='quotePortType'>
    <operation name='getQuote'>
        <input message='quote-wsdl-ns:quoteRequest'/>
        <output message='quote-wsdl-ns:quoteResponse'/>

A binding (concrete endpoint definition) for the portType specifies that SOAP should be used with a particular action value.

<binding name='quoteBinding' type='quote-wsdl-ns:quotePortType'>
    <operation name='getQuote'>
            <soap:body part='body' use='literal'/>
            <soap:body part='body' use='literal'/>

A service defines a stock quote endpoint instance at a particular address.

<service name='stockService'>
    <port name='stockPort' binding='quote-wsdl-ns:quoteBinding'>
        <soap:address location=''/>


As communications protocols and message formats are standardized in the Web community, it becomes increasingly possible and important to be able to describe the communications in some structured way. WSDL addresses this need by defining an XML grammar for describing network services as collections of communication endpoints capable of exchanging messages. WSDL service definitions provide documentation for distributed systems and serve as a recipe for automating the details involved in applications communication.

  • WSDL builds on XML, XML namespaces, and XML Schemas.
  • WSDL is extensible, allowing other specifications that define new protocols to introduce WSDL-specific grammar for conveying information about those protocols.
  • WSDL deliberately does not define complex flow information, but rather leaves this to flow languages.
  • WSDL does not define how WSDL documents are exchanged, but instead leaves this to inspection and directory specifications such as UDDI.