W3C home > Mailing lists > Public > public-ws-addressing@w3.org > October 2005

Re: Multiple Addresses in an EPR

From: Mark Little <mark.little@arjuna.com>
Date: Sun, 16 Oct 2005 15:53:29 +0100
Message-ID: <43526969.6020402@arjuna.com>
To: John Kemp <john.kemp@nokia.com>
CC: "Conor P. Cahill" <concahill@aol.com>, Mark Nottingham <mark.nottingham@bea.com>, WS-Addressing <public-ws-addressing@w3.org>

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:

>-----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 14:53:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:09 GMT