active rule engine for dynamic business rules

1

ACTIVE RULE ENGINE FOR DYNAMIC BUSINESS RULES S.Swamynathan and Dr.T.V.Geetha Department of Computer Science and Engineering College of Engineering, Anna University Chennai 600 025. INDIA

ABSTRACT Distributed large-scale applications for an enterprise need a system that enables the application to be easily modified and managed. A rule-based system is used to represent the business rules. Changes in the rules are immediately effected across the enterprise. The business rules can be represented in terms of ECA (Event-Condition-Action) rules. This paper present a rule engine system that will enable changes to the business logic to be performed at run time through changes in the business rules represented in the system. These rules are made compatible with the Java Expert System Shell (JESS) rule specifications. The Rule Engine runs as an RMI Server, providing the rule processing functionality to the Enterprise components running on the Application Server. The enterprise components interact with the rule server and add facts or rules or both to the rule server. The Rule Engine is a multithreaded process, which efficiently uses threads that control the engine functionality. Keywords: Active databases, rule engine, business logic, intelligent system.

1.0 INTRODUCTION Business rules represent business policies and are present in applications resulting from: corporate charters, marketing strategies, pricing policies, product and service offerings, customer relationship management practices and regulatory forces, in short everything to do with the competitive landscape. Business Rules change with changes in the competitive landscape resulting in modifications to the embedded rules in applications. Placing business rules in objects marries the objects to applications and makes the changes to business rule a vain effort resulting in high maintenance and enhancement cost. There is an associated problem in such a scenario. A change in a business rule is typically domain-centric and such change originates from a functional user's needs. Usable, efficient applications typically empower functional users to make such changes to the logic/rules. Similarly, Internet Service Vendors (ISV) need flexibility to make their applications configurable and enable their customers to manage rules themselves and thus reduce support and maintenance costs. Designing applications with such flexibility requires a well-planned business rulecentric approach that allows separation of business rules from application code. The need for the end user to be able to specify rules dynamically based on requirements that are suited to his needs is all too common[2]. By placing the business logic in the application code would mean that each time the user required a new rule to be added or a modification of an existing rule, he would have to somehow rewrite the application code and recompile the entire system for his new business rule to function. Considering a scenario where the application is available on the Internet, where hundreds of users can be accessing the system at the same time, it is impossible to enable each user to modify the core application code dynamically. Again, in such an application it is exceedingly important that the user be as unaware of the underlying complexities of the application code as possible. Simple interfaces to the rule system would enable him to directly interact with the business logic in the application, without having to modify the entire application. Another important need is for a system that would integrate seamlessly with existing application models. The multi-tier models that EJBs represent already have legacy support for most existing application models. Coupling the

2 Rule Engine with an application server would ensure that the technology would be available across all platforms and all users. Since the core technology used is Java based in both the application server and the rule engine, the integration is seamless and performance is maximized. Hence there is a need to monitor the business rules of each user. Active database is a technology, which will be of great useful to do this monitoring activity[14][15]. Active systems support both event detection and action execution. The response is achieved through the run time support part of the system, in accordance with the reaction definitions given by the application. Active databases do this by moving the reactive behavior from the application into the DBMS. It is also necessary to consider the rules in terms of object so that the manipulations on these rules can be extended to many other technologies.

