On the subject of general purpose workflow, the eclipse guys seem to be up to something interesting over here: http://www.eclipse.org/proposals/jwt/ as they seem to be trying to abstract the process definition language from the workflow engine.
hopefully for BpmScript or BeanFlow, it won't be too stuck on XML :) cheers, j. On 5/22/06, James Strachan <[EMAIL PROTECTED]> wrote:
On 5/18/06, Jamie McCrindle <[EMAIL PROTECTED]> wrote: > hiya, > > (james, correct me where i'm wrong) > > i haven't had a chance to play with BeanFlow but it looks pretty neat. > here are some more fundamental differences between the two: > > - Java (BeanFlow) vs. Javascript (BpmScript) > - Workflow classes (BeanFlow) vs. Continuations (BpmScript) Agreed. The motivation of BeanFlow was really to act as a simple Java-centric alternative to BPEL for orchestrating of asynchronous events. BpmScript is cool too though. > The rest of the things that BpmScript has at the moment (e.g. process > versioning, jms and hibernate persistence implementations, management > console, worklist support, etc.) could be built on top of BeanFlow. > > for what it's worth, my opinion would be: Java is better to program in > than Javascript. Continuations are a more natural way to write > programs compared to Workflow classes. > > What this does highlight, though, is that it would be awesome to have > a general purpose set of interfaces for managing workflow processes, > so you could choose between BeanFlow, BPEL, BpmScript etc. but some of > the higher level management remains the same e.g. starting, stopping, > deploying and monitoring of processes and process instances. Agreed! -- James ------- http://radio.weblogs.com/0112098/
