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:28:46 -0400
To: Assaf Arkin <arkin@intalio.com>, "Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>
Cc: www-ws-arch@w3.org
Message-id: <00b601c31ff9$1c3292a0$1702a8c0@WorkGroup>

There may be a service (and a resource) that is a printer farm,
that is, a colleciton of printers, and the farm is capable of answering
questions about printer eligibility for YOUR job, based on the
specified properties of your requirement.  And identifying the
printer that is the best match.

That view does not prevent an individual printer from also being
a resource in this picture.


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

> Mike,
> Thanks for the explanation. That clarifies a lot.
> I still have a question, though. Let's say that I have a printer in my
> building (the resource) and I want to lookup a service associated with
> that in order to send a large print job. If I have a smaller print job
> I'm willing to sacrifice print speed to save me the travel, so I would
> prefer to find a printer on my floor (also a resource). The printer on
> my floor is a printer in the building for someone on a different floor.
> So there are two different resource identifier I may use to end up
> selecting the same service.
> I can think of three possibilities. The URI is not-opaque so I can do a
> partial comparison of the targetResource URI to identify a printer in my
> building/floor. Or there are multiple target resources, one for floor
> and one for building. Or the URI is just a name and the "printer
> service" directory has an association between buildings and floors to
> printers (and hopefully also knows which floor I'm on). But then, could
> that directory just reference the service by it's QName?
> So trying to understand the value proposition of targetResource and best
> practice, it seems to me that it tries to solve a very specific problem:
> how to define multiple <service> definitions that are independently
> managed, yet all relate to the same service agent/provider/resource. I
> see the value in associating them all to the same entity, but would it
> not make more sense to pick a more applicable term, perhaps agent or
> provider?
> arkin
> Champion, Mike wrote:
> >
> >
> >
> >>-----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
> >in Rennes:
> >
> >
> >At the very bottom of the stack there is some code that does some real
> >in the real world.  For the sake of this discussion, let's say that it's
> >purchase order processing module in an ERP system, or maybe that BPEL
> >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
> >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
> >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
> >services world
> >http://webservices.xml.com/pub/a/ws/2001/10/03/webservices.html). The
> >about "turtles" is that you only deal with the hard shell that
> >them, and you don't care how many other "turtles" they are stacked on.
> >References to Dr. Seuss
> >-1/ref=sr_8_1/002-5339658-0637608?v=glance&s=books&n=507846 were
> >:-)
> >
> >Sitting on top of the "turtle" is an agent that understands its internal
> >semantics, APIs, data formats, etc. and can implement specific web
> >interfaces.  This is (I think) what the targetResource URI identifies.
> >also (more or less, and in my opinion) what we call "service" in the
> >public working draft.  This agent is the thing that has a unique identity
> >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
> >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
> >there's a  service which is a collection of endpoints, each of which has
> >or more bindings, and each binding describes a messaging protocol that
> >describes how a service requester communicates with a service provider
> >"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
> >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
> >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
> >out, out of sight of the service requester.
> >
> >Does this make any sense?
> >
> >
Received on Wednesday, 21 May 2003 20:24:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:07 UTC