Re: [werkflow-user] BPEL support

On Tue, 2004-02-24 at 23:57, Paul Russell wrote:
> On 24 Feb 2004, at 04:14, Brian Topping wrote:
> >
> >> [...] I come from a websphere
> >> process choreographer background, which works using database-based
> >> persistence to store state, and JMS + Message Driven Beans to provide
> >> activity scheduling and dispatch - I was kind of /assuming/ a similar
> >> architecture for implementing BPEL.
> >
> > Adding the MDB transport on the front end should be a couple dozen 
> > lines of code.
> 
> I'm not sure we're talking about quite the same thing here. Although 
> IBM's framework /can/ use JMS as a framework for controlling the 
> workflow container (including starting processes etc), it also uses it 
> internally to schedule the transitions between activities for 
> macro-flows. This allows one process to run across many nodes (although 
> usually, the EJB container's affinity will prefer each activity to run 
> on the same node as the last). If the node fails for any reason, the 
> process will forward recover on another node, since the message that 
> triggered the last activity will be 'rolled back' onto the queue.

I see what you're getting at, and I'm not sure how simple it would be to
hook that kind of functionality into werkflow. At the moment the core of
the engine uses Doug Lea's concurrent library to provide a simple thread
pooling system for scheduling activities. Currently this means that it
wouldn't be possible to run the werkflow core within an EJB container,
for example. That's not been a great problem up-to-date though - EJB
containers don't really provide much in the way of support for building
multithreaded applications.

The J2EE 1.4 spec adds a timer service to the EJB container, so with
that it should be possible to interface werkflow to an EJB container.
I'm thinking that this would be a case of splitting off the thread
scheduling part of werkflow into a pluggable interface. By doing that
we'd probably be able to schedule activities using JMS messages, the EJB
timer service, a simple thread pool, or whatever.

I'd been thinking about resilience and fail-over a bit myself: the
project I'm working on at the moment would need these kinds of features
in the future. My starting point would really be getting werkflow to
persist process cases into a relational database reliably (i.e. making
activity execution a transaction against the database), on the basis
that building resilient databases is a solvable problem. Once that's
done you should actually be able to cluster werkflow - you'd be using
database locks to make sure that only one instance of werkflow could run
a given activity at a given time.

One way of looking at it is that IBM's product is using JMS messages to
hold process case state, while werkflow is more likely to use a generic
relational database.

> You're absolutely correct that Werkflow shouldn't be directly involved 
> in this. However, as it stands, as far as I know, a process can't be 
> failed over half way through. This is fine for processes that take a 
> few seconds to execute and return a result, but if a process takes 
> weeks or even months, this is a bit of a killer for the application I 
> have in mind.

Yes, at the moment werkflow can't do this. The persistence interfaces 
need completing so that the state of the werkflow engine can be held on
disc rather than in memory. I definitely want to get this working
though.

-Mark.