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 18:36:36 UTC