W3C home > Mailing lists > Public > public-ws-addressing@w3.org > February 2005

detailed proposal for issues i024 and i026

From: Vinoski, Stephen <Steve.Vinoski@iona.com>
Date: Fri, 4 Feb 2005 14:07:44 -0500
Message-ID: <13AC4E67178F4D4EA31BB1BA645303133D542E@amereast-ems2.boston.amer.iona.com>
To: <public-ws-addressing@w3.org>

Below find a detailed proposal for resolving issues i024 and i026. Unlike our
previous draft proposal [1], this one details the changes this proposal
would make to the Core and WSDL binding specs, as requested by the WG in the
Monday 31 Jan 2005 teleconference.

[1] <http://lists.w3.org/Archives/Public/public-ws-addressing/2005Jan/0202.html>


Paco Curbera (IBM)
Greg Truty IBM)
Rebecca Bergersen (IONA)
Steve Vinoski (IONA)
Anish Karmarkar (Oracle)
Umit Yalcinalp (SAP)
Marc Hadley (Sun)

We (IBM, IONA, Oracle, SAP, Sun) propose the following as a resolution
to issues i024 (metadata) and i026 (multiple ports). The
representation of multiple ports may be considered metadata, and hence
can be resolved within the metadata solution described below.

Our proposed solution is to add a metadata element to the EPR, and
move all existing EPR metadata elements into it:

   <wsa:ReferenceParameters>...</wsa:ReferenceParameters> ?
   <wsa:Metadata>...</wsa:Metadata> ?

The EPR metadata element is intended to allow creators of EPRs to
include as much or as little metadata within each EPR as they deem
necessary. It allows for the inclusion of metadata directly ("by
value"), as well as for the inclusion of metadata indirectly ("by
reference"), or any combination thereof.

We propose that semantics and usage for metadata contained within the
EPR metadata element are specified by the relevant specification that
defines that particular metadata. The reason for this is that we
believe it allows for easy extensibility of the EPR with respect to
policies and other metadata. We propose moving the definitions of the
semantics and usage for any WSDL metadata that can appear within the
EPR metadata element to the WSDL binding document [1]. Similarly, any
future WS-Policy metadata intended for use within the EPR metadata
element would be defined in a WS-Addressing WS-Policy binding

The current draft WS-Addressing specification [2] already defines
several metadata elements within the EPR. Specifically, in section
2.1, the selected interface, service endpoint, and policies elements
each represent optional EPR metadata. As indicated by the previous
paragraph, we propose moving all of these elements into the EPR
metadata element.

Metadata defined within the EPR metadata element follows the
precedence definition defined in the resolution to issue i014 [3].


[1] <http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-wsdl.html>
[2] <http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-core.html>
[3] <http://www.w3.org/2002/ws/addr/wd-issues/#i014>

Changes to the WS-Addressing Core Working Draft

Section 2.1: remove the [selected interface], [service endpoint], and
[policies] abstract properties and their descriptions. Add the
following abstract property and description:

[metadata] : xs:any (0..1)
A reference may contain metadata that describes the behavior,
policies, requirements, and capabilities of an 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 the interaction occurs.

Section 2.2: change example 2-1 as follows:

  <wsa:ReferenceParameters>...</wsa:ReferenceParameters> ?
  <wsa:Metadata>...</wsa:Metadata> ?

>From the list following example 2-1, remove items
/wsa:EndpointReference/wsa:Policies/{any} and their
descriptions. Replace these items and descriptions with the following:

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

Each child element of Metadata represents an individual [metadatum].

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 WSDL
metadata specified within the [metadata] property.

Change the description for item /wsa:EndpointReference/@{any} as

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

Change Example 2-2 and the text just before it as follows:

The following shows an example endpoint reference. As indicated in its
[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.


Changes to the WSDL Binding Working Draft

Section 2: replace the final paragraph of the beginning of this
section with the following:

Endpoint references complement and do not replace WSDL services.  We
expect solutions built on WSDL to continue to utilize service
definitions. The endpoint references may link to services in WSDL, and
may directly cache information from WSDL definitions. Endpoint
references also support additional scenarios in which the WSDL
information is not known by a party processing a message. These
scenarios may include dynamic messaging or limited capability message

Section 2.1: replace this entire section with the following:

2.1 Information Model for Endpoint References

The WSDL binding of Web Services Addressing introduces the following 
additional abstract properties for use within the [metadata] element
of the endpoint reference:

[selected interface] : QName (0..1)

A QName identifying a description of the sequences of messages that a
service sends and/or receives. This corresponds to a WSDL 2.0
interface and/or a WSDL 1.1 port type. If this property appears in EPR
[metadata] together with a [service] property, it MUST match the WSDL
2.0 interface name or one of the WSDL 1.1 port names specified in the
[service] property.

[service endpoint] : (QName, NCName (0..1)) (0..1)

A QName, NCName pair that provide a reference to a full description of
a set of service endpoints. The QName identifies the set of endpoints
at which a particular Web service is deployed, the NCName identifies
one endpoint in particular. The set of endpoints is represented by a
service in WSDL 2.0 and WSDL 1.1. A particular endpoint is represented
by an endpoint in WSDL 2.0 and a port in WSDL 1.1. If this property
appears in EPR [metadata] together with a [service] property, it MUST
match the WSDL service name specified in the [service] property.

[service] : (WSDL 1.1 or 2.0 service definition) (0..1)

A service definition as specified by either the WSDL 1.1 or WSDL 2.0
specification. If a [service] property appears in EPR [metadata], then
a [service endpoint] property MUST be specified, because the service
QName in the [service endpoint] specifies the targetNamespace for the
[service] property name attribute. If the [service] property specifies
multiple endpoints, then the port NCName MUST be specified in the
[service endpoint]. When a [service] property contains multiple
endpoints, all endpoints supporting the same interface/portType as the
one indicated by the [service endpoint] property are considered
alternative access channels (address plus binding) to reach the same

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

      <wsa:ServiceName EndpointName="ep1">
      <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 2-2. An EPR containing WSDL 1.1 metadata.

      <wsa:ServiceName EndpointName="ep1">
      <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, 4 February 2005 19:07:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:03 GMT