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 Tuesday, 25 January 2005 19:29:31 UTC