Re: Fw: Naming a Web service resource

Bryan:
  Stipulated, that you may want to be able to identify a resource with a 
service description. It is just that targetresource is not the way to 
do it (again, in my opinion).
  I do not see the need to have a WSDL-level element that identifies 
*the* resource.

  A better solution is to permit a proper integration with an OWL-level 
description with a WSDL document. That way, if you want to do things 
like targetResource, you do it in OWL/RDF whatever, in a somewhat 
application-specific manner.

  Using OWL/DAML etc. gives you a whole class of power that you cannot 
embed directly into a WSDL document (nor should you).

As for bridging the Web and Web services, I think that the appropriate 
model looks like this:

The resource oriented model `sits on' (I have a much better term, but 
its technical: supervenes) the service oriented model.

The service oriented model `sits on' the message oriented model

SOAP is a technology at the MOM level, WSDL is a technology at the SOM. 
HTTP is a weird animal that crosses all the levels, but is 
fundamentally a ROM-level technology. This level crossing is a source 
of confusion for many.

One of the reasons that everyone wants to use HTTP as a message 
transport is because of tunneling. But in a few years, I hope that that 
reason will have gone away, in favor of a more consistent and 
sustainable story. Certainly, every month, using HTTP gets more 
problematic as corporations strengthen their firewalls.

Frank



On Monday, July 7, 2003, at 10:22  AM, Thompson, Bryan B. wrote:

>
> 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 14:07:03 UTC