i026 Metadata Proposal (amended)

The following (and enclosed) proposal addresses the concerns Microsoft
had with the original Metadata proposal [1] put forward by IONA, IBM,
SAP, Sun and Oracle.  This proposal is put forward as a friendly
amendment and has been deemed acceptable to each of the original
co-proposers, with the caveat that a few specific issues remain as
outlined below.  Microsoft joins the other authors in asking that these
remaining issues be discussed and resolved by the WG and the resulting
proposal be adopted.

Issues that remain to be resolved:

1) The proposal as written does not resolve the (new?) issue of how to
divide functionality between the Core and WSDL specs.  Many of the
co-authors prefer that all WSDL-related functionality be gathered into
the WSDL spec.  I for one prefer splitting the functionality along the
lines of extensions to WSDL (the WSDL Binding spec) and extensions to
WSA (extensibility is part of the Core spec).  Questions of what levels
one might conform to need to be explored.  The current set of specs is
not completely consistent to either of these viewpoints.

2) The desirability and practicality of enforcing the consistency of
[selected interface] and [service endpoint] with any embedded WSDL could
use some more exploration.

 Jonathan Marsh, Microsoft
in collaboration with
 Paco Curbera (IBM)
 Greg Truty IBM)
 Rebecca Bergersen (IONA)
 Steve Vinoski (IONA)
 Anish Karmarkar (Oracle)
 Umit Yalcinalp (SAP)
 Marc Hadley (Sun)


The list of changes provided below are provided in the enclosed
red-lined .doc as well for your convenience.

2.1: Replace the [policies] property with:

[metadata] : xsd:any (0..1)
  A reference may contain metadata that describes the behavior,
  policies, requirements and capabilities of the endpoint. Metadata 
  may be included in a reference to facilitate easier processing by 
  a consuming application, or because the metadata was dynamically
  generated. However, such metadata is not authoritative and may be
  stale or incoherent with the metadata associated with the endpoint at
  the time when the interaction occurs.

Update example 2-1 as follows:

    <wsa:ReferenceParameters>... </wsa:ReferenceParameters> ?
      <wsa:InterfaceName>xs:QName</wsa:InterfaceName> ?
      <wsa:ServiceName EndpointName="xs:NCName"?
            >xs:QName</wsa:ServiceName> ?

Update the list of elements in Section 2.2 as follows:

  This represents some element of type wsa:EndpointReferenceType. 
  This example uses the predefined <wsa:EndpointReference> element,
  but any element of type wsa:EndpointReferenceType may be used.

  This REQUIRED element (of type xs:anyURI) specifies the [address]
  property of the endpoint reference. This address may be a logical
  address for the service endpoint.

  This OPTIONAL element contains the elements that convey the 
  [reference parameters] of the reference.

  Each child element of ReferenceParameters represents an individual 
  [reference parameter].

  This OPTIONAL element (of type xs:Qname) specifies the value of 
  the [selected interface] property of the endpoint reference, see 
  Web Services Addressing 1.0 - WSDL Binding[WS-Addressing-WSDL] 
  for more details..

  This OPTIONAL element contains metadata that is relevant to the
  interaction with the endpoint.

  This OPTIONAL element (of type xs:QName) specifies the value of the
  [service endpoint] property, see Web Services Addressing 1.0 - WSDL
  Binding[WS-Addressing-WSDL] for more details..

  This OPTIONAL attribute (of type xs:NCName) specifies the name of a
  particular endpoint, see Web Services Addressing 1.0 - WSDL
  Binding[WS-Addressing-WSDL] for more details.

  This is an extensibility mechanism to allow additional attributes 
  to be specified. Some examples in this specification show use of this
  extensibility point to include a wsdlLocation[WSDL 2.0] attribute to
  provide a hint for the location of a WSDL description of the [selected
  interface] and [service endpoint] properties.

  Each child element of Metadata represents a piece of metadata relevant
  to the endpoint.

  This is an extensibility mechanism to allow additional elements to be 

  This is an extensibility mechanism to allow additional attributes to 
  be specified. 

The following shows an example endpoint reference. As indicated in it's
[metadata], this element references the [selected interface] 
"fabrikam:Inventory" at the endpoint URI
"http://example.com/www.fabrikam/acct". Note the use of the WSDL[WSDL
2.0] wsdlLocation attribute.

Example 2-2. Example endpoint reference.


Add Appendix A. Embedding WSDL metadata (non-normative)

WSDL 1.1 or 2.0 definitions can be embedded in the metadata section of
an EPR to provide a consuming application with WSDL information that
applies to the referenced endpoint. To do so, the creator of an EPR MAY
include a WSDL 2.0 description element (or a WSDL 1.1 definitions
element) in the metadata property of the EPR. The semantics of the
embedded WSDL is as defined by the WSDL 2.0 or 1.1 specifications. 

In particular, embedding a WSDL service component description MAY be
used by EPR issuers to indicate the presence of alternative addresses
and protocol bindings to access the referenced endpoint. The
alternatives are provided by the different endpoints of the embedded
service. In the case of WSDL 1.1, additional ports may be conveyed by
the WSDL 1.1 service definition which are not alternative access
channels to the endpoint. In that case, if the [interface] or [service
endpoint] properties are specified, only the ports with the same
interface as that which applies to the EPR are to be considered
alternative access channels. 

If the [service endpoint] property appears in the EPR's [metadata] and
an embedded WSDL service component is also provided inside a
descriptions or definitions component, then the [service endpoint]
information MUST match the name of (one or more of) the WSDL service(s)
included therein; the endpoint (port) name MUST match as well if
present.  The behavior of an EPR consumer when the [service endpoint]
doesn't match an embedded description is undefined. 

Example A-1. An EPR containing WSDL 2.0 metadata.


        <wsdl20:import namespace="http://example.com/fabrikam/"
        <wsdl20:import namespace="http://www.abccorp.com/" 
         <wsdl20:service name="InventoryService" 
            <wsdl20:endpoint name="ep1" binding="abc:soap-http-binding" 
            <wsdl20:endpoint name="ep2" binding="abc:iiop" 
            <wsdl20:endpoint name="ep3" 

Example A-2. An EPR containing WSDL 1.1 metadata.

     <wsdl11:definitions targetNamespace="http://example.com/fabrikam"
        <wsdl11:import namespace="http://example.com/fabrikam"  
        <wsdl11:import namespace="http://www.abccorp.com/" 
      <wsdl11:service name="InventoryService">
         <wsdl11:port name="ep1" binding="abc:soap-http-binding"> 
            <soap:address location="http://example.com/fabrikam/acct"/>
         <wsdl11:port name="ep2" binding="abc:iiop"> 
            <iiop:address location="..."/>

Received on Friday, 25 February 2005 07:37:30 UTC