A Scalable Rule Engine Architecture for Service ...

Download PDF
6 downloads 15172 Views 648KB Size Report
Comment
Buy(C, P) & R > Rs. 50,000. Then Generate Discount(10%) on P. End Rule. Rule 2. Category Samsung: If Customer(C) & Product(Laptop) & ...
A Scalable Rule Engine Architecture for Service Execution Frameworks Soumi Chattopadhyay1 , Ansuman Banerjee1 , Nilanjan Banerjee2 1 Indian Statistical Institute Kolkata, 2 IBM Research India {soumi r, ansuman}@isical.ac.in, [email protected] Abstract— Rule engines form an essential component of most service execution frameworks in a Service Oriented Architecture (SOA) ecosystem. The efficiency of a service execution framework critically depends on the performance of the rule engine it uses to manage it’s operations. Most common rule engines suffer from the fundamental performance issues of the Rete algorithm that they internally use for faster matching of rules against incoming facts. In this paper, we present the design of a scalable architecture of a service rule engine, where a rule clustering and hashing based mechanism is employed for lazy loading of relevant service rules and a prediction based technique for rule evaluation is used for faster actuation of the rules. We present experimental results to demonstrate the efficacy of the proposed rule engine framework over contemporary ones.

I. I NTRODUCTION Enterprises today need to be agile in order to sense and predict change in their environment and respond quickly, efficiently and effectively to the changes. Service Oriented Architecture (SOA)[1] has been widely accepted by the industry for the development of a new breed of cross-enterprise applications that are comprised of loosely coupled services, and hence are capable of being modified and/or extended on the fly. The loosely coupled services are self describing, platform-agnostic computational elements that support low-cost composition of distributed applications. In recent years, the SOA ecosystem has seen a number of proposals of service execution frameworks. Business processes are expressed as service rules and business rule management systems (BRMS) are employed to allow enterprise architects to separate the concerns in an aspect-oriented way and easily define, manage, update and run the decision logic that directs enterprise applications inside a rule engine without needing to write code or change the business processes calling them [2][3][4][5]. This enables modern businesses to change their business rules dynamically in order to adapt to a rapidly changing business environment, and they contribute to agility in SOAs by enabling reduced time to automate, easier change, and easier maintenance for business policies and rules. In this paper, we propose the design of a scalable rule engine that can be seamlessly adopted inside a standard service execution flow. We address the main limitations in contemporary matching algorithms based on the Rete [6] algorithm and propose an enhanced rule engine framework that enables faster end to end execution. Our proposal has the following key contributions.

A simple preprocessing step that creates rule clusters in a given business rule repository based on certain parameters. This in turn helps in faster rule loading by filtering out the irrelevant rules and loading the relevant ones for evaluation, based on the arriving facts. • A simple predictive model of execution for triggering faster actuations. This, on the other hand, serves as the basis for an efficient rule evaluation ordering based on their chances of being evaluated to true. We did an experimental evaluation of our proposal on manually created service rule sets for MakeMyTrip [16] and Flipkart [17] and compared our performance with rule engines that are based on the Rete evaluation paradigm. Performance results indicate that our proposal is effective. •

II. M OTIVATION FOR THIS WORK Figure 1 shows the general architecture [3] of a service execution framework with an embedded business rule engine that forms the core of the execution framework. The rule engine is highlighted and magnified to show the internal component level details as commonly found in most classical rule engine architectures [7][8] in a variety of domains [9][10]. The rule repository stores the rules usually designed by a domain expert. These business rules are loaded into the production memory for evaluation which are then pushed into the evaluation queue. Facts, or in other words, input data / business events from the environment (which arrive in real time on a case to case, situation to situation basis or are derived from rule actuations), are handled in the working memory. These facts can also be passed on to the production memory for training rule sets, as may be helpful in certain contexts. The facts can be stored or streamed from distributed sources. The inference engine matches / evaluates the rules against the facts in memory. In a usual case, multiple rules are affected by the same set of facts, and have to be actuated in response. Classical rule engine evaluation paradigm : We discuss below the traditional evaluation paradigm on a simple intuitive example. Consider the set of business rules as shown in Example 2.1 that may constitute the customer handling logic in a business rule repository. Each rule has a triggering condition (also called an antecedent), based on the truth of which, the action (also called the consequent) of the rule is performed.

