Introduction

The UServ Product Derby Tutorial traces the UServ Business Rules Model 2005 from natural language descriptions based on core ontological concepts like classes and variables, to target rule systems like JBossRules 3.0.6 and JenaRules 2.5.3, via the R2ML 0.4 markup language.

The UServ business rules are expressed in a natural english language, and provide a scenario which emulates a complete vehicle insurance service. Its purpose is to compute the UServ annual premium for a vehicle insurance policy, which belongs to an eligible client.

In order to achieve this purpose, UServ divides its business rules into business rules sets, each of them addressing different goals and contexts i.e. calculates the eligibility scores in order to set the eligibility status for a client/driver/car, pricing and cancellation policies at client portfolio level.

UServ business rules address the OMG's Model Driven Architecture CIM level(Computation Independent Business Model - rules level dedicated to the language of business users).

The I1 Rules Framework model, serialize and deploy rules according with the following steps:

1. First step is to create an UML class diagram model to obtain the UServ vocabulary. At this stage a PIM (Platform Independent Business Model) is built. Rules are modeled vizually using Strelka. Strelka generates the R2ML serialization of UServ Business Rules, which includes the rules together with their vocabularies.
2. Next step is to use the R2ML-to-JBossRules translator and R2ML-to-Jena translator in order to obtain JBoss Rules translation, respectively Jena rules implementation.
3. Finally we use JBoss Rules and JenaRules executional platforms to execute the obtained UServ business rules.

UServ Business Rules Model

UServ Product Derby provide a concrete business rules sets separation on distinct categories of rules such as:

• Automobile Eligibility - which establishes the eligibility category for a car.
• Driver Eligibility - which sets the eligibility category for a driver.
• Eligibility Scoring - which determines the client's eligibility category based on a scoring system, by testing the risk ratings for: driver, car and client categories. If the client is eligible for vehicle insurance, then the annual premium is calculated.
• Automobile Premiums - which calculates the car premium, based on model year, fabrication year, medical or uninsured motorist coverage.
• Driver Premiums - calculates the premium for particular driver.
• Automobile Discounts - which lowers the car premium with specific procents, if the car has or not airbags or alarm system.
• Market Discounts - which lowers the total premium (sum of car premium and driver premium) based on client segmentation (elite or preferred).

View Rules Browser!

Consider the following three UServ business rules from Automobile Eligibility Set. As this rules belong to different rules subsets, the rules names are coded taking into account the auto attribute they need to set its value.

For example, Rule 1, whose name is AE_PTC04 belongs to the Automobile Eligibility - Potential Theft Rating Rules SubSet, in order to set the potentialTheftRating attribute of the car. In an analogous way, the Rule 2 belongs to the Automobile Eligibility - Potential Occupant Injury Rating Rules SubSet, and Rule 3 belongs to the Automobile Eligibility Rules SubSet.

From the natural language description view of the rules, we can identify all the objects referenced in the rules, its attributes and their constraints. The natural language description of the rules also provide the rules general structure, which comprises the rule name, the rule conditions and the rule conclusion:

rule-name
if
  //conditions
then
 //conclusion 

So, the UServ business rules needs a rule language, based on vocabulary, in order to be represented.

1. Rule 1: (AE_PTC04): If all of the following are true, then the car's Potential Theft Rating is moderate:
   • car's price is between $20000 and $45000.
   • car model is not on the list of "High Theft probability Auto".
2. Rule 2: (AE_POI04): If the car has driver's front passenger and side panel air bags, then the car's potential occupant injury is low.
3. Rule 3: (AE_04): If none of the following is true, then the auto eligibility is "eligible":
   • Auto eligibility is "not eligible"
   • Auto eligibility is "provisional"

In order to illustrate the translation process from CIM to PSMs, the above rules code is provided for each of next steps:URML model, R2ML serialization, JBoss Rules and Jena implementation.

Visual Rule Modeling using Strelka

Using Strelka, which is a rule modeling tool, we developed an URML model of business rules from UServ. Strelka allows visual rule modeling on top of UML vocabularies. We choose to modelate rules with Strelka tool, which is a visual modeling tool, instead of using other textual modeling tools, in order to facilitate the rules understanding and representation. In our case study we use the UServ vocabulary, depicted in Figure:UServ PIM.

