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

Paco,
I don't fully understand the logic of your discussion here.

If I correctly understand what the old sec. 2.3 said, it stated that if
two EPRs have the same address and the same refProps, then the two EPRs
also have the same metadata, regardless of the fact the ref parameters
might be different.

After dropping refProps, the previous statement should remain valid,
provided you fix the "if" part, i.e. "if two EPRs have the same address,
then the two EPRs also have the same metadata". In other words,
different values of reference parameters cannot justify differences in
metadata (same as before).

It seems to me that what you are proposing is not just the elimination
of sec. 2.3, but a change in the semantics of reference parameters.
Everything else being equal, reference parameters would now have an
effect on metadata, while before they didn't. Am I missing something?

Ugo

> -----Original Message-----
> From: public-ws-addressing-request@w3.org 
> [mailto:public-ws-addressing-request@w3.org] On Behalf Of 
> Francisco Curbera
> Sent: Tuesday, January 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.
> 
> 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.
> 
> 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.
> 
> 
> 
> 
>

Received on Tuesday, 25 January 2005 23:43:05 UTC