Re: Multiple Addresses in an EPR

I agree with the requirement. I just disagree that it's so fundamental 
that it has to be within WS-Addressing.

Mark.


Conor P. Cahill wrote:

>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 11:33:31 UTC