The next step is to provide a serialization into the rule interchange format R2ML. Strelka tool is used to serialize rule models into the rule interchange format R2ML. Starting from this format by applying R2ML translators we obtain rules for different rule-based languages (i.e. JBoss Rules and Jena).

Notice that in the serialization process, the Strelka tool also generates the R2ML rule internal vocabulary. Every R2ML rule contains its own vocabulary, i.e. elements from the vocabulary xmlns:r2mlv="http://www.rewerse.net/I1/2006/R2ML/R2MLV".

The URML vocabulary of Rule 1, is depicted the Figure: AE_PTC04 URML Model

View complete UServ PIM Business Rule Model.

R2ML Markup

The generated R2ML markup from Strelka represents rules as formal statements, expressed in some formalism or computational paradigm,which can be directly mapped to executable statements of a software system.

Notice that R2ML is capable to express rules which don't require any conceptual changes in order to be implemented in PSM target platforms: rule systems such as JBoss Rules and semantic Web languages like Jena language.

In order to achieve this, R2ML has to comply Web naming concepts like (URI and Namespaces), datatype concepts of RDF and ontological distinction between objects and data. As an interchange language, R2ML addresses the PIM level.

An R2ML rule always refers to a vocabulary which can be R2ML own vocabulary or an imported one (RDF(S) and OWL). R2ML vocabulary is a serialization of an UML fragment of class diagrams. Below is an excerpt from Rule 1: AE_PTC04 vocabulary:

<r2ml:RuleBase xmlns:r2ml="http://www.rewerse.net/I1/2006/R2ML"
          xmlns:r2mlv="http://www.rewerse.net/I1/2006/R2ML/R2MLV"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xmlns:xs="http://www.w3.org/2001/XMLSchema" 
          xmlns:userv="http://www.businessrulesforum.com/2005/userv#" 
          xmlns:swrlb="http://www.w3.org/2003/11/swrlb"
          xsi:schemaLocation=http://www.rewerse.net/I1/2006/R2ML 
                             http://oxygen.informatik.tu-cottbus.de/R2ML/0.4/R2ML.xsd>
 <r2mlv:Vocabulary>
  <r2mlv:Class r2mlv:ID="Car">
   <r2mlv:Attribute r2mlv:ID="price">
    <r2mlv:range><r2mlv:Datatype r2mlv:ID="xs:integer"/></r2mlv:range>
   </r2mlv:Attribute>
   <r2mlv:Attribute r2mlv:ID="fabricationYear">
    <r2mlv:range><r2mlv:Datatype r2mlv:ID="xs:integer"/></r2mlv:range>
   </r2mlv:Attribute>
  </r2mlv:Class>
 </r2mlv:Vocabulary>
 <!-- ... -->
</r2mlv:RuleBase>

Modeled using OMG's Model Driven Architecture, R2ML offers support for: Derivation Rules, Production Rules, Reaction Rules and Integrity Rules

The UServ Product Derby Use Case rules are modeled as Production Rules. Below, we illustrate the Rule 1 R2ML serialization:

  <r2ml:ProductionRule r2ml:ruleID="AE_PTC04">
    <r2ml:conditions>
      <r2ml:DatatypePredicateAtom r2ml:datatypePredicateID="swrlb:lessThanOrEqual">
        <r2ml:dataArguments>
          <r2ml:TypedLiteral r2ml:datatypeID="xs:integer" r2ml:lexicalValue="20000"/>
          <r2ml:AttributeFunctionTerm r2ml:attributeID="userv:Car.price">
            <r2ml:contextArgument>
              <r2ml:ObjectVariable r2ml:name="car" r2ml:classID="userv:Car"/>
            </r2ml:contextArgument>
          </r2ml:AttributeFunctionTerm>
        </r2ml:dataArguments>
      </r2ml:DatatypePredicateAtom>
      <r2ml:DatatypePredicateAtom r2ml:datatypePredicateID="swrlb:lessThanOrEqual">
        <r2ml:dataArguments>
          <r2ml:AttributeFunctionTerm r2ml:attributeID="userv:Car.price">
            <r2ml:contextArgument>
              <r2ml:ObjectVariable r2ml:name="car" r2ml:classID="userv:Car"/>
            </r2ml:contextArgument>
          </r2ml:AttributeFunctionTerm>
          <r2ml:TypedLiteral r2ml:datatypeID="xs:integer" r2ml:lexicalValue="45000"/>
        </r2ml:dataArguments>
      </r2ml:DatatypePredicateAtom>
      <r2ml:AttributionAtom r2ml:attributeID="userv:CarModel.highTheftProbability">
        <r2ml:subject>
          <r2ml:ObjectVariable r2ml:name="carModel" r2ml:classID="userv:CarModel"/>
        </r2ml:subject>
        <r2ml:dataValue>
          <r2ml:TypedLiteral r2ml:lexicalValue="false" r2ml:datatypeID="xs:boolean"/>
        </r2ml:dataValue>
      </r2ml:AttributionAtom>
    </r2ml:conditions>
    <r2ml:producedAction>
      <r2ml:AssignActionExpression r2ml:propertyID="userv:Car.potentialTheftRating">
        <r2ml:contextArgument>
          <r2ml:ObjectVariable r2ml:name="car" r2ml:classID="userv:Car"/>
        </r2ml:contextArgument>
        <r2ml:TypedLiteral r2ml:lexicalValue="moderate" r2ml:datatypeID="xs:string"/>
      </r2ml:AssignActionExpression>
    </r2ml:producedAction>
  </r2ml:ProductionRule>

