Naming the service resource

See inline...
----- Original Message -----
From: "Ugo Corda" <cordau@acm.org>
To: <www-ws-desc@w3.org>
Sent: Saturday, June 28, 2003 3:48 PM
Subject: Re: Minutes of W3C WSDWG Conference Call, June 26th, 2003


> Anne,
>
> Let me see if I understand you correctly. I think you are saying two
things.
>
> a) A serviceURI is a way of associating a URI with a particular
wsdl:service
> (single interface), so that this URI abstracts away the individual
endpoints
> and associated URIs.
>
> This is fine with me. The URI of the WSDL document plus the fragment
> identifier mechanism gives us that type of URI right away.

My suggestion is that we name the *service resource*, as opposed to the
interface to the service or the definition of the service. I don't think
that it's appropriate to use the WSDL document plus fragment identifier for
this purpose, because the fragment identifier is the URI of the definition
of the service, not the service itself. The serviceURI would give us the
ability to directly associate this definition with the thing that it
defines. Also consider the fact that the service resource might be defined
using some other type of description language, such as DAML-S, and it would
be very useful to have a definition-language neutral mechanism to refer to
this resource. (Now that I think about it, I think this point is probably
the most important point in my argument.)

A week ago or so I asked whether a process can be a resource, and a
REST-oriented person (I forget who, now--sorry) responded, "yes". Way back
(at least a month ago), Sanjiva made a comment in response to one of the
questions regarding targetResource that we have no name for the thing behind
the interface, which--unless I'm missing something fundamental here--is the
service resource. IMHO such a resource should have a name. It's very
un-Webby not to name an important resource. I'd like to think that this idea
was the basic concept behind targetResource -- but then we started talking
about naming the thing that the service acts upon rather than the service
itself (e.g., the printer rather than the print queuing/management
services). I'm totally in agreement with Mark (!) that identifying the thing
that the service acts upon is too much implementation detail.

> b) A serviceURI is a way of abstracting away a particular wsdl:service
> document instance, so that I could change some of the endpoint URIs under
> that wsdl:service (and generate a new WSDL document) and still refer to
the
> same serviceURI.

The serviceURI names the service resource. It has nothing to do with
abstracting away a wsdl:service document instance. The wsdl:service document
instance defines some aspect of a service resource, hence it should specify
the resource that it is defining. A service resource may have multiple
endpoints, and these endpoints may change. But it's still the same resource.
Here's a simple analogy: Ugo Corda has many endpoints -- email addresses,
postal addresses, phone numbers, etc. Ugo may change some of these
endpoints. He may get new ones, he may get rid of some. But he's still Ugo
Corda.

> I am not sure we need this. We could just keep the endpoints the same
while
> changing the underlying implementation and/or deployment. (To take your
> parallel with a Web site's home page, the Yahoo home page is always
> http://www,yahoo.com regardless of any change in the underlying
> implementation and deployment).

That's exactly my point. http://www.yahoo.com names the Yahoo home page,
which is a resource. The URI isn't the definition of the resource. It isn't
the endpoint of the resource (that would be http://www.yahoo.com/index.html
or something like that). It names the resource. The implementation of the
resource can change, and things still work.

> Regarding the use case of a single service implementing multiple
interfaces,
> that "service" will actually be a bunch of wsdl:service's, and this
> particular type of relationship among them could be addressed by the
service
> group solution.

Perhaps, but how would you indicate the type of relationship in the service
group? And how would this solution allow me to discover that a wsdl:service
definition and a DAML-S definition in fact define different aspects of the
same service?

> (As you can see, I am taking a minimalist approach and trying to avoid
> introducing new concepts unless they appear to be absolutely necessary).
>
> Ugo
>
> ----- Original Message -----
> From: "Anne Thomas Manes" <anne@manes.net>
> To: "Ugo Corda" <UCorda@SeeBeyond.com>, <www-ws-desc@w3.org>
> Date: Sat, 28 Jun 2003 07:57:02 -0400
> Subject: Re: Minutes of W3C WSDWG Conference Call, June 26th, 2003
>
>
> Ugo,
>
> My proposal for point 1 is simply the assignment of a name (a URI -- let's
> call it serviceURI) to a service implementation (a resource). As with any
> resource, there's no reason why you can't change the code that implements
> this resource.
>
> In many respects, it is equivalent to assigning a URI to a Web site's home
> page. There's nothing stopping you from changing the code behind the Web
> page (in fact it happens all the time).
>
> I proposal the serviceURI SHOULD NOT be the same as the endpoint URL of
the
> service implementation -- for exactly the reason that you may want to
change
> its implementation some time down the road.
>
> And I think I agree that the new wsdl:service definition looks pretty
close
> to being right for the definition of a service implementation -- but I
> suggest that the resource MUST have a serviceURI name. Given the naming of
> the service implementation, I'm not sure we then need targetResource -- or
> perhaps it could be added to the service group definition as a means to
> identify the relationship among the services in the group.
>
> By naming the service implementation, you also solve the use case where a
> single service might implement multiple interfaces -- you would still
> maintain the one service/one interface requirement, but you could define
> multiple service implementations that reference the same serviceURI.
>
> Anne
>

Received on Wednesday, 2 July 2003 11:43:43 UTC