Re: [jbpm-dev] Proposal for jBPM5 first release

Ed, Thanks a lot for your feedback, comments inlined. Staub, Edward wrote: > 1.) Open persistence - by which I mean, a database schema where the process and "thread" states, definitions, etc., are modeled in the database - not in a big blob. JBPM has this, Drools-Flow doesn't. > It all depends on what you are trying to do. jBPM3 used to combine current runtime state and history logs. As of jBPM4, these are now stored separately, as does Drools Flow. You're right when you're saying that Drools Flow uses a binary storage mechanism by default (though persistence is fully pluggable), where the internal state of the process instances is stored using a binary format. There were various reasons for this (performance, migration, pluggability, shielding of execution engine, etc.). There is however also a separate history log that contains history information, but also is real-time, so it contains info like the current active nodes, etc. I would be very interested in the use cases you envision for "open persistence" though. > 2.) Isolated or collaborative custom nodes. In Drools-Flow, the WorkItem is (deliberately, I think) isolated from the engine. It can get parameters, and return values - that's it. In JBPM, the Activity has more-or-less full access to the engine. > I don't think there's a real difference here. You are correct in saying that a work item is a more limited than an Activity, as it's only purpose is getting results back (from an external system) based on some input. But that's what the work item node was written for specifically (and is very useful for defining domain-specific extension imho). You should probably compare a jBPM4 Activity with a NodeInstance in Drools Flow, which is the internal representation of a node executing. There you would have access to the entire internal engine. So you could plug in your own node implementation. So why the difference you might ask? I think not a lot of developers are experts in that they feel familiar with plugging in their custom nodes. But defining domain-specific nodes using the work item node (actually by just creating a configuration file) is a lot less complex. But again, I'd love to hear about the use case you had in mind where you would need to define your own Activity. > 3.) Custom Decision Handlers. In JBPM, decision nodes can be customized just as much as Activity/WorkItem nodes. In Drools-Flow, the only inputs to a decision are the KnowledgeBase variables. > The disadvantage of using Java classes for describing decisions like that is that you tend to end up with a lot of lower-level decision code. And you should be especially careful if you are trying to access external state, as you should in that case handle the transaction management yourself. In Drools Flow, this would probably be modeled using 2 separate nodes, one where you prepare the decision (and a result set the value of the decision variable) and then the actual decision node. Since we're moving towards BPMN2, we should probably be looking at whether we would need to extend the BPMN2 spec for specific use cases in this area. > 4.) Use of rules for decisions. They both have this in some form. The JBPM support is a subset of Drools-Flow. Is it sufficient to satisfy Drools-Flow users? If not, what's "missing"? > The vision is that you should be able to combine processes and rules seamlessly. The simplest case would be the use of a decision service where a decision is made based on some rules (and data). This is the case jPBM also supported. Currently, Drools Flow also supports use cases like rules for starting processes, rules for leaving wait states, assignment rules, rules reasoning on process events, processes driving rules, etc. But we believe in going much further, offering constructs where rules could override process logic for exceptional situations, or a process might be nothing more than a set of process fragments, where the user or rules could decide which fragment to execute when. I'm not saying everyone will need these features, but if you're looking for more flexible or adaptive processes, you'll be interested in this more advanced integration. To be honest, I think this will become the default in the future, especially if you see the current interest in topics like adaptive case management etc., as you shouldn't see processes and rules (and event processing for that matter) as completely separate technologies but rather different ways of modeling your business logic which you can easily combine. > 5.) A roadmap for web services. JBPM has historically done nothing in this area. Is this still the plan? > Short-term, jBPM will focus on a more Java-oriented audience. Invoking web services or integration with an ESB is definitely a target (you could even see them as a domain-specific node), but probably won't make the first release out-of-the-box. If you're interested in pure web service orchestration, you could take a look at the RiftSaw project using BPEL. While this uses a separate execution engine, we'll be sharing other components like management consoles, human task service, etc. But we're already doing the exercise, where we are trying to define what it is exactly that is currently missing (WS discovery, sync and async integration, XML handling, etc.) and what we need to improve it. We're more than happy to assist anyone who might be interested in this as well. Kris _______________________________________________ jbpm-dev mailing list jbpm-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbpm-dev