Brian Topping
2004-01-30 03:34:39 UTC
Bob, Jason and I just spent some quality time on IRC. I was explaining that
I need a workflow system that is going to be able to handle interactive task
delegation to users of a live system, and was contemplating what needed to be
done to get Werkflow up to what I need as well as something that is general
enough that it's worth checking into HEAD.
My Aalst book came in finally after a three-week wait as well, so I'm less
<clueless/>, as the case may be (never underestimate how <clueless/> i am
though...)
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? It's a minor irritant to have someone
implement something in HEAD with different code than what you already wrote
to solve the same problem, so before putting a lot of effort into breaking
your respective forks, I wanted to see if anyone wanted to get stuff in the
mix. Or if things are on branches, understand what they are.
Most of my issues revolve around making modular access to persistent storage
and auth -- i.e. I've got this grand object model that doesn't have any
relation to your grand object model and both of them ought to be able to work
without caring a bit about either. General persistence is a no-brainer. For
example, JBPM seems to be one of the two or three best Java/OSS interactive
workflow solutions out there right now, but it's got a real tight coupling to
the database (Hibernate .hbm.xml's checked into the source tree even!) I'd
personally rather see solid DAOs providing pluggable persistence. Same with
auth. 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. CMA isn't the most intuitive
thing and has it's issues, but the bar has to be set somewhere, and it's a
lot easier to give a secure implementation of workflow to someone integrating
it if they know that the middleware is going to do the right thing with the
login context.
The actual Petri code isn't high on my list of things I want to touch. Maybe
there are some coloring aspects once there is some more contextual
information, but it's a way out.
Hopefully people can take a minute to chime in. If the discussion dies down
by mid to late next week (or never takes off), I'll just presume that
everyone has been heard that's interested in the subject. I'm going to chew
on some authentication/authorization code in the mean time.
thanks,
-b
I need a workflow system that is going to be able to handle interactive task
delegation to users of a live system, and was contemplating what needed to be
done to get Werkflow up to what I need as well as something that is general
enough that it's worth checking into HEAD.
My Aalst book came in finally after a three-week wait as well, so I'm less
<clueless/>, as the case may be (never underestimate how <clueless/> i am
though...)
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? It's a minor irritant to have someone
implement something in HEAD with different code than what you already wrote
to solve the same problem, so before putting a lot of effort into breaking
your respective forks, I wanted to see if anyone wanted to get stuff in the
mix. Or if things are on branches, understand what they are.
Most of my issues revolve around making modular access to persistent storage
and auth -- i.e. I've got this grand object model that doesn't have any
relation to your grand object model and both of them ought to be able to work
without caring a bit about either. General persistence is a no-brainer. For
example, JBPM seems to be one of the two or three best Java/OSS interactive
workflow solutions out there right now, but it's got a real tight coupling to
the database (Hibernate .hbm.xml's checked into the source tree even!) I'd
personally rather see solid DAOs providing pluggable persistence. Same with
auth. 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. CMA isn't the most intuitive
thing and has it's issues, but the bar has to be set somewhere, and it's a
lot easier to give a secure implementation of workflow to someone integrating
it if they know that the middleware is going to do the right thing with the
login context.
The actual Petri code isn't high on my list of things I want to touch. Maybe
there are some coloring aspects once there is some more contextual
information, but it's a way out.
Hopefully people can take a minute to chime in. If the discussion dies down
by mid to late next week (or never takes off), I'll just presume that
everyone has been heard that's interested in the subject. I'm going to chew
on some authentication/authorization code in the mean time.
thanks,
-b