W3C home > Mailing lists > Public > www-ws-arch@w3.org > May 2003

Re: Separate concepts for "service" and "targetResource?" (was RE: /service/@targetResource ?)

From: Fred Carter <fred.carter@amberpoint.com>
Date: Wed, 21 May 2003 13:15:24 -0700
Message-ID: <3ECBDE5C.9000103@amberpoint.com>
To: www-ws-arch@w3.org

Thus quoth Assaf Arkin (~ 21-May-03 12:00 PM ~)...
> I am also puzzled by what is meant by resource and what does it buy me.
> To take the example of the bank, I tend to use my bank's ATMs and we can 
> easily assume the resource behind that service is the bank. So at first 
> though the resource should be the bank's URI.
Yes, that's right.  Moreover, any ATM labeled with your bank's "URI" are 
the same service.  One may, indeed, choose a bank based on the number of 
such "endpoints."  These are all urn=my-favorite-bank
> But if I'm out of town I may have to use some other bank's ATM. I tested 
(or even in town)
> it and it works, so now I have to acknowledge that the resource behind 
> my bank's ATM is possibly any bank in the world that issues standard 
> ATM/credit cards. Or maybe the resource is a global ATM system, which is 
> really saying nothing more about the service than what the interface 
> already says.
Yes, but you are using a different resource then.  Then, you are using a 
resource (the analogy a bit because multiple things exist at the same 
endpoint, if I consider the physical machine the endpoint .. but we'll 
ignore that) identified as urn=global-banking-device which offers the 
operation "sendRequestToAppropriateBank".

Alternatively, both systems are using this resource -- its just when 
"appropriateBank" is the one to which this ATM is "directly attached", 
things are cheaper. But that's a QoS or capability issue.
> If we take the example of a print job Web service then it may be 
> associated with some printer, or it may elect to use some print at 
> random, or if I'm printing multiple hardcopies of the same presentation 
> it may use multiple printers, or a printer and a photocopies, or just 
> send the job to Kinko's. The "agent" behind the service is just the 
> piece of software that coordinates all of that, knowing that is not 
> interesting. The resources used by the service are subject to change and 
> in many cases are only determined at real time.
Again, if the resource is "that printer in that corner of my floor of my 
building", it shouldn't send it out to Kinko's.  It may have a policy of 
not printing more than 20 pages, etc., but that's a separate issue.

If the resource is "print what I want within some timeframe in the 
cheapest way available to my company", that's a resource all together. 
You get to select which resource/printer-service you want.

Seems to me that these all correspond perfectly OK.
> So what exactly does the resource stand for?
> arkin
> Ugo Corda wrote:
>> I am quite uncomfortable with the concept of associating a "resource" 
>> URI with a service. The concept of resource, or even target Resource, 
>> is in my mind completely ill defined when it comes to Web services.
>> While examples can be made where a service acts like a facade in front 
>> of a physical resource (see the printer example), in the general case 
>> no specific "resource", particularly not a "physical" one, can be 
>> identified and associated with a service. (The typical example is a 
>> Web service that simply uses a bunch of other Web services to come up 
>> with its responses).
>> The only "resource" behind a service that I feel I could put my hands 
>> on is an agent (a piece of code). But I doubt the proponents of 
>> /service/@targetResource were referring to that.
>> Once we go beyond the agent immediately behind the service, all kind 
>> of other resources might surface that the agent acts upon. Many of 
>> these resources might be other services, and it might not be easy to 
>> find out what kind of "targetResource" they correspond to. In fact, 
>> the whole concept of service is such that you don't have to worry much 
>> about what's behind it, as long as you understand the semantics of the 
>> interface.
>> Even if we were able to associate a URI with the agent, what happens 
>> when I substitute the current agent with another one, for instance a 
>> better performing one? Do I need a different URI? Again, I thought 
>> that one of the advantages of the Web services concept is that you can 
>> replace an implementation with an equivalent one without affecting the 
>> service itself.
>> Ugo
>> P.S. I am responding only on the WSA list because I think it's better 
>> to come up with some understanding and agreement on this as a group 
>> before interacting with WSD.
>>> -----Original Message-----
>>> From: Champion, Mike [mailto:Mike.Champion@softwareag-usa.com]
>>> Sent: Wednesday, May 21, 2003 8:06 AM
>>> To: WS-Description WG
>>> Cc: www-ws-arch@w3.org
>>> Subject: Separate concepts for "service" and "targetResource?" (was RE:
>>> /s ervice/@targetResource ?)
>>>> -----Original Message-----
>>>> From: Jacek Kopecky [mailto:jacek@systinet.com]
>>>> Sent: Wednesday, May 21, 2003 10:03 AM
>>>> To: WS-Description WG
>>>> Subject: Re: /service/@targetResource ?
>>>> If yes, we're basically splitting the old service construct into a
>>>> number of the new service constructs limited to one interface each,
>>>> linked together by the value of the new attribute, right?
>>> That's how I understand the joint discussions between the WSA and WSD 
>>> WGs
>>> last Wednesday.  The WSA group discussed this quite a bit, and did 
>>> not come
>>> to a strong conclusion. 
>>> My own personal understanding is that we have to distinguish the 
>>> description
>>> of a service that is shared by the service requester and provider 
>>> from the
>>> reality of the service as deployed by the provider.  WSD can probably
>>> abstract away all the messy details of the service provider resource 
>>> behind
>>> a URI -- all you really care is that it has identity, and you can 
>>> compare
>>> two service descriptions to see if they ultimately refer to the same
>>> physical resource.  WSA has to hand more properties on the service 
>>> provider
>>> resource, such as whatever we are going to say about manageability, 
>>> whatever
>>> we can say about the semantics of the resource and the tasks it 
>>> performs,
>>> and the details of its interface to the Web services world.
>>> I think we need to discuss terminology a bit.  "Resource" is not good
>>> because it is too generic; a (deployed) web service clearly is a 
>>> Resource in
>>> the sense of the Web architecture document, but so is essentially 
>>> everything
>>> else that has identity.  "Target resource" is OK, or "ultimate target
>>> resource" or  "service provider resource" are probably more 
>>> descriptive (but
>>> verbose).  "targetResource" is probably a good label for now.
>>>> Jacek
>>>> On Wed, 2003-05-14 at 17:10, Arthur Ryman wrote:
>>>>> In the discussion with the architecture group today,       
>>> there seemed to
>>>>> be confusion between a service and the resource is acts on. The
>>>>> architecture group defines a Web service to have something       
>>>> that has a
>>>>> URI, but that URI is not the same as the resource that the       
>>>> Web service
>>>>> acts on.
>>>>> For example, a bank might have a personal banking Web service. The
>>>>> account Web service acts on the bank.
>>>>> We can build a URI from the QName of the personal banking       
>>>> Web service,
>>>>> e.g. http://xml.fredsbank.com#service(PersonalBanking). The bank
>>>>> itself might have the URI http://fredsbank.com.
>>>>> We agreed to add an optional @resource attribute to <service>. I
>>>>> suggest it would be clearer to rename that attribute to
>>>>> @targetResource to make it clear that the service acts on that
>>>>> resource as opposed to it being the URI of the Web service.
>>>>> Arthur Ryman

Fred Carter / AmberPoint, Inc.

tel:+1.510.433.6525 fax:+1.510.663.6301
Received on Wednesday, 21 May 2003 16:19:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:05:52 UTC