Re: Fw: Naming a Web service resource

Anne et al....

   Yes, I was was not intending a Web service URI to be the *same* as a  
name space URI. Certainly, the WSA has always assumed that a Web  
service has an identifier. There are many reasons for requiring this,  
not the least of which is for auditing purposes: I used such as such a  
service on such and such a date.

   Ugo's comment about latency is slightly beside the point I think. If  
there are genuine semantic differences between two services then they  
are simply different services.

   The parallel between a namespace URI and a Web service URI is the  
question of representations: in neither case is it all that obvious  
what the representation of the identified resource should be. The  
*cute* answer is a namespace definition document (URRL?) or a service  
description document respectively. But I don't think that that flies in  
the end.

  I realize that having a resource without a representation seems deeply  
unsatisfying to many. It is no more unsatisfying (IMO) than modeling a  
resource as a time-varying function from identifiers to  
representations. (Forget where this is defined ;-).

  If the intention of the targetResource is to identify the service,  
then great, lets call it the service URI!

Frank

On Monday, July 7, 2003, at 04:39  PM, Anne Thomas Manes wrote:

>
> Paul, Frank, et al,
>
> I agree with Frank that the current thoughts behind targetResource  
> (where
> targetResource represents the thing that a service acts upon) is a
> brain-dead idea, but I don't think that my opinion (or Frank's for that
> matter) is particularly at odds with Paul's opinion.
>
> If I might interpret for Paul, he views targetResource to be the  
> identity of
> the service (rather than the resource that the service acts upon). If  
> that
> were the current thinking, then I'd be totally behind the idea. But  
> that
> isn't the current thinking
>
> If I might interpret for Frank, he said:
>> a Web service has an identity, but that identity is
>> closer in spirit to the namespace uri than a web page uri
>
> I don't think he meant to imply that a Web service should be  
> identified by
> its namespace. I agree completely with Paul that such a move would not
> provide a mechanism to could differentiate between multiple instances  
> of the
> same service type. I think by "closer in spirirt" he meant that a Web
> service should have an abstract name, which does not resolve into a  
> physical
> URL, such as a namespace has an abstract name that does not resolve to  
> a
> physical address.
>
> My issue is that, as Frank says, Web services *do* have identity, but  
> yet
> they don't have a name. I agree with Frank that a Web service should  
> have an
> abstract name that doesn't need to resolve to a physical address.
>
> So let's look at Paul's example: What is the URI that repesents the  
> UDDI
> Business Registry (UBR)? The UBR is a Web service. It just so happens  
> that
> there are four nodes in this Web service, but regardless which node you
> access, you will always get the same response from any one of these  
> four
> nodes. So the four nodes do in fact represent a single Web service.
>
> I assert that this collective, four node entity is a Web resource, and  
> since
> it is a Web resource it should have a URI (e.g.,  
> http://www.uddi.org/ubr).
> But as far as I can tell there is no URI for the UBR. The UBR has a  
> bunch
> of endpoints (8 SOAP endpoints plus 4 browser endpoints), but each of
> these endpoint URLs represent UBR endpoints, not the UBR itself.
> Each node has a WSDL description, but the URLs of the WSDL files
> represent a service description, not the collective service. Even so,  
> the
> UBR
> is an abstract concept. If you did assign a URI to represent the UBR,  
> that
> URI would have to be an abstract URI, not a resolvable URL.
>
> I think that targetResource could be used to define a name (URI) for  
> the
> service, but according to the current discussion on WS-Desc, this  
> isn't the
> intended purpose of this attribute. targetResource defines the  
> resource that
> the service acts upon (rather than the service itself).
>
> I also don't think that WS-Desc should be wholely responsible for  
> defining
> the mechanism by which you name a service. The service URI could  
> potentially
> be used in any number of descriptions/systems -- not just in WSDL.
>
> Anne
>
> ----- Original Message -----
> From: "Paul Denning" <pauld@mitre.org>
> To: <www-ws-arch@w3.org>
> Sent: Monday, July 07, 2003 3:24 PM
> Subject: Re: Fw: Naming a Web service resource
>
>
>>
>> At 12:55 PM 2003-07-07, Francis McCabe wrote:
>>
>>> Anne:
>>>   This topic has been discussed a little in WSA.
>>
>> See
>> http://www.w3.org/2002/ws/arch/3/05/2003-05-15-ws-arch.htm
>>
>>> 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.
>>
>> I respectfully disagree with Frank's view.
>>
>> "Resources" are abstractions anyway, not necessarily a physical
>> resource.  I for one am not comfortable with the notion that a web  
>> service
>> is not associated with a resource ( a view that has been discussed a
>> little).  That would deviate too much from the TAG's web architecture,
>> where a Resource is a fundamental concept.
>>
>> The dynamic set of resources can be viewed as just another abstract
>> resource, not necessarily a superset (or having sub-resources).
>> The targetResource for a choreography (transparently-composed  
>> composite
>> service) is an abstraction (with perhaps some interesting  
>> relationships to
>> other more or less abstract resources).
>>
>> What is the resource for the URI http://www.w3.org?  for
>> http://www.w3.org/TR?  They are abstractions.
>>
>> I can see us having a discussion similar to
>> http://www.w3.org/2001/tag/ilist#namespaceDocument-8
>>
>> That is, given only a targetResource URI, I will try to dereference it
>> (like a namespace URI) to see if I can find out something more about
>> it.  TAG is leaning toward RDDL as "an" acceptable namespace document
>> (there may be others).  What is an acceptable "targetResource
>> document"?  RDDL probably is also a good candidate.
>>
>>
>>> 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.
>>
>> The namespace URI does not hack it for me.  I liked the idea of the
>> targetResource.
>>
>> For example, the public UDDI business Registry (UBR) could have a  
>> single
>> targetResource URI whether you access the "resource" through IBM, MS,  
>> SAP,
>> or NTT.  And it would differ from private UDDI registries, which would
> have
>> a different targetResource URI.  Both UBR and private UDDI registries
> would
>> use the same UDDI namespace and WSDL (interface, not implementation)
>> description, i.e.,
>>
> http://www-3.ibm.com/services/uddi/uddiget?tModelKey=UUID:AC104DCC- 
> D623-452F
> -88A7-F8ACD94D9B2B
>>
>> I don't want to be forced to use OWL just to distinguish between UBR  
>> and a
>> private UDDI registry.
>>
>>
>>
>>>>>> Frank
>>>>>>
>>>>>> On Friday, July 4, 2003, at 07:10  AM, Anne Thomas Manes wrote:
>> <snip/>
>>
>> Paul
>>
>>
>
>

Received on Tuesday, 8 July 2003 12:50:04 UTC