Skip to main content
MISMO Logo

Business Rules Exchange

Go Search
Home
  
MISMO Wiki > Business Rules Exchange > Wiki Pages > ProofOfConcept  

ProofOfConcept

Introduction
 
High Level Architecture for the POC
 
The diagram below illustrates the physical deployment of the two rules engine servers and that they will be communicating via DRAFT RIF over a web service.
BREWDeploymentDiagram
 
There are two primary flows for the BREW POC. The first flow is the exchanging of business rules between the iLOG rules engine and the JBoss rules engine as illustrated below.
 
BREWSequenceDiagram1
 
The second flow is the actual execution of these rules that have been exchanged in flow 1. This will be accomplished via submitting a MISMO 2.4 AUS XML document to both rulesengines from a custom created UI and comparing the results.
 
BREWSequenceDiagram2
 
 
APOCRIF : Translating production rules into RIF
 
Overview

The APOCRIF POC, developed by ILOG, explores the possibility of serializing/deserializing an IRL ruleset as an XML RIF document as a first step. It will help to send rules between two different rule engines, JRules and JBoss rules.

It has been developped with Java 5.0. The following assumptions have been been set:

  • The only common data model used by the rule engines is a schema provided by Mismo organization
  • The only data processed by the rule engine are represented as XML document provided by the Mismo organization, following the previous schema specification.
  • The rule engine shares the same Java model (JDK5.0) such a way any native method invocation has a meaning on both engine platforms.

The current state of the RIF core draft http://www.w3.org/2005/rules/wg/core/draft-20070323.html, limited to Horn clauses, does not permit to represent general production rules defined against object models such Java. However, a first analysis of the MISMO IRL rules proposed by Bruno Trimouille shows that a limited extension of the RIF core meta-model may be enough to serialize them as a RIF document.

APOCRIF Global architecture

Sharing same RIF metamodels

We propose to center the rule translation process around the meta-model of RIF. This meta-model is represented by a set of classes defined in the apocrif.core Java package. Those factory classes help to represent a RIF ruleset as a Java object tree.

This meta-model module provides an important RIF-XML serialization/deserialization service. The apocrif.core Java module could be shared among different engine implementations, factorizing the meta-model structure and its RIF-XML serialization.

The apocrif.pr (Production Rules) package, built upon the apocrif.core module, is a factory of RIF production rules. The data model is based on XML schema types and the procedural model is the libraries of Java 5.0.

Rule engine drivers

On top of the apocrif.pr package, we introduce a driver layer in charge of adapting the RIF rules and their meta-model to a dedicated rule language (IRL, JBoss rule). The driver API is likely to define the following method:

serialize: engine ruleset –> RIF ruleset
deserialize: RIF ruleset –> engine ruleset

Rule mapping

This section shows how production rules and object model notion could be mapped into RIF. The mapping is not unique. We try to reduce the needed extension of the RIF meta-model.

This mapping is described as a table given just below. In order to illustrate this table by affective examples, a MISMO rule is listed below.

The MismoRoot type is the mapping type of an XML complex type defined in the XML schema mismo.xsd. We assume for the moment that every type appering in a rule expression is related to an XML type.

rule Occupancy_Adjustments_1
{
  when {
     ?r : MismoRoot ();
     evaluate( ?r.division.equals( "wholesale"); ?r.occupancy.equals("Investors")  );
  }
  then {
    ?r.occupancyAdjustment = 0.95d;
  }
}

