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

Assaf Arkin wrote:
 >
>...
> 
> I disagree that the URI scheme for naming objects is the correct approach. I
> think the scheme should be a service URI and an object identity. 

If you want the scheme to be a service URI and an object identity, 
that's fine. What would be the harm if the "object identity" is 
represented by an HTTP URI and a GET on that URI would return "I am a 
purchase order" or potentially something much more useful.

urn:po:12345 is one string. You can use it as an opaque key. You can 
hand it to any service anywhere in the world as an opaque key and they 
can treat it opaquely.

http://www.../12345 is another string. You can use it as an opaque key. 
Everything wonderful about opacity also hods.

But the second string has an *extra feature*. It can *also* be used as a 
locator. You can also ask the object about itself in addition to using 
it as an opaque key. That's a feature, not a bug.

> ... When you
> use the GET method you would encode the object identity into the URI (WSDL
> 1.1 does that). When you use the POST method you would encode the object
> identity inside the message. Google supports both approaches.

This is not true. You should also POST to the object by its URI.

But anyhow you missed my point about Google. Google is a service that 
users URIs as *both* opaque keys *and* locators. It uses it as an opaque 
key to know how many things are pointing to a particular page. It can 
answer questions about "www.intalio.com" without derferencing 
intalio.com because it stores metadata *about* www.intalio.com, indexed 
by the URI.

>...
> To come back to my example of changing service addresses, I have a few
> searches that I keep doing every so often to check out new documents. 
 > The information I use (the message with object identity) is the
 > search string.

A search string is not an object with identity. It is a string. On the 
other hand, the "http://www.intalio.com" website is an object with 
identity. Google can answer questions about that object based on its URI.

> can run it against Google, Yahoo, AltaVista or any other search engine. I
> can use it with http://www.google.com, or if I want to narrow it down
> http://news.google.com (notice how Google now has two service URIs). The
> fact that I keep the service URI dissociated from the object identity means
> that I can use all these search engine services to run essentially the same
> search.

You can take the URI "http://www.intalio.com" to any search engine in 
the world and get them to answer questions about your website like when 
it was last indexed. It doesn't have to derference the URI to answer the 
question. The URI is *both a locator and an identifier*.

> I'm not saying the URI scheme is useless, just that it's much more powerful
> if everything is made of service + object identity, with URI encoding being
> one way to describe an input message that is an artifact of the protocol
> binding, and not the only architectural choice.

You're mixing up a bunch of things. URIs are not "descriptions of input 
messages." They are the fundamental addressing mechanism of the 
information system we are extending. They are to the Web what object 
references are to CORBA.

> That's no problem. New clients use the existing URI as a key into the
> approval process. Not only do you not lose anything, you actually gain
> something because some independent system that used the same URI XML
> format could be integrated without any integration effort. You merely
> hand the URI of the object to the approval service and it can go look up
> what's at the URI.
> 
> [AA] Again, you are making the assumption that all the services related t
> the object are accessible from the same URI.

Let me be VERY concrete. There are four services:

   1. purchase order fetching
   2. purchase order updating
   3. purchase order approval
   4. purchase order submission for auditing

The first two are offered by the HTTP server that "owns" the purchase 
order. The last two are offered by third parties on the Web.

1.

GET http://www.purchase_orders/po/2

2.

PUT http://www.purchase_orders/po/2

3.

GET http://www.approval.com/uri=http://www.purchase_orders/po/2

4.

POST http://www.auditing.com/

http://www.purchase_orders/po/2

> [AA] That is my argument. If you assume the identity can be a URI, then
> obviously it can be a URN. Like urn:ssn:xxx-xxx-xxxx to represent my social
> security number. Does the social security administration need to provide any
> Web service to make that URI possible? Not.

Only if they want to be helpful rather than obfuscatory. After all, the 
social security administration keeps a list of valid versus invalid 
social security numbers. Wouldn't it be helpful if you could dereference 
the social security number to check whether it was known to be assigned 
to a terrorist or a dead person?

For every example of an identifier you can give, I can give useful 
information that should be associated with it by the assigning body.

> ...
> Using URLs, or URIs that are definitely resolvable into a service end-point
> (no such beast exists, but we can create it if we so wish), is a different
> issue. What it means, as you put it, is that a service must exist to
> represent it. 

No, it means that a service *may* exist to represent it and *should* 
exist to represent it. But not must. Surely you can see how that works 
based on your experience with HTTP-based XML namespaces!
Does the "http://www.w3.org/2002/08/xforms/cr" namespace cease to work 
if the W3C web server goes down?

 > ...What happens if the service does not exist, or exists at a
> different address then the one that assigned it? If Google goes down
> tomorrow, can I no longer search for a Web site because all my searches
> require Google to exist? Or are my searches independent of which search
> engine I choose to use and I can change it on a daily basis?

If I put "http://www.intalio.com" into Google, Google can answer 
questions about it *whether the site is up or not*. The reliability of 
services that use the URI as a foreign key is completely orthoganal to 
the reliability of the site itself.

  Paul Prescod

Received on Wednesday, 25 September 2002 01:38:50 UTC