View complete R2ML code for Rule 2 and Rule 3.

JBoss Rules Experiences

JBoss Rules provide features due to which it makes a good choice for implementing such an application like UServ Product Derby Case Study:

• Separation of the business logic (the rules) from business data (the facts).
• Rule engine based on an enhanced version of Rete algorithm.
• Open-source, object-oriented production rules system written entirely in Java language.
• Light and easy to understood syntax.
• Easy to integrate into the application infrastructure.
• Collect complex decision-making logic and work with large data sets.

Test the UServ Product Derby Application using JBossRules!

The JBoss Rules syntax for UServ business rules is the following:

// Rule 1
rule "AE_PTC04"
      when
          $carModel:CarModel(highTheftProbability == false)
          $car:Car(carModel == $carModel, price >= 20000, price <= 45000)
      then
          $car.setPotentialTheftRating("moderate");
          modify($car);
end

// Rule 2
rule "AE_POIC04"
      when
          $car:Car(driverAirbag == true,passengerAirbag == true,
					         sideAirbag == true)
      then
          $car.setPotentialOccupantInjuryRating("low");
          modify($car);
end

// Rule 3
rule " AE_04"
      when
          $car:Car(carEligibility!= CarEligibility.NON_ELIGIBLE,
          carEligibility != CarEligibility.PROVISIONAL)
      then
          $car.setCarEligibility(CarEligibility.ELIGIBLE);
          modify($car);
end

These rules are obtained as an output of the R2MLtoJBoss translator. In our application, all UServ business rules are obtained via R2MLtoJBoss translator and encode the business logic for the UServ Product Derby application.

Below, we illustrate some data examples, provided by the UServ Product Derby Use Case. All this data is encoded in the Java beans of the application. They are matched against the rules, in order to execute them.

     // CarModel [hasHighTheftProbability, modelType] 
		 
     CarModel luxuryCarModel  = BeanFactory.createCarModel(false, ModelType.LUXURY);
     CarModel compactCarModel = BeanFactory.createCarModel(false,ModelType.COMPACT);
		 
     // Car [carName, fabricationYear, modelYear, hasAlarmSystem, price, hasRollBar,
     //      carModel, isConvertibleCar, hasDriverAirbag, hasPassengerAirbag, hasSideAirbag]
						 
     Car car1 = BeanFactory.createCar("Honda Odyssey", 2005, 2004, true, 39000, false, 
		                       luxuryCarModel, false, true, true, true);
     Car car2 = BeanFactory.createCar("Toyota Camry", 2002, 2003, false, 12000, false, 
		                       compactCarModel, false, true, true, false);	     

BeanFactory.createCarModel() and BeanFactory.createCar() are methods which creates instances of CarModel and Car Java beans classes.

We can easily see that car1 object will match all three rules:

The car1 object represents a Car instance. Once it is asserted into the knowledge base, it became a Car fact which is not a High Theft Probability car, its price is between 20000 and 45000 and has all airbags on bord therefore satisfies the rules conditions. Notice that the conditions of the third rule are satisfied too, because the carEligibility attribute of car1 is null i.e. neither NON_ELIGIBLE nor PROVISIONAL.

After the execution of the ruleset the car1 fact will have the potentialTheftRating attribute set to "moderate", and potentialOccupantInjuryRating attribute set to "low".

