Frequently Asked Questions (FAQ)

Why another rule engine? There are so many rule engines available (cf. the rule engine overview).

The reason for setting up a new rule project was that most existing rule engines do not aim at a lightweight implementation for being used as a small software component in the context of larger software projects. Often, complete Business Rule Management Systems are available and it is difficult to factor out only the pure rule engine. Most similar to Jadex Rules are maybe JESS and Jamocha.

In what projects Jadex Rules is used?

Currently, the primary usage of Jadex Rules is in the Jadex BDI agent system. In this context it is one essential building block for the BDI (Belief Desire Intention) agent architecture, which relies on condition monitoring and evaluation. Once, Jadex Rules is picked up by other people and used in third-party projects we will add a specific project page. If you like Jadex Rules and used it in a project it would be really nice if you will tell us about.

What language is used for rule specification?

In Jadex the specification languages for rules are different for the left and the right hand side of the rule. For the definition of the conditions (left hand side) three options are available:

1. A CLIPS language derivate can be used. You can find a thorough description of the CLIPS language at the CLIPS site.
2. A proprietary dialect of Java expressions called Java condition language (jcl), described in more detail in the about section?.
3. Conditions can be created manually by constructing the corresponding Jadex Rules objects directly.

The right hand side of rules, i.e. the actions that should be executed when a rule fires, are defined procedurally as plain Java code, which has API access to the state and the bound variables.

What mechanism is used for rule evaluation?

Jadex rules does not prescribe the usage of a specific rule evaluation mechanism. Though, the current verion of Jadex Rules provides support only for the RETE pattern matching algorithm, which is known to be very efficient but trades performance against state space. In future releases it is planned to support other state-efficient algorithms as well.

What state representation is used?

The state representation is based on a mixture of OAV (Object Attribute Value) and Java objects. OAV objects are based on OAV type definitions. These OAV types are desribed using attributes, which consist of name, type and possibly default values. Of course also various types of multislots are supports. At runtime the underlying type model is used for ensuring type safety by checking if inserted objects are conform to declared attribute type. In addition to OAV objects also normal Java beans can be used. These beans have to respect several aspects:

• They must not change any of their attributes without notifying the state via property change listeners.
• They must not change their identity (otherwise the state cannot lookup them anymore), i.e. they must not change their hashcode and equals results when contained in the state. You will e.g. encounter no problems if you do not override the hashcode and equals implementations of java.lang.Object.