On 11/6/07, Dan Kearns <[EMAIL PROTECTED]> wrote:
>
>
>
> 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.
>
For the AAM proposal, we have no intent of bringing process engines to
JavaScript, but bringing a simpler syntaxt to the process engine, and we
just think JavaScript is a good starting point for that.
Specifically for JavaScript, you have to consider all the ways of using it.
For example, this piece of Rails code:
<% remote_form_for(@post) do |f| %>
...
<% end %>
This one is shorter and easier to understand than instantiating Ajax.Request,
serializing the form, adding a callback function to evaluate
transport.responseText, all within the onSubmit event handler of the form.
So by analogy, we're working closer to Rails helper than Ajax.Request.
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...; };
>
We start with that line of thinking, and tried it out with a couple of
languages. It looks reasonable enough for a statement or two, but
afterwards it violates the first principle of our proposal, which is to come
up with a syntax that makes it easy to read/write process definitions.
Here's a couple of examples. What you want to express:
{
plink1.send(msg1);
msg2 = plink2.receive();
plink2.send(msg2);
}
What it would look like in JavaScript:
function step2(msg2) {
plink1.send(msg2);
}
function step1(msg1) {
plink1.send(msg1);
plink2.onReceive = step2;
}
What you want to express:
{
foo = plink.receiver()
} until (msg.foo == 'foo')
What it would look like in JavaScript:
function receiveFoo(msg) {
if (msg.foo == 'foo')
nextStep();
else
onReceive = receiveFoo;
}
onReceive = receiveFoo;
Assaf
-d
>
>
--
CTO, Intalio
http://www.intalio.com