Rule

Repository Business Process

Rule engine internals

. . . Decision logic

Rule Engine

Production Memory

Working Memory

.. .

Facts

Inference Engine

Service Execution Framework

R1 R2 ... Rk Queue

(Rules are scheduled)

Pattern Matcher Rule Evaluates to True

Start Actuation Fig. 1.

Rule Evaluates to False

Do Nothing

Rule Engine Architecture

Example 2.1: Consider the following rules: Rule 1: If a customer buys products more than three times in a year from Adidas, the customer is recorded as an Adidas high valued customer Rule 2: If a new product is lauched by Adidas, announce a special weekend sale on the product Rule 3: If long weekend is ahead, announce a special sale on travel bags Rule 4: If a customer purchases products worth more than Rs 15000 from Adidas, activate a special discount Rule 5: If it is Christmas time, Nike gives upto 50% discount on purchase of their products Rule 6: If it is Summer, Nike gives upto 25% discount on purchase of their old stock on hiking shoes We consider the following facts arrive in working memory. Fact 1: Customer: John, Fact 2: John wants to buy a shoe, Fact 3: Company: Nike, Fact 4: Christmas time A classical rule engine will usually load all the rules in the main memory for evaluation inside the inference engine against the facts. The time required to load the rules in main memory is called the rule set loading time, improvement of which is one of the objectives of this work. Once the rules are loaded into memory, they are usually evaluated sequentially one after another in a uniprocessor environment, or maybe in parallel in a multiprocessor-based support system. If the antecedent of a rule is evaluated to true based on the facts in

the working memory, the actuation corresponding to the rule is performed, which we term as rule firing or rule actuation. The time from when the evaluation starts to the time when the last rule, which is evaluated to true is fired, i.e. antecedent of the rule is evaluated to be true, is the rule set firing time or rule set actuation time. A session is a time period during which multiple facts come to the working memory and the already loaded rules are evaluated against the facts. The time required to evaluate all the rules in a session is called the rule set evaluation time. It is interesting to note that the rule set actuation time is less than or equal to the rule set evaluation time, since the last rule in the evaluation queue may evaluate to false. On our working example, Rules 1 to 6 would be examined in sequential order and based on the arriving facts, Rule 5 would be declared as true, while the rest as false. Most of the commonly used rule engines are based on the Rete [6] algorithm for pattern matching. A significant amount of memory is typically required to build a Rete tree containing a large number of rules, since all rules are loaded in production memory before the pattern matching starts. Consequently, the rule loading time increases. This is what we propose to improve in this work by selective rule loading. Our method at work: We now discuss how our method works in this case. It can be noted that rules 2 and 3 do not need to be loaded at all, since none of the facts affecting them have arrived. This gives us the motivation of selective rule loading, which is one of the key contribution of this work. The selective loading is backed up by different clustering mechanisms. Instead of matching all the rules against the facts individually, we can cluster the set of rules so that only a subset of the rules is affected by a fact and we do not need to check each rule individually to figure out if the rule is affected by a given set of facts or not. This saves in rule loading time. An intuitive clustering of the rule set based on rule fact predicate attribute is as follows: Rule 1, Rule 4, Rule 5, Rule 6 are affected by the predicate set Customer, Product, Purchase, Discount,

