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

RE: Multiple Addresses in an EPR

From: <paul.downey@bt.com>
Date: Mon, 17 Oct 2005 14:35:41 +0100
Message-ID: <2A7793353757DB4392DF4DFBBC952255E1879F@I2KM11-UKBR.domain1.systemhost.net>
To: <mark.nottingham@bea.com>, <concahill@aol.com>
Cc: <public-ws-addressing@w3.org>


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.


[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


We discussed this as part of a number of WD issues, including;

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.


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
Received on Monday, 17 October 2005 13:35:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:28:29 UTC