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

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

From: Walden Mathews <waldenm@optonline.net>
Date: Wed, 21 May 2003 20:25:28 -0400
To: Katia Sycara <katia@cs.cmu.edu>, "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>, www-ws-arch@w3.org
Cc: katia@cs.cmu.edu
Message-id: <00ad01c31ff8$a75ac4c0$1702a8c0@WorkGroup>

Katia,

That seems backwards to me.  The "service" is the desired change
to your account.  The account is the resource.  It may be private in
the sense your bank account is [should be] private, but it ain't private
in the sense of private methods and implementation detail.  It's
"exposed".

Walden

----- Original Message -----
From: "Katia Sycara" <katia@cs.cmu.edu>
To: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>;
<www-ws-arch@w3.org>
Cc: <katia@cs.cmu.edu>
Sent: Wednesday, May 21, 2003 3:20 PM
Subject: RE: Separate concepts for "service" and "targetResource?" (was RE :
/service/@targetResource ?)


>
> Mike,
>  the "turtle" picture you painted makes a lot of sense.
>
> As for Mark Baker's concern about the resources that a service changes
> "behind" it, such as accounts that a bank transfer service may change,
these
> resources are "private" to the service and do not have a URI anyway (as
far
> as the external world of services is concerned).
>
>  --Katia
>
> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Champion, Mike
> Sent: Wednesday, May 21, 2003 2:51 PM
> To: www-ws-arch@w3.org
> Subject: RE: Separate concepts for "service" and "targetResource?" (was
> RE : /service/@targetResource ?)
>
>
>
>
>
> > -----Original Message-----
> > From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
> > Sent: Wednesday, May 21, 2003 1:13 PM
> > To: Champion, Mike; www-ws-arch@w3.org
> > Subject: RE: Separate concepts for "service" and
> > "targetResource?" (was
> > RE: /service/@targetResource ?)
> >
> >
> > 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.
>
> Here's my (personal) conception of a way to sort out all the inputs we got
> in Rennes:
>
>
> At the very bottom of the stack there is some code that does some real
thing
> in the real world.  For the sake of this discussion, let's say that it's a
> purchase order processing module in an ERP system, or maybe that BPEL
script
> implementing a loan approval process.  We *could* think of this as a
> "resource" (but that would be a problem because it's identity and state
are
> not necessarily exposed to the outside world), and we could think of the
> "objects" that it manipulates as a set of "resources" (but that would be
> problematic because all those database records or whatever are not exposed
> to the outside world).  We called this a "turtle" in Rennes (partly in
> reference to the classic anecdote from Steven Hawking
> http://members.tripod.com/TheoLarch/turtle.html
> and partly in reference to Clay Shirky's application of this joke to the
Web
> services world
> http://webservices.xml.com/pub/a/ws/2001/10/03/webservices.html). The
point
> about "turtles" is that you only deal with the hard shell that
encapsulates
> them, and you don't care how many other "turtles" they are stacked on.
> References to Dr. Seuss
>
http://www.amazon.com/exec/obidos/tg/detail/-/0394800877/qid=1053541165/sr=8
> -1/ref=sr_8_1/002-5339658-0637608?v=glance&s=books&n=507846 were
inevitable
> :-)
>
> Sitting on top of the "turtle" is an agent that understands its internal
> semantics, APIs, data formats, etc. and can implement specific web
services
> interfaces.  This is (I think) what the targetResource URI identifies.
It's
> also (more or less, and in my opinion) what we call "service" in the
recent
> public working draft.  This agent is the thing that has a unique identity
as
> far as a Web service requester is concerned, and the thing with semantics,
a
> management interface, etc. as far as other aspects of the WSA architecture
> is concerned.  In the examples, this would be the SOAP interface that the
> ERP vendor offers, or the external view of the BPEL process.
>
> The rest of the stack is pretty much as WSDL envisions -- working top
down,
> there's a  service which is a collection of endpoints, each of which has
one
> or more bindings, and each binding describes a messaging protocol that
> describes how a service requester communicates with a service provider
(the
> "agent") to perform a specific operation.
>
> So, I think that addressed Ugo's concern: the agent *is* the WSDL
> targetResource, and had a URI.  All sorts of resources *could* exist
behind
> the agent, but all a Web service requester sees is the agent.  To address
> Mark's concern, the problem this attempts to solve is basically service
> aggregation (different WSDL services may refer to the same targetResource)
> and discovery (you may want to locate a service by the properties of the
> actual provided "resource" (e.g., "a printer in my building") rather than
> the properties of the interface description.  Furthermore, "there will be
> services that operate on resources whose identity is only determined at
> runtime" is true, but it is the "target resource agent"'s job to figure
that
> out, out of sight of the service requester.
>
> Does this make any sense?
>
>
Received on Wednesday, 21 May 2003 20:21:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:19 GMT