Re: Multiple Addresses in an EPR

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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

iD8DBQFDUlatmNJiOOM57NMRAlLyAKCjpVZWDq/hdK3OUzC1jKYIRAx5sACeMgIz
vzqAOIp4TUEl3FEYT6hGFrc=
=R4Tj
-----END PGP SIGNATURE-----

Received on Sunday, 16 October 2005 13:40:11 UTC