Time, HighValuedCustomer, Price and are therefore kept in one cluster, while Rule 2, Rule 3 having the predicate set LaunchedProduct, Sale are put in another cluster. We discuss in the following section how this notion of predicate attribute based clustering is used in practice. Furthermore, if we cluster the set of rules based on categories like company, product, range of purchase etc., we get even more benefits in terms of rule loading. In this example, we have 3 clusters as follows, considering the brand as the category. The first cluster contains Rule 1, Rule 2 and Rule 4 and the corresponding brand is Adidas. The second cluster contains Rule 3 without having any brand and the third cluster contains Rule 5 and 6, the corresponding brand is Nike. In this case, to serve the arriving facts, loading only Rules 5 and 6 is sufficient, i.e., we can load only cluster 3. The other important highlight of this paper is the proposal of outcome prediction to influence the rule evaluation order. This is done based on certain attributes, either at the individual rule level or at the level of the cluster to which it belongs. The prediction feature essentially attempts to predict the outcome of a given rule apriori, which in turn influences the rule evaluation order. The basic insight of our proposal is that rules which have more chances to be evaluated to true, if loaded into the evaluation engine early can lead to faster actuations of their effects if actually found to be true on the incoming facts. In this case, if we can predict that Rule 5 has a higher chance to be evaluated to true, we put it ahead of others in the evaluation queue and therefore benefit in the actuation time. This is what our prediction schemes aim to achieve. III. P ROPOSED A RCHITECTURE Figure 2 shows an architectural view of our proposed rule processing framework. We begin by formalizing the notion of a rule. A number of research articles in literature have proposed different formalisms for capturing the rules in different fragments of mathematical logic and their derivatives, for efficient processing and comprehension. In this paper, we adopt a simple intuitive formalism that makes itself amenable to easy analysis and illustration. A popular formalism for expressing the rules in the service community is in the form of If-Then statements as we describe below. Definition 3.1: Rule: A rule is an expression of the form: [Category] : hIf i, hT heni where the If component constitutes the rule antecedent and the Then component specifies the resulting actuation performed when the antecedent is satisfied. The Category is an optional part of a rule specifying the state of the fact world in which the rule is to be applied.  The rule antecedent is specified using first order predicate logic operators [11]. Each rule has a set of predicates defined over the fact variables. We have restricted this work to this logic fragment for simplicity of illustration and inspired by the fact that most rule engines employed in this community

work on similar rules. However, our approach is generic enough and can be seamlessly extended to rule sets captured in higher order logics or their derivatives. The following example illustrates our formalization. Example 3.1: In the following, we show two different representations of Rule 5 (given in Example 2.1). Rule If Customer(C) & Product(P) & Brand(P, Nike) & Buy(C, P) & ChristmasTime (true) Then Get Discount(50%) on P End Rule Rule Category Nike: If Customer(C) & Product(P) & Buy(C, P) & ChristmasTime(true) Then Get Discount(50%) on P End Rule A fact arrives in the working memory either from the environment or it is deduced by a rule. The fact is used to reason by the rule engine. A fact creates an instantiation of a predicate. Example 3.2: Consider the rules in Example 3.1. We may have the following as example facts for this rule. Customer(John), Product(shoe), Brand(shoe, Nike), Buy(John, Shoe), ChristmasTime(true).

When facts arrive in the system, a new session is started. We assume that the facts arrive synchronously in batches and are aggregated at session boundaries. For each session, rules are evaluated with the set of collected facts, and if a rule is found to be true in that session, the actuation for the rule is triggered immediately. The formal setting of a rule evaluation engine E is as follows. We are given: • A set of rules R = R1 , R2 , . . . , Rn , defined in the production memory of E. • A set of facts F = F1 , F2 , . . . , Fk in the working memory. Our proposal is to: • Load rules selectively in memory using clustering, to reduce loading time. • Expedite the rule actuation process using prediction. The above two techniques may appear to be independent; however, as we explain below, there is a strong correlation between them. The clustering technique, in fact, enhances the prediction mechanism. The way our clusters are formed facilitates the prediction step, based on the observation that if one fact can affect an element of a cluster, we can apply the prediction on other rules in the same cluster as well. The basis of clustering indicates that rules within a cluster have some similarity, and this is what the prediction step can exploit at a cluster level. The rule clustering step is done in preprocessing time, whereas we use prediction at runtime during the evaluation of the rule set. In the next two subsections, we elaborate our proposal in more detail.

Rules

Production Memory (Rules from Clusters)

Clustering Unit Clusters

Facts

Rules Working Memory

Prediction Unit Inference Engine

R1 R2 ... Rn Queue (Rules are scheduled)

Pattern Matcher Rule Evaluates to True

Start Actuation

Fig. 2.

...

Facts

Facts

Rule Evaluates to False

Do Nothing

Proposed Rule Engine Architecture

