W3C home > Mailing lists > Public > public-ws-addressing@w3.org > January 2005

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

From: Vinoski, Stephen <Steve.Vinoski@iona.com>
Date: Fri, 28 Jan 2005 14:25:48 -0500
Message-ID: <13AC4E67178F4D4EA31BB1BA645303132DC17C@amereast-ems2.boston.amer.iona.com>
To: <paul.downey@bt.com>, "Paco Curbera, Francisco" <curbera@us.ibm.com>, <public-ws-addressing@w3.org>


-----Original Message-----
From: paul.downey@bt.com [mailto:paul.downey@bt.com]
Sent: Friday, January 28, 2005 11:28 AM
To: Paco Curbera, Francisco; public-ws-addressing@w3.org
Subject: RE: NEW ISSUE: EPR comparison rule doesn't support Web services

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. 



-----Original Message-----
From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org]On Behalf Of Francisco
Sent: 25 January 2005 19:29
To: public-ws-addressing@w3.org
Subject: NEW ISSUE: EPR comparison rule doesn't support Web services

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

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
Received on Friday, 28 January 2005 21:20:57 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:08 UTC