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:23:28 UTC