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

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.


[AA] I am fully convienced that we need an ability to reference services and
be able to define references to service types. It doesn't matter whether or
not we use URIs to reference objects. In my opinion even if your services do
not represent any entity, you still need the ability to send URIs around and
type these URIs based on the service type(s) they support. I disagree this
is the job for XSDL or should be done as part of message type definition,
but that's a discussion for the WSDL working group. We can always take it
there to propose some solution.

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

If I was architecting a solution like Google, I would define a URI for the
service and the object identity, in this case an xsd:string. I would then
provide multiple protocol bindings. I could have one based on SOAP and POST
that puts the identity in the header. I could have one based on SOAP and GET
that encodes it in the URI. I could have one human representation that uses
POST, and another that uses GET. If I'm not mistaken, that's exactly how
Google works.

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

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.


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 to
the object are accessible from the same URI. It must be one URI if it is
used to represent the object. And I'm making the assumption that services
will be all over the place to essentially deal with the same object. It
doesn't preclude having one service at the same URI, just makes it a special
case.


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.

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

If it is a URI, then at the most it will be associated with a namespace URI.
But remember, a namespace URI says nothing. There is no indication that the
address contains a Web service, XML schema, or anything of that sort. A URN
is not much different than any other arbitrary data type. If you allow
arbitrary data types, such as xsd:string, surely a specific case would be to
allow URIs. So at the very least I support the notion of using URIs.

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

arkin

Received on Tuesday, 24 September 2002 22:31:13 UTC