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

Hi,

I have an inbox type app working to some extent. I have an inbox, which
lists cases deployed and called from a web-app. The app is based on
turbine and werkflow is deployed by an apache-avalon-merlin container.
I've had this for six weeks now and just need to write a flow and link
it to some pages. 

Its getting high priority again so it shouldn't take long to have
something worth submitting as an example.

Is any of this of interest?

Regards,

Peter


On Fri, 2004-01-30 at 10:38, Mark H. Wilkinson wrote:
> 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.
> 
> _______________________________________________
> werkflow-user mailing list
> [email protected]
> http://lists.codehaus.org/mailman/listinfo/werkflow-user
-- 
Peter Courcoux <[email protected]>