I implemented a couple of use cases for checking the integration of Drools rule within a jBPM workflow definition. It is a great step forward in having business rules integrated with jBPM activies, and allow the end user to specify the business rules to be invoked, but I ran into a few limitations, and I have a few questions about that.
1) jBPM expects to find the business rule deployed on the same deployment package with the process definition that is using that rule. IMHO this creates a pretty hard dependency between the rule files and the process definitions files, dependency that does not feel natural, as the process definitions changes and rule changes are not following the same pattern. On the real use case I can see business rules changing more frequent than the process definitions, and I also can see the same business rule being used by more than one process definition. And the process definitions that use the same business rule can be deployed on different deployment packages, on real life.
But having the constraint that the business rule and process definition that is using it to be on the same deployment package, pretty much imposes that all process definitions and all business rules for an application be deployed on the same deployment package, and every time when a process definition is modified to redeploy the whole package, not just the updated process definition.
I wonder if in the future releases, there is any alternative to this hard dependency between the business rule files and the process definition files being on the same deployment package. I wonder if it would make more sense to allow injection of the KnowledgeRule service into the jBPM RuleDeployer, and that service will know to return the correct KnowledgeBase based on the rule package and/or rule name, and/or rule file. This KnowledgeRule service will take care of loading the business rules from a custom location, and not from the jBPM deployment.
2) jBPM expects that all rule files are extension ".drl". This seems very limiting as Drools engine also has the decision table rules as excel files, or csv files, and also business rules using the designer with ".brl" file extension.
Is any plan for future releases to include the other rule files extensions besides the ".drl" one?
3) jBPM rule activity allows to specify the facts for a rule, and all rules deployed with the same process definition are fired.
I wonder if there is any plan for future releases to allow for a more granular rule state configuration, when a user can specify either the rule name, or the rule package, besides the rule facts. I can see on large applications business rules using the same facts, but actually having different functionality, and being able to specify the rule name or package, will fire the expected rule only.
I wonder if anybody else tried the jBPM Drools integration and whether it found out the same limitations as me. Any feedback is useful.