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

I would expose the accounts as resources, which implies that
they are "safe" behind a software implementation that is secure,
and so on.  Who wants to expose "database objects" anyway?

If the accounts are exposed as resources, and the transfer function
is also exposed as a resource (that one bothers me a little, but okay),
then it's resources, not turtles.  I like that.

-------------------------------------------------------------

It's late, and I'm sorry, but I thought the group should know that
trout, you see, don't swim in ponds.  They swim in streams.  Cold,
cold streams.  Ponds are warm; no good.  There are "lake trout",
but they're not trout at all, they're "togue".  So again, terminology
is key.  Two trout swimming in the same stream at the same time
are synchronized, yet it's not really "synchronized swimming", if you
get my drift...

---------------------------------------------------------------

"It's the paint fumes".
Walden

----- Original Message -----
From: "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>
To: <www-ws-arch@w3.org>
Sent: Wednesday, May 21, 2003 9:37 PM
Subject: RE: Separate concepts for "service" and "targetResource?" (was RE :
/service/@targetResource ?)


>
> +1  One *could* of course expose the database objects that implement an
> account as Web resources and manipulate them with CRUD-like operations,
but
> most people would object to such a design. Expose MY account rather than
> hiding it behind a service at your bank, Walden, and I'm taking my money
> outta there! :-)
>
> The point of web services is to expose the functionality of some
(hopefully
> secure) interface rather than exposing the data objects themselves --
that's
> what allows coarse-grained, loosely coupled, etc. interfaces.
>
>
>
> > -----Original Message-----
> > From: Katia Sycara [mailto:katia@cs.cmu.edu]
> > Sent: Wednesday, May 21, 2003 9:28 PM
> > To: Walden Mathews; Champion, Mike; www-ws-arch@w3.org
> > Subject: RE: Separate concepts for "service" and
> > "targetResource?" (was
> > RE : /service/@targetResource ?)
> >
> >
> > In Mark Baker's example, the "service" was a "transfer funds
> > service" not an
> > account changing service. So, the transfer funds service
> > could access the
> > account information in my bank's database. This database
> > access is not a Web
> > resource with a unique URI, in that sense it is "private" and
> > not visible to
> > requesters of the transfer money service. this is what I meant.
> >  --Katia
> >
> >
> > -----Original Message-----
> > From: Walden Mathews [mailto:waldenm@optonline.net]
> > Sent: Wednesday, May 21, 2003 8:25 PM
> > To: Katia Sycara; Champion, Mike; www-ws-arch@w3.org
> > Cc: katia@cs.cmu.edu
> > Subject: Re: Separate concepts for "service" and
> > "targetResource?" (was
> > RE : /service/@targetResource ?)
> >
> >
> > 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 Thursday, 22 May 2003 02:00:38 UTC