A. Clustering of Rules for Efficient Loading We first describe the cluster-based rule loading technique. The rule set is preprocessed and divided into different clusters, based on some similarity metrics. Clustering of rules enables lazy loading of rules and only relevant clusters of rules are loaded into memory, thereby reducing memory usage and potentially expediting the pattern match in the Rete tree. There is a preprocessing overhead for clustering the rules. However, the preprocessing overhead does not affect the runtime performance, which makes our approach an attractive proposal. In the worst case, however, based on the similarity metric we may also end up with only one cluster containing all the rules. In this section, we propose two rule clustering techniques, namely, structural and category-based clustering. As discussed earlier, we have a set of rules defined over a set of fact variables. The objective of this step is to produce rule clusters, such that elements in the same cluster have a higher chance of having similar actuation outcomes, based on the similarities in the fact variables they share. Structural clustering: In the structural clustering scheme, two rules having a common fact variable in their antecedents are put in the same cluster. The clusters are mutually exclusive, i.e., no two clusters contain the same rule. This ensures that at a time, only the rules in one cluster are affected by each fact and only that cluster gets loaded into the production memory for that fact. Let R = {R1 , R2 , . . . , Rn } be the set of rules. The antecedent of the rules are defined over a set of predicates P = {p1 , p2 , . . . , pk }. We present below an intuitive description of the structural clustering scheme in Algorithm 1. The essential idea is to start with a random cluster with a single rule and then grow it with other rules joining in based on fact variable overlap. The overlap is computed transitively. Once we reach a fix point, i.e., no new rule can join the current cluster, we start off with the formation of the next cluster around another set of fact variables. We now explain the working of our algorithm on Example 2.1 with 6 rules described earlier. We begin by arbitrarily choosing Rule 1 and putting it inside a new cluster C1 , and

Algorithm 1 Structural Clustering 1: Input: Set of Rules R = R1 , R2 , ..., Rn 2: Output: A set of clusters C = C1 , C2 , . . . , Ck 3: i = 1; 4: while no rule left do 5: Ci ←− Rj ; /∗ Pick any Rj from the current rule set R∗/ 6: R ←− R − Rj ; /∗ Delete Rj from R ∗/ 7: Pi ←− predicates appearing in rules in cluster Ci ; 8: repeat 9: Ci ←− Ci ∪ Rk ∈ R; /∗ Pick any Rk having a predicate contained in Pi ;∗/ 10: Add the predicates appearing in Rk to the current predicate set Pi for Ci ; 11: R ←− R − Rk ; /∗ Delete Rk from R ∗/ 12: until No new rules are added 13: i = i + 1;/∗ Initially Ci , Pi are empty∗/ 14: end while

start examining the other rules. Based on fact variable overlap, we can easily see that we can grow the cluster with Rules 4, 5 and 6, since they have overlapping fact variables with Rule 1. We therefore have a cluster C1 with four rules at the end of the first iteration of the while loop. We cannot grow this cluster further, and hence, we proceed with the formation of a new one. We take up the next unexamined rule, Rule 2, and start building another cluster around it. This cluster contains Rule 2 and 3. Thus, we end with two clusters, which are mutually exclusive and span the entire rule set we started with. Category based clustering: We now describe the other clustering scheme. The set of rules that are associated with a category can be clustered together as well. As indicated earlier, the category captures the condition of the fact world, at which a particular rule is expected to be actuated. The motivation behind the category based clustering strategy is to put in rules with the same category indicators together, which essentially signifies that all these rules are expected to be actuated together in a category when facts matching their category arrive. Consider the rule set shown in Example 3.3. Assuming product brands as category indicators for the rules and applying the category similarity based clustering scheme, we put the first two rules in one cluster, and the third in another. Example 3.3: Consider the following rules: Rule 1 Category Samsung: If Customer(C) & Product(P) & Price(P, R) & Buy(C, P) & R > Rs. 50,000 Then Generate Discount(10%) on P End Rule Rule 2 Category Samsung: If Customer(C) & Product(Laptop) &

