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

Hi Peter,

It is to me. I too have a product based on Turbine, although intend to move
to Plexus. I need simple inbox workflow management for tasks escalated from
automated data tranformations that fail due to data anomolies. I am
interested to see what you think about how you couple the page flow to the
underlying workflow.

Regards,

David

> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]]On Behalf Of Peter
> Courcoux
> Sent: 30 January 2004 17:37
> To: [email protected]
> Subject: 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]>
> _______________________________________________
> werkflow-user mailing list
> [email protected]
> http://lists.codehaus.org/mailman/listinfo/werkflow-user
>