Re: Naming the service resource

In response to your example, it's up to the provider of the resource to say
if the new implementation is the same resource as the original one or if it
is a different one. I can think of many reasons why you might want to go
either way. Speaking from a best practices point of view, though, I probably
wouldn't identify the new one as my production resource until I'm ready to
release it as a production service. In that case, it would be a
development/test resource (a different resouce) until I promote it to
productions status (at which point it replaces my original resource).

IMHO, the ability to select a service based on reliable response time is a
separate issue and not part of the service's basic identity.

Does no one else out there think that the service is an "important
resource," i.e., one that should be named?

Anne

----- Original Message -----
From: "Ugo Corda" <cordau@acm.org>
To: "'Anne Thomas Manes'" <anne@manes.net>; <www-ws-desc@w3.org>
Sent: Wednesday, July 02, 2003 2:20 PM
Subject: RE: Naming the service resource


> Ann,
>
> Thank you for your clarifications. I think now I better understand your
> point of view. But I am still not convinced that it is appropriate to
> introduce the concept of service resource at this point (it might be in
the
> future, if and when the WSD group decides to get heavily involved with
> service semantics).
>
> Defining the concept of a service resource that abstracts from particular
> implementations and endpoints is not easy in the general case and might
> ultimately depend on the application.
>
> To give you an example, suppose there are two implementations of the same
> service interface. They have different endpoints but they do exactly the
> same thing. There are two of them because the first one is a very slow
> legacy implementation and the second one is a brand new, much faster
> implementation. (But the second implementation is still undergoing
changes,
> so some times it is taken off line and people can only use the first one).
> Do the two implementations represent the same service resource?
>
> Well, it depends. If my application does not care about the response time,
> then I conclude that certainly they have the same semantics and I would be
> happy if somebody gave me a serviceResourceURI through which I could use
> either endpoint.
>
> But if my application can only operate under the response time provided by
> the second implementation, I would conclude that they indeed have
different
> semantics so that using a unique serviceResourceURI would be misleading.
>
> So, depending on the user's point of view, what is an implementation
detail
> in one case becomes a semantic differentiator in the other, and different
> implementations might or might not meaningfully correspond to the same
> service resource ...
>
> Ugo
>
>

Received on Wednesday, 2 July 2003 14:35:52 UTC