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

I suggest you explicitly raise an issue about the semantics of ref
params. Sec. 2.3 is pretty much irrelevant to this discussion.

Ugo

> -----Original Message-----
> From: Francisco Curbera [mailto:curbera@us.ibm.com] 
> Sent: Wednesday, January 26, 2005 11:23 AM
> To: Ugo Corda
> Cc: public-ws-addressing@w3.org; public-ws-addressing-request@w3.org
> Subject: RE: NEW ISSUE: EPR comparison rule doesn't support 
> Web services gateways/routers
> 
> 
> The problem is that Section 2.3 (2.4 in the submission doc) 
> was about differentiating properties and parameters. The 
> question is then, what are you differentiating now - and the 
> answer is that it isn't clear at all. Which might be ok (this 
> would certainly not make WS-Addressing the first fuzzy w3c 
> spec) except that this particular point puts a lot of real 
> world Web services deployments out of the WS-Addressing game. 
> Which in the end will likely hurt WS-Addressing more than 
> anything else - reality has its own ways of asserting itself 
> (rendering whole sections of a spec irrelevant in the way). I 
> think we just need to get real.
> 
> I think that under your argument lies an attempt to assert a 
> principle that no other Web services spec accepts - that 
> different metadata (say, different WSDL binding) mandates 
> different endpoint URLs. If this is the case I think it 
> should be put on the table explicitly, rather than dress it 
> as an automatic consequence of the vote on issue 1. This 
> "principle" is evidently absent form WSDL in any of its 
> incarnations (and I can imagine what would have been the 
> reaction had anyone tried to enforce that constraint), so I 
> don't quite see whatis the point to push it into 
> WS-Addressing through a back door. It is also completely 
> unrealistic, as the gateway scenario (and also the case of 
> dynamic policy changing
> in-flight) show.
> 
> The real issue here IMO is whether we want a spec with real 
> impact on the industry or we are up to some kind of academic exercise.
> 
> Paco
> 
> 
> 
> 
>                                                               
>                                                               
>             
>                       "Ugo Corda"                             
>                                                               
>             
>                       <UCorda@SeeBeyond        To:       
> Francisco Curbera/Watson/IBM@IBMUS                            
>                  
>                       .com>                    cc:       
> <Marc.Hadley@Sun.COM>, <public-ws-addressing@w3.org>,         
>                  
>                                                 
> <public-ws-addressing-request@w3.org>                         
>                           
>                       01/26/2005 01:50         Subject:  RE: 
> NEW ISSUE: EPR comparison rule doesn't support Web services   
>              
>                       PM                        
> gateways/routers                                              
>                           
>                                                               
>                                                               
>             
> 
> 
> 
> 
> Fine, but I have not seen any request to change the previous 
> semantics of ref params either.
> 
> What sec. 2.3 basically says, after dropping refProps, is 
> "differences in ref params values cannot imply differences in 
> metadata". That is the same thing that sec. 2.3 was saying 
> before refProps were dropped, and I consider that to be part 
> of the ref params semantics as it has been defined so far.
> 
> If we want to challenge the current ref params semantics, 
> that's fine with me. But let's just raise a new specific 
> issue, instead of sneaking it in by virtue of saying that we 
> can now drop sec. 2.3.
> 
> Ugo
> 
> > -----Original Message-----
> > From: Francisco Curbera [mailto:curbera@us.ibm.com]
> > Sent: Wednesday, January 26, 2005 10:36 AM
> > To: Ugo Corda
> > Cc: Marc.Hadley@Sun.COM; public-ws-addressing@w3.org; 
> > public-ws-addressing-request@w3.org
> > Subject: RE: NEW ISSUE: EPR comparison rule doesn't support Web 
> > services gateways/routers
> >
> >
> > From the discussion in Melbourne I think it would be safe 
> to say that 
> > different people had different reasons for voting as they did.
> >
> > Paco
> >
> >
> >
> >
> >
> >
> >                       "Ugo Corda"
> >
> >
> >                       <UCorda@SeeBeyond.com>          To:
> >   <Marc.Hadley@Sun.COM>, Francisco Curbera/Watson/IBM@IBMUS
> >
> >                       Sent by:                        cc:
> >   <public-ws-addressing@w3.org>
> >
> >                       public-ws-addressing-req
> > Subject:  RE: NEW ISSUE: EPR comparison rule doesn't support Web 
> > services
> >                       uest@w3.org
> > gateways/routers
> >
> >
> >
> >
> >
> >
> >
> >                       01/26/2005 11:56 AM
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > 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 19:29:40 UTC