On 11/6/07, Assaf Arkin <[EMAIL PROTECTED]> wrote:
>
> On 11/6/07, Dan Kearns <[EMAIL PROTECTED]> wrote:
> >
> >
> > Is there any reason not to attempt to have a process just be a totally
> > valid
> > javascript?
>
>
> Because JavaScript the language doesn't have the notion of 'store where
> you are, come back later'. If you write this in JavaScript:
>
> plink1.send(msg1);
> msg2 = plink2.receive();
> plink1.send(msg2);
>
> the semantics are that of a method call that blocks until the message
> arrives
>
Maybe I unintentionally implied the whole system would be javascript? I
meant just the specification of the process the author would supply.
It is possible to write a jacob-like cpu-slicer purely in javascript, and
maybe even do out-of-memory persistence in a gears/air type of runtime, but
I would assume we want to start on the server-side and use the java Ode
implementation. The obvious parallel is how existing javascript programmers
use XmlHttpRequest, where they are already trained on passing callbacks and
writing event handlers. Check out Prototype's Ajax.Request for an example -
the way it is written, serializing the whole context for retries or whatever
else is pretty easy.
The benefit of using json-style notation for the process is that the
definition becomes serializable so you can swap it out and slap it around: a
java+rhino implementation could use the Function.toString and eval (or the
java api for compilation) to do persistence in both directions. Internally
I'd assume the "script" would be analyzed by the engine to determine which
stuff turns into bpel, which stuff stays as javascript, which stuff is just
static config, etc.
So instead of:
msg2 = plink.receive();
You'd do more like:
plink.onReceive = function(partner, message) { ... some sequence or flow...;
};
-d
