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

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.

[AA] I agree that a solution is needed. I can't really recommend a change to
XML Schema itself. The problem is that saying what a URI means can be done
in different languages. One would be to say this URI is a type of WSDL 1.1
service. Another would be to

> 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.

[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.

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.



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".

[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.

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.

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.

That separation between the identified of the entity and the service that
operates on it is alive and well in the business world, and it makes all the
sense when the customer can choose which service to perform on a related
entity.



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.

[AA] Changing the URI is what I do everyday. Because once you send me the
purchase order, I may have a variety of internal applications to deal with
it. I don't have to actually go and change the URIs all day long, they may
be fixed for the next millenium. But I may still have multiple services that
are touch points for accessing the same entity, and add more services as I
go along. You, the customer don't see them, you get one access point. And my
application is defined exactly once and never changes, but it does use five
different services, at different URIs (not just hosts, think host and file).
So the URI of the entity does not represent the URI of the service that
accesses that entity.

arkin


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 Tuesday, 24 September 2002 14:20:03 UTC