Fw: Naming a Web service resource

I'm not getting much response from the ws-desc team on this issue, and it
occurs to me that it might be of more interest at the arch level.

Some background: The WS-Desc team has proposed the introduction of an
optional attribute called targetResource to provide some additional
discovery metadata to reference the "thing" behind a Web service
interface -- for example, it can help you discover that different service
interfaces provide access to the same thing. To some degree, this attribute
is tied to the groups decision to limit a service to a single interface,
because now you need a mechanism to express that fact that multple services
are related in some way.

Thinking through this scenario, I've realized that one of the must unwebby
features of the Web services framework is that a Web service doesn't have a
URI. It has a description (WSDL). It has one or more endpoints. But there is
no one URI that represents the resource that *is* the Web service.

Reading through the various documents that describe URIs and the Web
architecture, it seems obvious to me that a Web service is an "important"
Web resource, therefore it should have a URI.

I'd appreciate it if the WS-Arch group would discuss this issue.

Anne

----- Original Message -----
From: "Anne Thomas Manes" <anne@manes.net>
To: <cordau@acm.org>; <www-ws-desc@w3.org>
Sent: Wednesday, July 02, 2003 11:43 AM
Subject: 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 Saturday, 5 July 2003 16:52:49 UTC