Information Technology Reference
In-Depth Information
Old-fashioned integration
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 de-
cision, or because the sequence itself is not relevant to the evaluation itself. In the past, ad-
opting the process engine and the rule engine technologies was complicated due to the in-
tegration 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 busi-
ness domain—even if both engines were running in the same environment.
• Interaction between rules and processes implied specific mappings of both the loc-
ation 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 communica-
tion.
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:
