ode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Assaf Arkin" <ar...@intalio.com>
Subject Re: Easy BPEL aka BPEL4Coders aka BPEL4Hackers
Date Tue, 06 Nov 2007 22:28:15 GMT
On 11/6/07, Dan Kearns <dan@thekearns.org> wrote:
> On 11/6/07, Assaf Arkin <arkin@intalio.com> wrote:
> >
> > On 11/6/07, Dan Kearns <dan.kearns@gmail.com> 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:
  msg2 = plink2.receive();

What it would look like in JavaScript:

function step2(msg2) {

function step1(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')
    onReceive = receiveFoo;
onReceive = receiveFoo;



CTO, Intalio

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message