Re: Fw: Naming a Web service resource

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 Monday, 7 July 2003 20:16:58 UTC