commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Sanders" <>
Subject RE: Workflow & Turbine design questions
Date Fri, 30 Nov 2001 18:07:04 GMT
I would say that this would be an excellent addition to Avalon, if it is
not already there, or could be built in commons.  I think running this
as a JMX MBean would be great for the likes of JBoss.  Maybe JBoss
already has one?

Scott Sanders

-----Original Message-----
From: craigmcc@localhost [mailto:craigmcc@localhost] On Behalf Of Craig
R. McClanahan
Sent: Thursday, November 29, 2001 6:33 PM
To: Jakarta Commons Developers List;
Subject: RE: Workflow & Turbine design questions

One way to approach these issues (and would even fit into the Commons
charter :-) would be to conceive of a Commons package to do background
scheduling and execution (what legacy OSs called "batch job queues")
within a JVM.  Executing a particular workflow script would be only one
the interesting things you could do -- ideally the definition of a "job"
would be something like "call method X on object Y" so it could be fully

The "jobs" package could be configured with limits on how many
threads it could run, support ways to schedule jobs repeatedly, and all
the other stuff you can do with "cron" type utilities, if we wanted.  It
could be embedded in any sort of long-running JVM (such as in a webapp
a servlet container), as well as stand-alone background jobs.

This is a bigger task than just something that can run Workflow scripts
background threads (which isn't terribly difficult to hard code in your
application by starting a new thread and executing the Activity there),
but it would be a generally useful package.  What do you think?


On Thu, 29 Nov 2001, Brett Gullan wrote:

> Date: Thu, 29 Nov 2001 09:24:55 +0800
> From: Brett Gullan <>
> Reply-To: Jakarta Commons Developers List
> To: 'Jakarta Commons Developers List' <>
> Subject: RE: Workflow & Turbine design questions
> Almost...
> > #1. User starts workflow process by performing action.
> Let's say User A starts workflow process, by for instance, copying a
> file from his/her desktop to a directory on a local/remote server
> can/will be achieved by a variety of methods/protocols).
> > #2. Workflow performs tasks that may take time.
> Yes
> > #3. User should not be held up waiting for a response from the
> by
> background workflow tasks.
> Yes. However, User A may never even use the Web UI. User B on the
> hand may be watching the queue/progress monitor for regular updates.
> The web UI is intended to be a monitoring and configuration tool for
> underlying workflow engine. For the most part, general users would
> submit files (by desktop drag-n-drop, FTP, web-form, etc...) then use
> the web UI to monitor progress or change the queue priority (if
> authorised).
> Administrative users would have access to web forms that configure the
> workflow processing activity steps and the 'hot' folders that feed the
> processing queue.
> The application is intended to support deployment on a 'headless'
> where all interaction is via a web UI.
> I hope that makes more sense?
> Regards,
> Brett
> --
> Brett Gullan
> --
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message