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

Re: Multiple Addresses in an EPR

From: Conor P. Cahill <concahill@aol.com>
Date: Sat, 15 Oct 2005 19:26:52 -0400
To: "Mark Nottingham" <mark.nottingham@bea.com>
cc: WS-Addressing <public-ws-addressing@w3.org>
Message-ID: <4351903C.1000500@aol.com>

Mark Nottingham wrote on 10/15/2005, 4:35 PM:

 > Conor,
 > We discussed this as part of a number of WD issues, including;
 >    http://www.w3.org/2002/ws/addr/wd-issues/#i009
 >    http://www.w3.org/2002/ws/addr/wd-issues/#i026

While both of these have a somewhat similar feel to them they
are not the same issue.  I'm not  talking about different
protocols/ports, nor about multiple eprs.

I am simply talking about providing alternative physical
destination URIs that are all intepreted as the same logical
destination URI so that the client has alternatives should
there be a problem using one of them.

The intent is that only one logical message is sent to
one logical entity while giving the sender some level
of optimization/recovery should one of the physical
endpoints not be available.

I'm simply asking to allow <Address> to be multi-occurance
within the EPR whit the definition that all such elements
in a single EPR equate to the destination URI of the one
logical entity described by the EPR.

We need this kind of functionality in dealing with the hundreds
of millions of clients that we have in the real world that
talk to different instances of the same service, frequenqly
depending upon their geographic location, network status, etc.

Our work-around is to send multiple EPRs, but I think this
is a pretty painful workaround (lots of duplication of data
and the client now has to compare the multiple EPRS that they
get back to figure out which two are really the same EPR with
just a different addresss).

Of note: this is *implementation* feedback, not just spec reading
feedback.  In our implementation we find the need for this (and
feel that others, when the get to the point of supporting real
world situations will also need this -- not all, but many).

Received on Saturday, 15 October 2005 23:27:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:28:29 UTC