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 15:21:16 UTC