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

Assaf Arkin wrote:
> 
>...
> 
> [AA] Not necessarily. I am not implying that the service is hosted on one
> machine today and another tomorrow, I am implying that you may use one
> service today and another tomorrow, or even two services today. If the
> entity is persistent, then you can have multiple touchpoints, multiple
> applications that access it, and you can build new applications over time.
> And this is just a simplification, the host may remaind the same, but the
> URI change to reflect the addition of a new port type.

I don't understand that paragraph. I'm going to _guess_ that you are 
saying that I might want to have multiple services that have information 
about a single logical object. That's fine whether you use HTTP URIs or 
UUIDs. If you use URIs then you know you can go to that address for 
information about the resource. But nobody else is precluded from also 
having information about it. That's how Google works.

> Now, not all objects are persistent. But when you start dealing with objects
> that are persistent, or are exposed through a service but not themselves a
> service, as is the case with component architectures, you separate the
> identity of the object from the identity of the service that deals with it.

It is precisely the point that I want to separate the identity of the 
object from the identity of the service that deals with it. That's why I 
want to send messages *to the object* and not to the service.

>...
> [AA] We're getting bogged down with technicality. Maybe I just added another
> service to my stock of services dealing with Web services. Yesterday there
> was http://fulfill.myservice.com, and the URI remains static. Tomorrow, I
> add http://approve.myservice.com with additional operations that are
> independent of the old service, but can deal with the same stock of purchase
> orders. So old clients remain the same, new clients get a different URI.

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.

> In fact the case I was thinking of is different. Look at how we deal with
> airline tickets. Let's say you got your ticket from cheapfares.com and you
> walk to the airline counter and show them the picture. The system has your
> ticket under the number 12345. But the ticket identifier is
> http://cheapfares.com?id=4548748745. (This indeed represents ticket 12345,
> but cheapfares.com can create any URI they want, right?) The airline has no
> clue what ticket you're talking to.

You're presuming that the airline doesn't know what to do with the URI. 
But the URI is just a string, the same as the ticket number 12345. The 
URI can serve as a globally unique identifier for the object. That's how 
Google manages websites. That's how XML namespaces work. That's the 
basis for RDF, RSS and every other web metadata project.

Who has the number granting authority? If it is the airline, then they 
could just as easily supply a resolvable URI. If it is the travel 
service, then the same goes for them.

If there is a need to use numbers because they are mmenonic and easy to 
write out for physical-world use, then the document 
http://cheapfares.com?id=4548748745 can *contain* the physical-world number.

> Now, let's assume the ticket contained two different fields. One was the
> ticket number standardized for all services in the world that can access it,
> including cheapfares.com, your airline, your travel agent, the hotel that
> keeps track of it to give you a discounted room, etc. It also contained
> fields for various services you can use with that ticket number,
> cheapfares.com to get an invoice, the airline to get confirmation,
> dealsforflyers.com to get discounted related to that ticket, etc.

Whoever assigns ticket numbers can assign URIs without any loss of 
functionality. You only *gain* functionality because now when you see 
the ticket number URI you have a canonical place you can go to ask 
questions about that ticket like: "who booked this ticket?" If you also 
want to have associated services that treat the ticket numuber URI as an 
opaque string key in a database, more power to them. The Web wouldn't be 
the Web without Google.

>...
> So the URI of the entity does not represent the URI of the service that
> accesses that entity.

The URI of the entity can represent the URI of *one* service that knows 
about the entity. There can be many. But as long as there is one service 
attached to the URI, you know you can find out about it, even if nobody 
has told you anything about the others.

  Paul Prescod

Received on Tuesday, 24 September 2002 21:45:22 UTC