- From: Bijan Parsia <bparsia@isr.umd.edu>
- Date: Thu, 28 Aug 2003 11:16:54 -0400
- To: Monika Solanki <monika@dmu.ac.uk>
- Cc: www-ws@w3.org
[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 UTC