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

RE: NEW ISSUE: EPR comparison rule doesn't support Web services gateways/routers

From: Yalcinalp, Umit <umit.yalcinalp@sap.com>
Date: Tue, 25 Jan 2005 21:43:31 +0100
Message-ID: <99CA63DD941EDC4EBA897048D9B0061D0F676E94@uspalx20a.pal.sap.corp>
To: "Francisco Curbera" <curbera@us.ibm.com>, <public-ws-addressing@w3.org>

>-----Original Message-----
>From: public-ws-addressing-request@w3.org 
>Sent: Tuesday, Jan 25, 2005 11:29 AM
>To: public-ws-addressing@w3.org
>Subject: NEW ISSUE: EPR comparison rule doesn't support Web 
>services gateways/routers
>Reading the latest editors draft it seems clear that the last minute
>decision not to ditch the comparison of EPRs section was taken 
>a bit too
>hastily; some of its unintended consequences are becoming 
>apparent now. As
>historical background, the comparison section was only added 
>to justify the
>difference between reference parameters and properties (as one 
>can check by
>comparing successive versions of the spec). Lacking the latter the
>comparison section it out of context, however, its consequences can be

I agree. I was wondering how this work out as I could not attend the

>The text now states that two EPRs with the same URL and different ref.
>params. have the same metadata. This leaves out an important 
>use case of
>Web service gateways/routers which is one of the most pervasive Web
>services products in the industry. In a gateway architecture 
>we encounter
>situations where a single external address (http, smtp, message queue o
>whatever) front ends a variety of services deployed inside the 
>These have typically different metadata, including both 
>different WSLD and
>policies, etc. This not uncommon arrangement will not be 
>supported by the
>resolution above, since the implication is that all services 
>would need to
>be different copies of the same one - same WSDL etc. Note that 
>this kind of
>restriction is also completely absent from WSDL 2.0 for 
>example, where two
>endpoints are not restricted to have separate addresses.


>The natural thing to do is to just remove that section (2.3 in the core
>spec) as the group initially intended before someone (don't 
>remember who)
>made a last minute proposal to keep it. The idea would be to 
>stay away from
>this type of artificial restrictions and let EPR minters 
>decide what is the
>relationship between the different fields of the EPR and the applicable
>metadata, a direction perfectly in synch with the resolution 
>of issue 1: a
>healthy agnosticism on what are the likely usage patterns for EPRs and
>reference parameters, which lets us accommodate likely usage w/o being

+1 again. Since there were two separate categories which were only
distinguishable from the perspective of comparison of EPRs, it is a good
idea to remove the comparison altogether as one of them has been
eliminated per the decision of the wg. 


Received on Tuesday, 25 January 2005 20:44:23 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:08 UTC