Informática 32 (2008) 383-396 383 On Interchange between Drools and Jess Oana Nicolae, Adrian Giurca and Gerd Wagner Brandenburg University of Technology, Germany E-mail: {nicolae, giurca, G.Wagner}@tu-cottbus.de Keywords: Drools (aka JBossRules), Jess, RuleML, R2ML, RIF, Rete, ReteOO, business rules, interchange, standardisation Received: March 15, 2008 There is a growing demand forresearch in order to provide insights into challenges and solutions based on business rules, related to target PSMs (Platform Specific Model in OMG's MDA terms - Implementation Model). As an answer to these needs, the paper argues on the relevance of business rules target platforms for the actual IT and business context, by emphasising the important role of business rules interchange initiatives. Therefore, the rule-system developers can do their work without any concern about a vendor-specific format, and in particular without any concern about the compatibility between the technologies. The paper provides a description of the business rules translation from a particular object oriented rule-system such as Drools, to anotherrule-system as Jess coming from the Alarea, using R2ML as interchange language. The transformation preserves the semantic equivalence for a given rule set, taking also into account the rules vocabulary. Povzetek: Prispevk opisuje prenos pravil iz objektnega sistema Drools v AI sistem Jess. 1 Introduction There is a growing request for business rules technology standardisation from both UML and ontology architects communities. Due to these reasons, business rules aim to express rules in a platform independent syntax. A number of initiatives on rules interchange have been started. They include the RuleML (2), OMG Production Rules Representation (PRR) (8), RIF (1), and the REWERSE I1 Rule Markup Language (R2ML1) (10). We mention here the efforts to establish some standards for expressing business rules and their vocabularies in natural language such as OMG's SBVR (9) and Attempto Controlled English (ACE) (4). SBVR, this human readable format of business rules comes under OMG's Model Driven Architecture (MDA2) standards and is defined as Computation-Independent Model (CIM3). CIM is most frequently used in the context of the Model Driven Architecture (MDA) approach which corresponds the Object Management Group (OMG) vision of Model Driven Engineering (MDE). The Meta-Object Facility (MOF), is the OMG standard for Model Driven Engineering. The second layer in OMG's MDA is Platform-Independent Model (PIM)4 where rule interchange formats (i.e. RuleML, RIF, R2ML) try to accomplish their general purpose: a PSM to PSM business rules migration through the PIM level. The third MDA level is Platform- 1R2ML - http://oxygen.informatik.tu-cottbus.de/ rewerse-i1/?q=node/6 2MDA - Model Driver Architecture is a framework for distinguishing different abstraction levels defined by the Object Management Group. 3CIM - Computational Independent Model 4PIM - Platform Independent Model Specific Model (PSM5) containing rule specific languages together with their specific engines/platforms like: F-Logic (5), JRules(ILOG6), Jess7 or Drools8. The main purpose of an interchanging approach is to provide means for reusing, publication and interchange of rules between different systems and tools. Actually, it also plays an important role in facilitating business-to-customer (B2C) and business-to-business (B2B) interactions over the Internet. Moreover, an interchange approach always supposes less transformations than PSM-to-PSM translations. Our rule interchange work addresses Drools as source platform and Jess as a target platform, using the approach suggested by OMG's MDA, because these languages are actually in business market interest as popular business logic frameworks, used by Java developers to create complex rule-based applications by combining Java platform and business rule technology. Another reason for choosing these two rule systems is their efficiency in "pattern" matching, especially to handle updates to its working set of facts, as both Drools and Jess use an algorithm known as the Rete (i.e. Latin for "net") algorithm. Computational complexity per iteration of this algorithm is linear in the size of the fact base. The main standardisation communities, OMG9 and W3C10 focus their work on providing business rules specification languages for all MDA layers of models in order 5PSM - Platform Specific Model 6ILog, http://www.ilog.com 1 Jess, http://herzberg.ca.sandia.gov/jess/ 8 JBossRules, http://labs.jboss.com/jbossrules/ 9OMG - http://www.omg.org/ 10W3C - http://www.w3.org/ 384 Informatica 32 (2008) 383-396 O. Nicolae et al. to obtain rules interchange. Their standards are not sustained by most of business rules management system tools, as they implement proprietary rule languages. The reasons for this situation imply the existence of only a few interchange works in the academia i.e. RIF (1) language still has no well defined guidelines of how to implement the transformations and it also does not specify how to test the correction of the translation. In this context, EU network of Excelence REWERSE11 developed R2ML as an interchange language for deploying and sharing rules between different rule systems and tools (e.g. Object Oriented rule languages, Semantic Web rule languages, Artificial Intelligence rule languages). Actually, R2ML (now at version 0.5) is a mature and experienced enough rule interchange language to provide a concrete interchange format for different rule systems and languages (i.e.http://oxygen.informatik. tu-cottbus.de/rewerse-i1/?q=node/15). R2ML has a rich syntax, so it can represent business rules from both Drools and Jess languages, providing this way the interchange possibility. As an interchange language, R2ML addresses the PIM level. The main idea is to use a model transformation language (MTL), or an application transformation language (ATL) to transform a PIM model into a PSM as in the Figure 1. Business rules are built following a business model representation. In many cases, a business model is first represented in a natural language description based on core on-tologic concepts like classes and variables (OMG's MDA -CIM level). At this stage, we can identify all objects referenced in the rules, and for each object we identify all referenced properties. For each property, we identify all its constraints. 2 Drools to R2ML mapping In this section we describe the general JBoss business rules transformation into R2ML interchange language. Drools engine project, (now at version 4.0.x) is an open source and standards-based business rule engine and it uses an enhanced implementation named ReteOO12. Drools is classified as an Object-Oriented Production Rules engine written entirely in Java language, and more specifically it is a Forward-Chaining rule engine. A Production Rules System (i.e. PRS) relies on an Inference Engine that is able to scale to a large number of rules and facts. The Inference Engine matches facts and data, against PRs, also called Productions or just Rules, to infer conclusions which result in actions. The Rules are stored in the Production Memory. The facts that the Inference Engine matches against the rules are stored in the Working Memory. R2ML is a visual rule markup, XML-based language, 11 REWERSE - http://rewerse.net/ 12RETE adaptation for an object-oriented language, a descendant of the well-known RETE algorithm whose purpose is to capture rules formalised in different languages and to interchange them between rule systems and tools. It provides support for all kind of rules: - Integrity Rules - Derivation Rules - Production Rules - Reaction Rules A R2ML production rule has conditions and postconditions. The conditions and post-conditions of a R2ML production rule are usually interpreted as logical formulae which correspond to a general first order formula: quantified formula, existentially quantified or universally quantified (i.e. R2ML uses the concept of r2ml:QuantifiedFormula and by default, all R2ML formulae are universally quantified). Usually, PRS does not explicitly refer to events, but events can be simulated in a production rule system by externally asserting corresponding facts into the Working Memory. The R2ML production rules metamodel is depicted in the Figure 2: The mapping from Drools to R2ML is possible as R2ML supports the representation of the PRs by relying on the OMG's PRR (8) Specification. Following sections describe general principles of mapping from JBoss rules into R2ML PRs. 2.1 Mapping rules vocabularies Object oriented rules systems as Drools and ILOG JRules are build on top of Java vocabularies. Drools is designed to use Java beans as facts. These facts represent the domain of the rules, meaning the rules vocabulary. Java beans objects are defined by users in their applications. These objects inserted into Working Memory represent the valid facts that rules can access. Facts are the application data, meanwhile the rules represent the logic layer of the application. This vocabulary is used by rules through the import declarations, which are specified inside of the rules file (drl files or xml files). For example, a rule from Drools may use one or many Java beans classes in order to describe its own vocabulary. The Java bean classes represent a description of the facts used by the Drools rule engine. A R2ML rule always refers to a vocabulary which can be R2ML own vocabulary or an imported one (i.e. UML13, RDF(S)14 and OWL15 - see lines 3.-4. from Section 2.2 i.e. an example of the importing an OWL external vocabulary for an entire R2ML production rule set). R2ML vocabulary is a serialisation of an UML fragment of class diagrams. Below, we describe the corresponding translation class from a usual Java bean into R2ML elements of the vocabulary namespace with the help of the optionally element r2mlv:Vocabulary i.e. Since almost all names from 13UML - http://www.uml.org 14RDF(S) - http://www.w3.org/TR/rdf-schema 15OWL - http://www.w3.org/2004/OWL ON INTERCHANGE BETWEEN JBOSS RULES AND JESS Informatica 32 (2008) 383-396 385 Figure 1: Interchanging between Drools and Jess. Figure 2: R2ML Production Rules Representation Metamodel. 1. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. R2ML rule bases are qualified names (xs:QName), they must have declared the corresponding namespaces (i.e. see above lines 2.-5.). In the same manner, any Java qualified class name will be translated into a qualified name (xs:QName) together with the corresponding names declarations. For example, if we assume the Drools import declaration (i.e. a Java qualified name): org.drools.usecase.Cheese, this will translate into the following namespace declaration xmlns:ex="http://www.drools.org/usecase " used in the qual- ified name (i.e. ex:Cheese), in order to reference the class name. 2.2 Rule Sets Mapping All imported Java beans in Drools rule packages form the rules vocabulary. The set of Drools rules is individualized by its package namespace, declared at the beginning of the rules file, namespace that can be equal or can differ from Drools import declarations i.e. The Drools package of rules package org.drools.rules; import org.drools.usecase.Cheese; /* set of Drools rules */ finds its correspondent into the r2ml:ProductionRuleSet element. It contains three optional attributes: - r2ml:ruleSetID - is the name of the rule set. The name of the Java package of classes identifies in an unique way the name of a R2ML ProductionRuleSet (i.e. see line 2. from below R2ML code example). - r2ml:externalVocabulary - represents an URI of an external vocabulary. We used OWL to represent the vocabulary of the rule. - r2ml:externalVocabularyLanguage - refers the language of the external vocabulary. 1. Excepting the rules and their import declarations, a Drools package may contain other specific constructs like: glob-als, user-defined functions and queries, but they do not represent the subject of our translation. 386 Informatica 32 (2008) 383-396 O. Nicolae et al. 1. rule "" 2. when 3. 4. then 5. 6. end // java-like, single line comment # single line comment /* ... java-like, multi lines comment ... */ 2.3 Rule Mapping In Drools, a rule consists of the rule identifier, the conditions part called LHS (i.e. Left Hand Side) and the actions part called RHS (i.e. Right Hand Side). The general principles of mapping a Drools rule into a R2ML production rule is: - Every JBoss production rule is translated into a r2ml:Productio nRuie element. An optional element r2ml:Documentation can contain elements which comprise the rule text and also the representation of the rule in a specific rules language. - A R2ML r2mi:ruieiD production rule attribute is generated using the JBoss value. The r2ml:rule id unique identifies a rule inside a rule set. - A JBoss rule has a conditions part (i.e. when part) and an action part (i.e. then part). The condition part of a JBoss rule is mapped into the content of r2ml:conditions role element. The RHS part of a JBoss rule which contains multiple actions maps into the content of r2ml:producedActionExpr role element. - The Drools language syntax also contains the comments expressed in Java-like syntax, such as: When translated into R2ML syntax, they map into the XML <[!cdata[...]]> construct. For example: 1. 2. 3. <[!CDATA[ 4. JBoss rule expressed in natural language... 5. ]]> 6. 7. In the following lines we describe the mapping of Drools conditions into R2ML appropriate ones. The LHS (i.e. when part) of a JBoss rule consists of patterns (i.e. columns) and eval as Conditional Elements (i.e. CE) in order to facilitate the encoding of propositional logic and First Order Logic i.e. FOL. The entire LHS of a Drools rule is in fact a tuple of facts (i.e. a tuple of patterns). Each pattern may have zero or more field constraints i.e. the pattern terms (see Figure 4). The and (i.e. &&) CE is implicit when the JBoss rule condition contains multiple patterns. Field constraints compare and assess the field values from the fact object instances. Drools facts from Working Memory are Java beans objects instances, therefore these field constraints can be accessed from the "no arguments" methods, also called the accessors (i.e. getters). 2.3.1 Mapping Drools patterns without Field Constraints A Drools pattern without field constraints, will map into the r2ml:ObjectClassificationAtom. For example, the following Drools pattern, which corresponds to universally quantified formula from classical logic: v?c Cheese(?c) is expressed in Drools as following: $c: Cheese() This Drools pattern finds its R2ML translation into the below code. As an explanation, we mention that all the R2ML formulae are implicitly universal quantified: 1. 3. 5. Following RuleML, R2ML framework defines the generic concepts of variable. However, R2ML makes a clear distinction between object terms and data terms. Typed terms are either object terms standing for objects, or data terms standing for data values. The concrete syntax of first-order non-Boolean OCL (7) expressions can be directly mapped to R2ML abstract concepts of ObjectTerm and DataTerm, which can be viewed as a predicate-logic-based reconstruction of the standard OCL abstract syntax. The bounded variable c represents the value of the r2ml:name attribute of the corresponding term (r2ml:ObjectName and/or r2ml:ObjectVariable) and the name of the Java bean class (i.e. Cheese) is the value of r2ml:class attribute. The above Drools pattern can be declared inside rules conditions also without the c variable, such as: Cheese(), but to be able to refer to the matched facts, usually, the rules conditions use a pattern binding variable such as c (i.e. in Drools terminology we refer to it as a fact variable or declaration). Any JBoss variables translate into R2ML variables. Notice that the translation of the Drools variables into R2ML eliminates the $ symbol (used in Drools only as a notation convention) from the names of the variables. The JBoss fact variable used in the previous pattern example (i.e. c:Cheese() ) is mapped into r2ml:ObjectVariable using the value of r2ml:name="c" property to describe the variable name, which represents an instance of the Cheese class (see lines 3.-4.). The usage of this instance gives us the possibility to call properties and functions of Cheese class in the actions part of a JBoss rule. The optional r2ml:class property (see line 4. from the above example) specifies the type of the object variable (i.e. Cheese). An r2ml:Objectvariable is a variable that can be only instantiated by objects. ON INTERCHANGE BETWEEN JBOSS RULES AND JESS Informatica 32 (2008) 383-396 387 2.4 Mapping Drools patterns with Field Constraints In many cases, a JBoss pattern (see Figure 3) may contain many field constraints, all of them referring to the same context variable. The Drools field constraints may be of the following possible types (i.e. string, numeric, boolean and date). When separated by the following operators (i.e. enumerated here in their priority order see also Figure 5): &&, || and , (i.e. comma), they form a Drools pattern formula. A Drools pattern formula translates into R2ML formula, using the R2ML simple/imbricated concepts of r2ml:qf.Disjunction and r2ml:qf.Conjunction (qf stands for "quantifier free") applied on R2ML atoms, in order to serialize the Drools CE || and &&, respectively. In the example below, we have two Drools patterns that in classical logic have the following representation, taking into account the operators order from Drools i.e. V?c V?p 3?youngCheese (Person(?p) A like(?p, ?youngCheese) a (Cheese (?c) a (type(?c, ?youngCheese) a price(?c) < 10) V bestBefore(?c) < "27 - Oct - 2010")) 1.$p:Person($youngCheese:like) 2.$c:Cheese(type == $youngCheese && 3. price <10 || 4. bestBefore < "27-Oct-2010") The Cheese pattern (see lines 2.-4.) has three field constraints combined with a conjunctive connector (i.e. &&) and a disjunctive connector (i.e. || ). We mention that the comma represents by default the conjunctive logic operator. The pattern refers literal constraints used to match the facts (i.e. instances of Cheese class): type (i.e. string constraint), price (i.e. numeric constraint) and bestBefore (i.e. date type constraint). The valid operators that apply for the numeric and date operands are: The above Drools pattern translates into the following R2ML formula (i.e. the example below describes only the imbrication of the operators (&&, || ) inside the Drools pattern): 1. 2. 3. 6. ... 7. 8. 9. ... 10. 11. 12. 14. ... 15. 16. In the absence of the qf.Disjunction or qf.Conjunction, all atoms from the R2ML rule body are implicitly connected by conjunction. First pattern from the Drools example above (see line 1.) contains as field constraint a bound variable, called declaration. The JBoss variable $youngCheese is bound to the like property, so it can later constrain the type property of the Cheese class. Since the like property is a data type property (i.e. String), the R2ML mapping is an r2mi:AttributionAtom, while for an object type property would find its mapping into the r2ml:ReferencePropertyAtom. 1. 3. 4. 7. 8. 9. 12. 13. The r2ml:AttributionAtom contains the r2ml:subject element which encloses the object term we refer. This can be expressed, for example, by an r2mi:objectVariabie (i.e. lines 4.-6.). The value of the JBoss property is referred by the r2ml:dataValue. In this example, the value is encoded by the r2ml:DataVariable element (i.e. lines 9.-12.). The youngCheese variable borrows the type of the youngCheese property. R2ML uses XML Schema Datatypes16 as its default namespace for encoding basic datatypes. The usage of this set of pre-declared datatypes is not mandatory, the user can specify any other appropriate URI and namespace for referring later in the rules its datatypes declaration. The Java/XML type correspondence it is done according to the JAXB17 binding style correspondence principle, therefore a Java String value will be translated into xs:string qualified name (see line 11.). The relational operations from Drools are serialized into R2ML language using the r2ml:DatatypePredicateAtom construct. Until this version, R2ML had not declared its own built-in constructs, but it allows the use of external ones, such as SWRL18 built-ins for representing the predicate type of the relational operations (i.e. swrlb:lessThen). We also use the construct of r2ml:DatatypePredicateAtom to serialize the Drools literal field constraints that test equality / inequality of data types properties. When serializing object types literal field constraints we use the r2ml:EqualityAtom to express the concept of equality and the r2ml:InequalityAtom to express the concept of inequality (!=). The following Drools pattern describes a Drools literal String constraint. Drools pattern translates into r2ml:DatatypePredicateAtom using the r2ml:datatypePredicate="swrlb:equal" SWRL build- in to represent the equality operator and serialises the type property into the r2ml:AttributeFunctionTerm (see 16XML Schema Part 2: Datatypes Second Edition - http://www. w3.org/TR/xmlschema-2/ 17 Java Architecture for XML Binding - java.sun.com/ developer/technicalArticles/WebServices/jaxb/ 18SWRL - http://www.w3.org/Submission/SWRL 388 Informatica 32 (2008) 383-396 O. Nicolae et al. Q—temindiiig]->[ ^-( feWarr*?"]->[ restriction j-tQ Figure 4: Drools Field Constraint concept. lines 4.-10.). The r2ml:dataArguments attribute comprises $c:Cheese(type == $youngCheese) the Drools operands translation into R2ML terms objects or data types, depending on the types of the involved properties. The Drools $youngCheese variable is expressed using the concept of r2ml:DataVariable i.e. —$c:Cheese(buyer!=null)--> //$p:Person() 1.$c:Cheese(buyer $p, inStock == true) A Drools pattern containing a formula that implies only field constraints conjunctions, can be split into as many Drools patterns as field constraints it contains i.e. //$p:Person() 1.$c:Cheese(buyer == $p) 2.$c:Cheese(inStock == true) There are two possibilities to markup the above cheese patterns (see lines 1.-2.): to use a conjunction of R2ML appropriate atoms or to use the r2ml:ObjectDescriptionAtom construct. First option implies the use of the r2ml:ReferencePropertyAtom in order to markup the first pattern (see line 1. from Drools example) and a r2ml:AttributionAtom for the data type boolean field constraint (see line 2. from Drools example) i.e.