Hi,
[Sorry for the cross-posting, but I thought this might interest both
the Jakarta and the XML Cocoon communities.]
----- Original Message -----
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>
Sent: Tuesday, May 21, 2002 8:49 PM
Subject: Re: [Workflow] Is this project still active?
> > Now, I'm not saying it should go away (I would like to work on it
> > myself, but with Turbine in mind), but it has been a while since
> > it's last update (about 4 months from what I can tell).
> >
> > If I were going to tackle it, I would first look at making the
> > rulesets better. ie - probably use a real Rules Engine or
> > something of that sort. But I don't know what Craig is looking for
> > long-term.
> >
> > Then again, I'm not associated with this project, just highly
> > interested, so take with a big grain of salt =).
> >
>
> One thing that has changed a *lot* since I started the workflow thing is
> the number of different choices for embedding scripting languages into
> Java application servers. If we can find one (or even a plug-in
> framework for multiple languages) that is suitable for writing the
> workflow control scripts, that's probably a better choice than inventing
> YAXBSL ("yet another XML-based scripting language"). For example, using
> the expression language syntax from JSTL would clearly be better than the
> existing primitive Step implementations for control flow and looping.
>
> The only interesting technical challenge is the implementation of the
> "suspend" capability, so that you can have a single workflow script that
> lasts longer than a single HTTP request. If that can be solved easily, we
> can leverage the investments in one or more of the existing scripting
> languages and focus on adapting that to managing multi-page HTTP
> interactions, which was my primary motivation in the first place ...
>
> If someone else shared that same vision, I'd happily cheer from the
> sidelines and offer whatever time I can to help ... but in terms of
> leading this, it's going to be a while before that is practical for me.
What Craig is referring to as the ability to suspend the execution of
the flow script, only to restart it later, is a concept called
"continuation", that first appeared in functional languages like
Scheme. A continuation can be viewed as a first class object which has
the ability to capture the stack frame and the program counter, at a
particular point in the execution of the script, and restore that
context at a later time to restart the computation.
A program written with continuations has the ability to behave exactly
as you describe above. You can have the script send a response, save
the current state of the program, kill the executing thread, and
restart the computation later when a new request comes. Since the
continuations are normal objects, which the framework associates with
URI, you can go back and forth in the page history at will.
For a paper which describes this idea, check out (warning, Scheme
ahead :)
http://youpou.lip6.fr/queinnec/Papers/webcont.ps.gz
I have recently integrated in the main Cocoon CVS trunk an
implementation of the concepts described in this paper. Its design
strongly promotes an MVC pattern for building Web applications (and
perhaps Web services), by having the flow layer (the Controller)
invoke the business logic (the Model), and then passing business
objects to the page generation layer (the View). This fits nicely in a
data-push page processing model like Turbine. In Cocoon today an XSP
logicsheet provides the equivalent functionality, and JSP and Turbine
support could be easily added.
The work is based on a modified version of the Rhino JavaScript engine
which supports continuations, provided by Christopher Oliver
<[EMAIL PROTECTED]>. You can find this modified implementation
at:
ftp://ftp.primaryinterface.com/pub/rhino/
Other languages that support first-class continuations, like Scheme,
could be easily hooked up in the current Cocoon implementation.
I think we can take the continuation-based flow control layer from
Cocoon and modify it to work outside Cocoon, in a pure servlet-based
environment. This way we can have a shared infrastructure between
Jakarta projects that want to use advanced flow control and Apache
Cocoon2.
You can check out a very simple calculator example that's built using
continuations at:
http://cvs.apache.org/viewcvs.cgi/xml-cocoon2/src/webapp/samples/flow/examples/calc/
Some minimal documentation is available at:
http://cvs.apache.org/viewcvs.cgi/xml-cocoon2/src/webapp/samples/flow/docs/
I'm in the process of writing more docs and samples, I will commit
them as they become available.
Regards,
--
Ovidiu Predescu <[EMAIL PROTECTED]>
>>> I'm in the job market again, check out my resume and qualifications at:
http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