PR concept RIF concept Comment
Native Java type Native XSD corresponding type For example, java.lang.String is mapped on xsd:string. Obviously, it exists some Java types that can’t be represented in XML.
Dynamic Object type XML related type The MismoRoot type will be mapped on its related XML type.
Native Field getter not supported
Dynamic Field getter Dedicated uniterm getter ?r.division is represented as Uniterm(“xmlGetter”, “mismoRoot”, “division”, Var(“?r”) )
Native Field setter not supported
Dynamic Field setter Dedicated uniterm setter ?r.occupancyAdjustment is represented like Uniterm(“xmlSetter”, “mismoRoot”, “occupancyAdjustment”, Var(“?r”), Const(0.95) )
Equals method Dedicated uniterm equals ?z.equals( “wholesale”) is represented as Equal( Var(“z”), Const(“wholesale”) )
== operator Atomic Equal ?z == 2 is represented as Equal( Var(“z”), Const(2) )
Java constant Related XML type constant “Hello” represented as Const ( xsd:string, “Hello”)
Method invocation not supported Is it necessary for MISMO rules ?
universal variable declaration Variable inserted in the variables slot of the ProductionRule
Binary operator !=, gt… related uniterm for example ?x < 50 represented as Uniterm( “xpath:numeric-less-than”, Var(?x), Const(50) )
Variable declaration with initialisation Variable + Constraint int ?i = 2 translated into Var ( “?i” ) and Uniterm ( “aprif:variableConstraintOp”, Var(“?i”), Const(2) ) as a rule constraint.
in conditional generator varaible constraints inGeneratorOp ?a: A() in myTerm represented in the constraint part of the rule as Uniterm ( inGeneratorOp, Var(?a), myTerm )
from conditional generator varaible constraints fromGeneratorOp ?a: A() from myTerm represented in the constraint part of the rule as Uniterm ( fromGeneratorOp, Var(?a), myTerm )
Ruleset name Extending core meta model We add an attribute in the Ruleset class.
right statement Atomic Only one statement in the right part (Horn clause)
ruleset properties not supported
rule properties not supported Is the priority important for MISMO rules?

The way java invocation methods and Java library types (ArrayList) are mapped is not clear for the time beeing. Is it useful for MISMO rules and how to map them (add a new uniterm, dynamic or native arguments)?

Some binaru operators come from the XPath/XQuery library. Please refer to this specification for more details:http://www.w3.org/TR/xpath-functions/.

The previous rule is mapped as the following XML document.

<?xml version="1.0" encoding="UTF-8"?>
<Ruleset xmlns:aprif="http://apocrif/pr" xmlns:ns0="mismo"  
  xmlns:xpath="http://www.w3.org/2005/xpath-functions"   
  xmlns:xsd="http://www.w3.org/2001/XMLSchema">
 <name>IlrContext</name>
 <ProductionRule>
  <name>Occupancy_Adjustments_1</name>
  <declare>
   <Var type="ns0:root">r</Var>
  </declare>
  <if>
   <And>
    <Equal>
     <Uniterm>
      <Const type="xsd:QName">aprif:xmlGetter</Const>
      <Const type="xsd:QName">ns0:root</Const>
      <Const>division</Const>
      <Var type="ns0:root">r</Var>
     </Uniterm>
     <Const type="xsd:string">wholesale</Const>
    </Equal>
    <Equal>
     <Uniterm>
      <Const type="xsd:QName">aprif:xmlGetter</Const>
      <Const type="xsd:QName">ns0:root</Const>
      <Const>occupancy</Const>
      <Var type="ns0:root">r</Var>
     </Uniterm>
     <Const type="xsd:string">Investors</Const>
    </Equal>
   </And>
  </if>
  <constaints>
   <And/>
  </constaints>
  <then>
   <Uniterm>
    <Const type="xsd:QName">aprif:xmlSetter</Const>
    <Const type="xsd:QName">ns0:root</Const>
    <Const>occupancyAdjustment</Const>
    <Var type="ns0:root">r</Var>
    <Const type="xsd:decimal">0.95</Const>
   </Uniterm>
  </then>
 </ProductionRule>
