Re: Fw: Naming a Web service resource

Anne:
   This topic has been discussed a little in WSA. I can give you my 
personal view on this; it is not one that is necessarily shared ;-)

1. The targetResource concept is, IMO, a brain-dead idea. The principal 
reasons being:

a. The resource that a service manipulates may not be identifiable in 
any obvious way
b. A service may be inherently `about' a dynamic set of resources, and 
therefore it becomes onerous to identify them in the service description
c. The action-oriented level of description implicit in a service 
description is not the appropriate level to discuss resources.

However, who am I to say what WSD gets up to?

2. Web services *do* have identity; and hence can be expected to have a 
URI. However, that does not imply that a Web service has a meaningful 
representation:
a. For a simple, atomic, service, one might assert that the binding 
address of a service is a good candidate for the service identity. 
However, that seems too low-level and too transport specific.
b. The service description of a service is a potential candidate for 
the service representation, but different descriptions of the same 
service are likely.
c. A composite service, in the sense of a transparently composed 
service, is different to its component services and yet essentially 
unknown to the component parts. A simple example: a service composing a 
weather service with a language translation service to give weather 
reports in foreign languages. Ideally, one should be able to build such 
a service with no programming: simply by hooking together the weather 
service and the translation service. The service description amounts to 
a particular choreography over existing services. The foreign language 
weather service is still a service, and still had an identity (it may 
be composed further, by linking with an import-export service to 
predictively order umbrellas say).

So, the upshot seems to be that a Web service has an identity, but that 
that identity is closer in spirit to the namespace uri than a web page 
uri.

Frank

On Friday, July 4, 2003, at 07:10  AM, Anne Thomas Manes wrote:

>
> 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 Monday, 7 July 2003 12:55:50 UTC