[werkflow-user] let's set this thing on fire
"Brian Topping" <[email protected]> Thu, 29 Jan 2004 22:34:39 -0500
| Newsgroups | gmane.comp.java.werkflow |
|---|---|
| Message-ID | <[email protected]> |
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