</Ruleset>
RIF extension
In the next section, the alias aprif stands for “http://apocrif/pr”, and xpath for “http://www.w3.org/2005/xpath-functions”. 
 
  class Rule {
    subclass ProductionRule {
      property name: xsd:String
      property ifPart: Condition
      property constraintPart: AndCondition
      Property thenPart: ATOMIC
    }
  }

  Uniterm ::= XmlGetterOp | XmlSetterOp | VarConstraintOp | BinaryTermOp | UpdateOp | inGenereratorOp | fromGeneratorOp

  BinaryTermOp ::= NotEqualOp | GreaterOp | GreaterEqualOp | LowerOp | LowerEqualOp | PlusOp | MinusOp

  XmlGetterOp ::= 'aprif:xmlGetter' '(' XMLType ',' XmlField ',' TargetTerm ')'
  XmlSetterOp ::= 'aprif:xmlGetter' '(' XMLType ',' XmlField ',' TargetTerm, NewTerm ')'
  VarConstraintOp ::= 'mismo/pr/variableConstraint' '(' Var ',' Term, ')'
  UpdateOp ::= 'mismo/pr/updateOp' '(' TargetTerm ',' Uniterm ')'
  InGeneratorOp ::= 'mismo/pr/inGeneratorOp' '(' TargetTerm ')'
  OutGeneratorOp ::= 'mismo/pr/outGeneratorOp' '(' TargetTerm ')'
  NotEqualOp ::= 'aprif:ne' '(' Term ',' Term ')
  GreaterOp ::= 'xpath:numeric-greater-than' '(' Term ',' Term ')
  GreaterEqualOp ::= 'aprif:ge' '(' Term ',' Term ')
  LowerOp ::= 'xpath:numeric-lower-than' '(' Term ',' Term ')
  LowerEqualOp ::= 'aprif:le' '(' Term ',' Term ')
  PlusOp ::= 'xpath:numeric-add' '(' Term ',' Term ')
  MinusOp ::= 'xpath:numeric-substract' '(' Term ',' Term ') 

  XMLType ::= Const
  XMLField ::= Const
  TargetTerm ::= Term
  NewTerm ::= Term 
 
Rule mapping issue
  • There is no way to distinguish between the “equals” method and the “==” operator. We choose to implement them by the same Equal node in RIF.
  • After a round tripping, the structure of its condition may have change, although its semantic is kept unchanged.
  • Rule condition must be assigned to a variable to be represented in RIF: What about introducing anonym variables in RIF?
  • No ruleset variable in RIF. It is convenient to insert and retrieve data after the execution.
  • Some usual operators (le,ge,ne…) are not defined in the XPath function library.
  • There is a difference in JRules factory between a variable declaration and a variable value used in expression. Such a difference does not exist in RIF.
  • the meta-properties do not exist in RIF.
  • The MISMO schema introduces union type for representing numeric values. Such an XML construction is difficult to support by the Object Model binding. We change slightly for the need of the demo the schema by replacing some union by pure numeric type such as xsd:int or xsd:double. This difficulties will be studied later in next version of APOCRIF.
  • The in/from generator are commonly used inside left part of production rules to navigate in the model.It has been introduced in APOCRIF and represented has constraints on condition variables
  • Apocrif development state

    The 1.1 version is attached here: apocrif1.1.zip

    • we introduce some minor differences with RIF core. A Logical Rule class replaces the ForAll class. A Ruleset is named. The Or condition is not supported for the moment.
    • the RIF meta-model has been extended. A new ProductionRule class represents now a production rule. This class is composed of four important parts ( universal variable, if, constraints, then).
    • the round tripping has been tested against the two proposed rules translated into JRules
    • We choose to select some binary operators when existing from the XPath2.0 library: http://www.w3.org/TR/xpath-functions/
    • The modified MISMO schema is located at data/xsd/AUS_V2_4_modified.xsd.

    Modification to the schemas

    • BorrowerRequestedLoanAmount: type=“AUS_MISMOMoney” –> “xs:int”
    • RequestedInterestRatePercent: type=”AUS_MISMONumeric“ –> ”xs:double”
    • MORTGAGE_SCORE _Value: type=“xs:string” –> "xs:int”

    Current issues:

    • How to distinguish between the equals method and the ’==’ operator when a RIF expression is deserialized?
    • How to represent XML getter/setter of XML anonym type fields? using XPath expressions? beyond the scope of the demo?
    • What about considering that the common procedural model should be limited to Web Services, except some instructions such as insert, update, retract…?

    Last modified at 8/12/2010 11:17 AM  by PROD-SPOINT\administrator