Re: Multiple Addresses in an EPR

+1

Fail-over or load-balancing are better handled from the server end 
transparently than punting it to the client-level (EPR)  that requires 
special handling by all clients, IMO.

Regards,
Prasad

-------- Original Message --------
Subject: 	RE: Multiple Addresses in an EPR
Resent-Date: 	Mon, 17 Oct 2005 13:35:54 +0000
Resent-From: 	public-ws-addressing@w3.org
Date: 	Mon, 17 Oct 2005 14:35:41 +0100
From: 	<paul.downey@bt.com>
To: 	<mark.nottingham@bea.com>, <concahill@aol.com>
CC: 	<public-ws-addressing@w3.org>



Conor, 

You might see allowing multiple wsa:Address values in an EPR
as an obvious requirement to perform load balancing or fail-over 
(i'm not clear which you are proposing), but it raises a large
number of questions the specification would need to answer:

- is the order of the addresses important? 
- if so, how much more is the first address desirable over the second?
- is it acceptable to send the same message to both addresses? 
- which failures or conditions result in sending to 
  the alternate address? 
 
Also others in the WG will expect to see multiple addresses providing a 
distribution, subscription, TO/CC/BCC list, or some other, possibly
unforeseen, form of multiplexing that is likely to conflict with 
the supposed simple use-case you have in mind.
 
Some of the proposals discussed by the Working Group for issue#9 [1]
a year ago, surrounded adding a processingStyle property to handle 
multiple addresses. OK, much of issue#9 discussion surrounded multiple 
wsa:ReplyTo's within a message, but the same issues will apply
to multiple addresses within an EPR. 

 
The Working Group therefore concluded this an unnecessary complication
to the base addressing specification, possibly out of scope based
on the wording of the Charter, especially given:

* an URI/IRI is an identifier, and may be de-referenced
  to another physical location or locations at the discretion 
  of the sender 

* the EPR may contain meta-data to assist such de-referencing

* the EPR structure is extensible allowing the addition of multiple 
  addresses along with other information items by another specification
  

As the person who raised issue#9 and who worked through a number of 
proposals for the working group to consider to support extensible,
multiple addresses, or at least understand the implications of not 
supporting them, my member company would be very unhappy if this 
issue were to be reopened during CR, resulting in further delay 
to the already delayed schedule.

Paul

[1] http://www.w3.org/2002/ws/addr/wd-issues/#i009



-----Original Message-----
From: public-ws-addressing-request@w3.org on behalf of Mark Nottingham
Sent: Sat 10/15/2005 9:35 PM
To: Conor P. Cahill
Cc: WS-Addressing
Subject: Re: Multiple Addresses in an EPR
 

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

I believe that the current answer is that while this isn't possible,  
you can embed WSDL in an EPR that contains multiple ports for the  
same portType, thereby achieving much of the same effect.

Regards,


On 15/10/2005, at 3:46 AM, Conor P. Cahill wrote:

>
> In working on using EPRs, we have run into several cases where EPRs  
> would be much more efficient if we could put multiple addresses int  
> one EPR (meaning that the recipient can use any of the Addresses).
>
> The only way to currently do this is to send multiple EPRs with  
> everthing other than the address duplicated across the EPRs which  
> is not very efficient, nor does it clearly have the same semantics  
> unless the client does a complete EPR comparison to determine that  
> the remaining data is the same.
>
> The need for multiple addresses is driven by our need to support  
> clients communicating on unstable networks, with geographically  
> dispersed clusters, etc.   One of our applications in particular is  
> configured to initiate the connection on each of the addresses and  
> when one answers, shut down the others.
>
> To be clear, I am asking that the working group consider allowing  
> the Address element in the EPR to be a multi-occurance element  
> (maxOccurs="unbounded").
>
> Conor


--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems




paul.downey@bt.com wrote:

>Conor, 
>
>You might see allowing multiple wsa:Address values in an EPR
>as an obvious requirement to perform load balancing or fail-over 
>(i'm not clear which you are proposing), but it raises a large
>number of questions the specification would need to answer:
>
>- is the order of the addresses important? 
>- if so, how much more is the first address desirable over the second?
>- is it acceptable to send the same message to both addresses? 
>- which failures or conditions result in sending to 
>  the alternate address? 
> 
>Also others in the WG will expect to see multiple addresses providing a 
>distribution, subscription, TO/CC/BCC list, or some other, possibly
>unforeseen, form of multiplexing that is likely to conflict with 
>the supposed simple use-case you have in mind.
> 
>Some of the proposals discussed by the Working Group for issue#9 [1]
>a year ago, surrounded adding a processingStyle property to handle 
>multiple addresses. OK, much of issue#9 discussion surrounded multiple 
>wsa:ReplyTo's within a message, but the same issues will apply
>to multiple addresses within an EPR. 
>
> 
>The Working Group therefore concluded this an unnecessary complication
>to the base addressing specification, possibly out of scope based
>on the wording of the Charter, especially given:
>
>* an URI/IRI is an identifier, and may be de-referenced
>  to another physical location or locations at the discretion 
>  of the sender 
>
>* the EPR may contain meta-data to assist such de-referencing
>
>* the EPR structure is extensible allowing the addition of multiple 
>  addresses along with other information items by another specification
>  
>
>As the person who raised issue#9 and who worked through a number of 
>proposals for the working group to consider to support extensible,
>multiple addresses, or at least understand the implications of not 
>supporting them, my member company would be very unhappy if this 
>issue were to be reopened during CR, resulting in further delay 
>to the already delayed schedule.
>
>Paul
>
>[1] http://www.w3.org/2002/ws/addr/wd-issues/#i009
>
>
>
>-----Original Message-----
>From: public-ws-addressing-request@w3.org on behalf of Mark Nottingham
>Sent: Sat 10/15/2005 9:35 PM
>To: Conor P. Cahill
>Cc: WS-Addressing
>Subject: Re: Multiple Addresses in an EPR
> 
>
>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
>
>I believe that the current answer is that while this isn't possible,  
>you can embed WSDL in an EPR that contains multiple ports for the  
>same portType, thereby achieving much of the same effect.
>
>Regards,
>
>
>On 15/10/2005, at 3:46 AM, Conor P. Cahill wrote:
>
>  
>
>>In working on using EPRs, we have run into several cases where EPRs  
>>would be much more efficient if we could put multiple addresses int  
>>one EPR (meaning that the recipient can use any of the Addresses).
>>
>>The only way to currently do this is to send multiple EPRs with  
>>everthing other than the address duplicated across the EPRs which  
>>is not very efficient, nor does it clearly have the same semantics  
>>unless the client does a complete EPR comparison to determine that  
>>the remaining data is the same.
>>
>>The need for multiple addresses is driven by our need to support  
>>clients communicating on unstable networks, with geographically  
>>dispersed clusters, etc.   One of our applications in particular is  
>>configured to initiate the connection on each of the addresses and  
>>when one answers, shut down the others.
>>
>>To be clear, I am asking that the working group consider allowing  
>>the Address element in the EPR to be a multi-occurance element  
>>(maxOccurs="unbounded").
>>
>>Conor
>>    
>>
>
>
>--
>Mark Nottingham   Principal Technologist
>Office of the CTO   BEA Systems
>
>
>
>  
>