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

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.

Received on Wednesday, 26 January 2005 15:05:54 UTC