2.0 EXISTING WORK There are many works in the field of rule engine and business logics. Products like Jrules and QuickRules have a reasonable market presence in this field of integrating rule engines with application servers[11][13]. Both are similar in their approach to the problem in that they provide similar features and are based on the same design. QuickRules provides basic capabilities for easy design, development, deployment and management of business rules by application architects/functional experts/line managers. QuickRules is especially helpful in network management scenarios (event, alert or trap correlations), financial applications (changing business policies to suit regulatory changes), healthcare and personalization (one-to-one customer interaction using some form of messaging) [13]. ILOG’s high-performance rule engines implement an optimized RETE algorithm designed to optimize the evaluation of a large number of rules across a large number of objects. Additionally, ILOG's rule engines provide unique features to fine-tune the engine to meet application performance requirements. The Java and C++ rule engines take advantage of automatic and developer-provided optimizations to maximize performance and make better use of application resources. ILOG rule engines are designed to scale effectively to support large, mission-critical applications. ILOG Rules and ILOG JRules have been deployed in applications supporting large numbers of users and requiring high-transaction volume. From heavily used Web-based applications to enterprise-wide core business applications, ILOG Rules for C++ and ILOG JRules for Java support scalability through multithreaded application architectures often deployed on multi server configurations. ILOG rule engines are thread-safe and thread-hot, allowing both cross-thread calls to the rule engines and sharing of objects by rule engines running in separate threads [12]. These engines are written in Java and integrate with the application server by being deployed as a stateless session bean within the application server[10]. The tight coupling that this provides enables the rule engine to interact seamlessly with the application server. However, this has its own drawbacks. The efficiency of the rule engine is reduced, as it is now dependant on the application server for it’s processing. Most application servers define similar thread priorities to all their session beans. Since these session beans are not given any extra privileges, they would lack in the performance that they would have had if they were implemented as a separate server by themselves. The user interface that these applications use is quite advanced, with natural language processing capabilities, that enable a domain expert or the system developer to effect new rules within the system. But in doing so, these products have not considered interfaces that the end-user can use to generate rules. In applications where the end user would require changing the rules dynamically, it would require him to contact the domain expert and get the job done through him. Considering applications on the Internet where there could potentially be hundreds of users, this would defeat the purpose of the application entirely. Also, the presence of the complex interface makes it difficult for the developer to design a simpler end-user interface. In this paper, the enterprise components interact with the rule server and add facts or rules or both to the rule server. The rule server can make changes to the representation of the data within the application server on the firing of an event within the rule server. In order to monitor the firing of an

3 event and to take the required action, active database technology will be of great useful. Hence, the business rules, which need to be monitored for each user, are converted into an ECA rule and are mapped to JESS specification. These rules are grouped and are kept in a rule engine. The mapping of ECA rules into JESS specification helps to make use of the full potential of JESS which is java compatible and can hence be extended to any level[1]. This paper also integrates the JESS rule engine with the WebSphere application server[6]. The communication between the Rule Engine and the Application server is through RMI, a core Java technology. The advantage of this architecture is that the rule engine can now exist on a dedicated server system and that the application server would still have the same performance features that were found in the other application scenarios. The decoupling of the rule engine from the server also ensures a better service and enables the rule engine to run as a multi threaded application that the server can interact with dynamically. The other factor that sets this paper apart is the introduction of the interfaces that enable the end user to directly interact with the rule engine and deploy rules on the server, at the same time maintaining the security and efficiency that are essential in enterprise applications. The user interfaces are simple and effective and enable the user to perform complex operations on the system.

3.0 SYSTEM ARCHITECTURE The system architecture of the active rule engine for the business logic is shown in figure 1. This system consists of application server, rule engine and the data store. An interface is provided between the rule engine and the rule integrator component of the application server.

Application Server EJB Container Rule Integrator

Rule Engine Session Bean

Entity Bean

Data Store

Session Bean

Entity Bean

Data Store

Figure 1 Architecture of the Application server The system implements the Rule Engine as a separate multithreaded server that runs as an RMI Server. Communication from the Application Server is through the use of the Rule Integrator Session Bean that interfaces between the Application Server and the Rule Engine. The FireRule Session Bean is used to communicate between the Rule Engine and the Application Server. It acts on the Session beans within the Application Server and updates the entities based on the rules that are fired in the Rule Engine[6].

4

3.1 WORKFLOW WITHIN THE SYSTEM User Request

Session Bean

Rule Integrato Entity Bean

Rule Engine

Fire Rule Data store

Figure 2 Workflow between the Components and the Rule Engine The workflow between the components and the rule engine is shown in figure 2. The user interacts only through the session bean interfaces provided. The session bean communicates with the rule integrator to inform the rule engine about the changes that the user requested. The user request is also sent to the entity bean from the session bean. The rule engine, on getting the request from the rule integrator, activates rules and if a rule fires due to the changes in the facts represented within the engine, the fire rule session bean is invoked which would perform the necessary changes within the database. The only components that interact with the data store are the entity beans[4]. Again any changes that need to be communicated to the user only communicate through the session beans.

4.0 APPLICATION SPECIFICATION An online share trading application was considered to define the business rules of users. The two main entities are the Stock Market and the account details entities. The account details entity has the account activity and the user information entities with one to one relationships that add more meaning to the account information that this entity represents. The account Investment details entity depends on both the stock market and the account details entities and represents the shares that a particular account holder has acquired through this company. It has a one to many relationship with both account details and the stock market, the key field being the composite key comprising of both the stock market’s key and the account details Key. The user rule entity is the internal representation of the rule within the application server that enables the user to interact with the server and modify the rules even after they are deployed. Classes within the system are the basic underlying architecture that goes into making the components. The class relationships are also reflected within the components. The user account information class is an aggregation of the user information, account activity and account details classes. The stock market class also encapsulates all activity on the stock market. The user account stock details class is an aggregation [3] of data pertaining to both the user account and the stock holdings of that particular user. The account investment details class has data pertaining to each

