Re: Separate concepts for "service" and "targetResource"?

Ugo,

You're definitely right that "agent" and "resource" shouldn't be synonyms;
the
agent is swappable, while the resource (closely related to "service") is
more
abstract and more consistent over time.

You say:

"...in the general case, no specific "resource", particularly not a
"physical" one,
can be identified..."

I believe the notion of "physical resource" is the problem there, and that
if
resources are (correctly) regarded as conceptual, then it becomes true that
in
the general case it *is* possible to identify the "resource" behind any
"service".

You talk about the "typical example" of a web service composed of other
web services.  If you will make your example concrete, we can investigate
the issue directly.  Failing that...

A service performed often takes the place of information delivered to the
requestor (informational services subset, let's call it).  Those data
represent
something repeatably nameable and identifiable, and hence they represent a
"resource" in the nearly-normative sense of the word in this context.

For the other case (non-informational services subset, let's call it),
either some
data have been offered by the requestor for storage or processing (in which
case this use case masks "informational services", since write-only memory
is
essentially *very limited* in its uses) and the "resource" may, imprecisely,
be
thought of as a "processor"... without binding to any particular agent or
imple-
mentation.

Otherwise, the only other case I can come up with is control: the requestor
is essentially writing "control registers" for some activity, such as
programming
a robot, so that non-informational services will motivate.  Again, it's not
difficult to identify the "resource" in that picture.  Indeed, it's the
"physical"
thing you mention, behind a conceptual level of indirection to allow
physical
implementations to evolve.

Does this help at all?

--Walden


----- Original Message -----
From: "Ugo Corda" <UCorda@SeeBeyond.com>
To: "Champion, Mike" <Mike.Champion@softwareag-usa.com>;
<www-ws-arch@w3.org>
Sent: Wednesday, May 21, 2003 1:13 PM
Subject: RE: Separate concepts for "service" and "targetResource?" (was RE:
/service/@targetResource ?)


>
> 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
> > >
> >
> >
>
>

Received on Wednesday, 21 May 2003 13:44:21 UTC