A rule engine can become extremely useful when evaluating situations that would become very difficult to determine through a business process, either because the situation is too complex to make a clear diagram out of the sequence of steps required to evaluate the decision, or because the sequence itself is not relevant to the evaluation itself. In the past, adopting the process engine and the rule engine technologies was complicated due to the integration work required to make both engines share the necessary information to operate as expected. As the rule engine and the process engine were completely different applications, communication protocols had to be established between each other. This usually caused a few problems:
- Communication protocols between both engines could fail, creating a whole new group of issues that needed to be tested for a specific implementation of our business domain—even if both engines were running in the same environment.
- Interaction between rules and processes implied specific mappings of both the location of the other system, as well as the required inputs and expected outputs of process and rule executions. This is because every piece of relevant data needs to be sent back and forth between each engine.
- Transaction management could become a difficult issue to handle, because all transactions should be considered from a business perspective and have to be cross-engine execution.
- If you need both processes invoking rules as well as rules invoking processes, handling the communication could become troublesome and hard to maintain, and can increase the possibility of error due to increased complexity in the communication.
The overall intercommunication architecture needed to have both the rule engine and the process engine collaborating with each other, as shown in the following figure:
In the preceding figure, every arrow you see is a potential communication problem. This is not an issue with jBPM6 and Drools, because the rule and process engine are the same thing. You can seamlessly invoke rule executions from a process instance, and a rule can trigger a specific signal or interact with a particular process instance—all without creating any intercommunication mechanism between both components, unless a clear separation of both engines is desired. This simplifies the initial adoption of rules and processes interactions.