Price(Laptop, R) & R > Rs. 65,000 Then Add a headphone free of cost free in the cart End Rule Rule 3 Category Lenovo: If Customer(C) & Product(P) & Price(P, R) & Buy(C, P) & R > Rs. 40,000 Then Add a mouse in free of cost into the cart End Rule The category-based clustering algorithm is simple and similar to the one described for structural clustering, the only difference being that in this case, the clustering is done around the category. It can be noted that every rule in this clustering does not require to have a category. Therefore the rules having no categories are considered to be in a default category. The formal algorithm is shown in Algorithm 2. Algorithm 2 Category based Clustering 1: Input: Set of Rules R = R1 , R2 , ..., Rn 2: Output: A set of clusters C = C1 , C2 , . . . , Ck 3: The rules that have no category, add a category as Default; 4: For every category Si create a cluster Ci ; 5: for Rule Ri ∈ R do 6: if Ri has category Sj then 7: Put Ri in Cj ; 8: end if 9: end for B. Predictive Rule evaluation We now describe the second key element of our proposal, namely the predictive actuation and the algorithms that enable it. Prediction is done at the time of rule evaluation. When facts comes into the system, we wish to predict which rules are expected to be evaluated to true against them and schedule them for early evaluation. We describe two prediction schemes: deterministic and probabilistic. Once the appropriate clusters are loaded into the production memory, the rules are evaluated against the facts in the working memory. Instead of evaluating the rules sequentially, we predict which rule is likely to be evaluated to be true and we generate the rule evaluation sequence accordingly. A naive prediction scheme would in turn increase the overall rule evaluation time due to the sequence computation step, we address this issue by overlapping this latency of evaluation and prediction by pipelining the processing of the evaluation queue. Once a rule is predicted to be true, it is scheduled for evaluation immediately. After the evaluation is done for all the rules that are predicted to be true, the rule engine evaluates the rules that are predicted to be false. It can be noted that the overall rule set evaluation time remains the same as in the normal evaluation process. However, early evaluation of

some of the rules which actually turn out to be true, helps in triggering their actuations earlier. The essential idea behind predictive evaluation is to store for each rule, some amount of information relating to its past evaluation outcomes on different fact valuations. The more the amount of history we store, better is the chance of an accurate prediction. We describe below a few choices that we employed and found to be useful, the basic difference being the amount of information being stored in history for future predictions. Instead of storing fact valuations, we store rule evaluation outcomes, which makes our scheme a light-weight proposition. We now discuss four different prediction schemes. Prediction based on Single history: This is a simple prediction mechanism. In this scheme, only the last evaluation outcome of a rule is stored in history. In this case, we use two prediction schemes. •

•

Deterministic prediction: If a rule R is true in the previous session, then R is predicted to be true in the next session in which it is loaded. Probabilistic prediction: If a rule R is true in the previous session, then R is predicted to be true with a probability 0.5 in the next session in which it is loaded.

Prediction based on Multi-history: In this case, we store the last x preceding outcomes for each rule. Here as well, we adopt two prediction schemes. •

•

Deterministic prediction: If a rule has been evaluated to true more than 50% of the time in its saved history of its last x outcomes, it is predicted to be true in the next session in which it is loaded. Probabilistic prediction: Here the rule is predicted to be true with a probability proportional to its number of occurrences in the saved history. If a rule evaluates to true y times, it is predicted true with probability y/x.

The intuition behind the multi-history prediction schemes is the fact that if a rule is frequently evaluated to true in previous execution sessions, it has high chances to be true in the current evaluation as well. The scheme below considers the rule-fact affinity in its prediction mechanism. Prediction based on predicate history: Let R be a rule containing a predicate p. Let us assume, p is encountered α number of times, of which R is evaluated to true β times. We store, History(R, p) = (α, β). This is done for all the predicates appearing in the rule. We now have the following: •

•

Deterministic prediction: Given a fact set that triggers an instantiation of the predicate p and History(R, p) = (α, β), a rule R is predicted to be true, if β/α > T , where T is a given threshold. Probabilistic prediction: In this case the same prediction is done with probability β/α.

Prediction based on clustering: In this prediction scheme, we discuss how a simple clustering technique is used in rule outcome prediction. The idea is to use sub-expression matching based clustering (as described in Algorithm 3), using the idea of overlapping predicates as the similarity metric. We consider the antecedent of the rule in CNF [12] form. If not, we adopt appropriate transformations to convert it into CNF form. We now define the concept of the matching index (MI). Definition 3.2: Matching Index: The matching index of a rule R2 with respect to a rule R1 is defined as follows: M I(R1 , R2 ) =

N umber of predicates common between R1 and R2 N umber of predicates in R2

