Re: Workflow

[Ovidiu Predescu <ov...@cup.hp.com>]

On Thu, 7 Feb 2002 14:52:22 -0800 (PST), "Craig R. McClanahan" <cr...@apache.org> wrote:

> 
> 
> On Thu, 7 Feb 2002, Viraf Bankwalla wrote:
> 
> > Date: Thu, 7 Feb 2002 14:37:36 -0800 (PST)
> > From: Viraf Bankwalla <vi...@yahoo.com>
> > Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> > To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> > Subject: Workflow
> >
> > Hi,
> >
> > I noticed that there was a workflow component in the
> > commons sandbox.  I have read the proposal, and was
> > inquiring to see if there were more details.
> >
> > Are we leveraging any existing work for this ?  Are we
> > basing it on any standards such as the WFMC ?
> >
> 
> Hello Viraf,
> 
> I looked at WFMC and a couple of the other "high level" standards for this
> sort of thing before designing the Workflow component.  They didn't really
> address the sort of "low level" things that I was interested in scripting,
> which tend to be synchronous, short duration, and executed by a single
> individual.  In particular, I wanted to be able to script things like a
> "wizard" dialog in web applications, where you had to interact with the
> user across multiple HTTP requests, which required the ability to suspend
> and resume execution of the script.

I am doing exactly that as part of the Cocoon project. The idea is to
have the developer write a script in a procedural language on the
server side. The script describes what is the flow of pages to be sent
to the client browser, something like this:

function execute()
{
  for (var count = 0; count < 3; count++) {
    response.sendPage("login.html");

    var username = request.getParameter("user");
    var password = request.getParameter("password");

    if (usersDB.hasCredentials(username, password))
      startApplication(username);
  }
  response.sendPage("badLogin.html");
}

function startApplication(username)
{
  ...
}

The idea is that the sendPage() method will send the page to the
client browser, capture the whole context of the execution - stack,
local variables, program counter - and save it in a hash table, while
associating it with an URL. This URL gets encoded in the login.html
page, and when clicked by the user, the server restores the context of
the script.

This notion is based on the idea of continuations from languages like
Scheme. As I mentioned in the beginning of the message, I'm
implementing something like this for Cocoon, but it could be easily
extracted out of it and implemented as a plain servlet if one wishes
to.

For more readings on this subject, you could follow the Cocoon-dev
thread at:

http://marc.theaimsgroup.com/?l=xml-cocoon-dev&w=2&r=1&s=flowmaps%3A+the+wrong+approach&q=t

http://marc.theaimsgroup.com/?w=2&r=1&s=%5Brt%5D+Managing+Flow+and+Resources&q=t

It's a lot of reading, so you may want to look at a complex sample of
how one would write a Web app using a language with continuations:

http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100802231017059&w=2

This idea is based on two papers which describe the concept:

  http://youpou.lip6.fr/queinnec/Papers/webcont.ps.gz

and

  http://www.cs.rice.edu/CS/PLT/Publications/esop2001-gkvf.ps.gz

They describe the concepts in Scheme, so if you're not familiar with
it, check out the following resources:

http://www.cs.rice.edu/~dorai/t-y-scheme/

Here's a longer, more complete document (is actually a printed book):

http://www.scheme.com/tspl2d/

The system I'm building will use a language similar to the one
described above, not Scheme, so people will not run scared away. The
system is implemented however in Scheme, using a Scheme interpreter
written in Java. For Schecoon, the Cocoon project which integrates the
flow engine I discussed above, checkout the CVS repository at:

http://cvs.apache.org/viewcvs.cgi/xml-cocoon2/src/scratchpad/schecoon/

If there's enough interest in this work, I can try to take the
language implementation out of Cocoon, and have it work in a plain
servlet.


Best regards,
-- 
Ovidiu Predescu <ov...@cup.hp.com>
http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff)

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>