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

Exactly my feelings. Since refProps were dropped, let's now shift their
semantics to ref params so that we still have refPros around, just under
a different name ... I don't think that was what the group wanted to
achieve by dropping refProps.

Ugo

> -----Original Message-----
> From: Marc.Hadley@Sun.COM [mailto:Marc.Hadley@Sun.COM] 
> Sent: Wednesday, January 26, 2005 7:06 AM
> To: Francisco Curbera
> Cc: public-ws-addressing@w3.org; Ugo Corda
> Subject: 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 16:57:21 UTC