User development, A new message was posted in the thread "Upgrade from JBPM3 to JBPM4 woes":
http://community.jboss.org/message/524867#524867 Author : nick bauman Profile : http://community.jboss.org/people/nick.bauman Message: -------------------------------------------------------------- Ronald, > What does make me wonder though is how you asses the risk of something > different but existint (jbpm 3 vs 4) in relation to something none existing I might have not made this clear, but we're going to stay on JBPM3 for now. If we revisit upgrading we won't limit our options to JBPM4 > And migrating from jBPM3 to another BPM solution almost certainly as > difficult as migrating to jBPM4 Totally agree, > So I am truly honestly, openly interested in the ++/+/0/-/-- lists/ Balanced > scrore card/SWOT-analysis leading to this without wanting to lure you back :-) Okay, that's a fair request. What we were looking for moving to JBPM4: 1.Better handling of subprocesses / superstates. Right now with JBPM3 we can only have subprocesses behave in a “fire and forget” fashion because any other type of subprocess assumes access to a persistent store, which we do not want. No wait state / prompt can occur in a subprocess. We were hoping this restriction would be lifted in JBPM4. 2.Better Spring integration. JBPM3 has limited Spring integration. 3.Keeping up with the rest of the JBPM world. Staying up to date on 3rd party systems means we get the benefits of increasing stability and openness to innovation over time. What we found: The Good 1.The interfaces are based on a service facade and the process definitions are pieced together of Composites, making the FSM better modeled. In theory it also means that handling sub processes might be simpler. 2.A process definition conversion tool exists. It's considered experimental bu it's purported to convert JBPM3 to JBPM4 process definition XML files. 3.Actions can be scripted with dynamic languages instead of Java. 4.Many different idioms for the FSM have been added, such as Swimlanes and Tasks. The Bad 1.No binary compatibility exists between JBPM3 and 4. Not even the process definitions are compatible because JBPM4 is a complete rewrite. 2.The process definition conversion tool doesn't work. When running the conversion tool over one of our process definition it appears to assume that if any GraphElement exists that does not have an action element, it's invalid when clearly this is a perfectly valid GraphElement. It throws an exception: invalid process xml: Could not convert a node without action element. It also assumes that any action handlers or exception handlers are on your classpath before it converts them. 3.Significant additions to our current target platform would be required. These additions imply a potential ripple effect on other subsystems and integration with our SCADA control system. 4.Spring integration seems still a back art. It may even require Hibernate integration: something we need to avoid. We have not been able to find good examples of how the Spring integration works in v4. 5.The design of JBPM4 is oriented toward a service facade which makes it less clear how we control process definitions. JBPM3 is a simple Finite State Machine with some decent GUI designers. -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/524867#524867
_______________________________________________ jboss-user mailing list [email protected] https://lists.jboss.org/mailman/listinfo/jboss-user
