RE: NEW ISSUE: EPR comparison rule doesn't support Web services 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 Friday, 28 January 2005 17:53:35 UTC