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

RE: Multiple Addresses in an EPR

From: Conor P. Cahill <concahill@aol.com>
Date: Sun, 16 Oct 2005 22:41:35 -0400
To: vikas@sonoasystems.com
cc: "'David Orchard'" <dorchard@bea.com>, "'John Kemp'" <john.kemp@nokia.com>, "'ext Mark Little'" <mark.little@arjuna.com>, "'Mark Nottingham'" <markn@bea.com>, 'WS-Addressing' <public-ws-addressing@w3.org>
Message-ID: <43530F5F.8040606@aol.com>

Vikas Deolaliker wrote on 10/16/2005, 10:02 PM:

 > Multiple physical resolutions of a single logical address should be
 > done by
 > an external resolving server (something like DNS). Having the addressing
 > mechanism do resolution from logical to physical means every client in
 > the
 > world would have to keep a database of all the physical resolutions of a
 > logical address and continuously update it to avoid stale entities.

The recipient of the EPR keeps track of the addresses in the EPR for
the duration of the validity of the EPR.  THey don't need to keep
track of each and every address in the world for all time.

Nor do they need to do this in situations where DNS already does
the job.  In our case, DNS doesn't solve the problem, nor does
an intelligent switch (especially considering that our clients
are typically running in environments where there is no centrally
managed system administration ensuring that there is proper
configuration of the network).  Consumers aren't known to be
the best system adminstrators in the world.

 > It might not be a big problem for small number of resolutions, but
 > when the number of services explode, that addressing mechanism
 > will not scale.

It isn't a big problem in either case as we're just talking about
an EPR provided to a client that needs to dereference the EPR to
access a service.  They only really need to deal with the multiple
addresses for first access (although we would expect most to keep
track of it for the duration of the dereference (e.g. multiple

Received on Monday, 17 October 2005 02:43:38 UTC

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