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

Re: Use case for intra -service composition

From: Bijan Parsia <bparsia@isr.umd.edu>
Date: Thu, 28 Aug 2003 11:16:54 -0400
Cc: www-ws@w3.org
To: Monika Solanki <monika@dmu.ac.uk>
Message-Id: <A82D191A-D96A-11D7-86BD-0003939E0B44@isr.umd.edu>

[moving this to www-ws, as per policy)

On Thursday, August 28, 2003, at 06:28  AM, Monika Solanki wrote:

> Hi All,
>
> I am very interested in authoring a use case (DAML-S specification) 
> for composite services executing on distrbuted systems concurrently.

Yes. Good.

>  There is one such use case in the BPEL doc as I mentioned in the 
> telecom yesterday.

Pointer, please?

> Bijan had also mentioned an example in the sensor network environment.

To recap: you have a distributed sensor & processor network running 
over not huge bandwidth wireless getting heavy use. Sensors and various 
processors ("data fuselets", feature extractors, etc.) can be, and have 
been, composed in various ways for particular tasks. Invocation of a 
step in these compositions tends to involve a fairly large value (say, 
a sound file) being passed from one process to another *and* there is 
flakiness in the system, including contact with the originating node.

A originating node only control flow mechanism, especially using an RPC 
style would be extremely wasteful of bandwith (there are ways around 
that, e.g., by exchanging control messages, but once you start that 
they you are, imho, moving into distributed process model processing). 
Also, given that the originating node might want to be able to pop on 
the network, get things running, check in later, if done successfully 
get the result, if not, issues some correction, etc., maintaining 
control isn't feasible.

In our actual work, our composer (available from our website, 
http://www.mindswap.org/~evren/composer) while having a DAML-S process 
model internally, will generate a soap message with a body that 
contains a workplan. Each node evaluates it's step of hte plan and 
passes it on to the next node. One could also do this with SOAP headers.

I believe the paper on the page describes this approach a little more. 
I have a quite stale draft of a paper outlining this whole issue in 
some detail which, coincidently, I've been trying to unearth and revise 
recently, along with a more sophisticated implementation of "smart" 
soap nodes.

>   I would appreciate some ideas from other team members about the kind 
> of examples that we can have. I think, we will also have to include 
> additional constructs in the process model for this.

I actually disagree. You can do a lot, as we discuss, with the current 
model *if* the semantics of certain things come out right. Nothing in 
the model as it stands mandates a single controller (indeed, Sheila's 
Petri net based Distributed OPErational (DOPE) semantics quite clearly 
suggests this).

Given this capability is built-in SOAP and there's ome recognition that 
such patterns might be interesting (see: 
http://www.w3.org/2000/xp/Group/2/04/09/soap12-scenarios.html), and 
that I would expect there to be WSDL extensions for some of these, and 
that Chore will be concerned with such interactions....it seems worth 
taking note of. :)

Cheers,
Bijan Parsia.
Received on Thursday, 28 August 2003 11:14:24 GMT

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