5 individual user’s share holdings and how many shares of each stock the user has. The beans within the container and their interaction are shown in figure 3. User Account Information

User AccountStock Details

Rule Engine Integrator

Stock Market

Account Investment Details

Fire Rule

Figure 3. Component diagram of Session Beans in the System

4.1 DEVELOPMENT ENVIRONMENT The EJB development environment of IBM VisualAge for Java is a specialized environment that can be used to develop and test enterprise beans for use in Enterprise applications[5][7]. The EJB development environment consists of multiple tools. The test environment provides an EJB server and a user interface that allows testing and debugging of enterprise beans. The developer can create and manage server configurations, which are instances of the EJB server running inside the VisualAge for Java Virtual Machine[9]. For example, the EJB server can be configured with a set of enterprise beans and then set breakpoints in the enterprise bean code. This allows the developer to leverage the full debugging capabilities of VisualAge for Java to debug enterprise beans. A test client is also provided to help test enterprise beans. The test client features its own user interface and allows testing the individual methods in the home and remote interfaces of each enterprise bean

5.0 IMPLEMENTATION The implementation details include the Rule engine implementation, the application server implementation, connecting the rule engine with the application server and the client interface. A class in the rule engine activates the JESS Rete engine object. It has interfaces that enable the Runner and the RandomGenerator to access the engine and perform operations on it. The engine can also be configured to save its current state periodically, to be reinstalled when the engine starts up. The initial JESS rules are loaded up into the engine and a new thread is initialized to takeover the engine’s processing. The generator runs through the stocks in the stock list and randomly changes some values by a small random margin. Another class implements the JESS user function that is needed to perform operations from within JESS onto the application server. The user function would be called by a rule that requires updating the entity representations on the server. JESS user function that is needed to perform operations from within JESS onto the application server are also implemented. A vector listing of data beans objects are maintained. Changes made to this list are reflected on the facts

6 represented within the rule engine. The use of PropertyChangeSupport within the databeans, and the PropertyChangeListeners within JESS ensure that the beans that are on the StockList are synchronized with their internal representations within JESS. The application server contains the entity and session beans, the RuleIntegrator and FireRule session beans that are used to interact with the rule engine. The entities EJBReserved and the sessions EJBReserved packages are generated by the VisualAge for Java EJB development environment to help it identify the EJB groups. The Rule Engine communicates with the application server using RMI. RMI was chosen as it is compatible with the existing EJB technologies and it is also efficient in cases where there is a possibility of multiple calls to the engine, as the client would maintain the connection state and would not have to reconnect and lookup in the RMI Registry each time. Another advantage of RMI is that the rule engine can be configured to run on a remote system and yet maintain the integrity with the Application Server. The client interfaces are designed and developed using the Visual Composition Editor that VisualAge for Java provides. This helps in the visual development by providing a WYSIWYG editing environment for Swing or AWT based development. Associations and connections between different visual and non visual components, connecting their events, properties and code are possible through this interface and the code for these connections would be generated automatically.

6.0 RESULTS The screen shot used for creating the user specific rule interface is shown in figure 4. This includes the specification of event date and time, the account and stock details and the action to be taken. The JESS rule is generated when the specifications are provided.

Fig 4. User Rule Interface