It is intuitively obvious that M I(R1 , R2 ) may not always be equal to M I(R2 , R1 ), since they may have different number of predicates. Example 3.4: Consider the two rules, R1 = p1 & p2 & p3 ; R2 = p1 & p2 & p4 & p5 & p6 . In this case, M I(R1 , R2 ) = 2/5, while M I(R2 , R1 ) = 2/3. Algorithm 3 Sub Expression Matching Based Clustering 1: Input: Set of Rules R = R1 , R2 , ..., Rn 2: Output: A set of clusters C = C1 , C2 , . . . , Ck 3: i = 1; 4: while no rule left do 5: Ci ←− Rj ∈ R, where Rj is not included in any cluster; 6: repeat 7: Select a Rule Rl from Ci which is not yet selected; 8: Calculate M I(Rl , Rk ) and M I(Rk , Rl ); 9: If any one of them is greater than 0.5, include Rk in Ci ; 10: until No new rules are added 11: i = i + 1; 12: end while Based on the matching index, we compute the clusters as described in Algorithm 3. For each cluster, we compute a cluster head, which identifies the rule sharing the maximum amount of similarity with its peers inside the same cluster. We compute that as follows: For a given cluster Ci , for each Rule Rj ∈ CiP , we compute the cumulative pair wise similarity measure γ = Rj 6=Rk ,Rk ∈Ci M I(Rj , Rk ). The rule with the highest value of γ is designated as the cluster head. We now use the cluster head as the first rule to predict and put it in the front of the evaluation queue while processing a particular cluster. When a set of facts come in, multiple clusters are triggered. For each cluster, we take the head and evaluate it. Depending on the evaluation we start our prediction, as below. •

•

Deterministic Prediction: Consider a rule R1 with R1 6= H and M I(H, R1 ) > T1 where T1 is a threshold. If H is true and M I(H, R1 ) > T1 , we predict R1 as true. Probabilistic Prediction: Consider M I(H, R1 ) = m. If H is true, with probability m, we predict R1 to be true.

The intuition behind this prediction scheme is, if a rule R is evaluated to true, another rule R1 , which has high matching index with R, has more probability to evaluate as true. Hence, we predict R1 to be evaluated to true as well, and push it towards the front of the evaluation queue. Consider the cluster generated by the category based clustering for the rule set in Example 3.3. In this case R1 and R2 were put into the same cluster. In this case, MI(R1 , R2 ) is 0.75 and MI(R2 , R1 ) is 0.6. Hence R1 is considered as the cluster head and hence put in the front of the evaluation queue. IV. E XPERIMENTAL R ESULTS We implemented the proposed architecture on top of JRuleEngine [13]. The rule repository was provided using the ILOG [14] description syntax which is the default input format for JRuleEngine. We evaluated its performance on two generated datasets. For our experimentation, we collected a sample of representative sessions executed by a few colleagues. Also we studied the purchase hints given by Flipkart and MakeMyTrip in different representative transaction sessions. Based on this, we modelled representative rule sets. The facts were also derived similarly. This reverse engineering approach of generating rule set was quite useful in practice and gave us an appropriate use case to demonstrate our proposal. For Flipkart, 20 rules were created and 9 different fact sets were used for experimentation. For MakeMyTrip, similarly 30 different rules and 10 different fact sets were created. We used these generated data as the experimental data set for evaluating both our proposals, namely, that of selective rule loading and predictive evaluation. Table I shows a comparison of the number of rules loaded for both the rule sets in the normal scheme (without clustering) and in our scheme (with clustering). As we can see, our proposal outperforms a normal rule loading scheme in all the cases in terms of the number of rules loaded in memory. All experiments were performed on a Intel Core i3 machine with 4 GB RAM. The preprocessing time for cluster generation for Flipkart and MakeMyTrip rule sets were around 15 ms and 29 ms respectively. The rule loading time incurred by our method was in the order of ms as well. The thresholds T and T1 were set to 0.5 and 0.85 respectively in our experiments. Figure IV(a),(b),(c) and (d) shows a comparative plot of the rule set actuation time obtained by the normal scheme (without clustering and prediction) and our proposed four different prediction schemes, namely, deterministic single bit history (DSH), probabilistic single bit history (PSH), deterministic multi bit history (DMH), probabilistic multi bit history (PMH), deterministic predicate based history (DPH), probabilistic predicate based history (PPH), deterministic prediction based on clustering (DPC) and probabilistic prediction based on clustering (PPC) for Flipkart with different fact sets. Figure IV(e),(f),(g) and (h) show the corresponding results for the MakeMyTrip rule and fact sets. As we can see from the results, our prediction mechanisms outperform the normal scheme for most of the cases. The fact that rules indeed have a similarity in outcomes across sessions

