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

Why is comparison of EPR important for ws-addressing itself?

Another spec using ws-addressing (say ws-resource Framework) could apply 
extra semantics to reference parameters (e.g.,
they are used to distinguish resource instances in an operation 
invocation).  These extra semantics might affect their
concept of "epr" equivalence.  Thus WS-RF could define their own 
comparision rules for EPRs, specific to the semantics
they add with their usage of WS-addressing.

Tom Rutt
Fujitsu

Marc Hadley wrote:

>
> On Jan 26, 2005, at 9:18 AM, Francisco Curbera wrote:
>
>>
>> I guess it is me who doesn't understand your logic. The comparison fully
>> depended on both URL and ref. props. precisely because its sole role in
>> life (you have to trust me on this) was to distinguish parameters from
>> properties. Now there is nothing to distinguish, so the whole thing 
>> needs
>> to be dropped. Still, some would like to give remaining text fragment a
>> significance it never had. We should call that approach "design by
>> accident": take a leftover piece and pretend there is really something
>> behind it. The case I pointed out is simply an example of how this
>> "accidental" approach to design works.
>>
> I find myself in agreement with Ugo's reasoning. Ref params were never 
> part of EPR comparison, we nixed ref props because of their 
> association with identity (at least part of that association came 
> about because they were used in comparing EPRs). It sounds like you 
> want to muddy the semantics of ref params so they can be used like ref 
> props but just not say it explicitly ?
>
> Marc.
>
>>
>>                       "Ugo Corda"
>>                       <UCorda@SeeBeyond.com>          To:       
>> Francisco Curbera/Watson/IBM@IBMUS, <public-ws-addressing@w3.org>
>>                       Sent by:                        cc:
>>                       public-ws-addressing-req        Subject:  RE: 
>> NEW ISSUE: EPR comparison rule doesn't support Web services
>>                       uest@w3.org                      gateways/routers
>>
>>
>>                       01/25/2005 06:42 PM
>>
>>
>>
>>
>>
>>
>> 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.
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>>
> ---
> Marc Hadley <marc.hadley at sun.com>
> Web Technologies and Standards, Sun Microsystems.
>
>

-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133

Received on Wednesday, 26 January 2005 20:35:29 UTC