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 15:10:21 UTC