Re: Multiple Addresses in an EPR

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.

On the one hand, duplication across instances of a given structure is a
generic problem.  If the only problem is to eliminate duplication across
a set of EPRs that only differ in their [address], then one generic
solution is to include the duplicated material by reference instead of
by value.  Another is to define a special form for generating a set of
instances (in this case from a set of [address] values and a single
reference parameters and metadata).  Either approach makes it clear that
the duplicated material is the same object, as opposed to being
syntactically identical by accident. 

On the other hand, as has been pointed out, the proposed change of
having multiple [address] fields in the same EPR says nothing at all
about the semantics of those addresses, or at least it doesn't without
significant further work.  All that we would know is that some set of
[address] values was packaged together with some (possibly empty)
[reference parameters] and [metadata].  It might be a reasonable
inference that each [address] value is associated with all the
[reference parameters] and all of the [metadata], but even this is just
an inference.  Going further than this, for example, defining a "try all
and use the first that answers" policy, is not even a reasonable
inference without further context.

I don't see a meaningful semantic difference  between "when you see
several EPRs, try to connect to all of them and shut down all but one
(and presumably fault if none answers within a given time ...)" and
"when you see an EPR with several [address] values, connect with each
one, using the [reference parameters] and [metadata] given in the rest
of the EPR, and shut down all but the first one that answers (and
presumably fault ...)", except that the first is more flexible.  The
second approach is effectively constructing a set of EPRs anyway, by
combining each of the [address] values with the constant [reference
parameters] and [metadata].

>From an architectural point of view, the first alternative seems
simpler.  EPRs are the unit of currency in WSA.  Trying a set of EPRs,
as opposed to trying a set of addresses in a given EPR, generalizes
smoothly to the case where the reference parameters or metadata don't
happen to the be the same.  An implementation built this way will be
able to handle alternate endpoints more flexibly than one that insists
that only the address may differ. 

If you accept that at the end of the day, it's all EPRs, then the only
difference is how to represent several EPRs that happen to differ only
in their [address].  If it helps, I wouldn't be against defining
(separately from WSA proper) something like

<wsaext:MultipleEndpointReference>
    <wsa:Address>xs:anyURI</wsa:Address>+ <!-- Note, [1 .. *] -->
    <wsa:ReferenceParameters>... </wsa:ReferenceParameters> ?
    <wsa:Metadata> ... </wsa:Metadata>?
    <xs:any/>*
</wsaext:MultipleEndpointReference>

for some value of "wsaext", as an abbreviation for a set of EPRs that
differ only in [address], but I don't see that this group could take on
even that much now.  I agree with everyone else who has said we're way
to late in the game to consider either such change without a very
compelling justification.

>
> 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