TABLE I C OMPARISON BETWEEN THE NO . OF RULES LOADED ON BOTH THE DATA SETS No. of rules loaded into memory for Flipkart data set

F1 20 18

Fact Set Normal Scheme Clustering Scheme

F2 20 18

F3 20 18

F4 20 18

F5 20 18

F6 20 18

F7 20 18

F8 20 1

F9 20 17

F8 30 26

F9 30 26

F10 30 26

No. of rules loaded into memory for MakeMyTrip data set

Fact Set Normal Scheme Clustering Scheme

F1 30 26

F2 30 26

F3 30 26

is thus clearly evident from the experiment. This is what makes our proposal an attractive proposition for practical use for large rule sets and continuously arriving diverse fact sets. The fact sets being arbitrary, the normal scheme does perform better in some cases (though very few) as well. Our prediction scheme being speculative and dependent on history, we pay the cost of mis-prediction and hence lose out to the normal scheme on a few cases. Intuitively, this happens for some rules (originally higher in the sequential order in the rule repository) which we predict to be false and push them to the back of the evaluation queue, thereby delaying their actuations. These rules actually evaluate to true. Hence in a sequential order of evaluation, their actuations are triggered much earlier. V. R ELATED W ORK In the service execution paradigm, the overall performance of the enterprise services delivered depends crucially on the performance of the rule engine used for handling the manipulation of the rules present in the business rule repository. Most popular service rule execution frameworks based on JRuleEngine [14], Drools [15] use the classical Rete [6] algorithm for faster matching of rules against incoming facts or business events. A number of proposals exist in literature [18][19][20][21][22] that aim to improve the performance of rule evaluation with efficient strategies for pattern matching. Significant research has been conducted on efficient rule engine design [23][24][25][26][27][28]. In [29], the authors present effective priority rules design so that good solutions are constructed within very short time using problem-specific knowledge. In [30], the authors present an improvement of the Rete algorithm based on double hash filter and node indexing to decrease the response time of the application system. Rete based rule engines have been found to suffer from scalability issues during the loading of the rule sets [31][32]. Larger the rule set, larger is the memory requirement for the Rete tree and larger is the time required for matching a rule with the incoming facts. This makes the operation gradually slow and makes it unsuitable for large-scale deployment. In this work we try to address this issue. VI. C ONCLUSION In this paper, we have proposed two mechanisms that can expedite the performance of a business rule engine. On one hand, we proposed selective rule loading using clustering and

F4 30 1

F5 30 26

F6 30 26

F7 30 26

