Re: [werkflow-user] let's set this thing on fire

On Fri, 2004-01-30 at 03:34, Brian Topping wrote:
> Bob, Jason and I just spent some quality time on IRC.

Damn; missed it! Does anyone have a log, if there's interesting stuff in
their?

> A few names came up as having some code that may be of interest.  Mark
> Wilkinson on Plexus, Bart (???) on persistence, someone else that is escaping
> me (courtesy of mIRC and Heineken).  Does anyone that have code that they
> want to have as a part of the system?

I've got no changes sitting in my source tree at the moment. I've
integrated werkflow into the system I'm working on, but should be able
to track changes.

> Most of my issues revolve around making modular access to persistent storage
> and auth

I'm using werkflow to orchestrate message-driven integration between
systems, so my main interests right now are:
      * message initiation and correlation
      * persistent storage of case state
      * transactional reliability for case state changes
      * scaling to handle large numbers of processes and cases
I'd be interested in the interactive workflow stuff you're thinking
about too (presume you're meaning the kind of stuff you'd build an
inbox-type application around), but my main aim at the moment is
orchestration of message processing.

Off the top of my head the things I think might need tackling at the
moment are:

The lifecycle of a case isn't particularly easy to follow; there are a
few places where a case can be created, woken up or terminated, but the
code to actually do the work is scattered around. It might be easier if
there were some basic primitives that could be applied to process cases
(create, sleep, wakeup, etc. perhaps). Practical up-shot of this: at the
moment, having a process call another process doesn't work because
there's a chunk of code missing to create the sub-process instance, plus
there's no mechanism for recognising that the sub-process has
terminated.

When a case does get woken up the state changes seem to happen in a few
different places, and (possibly more of a problem) in different threads.
This might make it difficult to group all the state changes into a
database transaction, for example.

> I'd personally rather see solid DAOs providing pluggable persistence.

Agreed. The data model that underpins a workflow system is simple enough
that I think OR-mapping is a bit over the top.

> I guess I'm looking at this from a perspective of adoption; if the
> system can be used in a two-tier MVC app and run under J2EE container-managed
> auth, it makes the system a lot more pluggable.

Yup; from an adoption point of view I think one of the problems with
werkflow at the moment is that it's too generic: out of the box it won't
actually do very much, and it takes a bit of imagination to see how to
exploit it. I think that's probably put people off. Anything that
packages the core as a solution for a particular use case has to be
good.

Running werkflow in a J2EE container could be a bit of a problem at the
moment: it uses threads internally to schedule activities, and you're
not supposed to create new threads within a J2EE container. There may be
some leeway here though - I've not actually looked into whether specific
application servers allow threads to created under restricted
conditions. I'm also not sure whether J2EE 1.4 begins to provide some
kind of scheduling services to J2EE components.

-Mark.