7 6.1 SAMPLE RULES IN THE SYSTEM System Rule To Calculate Previous Day’s Closing Value (defrule prevDayCalc (MAIN::Stock1 (currentValue ?value)(OBJECT ?stk))(MAIN::RuleGlobals1 (checkClosing "0")) => (call ?stk setPrevDayClosing ?value)(facts)) User Rules Based On Stock Values When Stock 1 >= 12 then buy 33 shares of Stock 1 for Account 1 (defrule 1-990294040550 (MAIN::Stock1 (stId 1) (currentValue ?value1&:( >= ?value1 12))) => (printout t "buy 33 stock" crlf)(buystock 1 1 ?value1 33)(undefrule 1-990294040550)) When Stock 2 < 25.65 then buy 500 shares of Stock 2 for Account 12 (defrule 12-990294110200 (MAIN::Stock1 (stId 2) (currentValue ?value2&:( < ?value2 25.65))) => (printout t "buy 500 stock" crlf)(buystock 12 2 ?value2 500)(undefrule 12-990294110200)) When Stock 1 > 45 then buy 500 shares of Stock 2 for Account 5 (defrule 5-990294150570 (MAIN::Stock1 (stId 1) (currentValue ?value1&:( > ?value1 45))) => (printout t "buy 500 stock" crlf)(buystock 5 2 ?value2 500)(undefrule 5-990294150570)) When Stock 2 > 25 , and Stock 1 > 12.5 then buy 250 shares of Stock 2 and sell 500 shares of Stock 1 for Account 5 (defrule 5-990294233450(and (MAIN::Stock1 (stId 2) (currentValue ?value2&:( > ?value2 25))) (MAIN::Stock1 (stId 1) (currentValue ?value1&:( > ?value1 12.5))) ) => (printout t "buy 250 stock" crlf)(buystock 5 2 ?value2 250)(printout t "sell 500 stock" crlf)(sellstock 5 1 ?value1 500)(undefrule 5-990294233450)) When 56 > Stock 1 > 45 then buy 500 shares of Stock 1 for Account 1 (defrule 1-990294306450(and (MAIN::Stock1 (stId 1) (currentValue ?value1&:( < ?value1 56))) (MAIN::Stock1 (stId 1) (currentValue ?value1&:( > ?value1 45))) ) => (printout t "buy 500 stock" crlf)(buystock 1 1 ?value1 500)(undefrule 1-990294306450)) When (Stock 1 < 23, or Stock 3 >= 22.50), and Stock 2 = ?value3 22.5))) ) (MAIN::Stock1 (stId 2) (currentValue ?value2&:( (printout t "buy 500 stock" crlf)(buystock 1 1 ?value1 500)(printout t "sell 230 stock" crlf)(sellstock 1 3 ?value3 230)(undefrule 1-990294459850)) User Rules based on date and time On 20-05-2001 at 10:30.00 hrs, buy 200 shares of Stock 1 for Account 1 (defrule 1-990332957740 (MAIN::RuleGlobals1 (currentTimeMS ?value)) (test (= (checkdate 990334800020 ) 0)) => (printout t "buy 200 stock" crlf)(buystock 1 1 ?value1 200)(undefrule 1990332957740)) After 23-05-2001 ,11:30.00 hrs, sell 120 shares of Stock 2 for Account 1 (defrule 1-990333143280 (MAIN::RuleGlobals1 (currentTimeMS ?value)) (test (= (checkdate 990597600020 ) 1)) => (printout t "sell 120 stock" crlf)(sellstock 1 2 ?value2 120)(undefrule 1990333143280))

8 Unconditional User Rules Buy 200 shares of Stock 1 for Account 1 (defrule 1-990333451460 (MAIN::RuleGlobals1 (currentTimeMS ?value)) (test (= (checkdate 990333374350 ) 1)) => (printout t "buy 200 stock" crlf)(buystock 1 1 ?value1 200)(undefrule 1990333451460)) Rules combining date and time with Stock based Events Before 30-12-2002 at 4:30.00hrs, if Stock 1 < 20 then, buy 500 shares of Stock 1 for Account 1 (defrule 1-990333887520 (MAIN::Stock1 (stId 1) (currentValue ?value1&:( < ?value1 20))) (MAIN::RuleGlobals1 (currentTimeMS ?value)) (test (= (checkdate 1041202800350 ) -1)) => (printout t "buy 500 stock" crlf)(buystock 1 1 ?value1 500)(undefrule 1-990333887520)) On 20-05-2001 at 5:20.30hrs, if Stock 2 < 23.50 and Stock 1 > 45 then, sell 200 shares of Stock 2 and buy 120 shares of Stock 1 for Account 1 (defrule 1-990333710490(and (MAIN::Stock1 (stId 2) (currentValue ?value2&:( < ?value2 23.50))) (MAIN::Stock1 (stId 1) (currentValue ?value1&:( > ?value1 45))) )(MAIN::RuleGlobals1 (currentTimeMS ?value)) (test (= (checkdate 990316230350 ) 0)) => (printout t "sell 200 stock" crlf)(sellstock 1 2 ?value2 200)(printout t "buy 120 stock" crlf)(buystock 1 1 ?value1 120)(undefrule 1-990333710490)) After 1-1-2003 at 9:30.00 hrs, if Stock 1 < 20 or if Stock 2 < 15 then, buy 500 shares of Stock 1 for Account 1 (defrule 1-990334140120(or (MAIN::Stock1 (stId 1) (currentValue ?value1&:( < ?value1 20))) (MAIN::Stock1 (stId 2) (currentValue ?value2&:( < ?value2 15))) )(MAIN::RuleGlobals1 (currentTimeMS ?value)) (test (= (checkdate 1041393600350 ) 1)) => (printout t "buy 500 stock" crlf)(buystock 1 1 ?value1 500)(undefrule 1-990334140120))

7.0 CONCLUSION AND FUTURE ENHANCEMENTS The business rules were converted into ECA rules and were represented as JESS specifications. The rule engine was built by grouping the rules together. The rules were classified based on simple or complex events. The integration of a rule engine with an application server enhances the performance of the application server by providing the system with a dedicated processing mechanism for activation and processing of the business rules that are required by the application. The rule engine being separate was seen to enhance the development process and allowed the user to dynamically alter and add rules to the enterprise system. Using RMI to communicate between the rule server and the application server ensured that the distributed nature of the system is maintained. This enables the rule server to be moved to a dedicated server, thus improving performance. The online share trading application aptly demonstrated the feasibility and efficiency of a system that used a rule engine to de-couple the business rules from the application logic. The ClassFileServer implementation for RMI to serve the class files required by the server and the client is not very scalable and can be replaced by a Web Server like IBM Http Server or Apache. The rule being generated within the client interface for the user rule makes the client very complex. Instead the generation could be performed at the application server at the session bean. Servlet and JSP interfaces could be used to make the application more web centric and thus more widely available. Security mechanisms could be introduced within the application server to ensure proper access rights to the clients. The rule engine could be developed into a more generic engine that supports more operations done on the engine. This would enable the end user to directly add rules and

9 facts on the engine from the client interfaces. However the more generic the engine becomes, the harder it would be to create interfaces for the client to perform operations on the rule server. REFERENCES [1]

Ernest J. Friedman-Hill Jess, “The Expert System Shell for the Java Platform”, Sandia National Laboratories, Livermore, CA, 2001.

[2]

Stuart Russell and Peter Norvig, “Artificial Intelligence - A Modern Approach”, McGraw Hill, 1997.

[3]

Grady Booch, James Rumbaugh and Ivar Jacobson, “The Unified Modeling Language User Guide”, Addison Wesley Pvt. Ltd, 1999.

[4]

Roman Ed, Ambler Scott, Jewell Tyler, “Mastering Enterprise Java Beans Second Edition”, John Wiley & Sons Inc, 2002.

[5]

Joaquin Picon, Patrizia Genchi, Maneesh Sahu, Martin Weiss, Alain Dessureault, “Enterprise JavaBeans Development Using VisualAge for Java”, IBM Corporation, International Technical Support Organization, 1999.

[6]

Barry Nusbaum, Matias Djunatan, Wakako Jinno, Peter Kelley, “WebSphere Application Servers: Standard and Advanced Editions”, IBM Corporation, International Technical Support Organization, 1999.

[7]

Ueli Wahli, Tobias Himstedt, Sean Lee, Amir Razmara, “IBM WebSphere and VisualAge for Java Database Integration with DB2, Oracle, and SQL Server”, IBM Corporation, International Technical Support Organization, 1999.

[8]

Joaquin Picon Regis Coqueret Andreas Hutfless Gopal Indurkhya Martin Weiss, “Design and Implement Servlets, JSPs, and EJBs for IBM WebSphere Application Server”, IBM Corporation, International Technical Support Organization, 2000.

[9]

Ueli Wahli, Dominique Faidherbe, Akis Laftsidis,Karthikeyan Ponnalagu,, “EJB Development with VisualAge for Java for WebSphere Application Server”, IBM Corporation, International Technical Support Organization, 2001.

[10]

Eduardo Pelegri-Llopart, Laurence P. G. Cable, “How to be a Good Bean”, JavaSoft, Palo Alto, CA, 1997.

[11]

http://www.ilog.com/products/rules/engines/index.cfm - “ILOG JRules home page”.

[12]

http://www.manufacturingtalk.com/news/ilo/ilo000.html - “Business rule engine personalizes enterprise”, 2002.

[13]

http://www.yasutech.com/rules-engine-overview.htm - “Overview of the QuickRules Rule Engine for enterprise applications”.

[14]

Widom J., Ceri S., “Active Database Systems Triggers and Rules for Advanced Database Processing”, Morgan-kanfmann Publishers., 1996.

[15]

ACT-NET Consortium, “The Active Database Management System Manifesto : A Rule base of ADBMS Features”, ACM SIGMOD Record, 1996, Vol. 25, No.3.