Re: Proposed resolution for issues 24 (metadata) and 26 (multiple ports)

I kind of like this. One nice side effect is that we can remove mention  
of the [selected interface] and [service endpoint] endpoint reference  
properties (and their associated XML Infoset representations) from the  
core spec and just define them in the WSDL binding spec, this would  
improve the separation between the two.

A few questions:

> <wsa:endpoint>
>    <wsa:address>http://foo.com</wsa:address>
>    <wsa:metadata>
>       <wsdl20:service name="myservice"
>                       interface="..."
>                       wsa:targetNamespace="..."
>                       wsdli:wsdlLocation="....">
>          <wsdl20:endpoint name="e1" binding="abc:soap-http-binding"
>                  address="http://foo.com"/>
>          <wsdl20:endpoint name="alternate1" binding="abc:iiop"
>                  address="..."/>
>          <wsdl20:endpoint name="alternate2"
>                  binding="abc:soap-http-binding"
>                  address="http://foo.alternate.com"/>
>       </wsdl20:service>
>   </wsa:metadata>
> </wsa:endpoint>

(i) If I use the alternate2 endpoint, do I still use http://foo.com for  
the value of the EPR [address] or does the wsdl20:endpoint/@address  
override the wsa:address value ?

(ii) Metadata seems like a very general purpose bucket, do we still  
need the element extensibility point in wsa:EndpointReference if we  
adopt this scheme ?

(iii) I assume you are not suggesting renaming the elements used in the  
Infoset representation of an epr, i.e. that wsa:endpoint should be  
wsa:EndpointReference, wsa:address should be wsa:Address and (to keep  
things consistent case-wise) wsa:metadata should be wsa:Metadata ?

Marc.

On Jan 31, 2005, at 1:30 PM, Vinoski, Stephen wrote:

>
> We (IBM, IONA, SAP) propose the following as a resolution to issues 24
> (metadata) and 26 (multiple ports).  The representation of multiple  
> ports
> may be considered metadata and hence can be resolved within the  
> metadata
> solution.
>
> 1. There should be a metadata bucket in an EPR:
>
> <wsa:epr>
>    <wsa:address>http://....</address>
>    <!-- other stuff-->
>    <wsa:metadata>
>         ...
>    </wsa:metadata>
> </wsa:epr>
>
> 2. The contents of the metadata bucket are represented by value or by
> reference. Examples of content would be the WSDL Service definition;  
> lists
> of QNames and ports, policies; etc. See below.
>
> 3. The semantics and usage of the contents of the metadata bucket are  
> explained
> in the WSDL binding section when the metadata section includes WSDL.   
> If
> wsp-policy are found in the metadata section, then its use is  
> clarified by
> the WS-Policy spec.  In other words, the various kinds of information  
> found
> in the metadata section are clarified by the relevant specs and binding
> sections.
>
> 3A. A corollary is that the ws-addressing policy section is removed and
> replaced by the metadata section.
>
> 4. Data included in the metadata bucket follows the precedence  
> definition in
> the resolution to issue 14.
>
> Example usage:
>
> <wsa:metadata>
>    [<wsdl11:service> | <wsdl20:service> ] <extensibility>*  
> </wsa:metadata>
>
> - This allows partially reusing the wsdl11 and wsdl20 schema  
> definitions for
> service element that includes the port/endpoints. It also allows other
> metadata, even the full wsdl definitions to be included if desired.
>
> - WSDL 2.0 service element is defined by wsdl 2.0. See [1].
>
> - By using the wsdlLocation attribute one may be able to obtain  
> portions
> of wsdl by reference and use it, such as bindings etc. The example  
> below
> illustrates this.
>
> - we propose the use of the WSDL 1.1 service element defined by WS-I  
> BP 1.1
> profile which allows element and attribute extensibility. (It is  
> currently
> missing from the website that is why it is not included as a reference  
> in
> this email).
>
> WSDL 2.0 example:
>
> <wsa:endpoint>
>    <wsa:address>http://foo.com</wsa:address>
>    <wsa:metadata>
>       <wsdl20:service name="myservice"
>                       interface="..."
>                       wsa:targetNamespace="..."
>                       wsdli:wsdlLocation="....">
>          <wsdl20:endpoint name="e1" binding="abc:soap-http-binding"
>                  address="http://foo.com"/>
>          <wsdl20:endpoint name="alternate1" binding="abc:iiop"
>                  address="..."/>
>          <wsdl20:endpoint name="alternate2"
>                  binding="abc:soap-http-binding"
>                  address="http://foo.alternate.com"/>
>       </wsdl20:service>
>   </wsa:metadata>
> </wsa:endpoint>
>
> WSDL 1.1 example:
>
> <wsa:endpoint>
>    <wsa:address>http://foo.com</wsa:address>
>      <wsa:metadata>
>       <wsdl11:service name="myservice"
>                       wsa:targetNamespace="..."
>                       wsdli:wsdlLocation="....">
>          <wsdl11:port name="e1" binding="abc:soap-http-binding">
>                  <soap:address location="http://foo.com"/>
>          </wsdl11:port>
>          <wsdl11:port name="alternate1" binding="abc:iiop">
>                  <iiop:address location="..."/>
>          ...
>         </wsdl11:service>
>   </wsa:metadata>
> </wsd:endpoint>
>
> [1]
>
> http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/ws/desc/wsdl20/ 
> wsdl20.xsd?content-type=application/xml
>
> Regards,
>
> Rebecca Bergersen (IONA)
> Paco Curbera (IBM)
> Greg Truty (IBM)
> Steve Vinoski (IONA)
> Umit Yalcinalp (SAP)
>
>
>
---
Marc Hadley <marc.hadley at sun.com>
Web Technologies and Standards, Sun Microsystems.

Received on Monday, 31 January 2005 19:43:58 UTC