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

Hello Vikas,

These are good questions. We are currently adding more detail to the proposal, so we'll take your questions into account in the revision, which we'll send to this list later this week.


-----Original Message-----
From: Vikas Deolaliker []
Sent: Monday, January 31, 2005 6:33 PM
To: Vinoski, Stephen;
Cc: Paco Curbera, Francisco; Bergersen, Rebecca; 'Yalcinalp, Umit';
'Greg Truty'
Subject: RE: Proposed resolution for issues 24 (metadata) and 26
(multiple ports)

A few questions...

a) How do we differentially apply policy1 to alternate 1, policy2 to
alternate2 etc? 

b) How do we communicate to the consumer (client) the differences between
the alternatives. For example, one can be a reliable/persistent path and
other a fast best effort path. 


Vikas Deolaliker
Sonoa Systems, Inc.

-----Original Message-----
[] On Behalf Of Vinoski, Stephen
Sent: Monday, January 31, 2005 10:31 AM
Cc: Paco Curbera, Francisco; Bergersen, Rebecca; Yalcinalp, Umit; Greg Truty
Subject: Proposed resolution for issues 24 (metadata) and 26 (multiple

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

1. There should be a metadata bucket in an EPR:

   <!-- other stuff-->

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
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

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:

   [<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: 

      <wsdl20:service name="myservice" 
         <wsdl20:endpoint name="e1" binding="abc:soap-http-binding" 
         <wsdl20:endpoint name="alternate1" binding="abc:iiop" 
         <wsdl20:endpoint name="alternate2" 

WSDL 1.1 example: 

      <wsdl11:service name="myservice" 
         <wsdl11:port name="e1" binding="abc:soap-http-binding"> 
                 <soap:address location=""/>
         <wsdl11:port name="alternate1" binding="abc:iiop"> 
                 <iiop:address location="..."/>



Rebecca Bergersen (IONA)
Paco Curbera (IBM)
Greg Truty (IBM)
Steve Vinoski (IONA)
Umit Yalcinalp (SAP)

Received on Tuesday, 1 February 2005 16:15:42 UTC