Re: Multiple Addresses in an EPR

Hi Conor. Wouldn't that be something to layer on WS-Addressing? WS-QoS 
or WS-HighAvailability/WS-Group perhaps? The same requirements have 
certainly arisen in other distributed systems/architectures in the past 
and been often been tackled as an abstraction on top of baseline 
addressing, e.g., by introducing the notion of a logical group address. 
For example, in CORBA they introduced the notion of an Interoperable 
Logical Group Reference (IOGR) within the Fault Tolerant specification 
(http://www.omg.org/cgi-bin/doc?formal/04-03-21) which allowed them to 
do pretty much what you describe.

One of the problems with putting this within the baseline addressing 
infrastructure is that it's not as simple as just adding multiple EPRs. 
You need to think about what the "fail-over" policy is (essentially why 
and when do I use one EPR over another?): what's good for one 
client/application may not be good for another, particularly when you 
consider things like service consistency and split-brain scenarios. So I 
think if we went down that route within WS-Addressing we'd either spend 
a long time developing the right framework to handle all of this, or 
we'd come up with something basic which will eventually be superceded by 
something like a WS-Group because it doesn't cope with all of the use cases.

Mark.


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
>
>
>
>
>  
>

Received on Sunday, 16 October 2005 07:37:34 UTC