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

>-----Original Message-----
>From: public-ws-addressing-request@w3.org 
>[mailto: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
>damaging.
>

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

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

+1. 

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

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


--umit

>
>
>
>

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