RE: Fw: Naming a Web service resource

Frank,

I am not sure if I am reading your first point correctly.  I see that it is
critically important that it is _possible_ to have the same URI serve to
identify
both the service interface instance and the resource on which that service
is
operating.  This is the case today with HTTP.  We have a problem with WSDL
1.1
precisely because it does not make it possible to do the same thing with
SOAP.
Ideally, we want to be able to have both a SOAP and an HTTP interface
defined
at the same URI as the resource.  This has the further implication that the
method name must not be part of the URI for the service interface.

For example, given:

	http://www.myorg.org/foo112

You should be able to write WSDL that indicates that this URI identifies:

	1. a resource, with an HTTP interface (POST, PUT, GET, DELETE,
HEAD).
and	2. a SOAP service, with some arbitrary set of method signatures.

I do understand that people may not always want to bind the service
interface
and the resource on which the service is operating to the same URI.  However
I
view the ability to do this as vital.  If you can not express this notion
then
it is not possible to bridge the architecture of the web and the
architecture
of web services.

-bryan


-----Original Message-----
From: Francis McCabe [mailto:fgm@fla.fujitsu.com] 
Sent: Monday, July 07, 2003 12:55 PM
To: Anne Thomas Manes
Cc: Www-Ws-Arch@W3. Org
Subject: 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 13:23:00 UTC