RE: Multiple Addresses in an EPR

WSA does allow for it.  Create a new QName like wsalt:address, define
the semantics, and put it in EPR instances.  WSA just didn't want to get
into the business of defining the semantics of duping the wsa:address
for EPRs everywhere.

Dave

> -----Original Message-----
> From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-
> request@w3.org] On Behalf Of John Kemp
> Sent: Sunday, October 16, 2005 8:02 AM
> To: ext Mark Little
> Cc: Conor P. Cahill; Mark Nottingham; WS-Addressing
> Subject: Re: Multiple Addresses in an EPR
> 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I believe that WS-Addressing already supports profiling of a set of
ref
> params and metadata defined for each EPR address (via multiple EPRs).
> 
> WS-Addressing does not support, however, a case where a generator of
> EPRs wishes to define multiple address elements accompanied by a
single
> set of metadata and ref params, all within one EPR.
> 
> There may be many cases where an alternative URI in the same EPR will
be
> useless, but there are also cases where it would be useful.
> WS-Addressing should allow for such cases, if (as I think we've
agreed)
> there is a valid requirement to do so.
> 
> - - JohnK
> 
> ext Mark Little wrote:
> > Understood. However, you can't profile the usage of just the URI,
when
> > the EPR is more than that. Each (set of) ReferenceParameter(s) is
> > typically defined on a per URI basis and in fact provided by the
> > service. So in many cases I think an alternate URI will be useless,
> > because an alternate EPR is what is required.
> >
> > Mark.
> >
> >
> > John Kemp wrote:
> >
> > I think the point Conor is trying to make is that without the
ability to
> > put multiple addresses into an EPR (ie. via XML schema
> > maxOccurs="unbounded") at the WS-Addressing specification/schema
layer,
> > no-one can profile the usage of this functionality.
> >
> > And I agree with the requirement BTW.
> >
> > - JohnK
> >
> > ext Mark Little wrote:
> >
> >
> >>>> 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
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >
> >
> 
> >>
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (Darwin)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> 
> iD8DBQFDUmt5mNJiOOM57NMRAg/KAKD2a1ULPzvRbXrJWqo+Xs4G8O6LlACeIvci
> xVCdAkBbXDw6IEjyhs6KQJY=
> =CUsa
> -----END PGP SIGNATURE-----

Received on Sunday, 16 October 2005 17:10:05 UTC