W3C home > Mailing lists > Public > www-ws@w3.org > April 2003

Identifiers, locators, and scalability

From: Mark Baker <distobj@acm.org>
Date: Sat, 26 Apr 2003 02:34:31 -0400
To: "Clemens F. Vasters" <clemensv@newtelligence.com>
Cc: www-ws@w3.org
Message-ID: <20030426023431.L23133@www.markbaker.ca>

Hi Clemens,

This doesn't seem to be relevant to WSD at all, so I've taken it
to www-ws@w3.org.

On Sat, Apr 26, 2003 at 07:55:38AM +0200, Clemens F. Vasters wrote:
> Mark,
> 
> I believe there is a problem with the approach to web services you are
> advocating, because the same service may exist in several places without
> either
> (a) a 1:1 mapping between a URI and that service
> (b) a fixed location or even port at which this service can be reached. 
> 
> You seem to be ignoring the fact that, for instance, absolutely
> identical copies of services providing certain R/O data may be located
> at more than one place for the purpose of reducing network latency
> (Earth, together with its geostationary orbit is a big place, still) and
> other problems related to the location of the service. Each of the host
> locations of the service has a unique URI, because it must be possible
> to talk to it indiviually. Virtualizing this service would require an
> "abstract" URI which points to a logical location that will choose the
> most appropriate place for you to talk to.

Not necessarily.

> So, in that case, each
> service has indeed at least two URIs, even in the case of HTTP. One that
> you bind to and one that you talk to. If you take additional protocols
> into account (I hope you don't deny the fact that SMTP is around), a
> service endpoint may even have more URIs.

Sure.

> The uniqueness of a URI requires a distriction between URI and URL
> wheree you always define URI as a protocol independent entity
> "urn:my-service" which has multiple URLs associated with it.
> 
> The approach to web services that you describe doesn't scale for a large
> set of use cases.

You're assuming a distinction that doesn't exist in Web architecture;
that between a locator and an identifer.  "Locator" is a role played
by an identifier at different points in time, it is not intrinsic to a
string.  In general, only the second last component in any chain treats
an identifier as a locator, because only it needs to open a connection
to the origin server.  Everybody else treats it as just an identifier.

In Web architecture, URIs are identifiers.  There is nothing
preventing a Web server hosted at place A from answering requests for
URIs from place B.  All Web servers are potentially proxies, because
all Web components implement the same connector semantics.

There is certainly work to be done in knowing where and when to *route*
requests to servers that answer requests for these nomadic resources.
But architecturally speaking, the Web has sketched out a solution for
us.  It will still be up to some smart folks to build a scalable
way of managing that, but Web architecture doesn't necessitate it
being non-scalable.

MB
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca
Web architecture consulting, technical reports, evaluation & analysis
Received on Saturday, 26 April 2003 02:32:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:41 GMT