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

Assaf Arkin wrote:
> Good example. The question is, what form will PurchaseOrderReference take.
> 
> 1) A URL. ...
 > 2) A URI....

URLs are URIs and most deployed URIs are URLs, so I'm going to deal with 
just one of these cases.

http://www.w3.org/TR/2001/NOTE-uri-clarification-20010921/

> A purchase order is a service with associated operations that you
> can perform on it, the URL of that service is known and you can pass it
> around. Here is where you want strong typing of the port being passed.

Agreed.

> Just saying it's a URI is not enough - what operations can you do about it?
> You want to be able to say it's a port that implements a particular portType
> (or service type) so you know which operations you can perform on this
> service.

Agreed.

> You could pass a service definition (e.g. element of type wsdl:service) but
> that would allow run-time type checking not design-time type checking.

But there isn't really any rocket science here. You need to be able to 
declare at design time what the runtime type of the URI is. This is no 
different than declaring a pointer type in C. Yes, it might require a 
WSDL-specific annotation to XML schema or maybe a new feature in XML 
Schema 1.1.

> One caveat. If I decide to move my service from http://host1.com to
> http://host2.com tomorrow and you keep track of URIs pointing to the
> purchase order, you will have to change all these URIs.

That would be profoundly irresponsible of the service maintainer. There 
is no reason to make that change.

  * http://www.w3.org/Provider/Style/URI.html

 > ... It takes changing
> one line in a configuration file to make the application point to a
> different service, I'm not sure changing URI references to objects, if these
> are stored in a database, is that trivial.

You've published your service on the Web. There are thousands of 
clients. Now you change the URI. You can't change one configuration 
file. You must change thousands, on machines you don't own. Obviously 
there is no way, therefore "Cool URIs don't change".

>...
> 3) A typed identifier. If it's not a service reference, maybe we should not
> be using a URI. How about a simple type to represent a purchase order
> number, e.g. pom:poNumber. The element type or simple/complex type tells you
> exactly what you are dealing with. You can also express how that information
> is contained in a message using something like a selector (see WSCI).

You're making things more complex for no reason. Now we have a plethora 
of incompatible reference types and hooking together two systems becomes 
quite expensive and difficult. Plus you have a very messy relationship 
between the SOAP-for-GET feature and the rest of the web services 
architecture (to say nothing of the Web architecture).

Changing the URI is not feasible whether it is one URI or a thousand. If 
you really need to change the URI you can use HTTP redirect features.

>...
> But I'm also indicating that one should not discard the two type of
> references that exist. The service itself, and the entity managed by the
> service, in the latter case the identifier is disjoint from the address of
> the service and is represented by some business friendly identifier.

I'm not discarding the two types of references. I'm unifying them into 
"uniform/universal resource identifiers". I'm discarding the 
distinction, because it isn't a helpful distinction. It's a meaningless 
distinction anyhow because sometimes the "business entities" are 
*services* so you need a way to refer to strongly typed services anyhow. 
Once you've done that, the distinction between services and their 
entities looks pretty arbitrary. There is a good reason that programming 
languages don't have any such distinction.

I'm not going to go into the rest of your discussion because it depends 
on distinctions that I don't think are useful, to whit:

 > ...
 > When creating the WSCI specification we realized the need to
 > support both references to services (locators), means to express
 > how identifiers (and other properties) are expressed in WSDL
 > messages (selectors), and means to  indicate what entity an
 > operation refers to (correlation).

It is precisely this confusing and damaging duplications of 
functionality that I am arguing against. We don't need to deploy a 
totally different suite of tools in managing "entities" and "services". 
You're proposing that WSDL should have a first-class notion of "entity" 
which is more complexity, and IMHO, unjustified.

If there is any virtue to a distinction between "service referencing" 
and "entity referencing", I don't get it.

  Paul Prescod

Received on Monday, 23 September 2002 23:25:33 UTC