Visual Inference Specification Methods for Modularized Rulebases. Overview and Integration Proposal

The paper concerns selected rule modularization techniques. Three visual methods for inference specification for modularized rule- bases are described: Drools Flow, BPMN and XTT2. Drools Flow is a popular technology for workflow or process modeling, BPMN is an OMG standard for modeling business processes, and XTT2 is a hierarchical tab- ular system specification method. Because of some limitations of these solutions, several proposals of their integration are given.

💡 Research Summary

The paper addresses the scalability and maintainability challenges of large rule‑based systems (RBS) by examining three visual inference specification approaches: Drools Flow, Business Process Model and Notation (BPMN), and EXtended Tabular Trees (XTT2). It first outlines classic modularization techniques such as CLIPS and JESS, noting that while they introduce modules and separate agendas, they do not reduce the need to evaluate every rule against the fact base. Drools Flow, part of the Drools 5 platform, provides a graphical workflow editor where rules are grouped into rule‑flow‑groups and connected through split and join blocks that support AND, OR, and n‑of‑m control flows. This enables explicit ordering of rule execution and improves the efficiency of the ReteOO algorithm. However, Drools lacks standardization, is tightly coupled to Java, and its rule‑flow files have changed across versions, limiting design‑time verification and portability.

XTT2, developed in the HeKatE project, combines decision tables and decision trees into a hierarchical XML representation. It uses ARD+ diagrams for conceptual design, a logical XTT2 hierarchy for rule organization, and a physical phase that generates executable code. Rules are expressed in ALSV(FD) logic and interpreted by a Prolog engine, allowing formal verification, online analysis, and automatic prototype generation. The main drawbacks are limited tool support, a lack of sophisticated workflow constructs, and low industry adoption.

BPMN is an OMG standard for modeling business processes. It offers rich visual elements—events, activities, gateways, swimlanes—and can be serialized to XML and mapped to execution languages such as BPEL. Nevertheless, BPMN does not natively model business rules, and the mapping to executable form is non‑trivial; many BPMN diagrams cannot be directly transformed into BPEL, and the semantics of rule execution remain ambiguous.

A comparative table in the paper highlights that Drools excels in workflow modeling but lacks standardization; BPMN provides a widely accepted notation but does not define rule‑process interaction; XTT2 offers formal verification and hierarchical rule representation but suffers from limited tooling.

To overcome these individual limitations, the authors propose two integration strategies. The first translates XTT2 models into Drools artifacts. An XTT2 XML file is parsed to produce three outputs: (1) a Drools Flow XML describing the execution graph, (2) a CSV decision‑table file containing the transformed rules, and (3) a Java “Workspace” class that aggregates all XTT2 attributes as facts. This conversion preserves XTT2’s verification results while leveraging Drools’ efficient runtime engine and workflow capabilities.

The second strategy couples BPMN with XTT2. BPMN process diagrams are enriched with XTT2‑derived rule nodes; BPMN gateways are aligned with XTT2’s logical connections (forward or backward chaining), and the combined model can be mapped to BPEL for execution where feasible. This integration aims to exploit BPMN’s standardized visual language and widespread tool ecosystem while providing a rigorous rule specification backbone from XTT2.

Overall, the paper presents a coherent vision for a hybrid modeling environment where Drools supplies execution efficiency, XTT2 contributes formal design‑time analysis and hierarchical rule organization, and BPMN offers a universally understood process notation. The proposed integrations promise improved scalability, better maintainability, and clearer documentation for large‑scale RBS projects. Future work is suggested on refining the automated transformation tools, extending runtime monitoring, and defining a meta‑model that could be standardized across the three technologies.