The car2 fact don't match any of the three rules.

Jena Experiences

Jena is a Java framework for building Semantic Web applications. It provides a programmatic environment for RDF, RDFS and OWL, SPARQL and includes a rule-based inference engine. We choose Jena platform/reasoning engine to build the UServ application because is open source and also an interoperable rule language for the semantic web, which allows us to develop the UServ Product Derby Case Study as a Semantic Web Application.

Test the UServ Product Derby Application using Jena Rules!

The Jena syntax for UServ business rules is the following:

// Rule 1
[AE_PTC04:  (?car rdf:type Car)
            (?car carModel ?carModel)
            (?carModel highTheftProbability 'false'^^xs:boolean)
            (?car price ?price)
            ge(?price,20000)
            le(?price,45000)
            ->
            (?car potentialTheftRating 'moderate')]

// Rule 2
[AE_POIC04: (?car rdf:type Car)
            (?car driverAirbag 'true'^^xs:boolean)
            (?car passengerAirbag 'true'^^xs:boolean)
            (?car sideAirbag 'true'^^xs:boolean)
            (?car convertible 'false'^^xs:boolean)
            ->
            (?car potentialOccupantInjuryRating 'low')]

// Rule 3
[AE_04:     (?car rdf:type Car)
            noValue(?car carEligibility 'not eligible')
            noValue(?car carEligibility 'provisional')
            ->
            (?car carEligibility 'eligible')]

The facts examples, provided by the UServ Product Derby Use Case are expressed in the RDF syntax:

 <userv:Car rdf:ID="car_1">
   <userv:Car rdf:ID="car_1">
    <userv:vehicleName>Honda Odyssey</userv:vehicleName>
    <userv:convertible rdf:datatype="xs:boolean">false</userv:convertible>
    <userv:fabricationYear rdf:datatype="xs:integer">2005</userv:fabricationYear>
    <userv:price rdf:datatype="xs:double">39000</userv:price>
    <userv:alarmSystem rdf:datatype="xs:boolean">true</userv:alarmSystem>
    <userv:driverAirbag rdf:datatype="xs:boolean">true</userv:driverAirbag>
    <userv:passengerAirbag rdf:datatype="xs:boolean">true</userv:passengerAirbag>
    <userv:sideAirbag rdf:datatype="xs:boolean">true</userv:sideAirbag>
    <userv:carModel>
      <userv:CarModel>
        <userv:modelType>luxury</userv:modelType>
        <userv:highTheftProbability rdf:datatype="xs:boolean">false</userv:highTheftProbability>
      </userv:CarModel>
    </userv:carModel>
  </userv:Car>
  
  <userv:Car rdf:ID="car_2">
    <userv:vehicleName>Toyota Camry</userv:vehicleName>
    <userv:convertible rdf:datatype="http://www.w3.org/2001/XMLSchema#boolean">false</userv:convertible>
    <userv:fabricationYear rdf:datatype="http://www.w3.org/2001/XMLSchema#integer">2002<    
        /userv:fabricationYear>
    <userv:price rdf:datatype="http://www.w3.org/2001/XMLSchema#double">12000</userv:price>
    <userv:driverAirbag rdf:datatype="http://www.w3.org/2001/XMLSchema#boolean">true</userv:driverAirbag>
    <userv:passengerAirbag rdf:datatype="http://www.w3.org/2001/XMLSchema#boolean">true< 
        /userv:passengerAirbag>
    <userv:sideAirbag rdf:datatype="http://www.w3.org/2001/XMLSchema#boolean">false</userv:sideAirbag>
    <userv:alarmSystem rdf:datatype="http://www.w3.org/2001/XMLSchema#boolean">true</userv:alarmSystem>
    <userv:carModel>
      <userv:CarModel>
        <userv:modelType>compact</userv:modelType>
        <userv:highTheftProbability rdf:datatype="http://www.w3.org/2001/XMLSchema#boolean">false< 
           /userv:highTheftProbability>
      </userv:CarModel>
    </userv:carModel>
  </userv:Car>

The car_1 and car_2 objects represents Car instances. They are the facts from the Jena Application knowledge base. As same as in the JBoss Rules examples, only the car_1 fact matches the rules, causing their execution.

Copyright © 2006 Some rights reserved.

This page is maintained by Oana Nicolae, Mircea Diaconescu and Adrian Giurca. Last update September 24, 2007