RE: detailed proposal for issues i024 and i026

i personally don't like the idea of sending WSDL information in an EPR,
it seems to me that a WSDL is good way to describe messages being
exchanged on the wire, but tying the messages themselves to a particular
description is limiting.
 
Given i may elect to describe an individual message exchange in any
one of a number of WSDLs each with their own abstract interface 
name, sentences like "it MUST match *the* WSDL 2.0 interface name ...." 
trouble me somewhat.
 
Paul

 -----Original Message----- 
 From: public-ws-addressing-request@w3.org on behalf of Vinoski, Stephen 
 Sent: Fri 04/02/2005 19:07 
 To: public-ws-addressing@w3.org 
 Cc: 
 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 Monday, 7 February 2005 20:42:00 UTC