[jboss-dev-forums] [Design of JBoss jBPM] - jbpm drools integration meeting

This is a report of the jBPM drools meeting we just had in london. 1) Rules deployment model is quite different from jBPM's deployment model. This discussion brought us to an interesting conclusion: there does not seem to be an obvious common model on how domain specific sources end up on a runtime deployed system. Drools and jBPM will keep their current deployment models. But as part of the jBPM-drools integration, we worked out how we can build a unified process-rules repository. Basically, the idea will be that the unified repository will be a jBPM database, extended with a table for rule bases. A rule base will be stored as a blob and referenced by a name. Then from inside of a process, you can reference the rule bases by name. This scenario allows for rule bases to be deployed and managed separately from processes but in the same repository. A special simplified use case is when a process archive contains a set of rules in source format. In that case a default rule base will be created and associated with the process. The process and the rules will then appear to the user as one logical entity. In a process you can then say 'fireAllRules' without specifying a specific rule base. Processes will contain a mapping between logical names and rulebases. Rule bases can be referenced in the unified process repository or in any other location. One of the referenced rule bases can be the default rule base. 2) Process variables as facts. In each process operation you can already feed in all the process variables into a working memory. This will fire rules and many of the intermediate results will be kept in the working memory. In a subsequent process operation, you might want to fire all rules again. Currently, that would require that all the process variables will have to be fed in again. Re-asserting all the variables as facts is not desirable: all the concequences will be re-fired with potential side effects This implies redoing a lot of calculations of which the result was available in the working memory. Currently, there is no way to store the working memory, restore it later and re-install the process variables as facts into the working memory again. Mark will be adding support for storing and retrieving working memories. A working memory is composed of facts and an agenda. The solution will be to store the agenda and a mapping between rule-fact-handles and process variables. At working-memory reconstruction time, the agenda will be deserialized and the mapping will be used to rebind the rule-fact-handles in the agenda to the process variables. By default, jBPM will fire all rules when a process variable is updated. The working memory will be stored as process execution data (along side the process variables). 3) making process objects (varables, taskInstance, token, ...) available on the right hand side in rules as global variables. Drools will add an interface like this public interface VariableResolver { Object resolveVariable(String name); } Then jBPM and SEAM can provide a different implementations that know about the contextual objects. All questions and remarks on this strategic directions are appreciated. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3963768#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...