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 Wednesday, 21 May 2003 21:37:18 UTC