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 15:02:40 UTC