fact based filtering. On the other hand, we proposed prediction mechanisms for rule set evaluation ordering. We believe that our methods can be seamlessly adopted inside a classical service execution flow and open up multiple avenues of future research in this direction. Our method is generic enough to be adopted in any rule engine setting. As future work, we are examining the notion of concurrency in our predictive execution framework. R EFERENCES [1] R. Perrey, M. Lycett, “Service-oriented architecture”, Applications and the Internet Workshops, 2003. [2] Paschke, Adrian and Teymourian, Kia and Web, AG Corporate Semantic, “Rule Based Business Process Execution with BPEL+”, I-SEMANTICS, 2009. [3] Florian Rosenberg, Schahram Dustdar, “Business rules integration in bpel-a service-oriented approach”, E-Commerce Technology, 2005. CEC 2005. [4] Hans Weigand and van den Heuvel, Willem-Jan and Hiel, Marcel, “Rule-based service composition and service-oriented business rule management”, ReMoD, 2008. [5] Adrian Paschke and Alexander Kozlenkov, “A Rule-based Middleware for Business Process Execution”, Multikonferenz Wirtschaftsinformatik, 2008. [6] Charles L. Forgy. 1991. “Rete: a fast algorithm for the many pattern/many object pattern match problem”. IEEE Computer Society Press, pp. 324-341. [7] F. Ongenae, “Towards computerizing intensive care sedation guidelines: design of a rule-based architecture for automated execution of clinical guidelines”, BMC Medical Informatics and Decision Making, 2010. [8] K. Verlaenen, Arriclides: “An Architecture Integrating Clinical Decision Support Models”, HICSS 2007. [9] S. Chattopadhyay et. al., “A Scalable Architecture for Rule Engine Based Clinical Decision Support Systems”, MedInfo 2015. [10] Berlin et al., “A taxonomic description of computer-based clinical decision support systems”, Journal of Biomedical Informatics, 2006. [11] First order predicate logic, http://en.wikipedia.org/wiki/ First-order_logic [12] M. Morris Mano, Digital Logic & Computer Design, Pearson India , 2004. [13] JRULEENGINE: http://jruleengine.sourceforge.net/ [14] ILOG: http://www-01.ibm.com/software/info/ilog/ [15] DROOLS: http://www.drools.org/ [16] MakeMyTrip: http://www.makemytrip.com [17] Flipkart: http://www.flipkart.com [18] Yu-Wang Wang et. al., “A Performance Comparison of the Rete and TREAT Algorithms for Testing Database Rule Conditions”, Proceedings of the Eighth International Conference on Data Engineering, 1992. [19] Hanson, Eric N., “Rule Condition Testing and Action Execution in Ariel”, Proceedings of the ACM SIGMOD, 1992. [20] Srdjan Komazec et. al., “Continuous Schema-enhanced Pattern Matching over RDF Data Streams”, DEBS, 2012. [21] Srdjan Komazec and Davide Cerri, “Towards efficient schema-enhanced pattern matching over RDF data streams”, Proceedings of the First International Workshop on Ordering and Reasoning, 2011.

(a)

(b)

(c)

(d)

(e)

(f)

(g)

(h)

Fig. 3.

Comparison of rule set actuation time for Flipkart data set (a),(b),(c),(d) and for MakeMyTrip data set (e),(f),(g),(h)

[22] Kirsten Terfloth et. al., “Facts-a rule-based middleware architecture for wireless sensor networks”, Communication System Software and Middleware, 2006. Comsware 2006. First International Conference on, 2006. [23] Yan Sun, et. al., “Efficient Rule Engine for Smart Building Systems”, IEEE TC, vol.64, no. 6, pp. 1658-1669, June 2015. [24] M. P. R. Sai Kiran et. al., “Adaptive rule engine based IoT enabled remote health care data acquisition and smart transmission system”, Internet of Things (WF-IoT), pp. 253-258, 2014. [25] Ziqin Yin et. al., “A Service-Oriented Business Rules Designer Based on Rule Engine”, ICFCE, pp. 675–682, 2011. [26] Stijn Hoppenbrouwers et. al., “Agile Service Development: A RuleBased Method Engineering Approach”, Engineering Methods in the Service-Oriented Context - 4th IFIP WG 8.1 Working Conference on Method Engineering, pp. 184–189, 2011. [27] Beibei Hu et. al., “A rule engine for relevance assessment in a contextualized information delivery system”, International Conference on

Intelligent User Interfaces, pp. 343–346, 2011. [28] Luciano Baresi et. al., “Self-healing BPEL processes with Dynamo and the JBoss rule engine.” International workshop on Engineering of software services for pervasive environments: in conjunction with the 6th ESEC/FSE joint meeting. ACM, 2007. [29] Alena Otto, Christian Otto, “How to design effective priority rules: Example of simple assembly line balancing”, Computers & Industrial Engineering, pp. 43–52, 2014. [30] Tianyang Dong et. al., “An Improved Rete Algorithm Based on Double Hash Filter and Node Indexing for Distributed Rule Engine”, IEICE Transactions, pp. 2635–2644, 2013. [31] Di Liu et. al., “Rule Engine based on improvement Rete algorithm”, ICACIA, 2010. [32] Femke Ongenae et. al., “Towards computerizing intensive care sedation guidelines: design of a rule-based architecture for automated execution of clinical guidelines”, BMC medical informatics and decision making, 2010.