Re: Multiple Addresses in an EPR

So I can read the writing on the wall (and in the emails, I guess)
and I understand the drive to get the spec to finalization.   We
will use separate EPRs and add some guidance for clients to
determine that the multiple EPRs represent the same "endpoint"
(and perhaps some additional Metadata to make this easier).

I do want to point out a few reasons why the WS-A spec
may want to "address" this issue in a subsequent release:

    * Our model needs to support the case where the
      client is in an uncontrolled environemnt (e.g.
      in the entertainment system in a home) where you
      can't depend upon DNS, or a local endpoint for
      a commercial messaging system.  In fact in many
      cases we will return actual IP addresses
    * The use of multiple endpoints supported several
      models that would be profiled ontop of WS-A
      including redundancy and locality.  However we
      were not considering this as a means of sending
      a message to multiple recipients as we feel that
      an EPR is about describing a recipient, not
      about sending a message.
    * The use of a custom URI to represent multiple
      addresses would not be an acceptable solution
      for several reasons including the fact that
      off-the-shelf WS-A toolkits would not understand
      the meaning of the URI and we would have to develope
      yet another protocol to be used by the client to
      figure out what the URI meant.
    * Our usage of EPRs is in a real-time description
      of how to reach one or more services so keeping
      the single service related information in a single
      EPR would have made this simpler on the client and
      would have reduced the amount of traffic sent
      across the wire.  We aren't talking about using
      this for the Reply-To/Fault-To, etc header fields.
    
I also want to add that we brought this up during the CR process
(and not during the LC process) as we discovered this issue when
we were implementing the spec as it currently stands.  Obviously
it would have been better to bring this up earlier (although
I'm not sure the results would have been different) but we
didn't have the implementation experience at that time.

Conor

Received on Tuesday, 18 October 2005 04:57:00 UTC