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

+1
----- Original Message -----
From: "Francisco Curbera" <curbera@us.ibm.com>
To: "Ugo Corda" <UCorda@SeeBeyond.com>
Cc: <paul.downey@bt.com>; <public-ws-addressing@w3.org>
Sent: Friday, January 28, 2005 6:46 PM
Subject: RE: NEW ISSUE: EPR comparison rule doesn't support Web services
gateways/routers


>
> Ugo,
>
> Paul is completely right when he lists all the stuff this specification
> should not be concerned with: EPR lifecycle, caching, comparisons etc.
He's
> also right that we need to put Section 2.3 out of its misery asap. I don't
> understand your "hostage" suggestion: Section 2.3 is broken and it must
go,
> period. If you think the description of parameters is not good, you should
> open an issue to get it changed - maybe, after all, I am not the one
trying
> to change the semantics of ref. parameters :-) .
>
> Paco
>
>
>
>
>                       "Ugo Corda"
>                       <UCorda@SeeBeyond        To:
<paul.downey@bt.com>, Francisco Curbera/Watson/IBM@IBMUS,
>                       .com>
<public-ws-addressing@w3.org>
>                                                cc:
>                       01/28/2005 12:53         Subject:  RE: NEW ISSUE:
EPR comparison rule doesn't support Web services
>                       PM                        gateways/routers
>
>
>
>
>
> Paul,
> I would agree on removing sec. 2.3 only after the semantics of ref
> params gets completely spelled out in the spec. (In other words, I like
> to keep sec. 2.3 as hostage to force clarification on ref params
> semantics ;-).
>
> I feel there is considerable disagreement within the group (and outside
> the group) regarding the use of ref params. The current definition of
> ref params found in the spec is completely vague and will only translate
> into extended lack of interoperability if left that way.
>
> Ugo
>
> > -----Original Message-----
> > From: public-ws-addressing-request@w3.org
> > [mailto:public-ws-addressing-request@w3.org] On Behalf Of
> > paul.downey@bt.com
> > Sent: Friday, January 28, 2005 8:28 AM
> > To: curbera@us.ibm.com; public-ws-addressing@w3.org
> > Subject: RE: NEW ISSUE: EPR comparison rule doesn't support
> > Web services gateways/routers
> >
> >
> >
> > Reading the latest Working Drafts it does seem to me that
> > section 2.3 cries out for some extra work. I particularly
> > dislike the final sentence:
> >
> > [[
> > Therefore, a consuming application should assume that different XML
> > Schemas, WSDL definitions and policies apply to endpoint references
> > whose addresses differ.
> > ]]
> >
> > Metadata such as WSDL and Policy surrounding endpoints *may*,
> > or indeed
> > *may not* differ for a whole host of different reasons,
> > including having more than one description mechanism for an
> > endpoint, other interactions
> > which may have taken place, username being used, content negotiation,
> > out of band data, etc, etc. Therefore this sentence is at
> > best redundant, worst misleading.
> >
> > As with the EPR life cycle, we should push how EPRs and any
> > surrounding
> > meta-data may be employed, compared and cached firmly out of
> > scope and
> > in the domain of specs layering upon Addressing.
> >
> > So in the absence of a compelling requirement for specifying EPR
> > comparison in *this* specification, I feel we should put EPR
> > comparison
> > out of our misery and ditch the whole of section 2.3.
> >
> > Paul
> >
> > http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr
> -core.html?rev=1.12
>
>
>
> -----Original Message-----
> From: public-ws-addressing-request@w3.org
> [mailto:public-ws-addressing-request@w3.org]On Behalf Of Francisco
> Curbera
> Sent: 25 January 2005 19:29
> 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.
>
>
>
>
>
>
>
>
>

Received on Monday, 31 January 2005 00:12:14 UTC