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

RE: detailed proposal for issues i024 and i026

From: David Orchard <dorchard@bea.com>
Date: Fri, 18 Feb 2005 14:15:25 -0800
Message-ID: <32D5845A745BFB429CBDBADA57CD41AF0DBCCEE1@ussjex01.amer.bea.com>
To: "Vinoski, Stephen" <Steve.Vinoski@iona.com>, <public-ws-addressing@w3.org>

I'm really confused  Why differentiate between metadata and data?  How
does an extension author "know" whether to put their extension as a
child of endpointreference or metadata, and how are they treated
differently?  

In both cases, the EPR consumer either knows about the extension, or
not.  And I don't see any WS-A specific behaviour for non-metadata
extensions or metadata extensions.  

I must be missing something, can you elaborate?

Cheers,
Dave

> -----Original Message-----
> From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-
> request@w3.org] On Behalf Of Vinoski, Stephen
> Sent: Friday, February 04, 2005 11:08 AM
> To: public-ws-addressing@w3.org
> Subject: detailed proposal for issues i024 and i026
> 
> 
> 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>
> 
> Regards,
> 
> 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:EndpointReference>
>    <wsa:Address>xs:anyURI</wsa:Address>
>    <wsa:ReferenceParameters>...</wsa:ReferenceParameters> ?
>    <wsa:Metadata>...</wsa:Metadata> ?
>    <xs:any/>*
> </wsa:EndpointReference>
> 
> 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
> specification.
> 
> 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].
> 
> References
> ==========
> 
> [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:EndpointReference>
>   <wsa:Address>xs:anyURI</wsa:Address>
>   <wsa:ReferenceParameters>...</wsa:ReferenceParameters> ?
>   <wsa:Metadata>...</wsa:Metadata> ?
>   <xs:any/>*
> </wsa:EndpointReference>
> 
> >From the list following example 2-1, remove items
> /wsa:EndpointReference/wsa:InterfaceName,
> /wsa:EndpointReference/wsa:ServiceName,
> /wsa:EndpointReference/wsa:ServiceName/@EndpointName,
> /wsa:EndpointReference/wsa:Policies,
> /wsa:EndpointReference/wsa:Policies/{any} and their
> descriptions. Replace these items and descriptions with the following:
> 
> /wsa:EndpointReference/wsa:Metadata
> This OPTIONAL element contains the elements that convey the [metadata]
> of the reference.
> 
> /wsa:EndpointReference/wsa:Metadata/{any}
> Each child element of Metadata represents an individual [metadatum].
> 
> /wsa:EndpointReference/wsa:Metadata/@{any}
> 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
> follows:
> 
> 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.
> 
> <wsa:EndpointReference
>      xmlns:wsa="http://www.w3.org/@@@@/@@/addressing">
>    <wsa:Address>http://example.com/fabrikam/acct</wsa:Address>
>    <wsa:Metadata
>        xmlns:fabrikam="http://example.com/fabrikam"
>        xmlns:wsdli="http://www.w3.org/@@@@/@@/wsdl-instance"
>        wsdli:wsdlLocation="http://example.com/fabrikam
>          http://example.com/fabrikam/fabrikam.wsdl">
>      <wsa:InterfaceName>fabrikam:Inventory</wsa:InterfaceName>
>    </wsa:Metadata>
> </wsa:EndpointReference>
> 
> 
> 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
> processors.
> 
> 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
> service.
> 
> Example 2-1. An EPR containing WSDL 2.0 metadata.
> 
> <wsa:EndpointReference
>      xmlns:wsa="http://www.w3.org/@@@@/@@/addressing">
>    <wsa:Address>http://example.com/fabrikam/acct</wsa:Address>
>    <wsa:Metadata
>         xmlns:fabrikam="http://example.com/fabrikam"
>         xmlns:abc="http://www.abccorp.com/"
>         xmlns:wsdl20="http://www.w3.org/2004/12/wsdl"
>         xmlns:wsdli="http://www.w3.org/@@@@/@@/wsdl-instance"
>         wsdli:wsdlLocation="http://example.com/fabrikam
>           http://example.com/fabrikam/fabrikam.wsdl">
>       <wsa:ServiceName EndpointName="ep1">
>          fabrikam:InventoryService
>       </wsa:ServiceName>
>       <wsdl20:service name="InventoryService"
>                       interface="fabrikam:Inventory">
>          <wsdl20:endpoint name="ep1" binding="abc:soap-http-binding"
>                  address="http://example.com/fabrikam/acct"/>
>          <wsdl20:endpoint name="ep2" binding="abc:iiop"
>                  address="..."/>
>          <wsdl20:endpoint name="ep3"
>                  binding="abc:soap-http-binding"
>                  address="http://alt.example.com/fabrikam/acct"/>
>       </wsdl20:service>
>   </wsa:Metadata>
> </wsa:EndpointReference>
> 
> Example 2-2. An EPR containing WSDL 1.1 metadata.
> 
> <wsa:EndpointReference
>      xmlns:wsa="http://www.w3.org/@@@@/@@/addressing">
>    <wsa:Address>http://example.com/fabrikam/acct</wsa:Address>
>    <wsa:Metadata
>         xmlns:fabrikam="http://example.com/fabrikam"
>         xmlns:abc="http://www.abccorp.com/"
>         xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
>         xmlns:iiop="http://www.iiop.org/"
>         xmlns:wsdl11="http://www.w3.org/@@@@/@@/wsdl">
>       <wsa:ServiceName EndpointName="ep1">
>          fabrikam:InventoryService
>       </wsa:ServiceName>
>       <wsdl11:service name="InventoryService">
>          <wsdl11:port name="ep1" binding="abc:soap-http-binding">
>             <soap:address
location="http://example.com/fabrikam/acct"/>
>          </wsdl11:port>
>          <wsdl11:port name="ep2" binding="abc:iiop">
>             <iiop:address location="..."/>
>         </wsdl11:service>
>   </wsa:Metadata>
> </wsd:EndpointReference>
Received on Friday, 18 February 2005 22:15:33 GMT

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