Re: Multiple Addresses in an EPR

While the particular example that I gave could be considered a
profile of how one uses an EPR, the fact is that the basic
data structure of the EPR, as it currently stands, does not
allow such a profile by only permitting (and requiring)
a single URI in a single-occurance element called address.

I think that by loosening this requirement to allow
multiple address elements, the spec then becomes
profilable to support different situations.

EPRs are a method of describing how to reach a logical
endpoint for the destination of one or more messages,
it makes alot of sense (IMHO) to allow such a container
to have multiple addresses.

Conor

Mark Little wrote on 10/16/2005, 3:37 AM:

 >
 > 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 10:20:12 UTC