- 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