commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <james_strac...@yahoo.co.uk>
Subject Re: Workflow & Turbine design questions
Date Fri, 30 Nov 2001 10:41:36 GMT
+1.

I've wanted a scheduler component for some time - up until now everything
I've seen has been integrated into larger frameworks or has been payware.
Maybe a combination of a general ThreadPool that asynchronous tasks can be
dispatched to (probably using the Runnable interface to represent the tasks)
with a Scheduler capable of dispatching tasks at fixed or repeated
intervals.

The Timer and TimerTask in JDK1.3 are a pretty good start for a Scheduler if
used with ThreadPools for the heavy-lifting. Though Timer/TimerTask is only
available on 1.3. Its a real shame we're not allowed to redistribute classes
from the newer JDKs so we can use them on older JDKs like 1.2. (Ditto for
other stuff in 1.4).

James
----- Original Message -----
From: "Craig R. McClanahan" <craigmcc@apache.org>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>;
<brettgullan@mac.com>
Sent: Friday, November 30, 2001 2:32 AM
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 job
> scheduling and execution (what legacy OSs called "batch job queues")
> within a JVM.  Executing a particular workflow script would be only one of
> 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
> generalized.
>
> The "jobs" package could be configured with limits on how many background
> 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 on
> a servlet container), as well as stand-alone background jobs.
>
> This is a bigger task than just something that can run Workflow scripts in
> 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?
>
> Craig
>
>
> On Thu, 29 Nov 2001, Brett Gullan wrote:
>
> > Date: Thu, 29 Nov 2001 09:24:55 +0800
> > From: Brett Gullan <brettgullan@mac.com>
> > Reply-To: Jakarta Commons Developers List
<commons-dev@jakarta.apache.org>,
> >      brettgullan@mac.com
> > To: 'Jakarta Commons Developers List' <commons-dev@jakarta.apache.org>
> > 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 (this
> > 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 server
> > by
> > background workflow tasks.
> > Yes. However, User A may never even use the Web UI. User B on the other
> > hand may be watching the queue/progress monitor for regular updates.
> >
> > The web UI is intended to be a monitoring and configuration tool for the
> > 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' server
> > where all interaction is via a web UI.
> > I hope that makes more sense?
> > Regards,
> > Brett
> > --
> > Brett Gullan
> > brettgullan@mac.com
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message