- From: Mark Nottingham <mark.nottingham@bea.com>
- Date: Mon, 17 Oct 2005 12:02:17 -0700
- To: "Conor P. Cahill" <concahill@aol.com>
- Cc: WS-Addressing <public-ws-addressing@w3.org>
Conor, If you'd like a definitive answer to this by the WG, I'd recommend you raise a CR issue, as outlined in the status section of either document. Cheers, On 15/10/2005, at 4:26 PM, Conor P. Cahill wrote: > > > 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). > > Conor > > > > -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems ________________________________________________________________________________ BEAWorld 2005: coming to a city near you. Everything you need for SOA and enterprise infrastructure success. Register now at http://www.bea.com/4beaworld London 11-12 Oct| Paris13-14 Oct| Prague18-19 Oct |Tokyo 25-26 Oct| Beijing 7-8 Dec
Received on Monday, 17 October 2005 19:03:12 UTC