W3C home > Mailing lists > Public > www-ws-arch@w3.org > September 2002

Re: service references (was: Re: WSA diffs from REST)

From: Paul Prescod <paul@prescod.net>
Date: Mon, 23 Sep 2002 20:31:55 -0700
Message-ID: <3D8FDCAB.10903@prescod.net>
To: Assaf Arkin <arkin@intalio.com>
CC: www-ws-arch@w3.org

Assaf Arkin wrote:
> I've seen two schools of thought around this subject.
> 
> One that believes it should be a URI regardless, and would often interpret
> URI to mean an accessible URI (a URL, in fact). 

Right, this is the school of thought already represented in the writings 
of the Technical Architecture Group of the World Wide Web. 
www.w3.org/TR/webarch

> .... In this case, when I create
> the purchase order I would use the URI http://myserver.com?poNum=1234. The
> obvious risk here is that tomorrow I will be using the service at
> http://yourserver.com to access the purchase order, and the client
> application will attempt to use the URI to access the service by talking to
> the wrong server.

I've debunked this in another message so I won't do it again.

> The other shcool of thought believes that the instance ID should be based on
> the type that is most applicable. It could be an eleven digit type, or an
> alphanumeric, or it could be a URI. There are identifiers out there that are
> based served by URI. But if you subscribe to this school of thought you
> understand that the URI is not necessarily an accessible resource, but
> merely an encoding scheme for an identifier. For example, urn:po:1234 could
> be a valid URI scheme for a purchase order number.

If the identifier is not an accessible resource then you can't contact 
the thing to use it as a SOAP endpoint. You can't send it messages or 
ask it questions...unless you indirect through a location-based URI of 
some sort.

> .... You could use it equally
> as well with the service at http://myserver.com or http://yourserver.com.

And you're back to where you started because you have no way to 
communicate when the URI to the service moves. If you contact the thing 
through any location-based URI (whether a service URI or an entity URI) 
then you have a responsibility for maintaining that URI or providing a 
redirect. On the other hand, if you have some technique for accessing 
web services without regard to their DNS location then you can use the 
*same technique* for accessing the entities/purchase orders. So there is 
no reason to use ONE addressing scheme for services and another for 
domain entities.

  Paul Prescod
Received on Monday, 23 September 2002 23:32:46 GMT

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