General Java

Twenty years after it first made waves, rule-based technology is making a comeback. Java developers with an eye on the e-commerce market are becoming aware of how integrating business rules and objects in Java can help expand Java into new niches within Web-based applications. This article discusses how rules fit with Java, the types of rule engines available and how a rule engine is used to execute rules for integration into a Java applet or application.

Business rules are the fundamental policies and procedures that define or constrain a business, guiding how it functions. In modern businesses thousands of these policies and procedures are often embedded in application code, with "rule engines" ­ intelligent software components ­ frequently used as the fastest and most effective method to evaluate and execute business rules. Relying on rule engines is usually preferable to embedding rules in application logic, which makes changing and maintaining rules difficult and costly. Developers are increasingly using them, especially to reduce development and maintenance time, increase application performance, and improve application adaptability and flexibility.

In many ways Java is an ideal language for business rules because platform-independent, robust, maintainable, object-oriented Java applications more accurately reflect the structure of a business. Even though the Java language doesn't currently support rules, new tools ­ including freeware ­ are helping to overcome Java's limitations in making changes or updates. For developers, being aware of rule engines and the available tools for Java is highly applicable to the burgeoning e-commerce market. Having an approach for integrating business rules and objects in the Java language can be a boon to expanding Java into new niches within Web-based applications ­ particularly for fast-growing applications like online lending and investment management, and for the many Web personalization solutions ideally suited to business rules and rule engines.

In this article we'll also address design/implementation strategies for business rules and the changing requirements driven by the Web and by e-commerce that mean nonprogrammers must have access to the technology. It's important to note that there are other rule-based software systems, but this article will discuss only Java implementations

Rule-Based Systems: A Brief History
Rules are declarative statements that drive activity in a software application by describing the action or actions to take when a specified set of conditions is met. Rules consist of a left side ­ an "IF/WHEN" condition statement ­ and a right side ­ a "THEN" action statement.

The earliest rules technologies had their roots in artificial intelligence (AI) methodologies. MYCIN (written in LISP), developed at Stanford University in the 1970s, was the first system to use rule-based knowledge representation. Used to diagnose blood diseases and recommend treatments, MYCIN's core concept was the separation of knowledge and control. Knowledge, represented in rules, was separated from the control logic responsible for evaluating and executing the rules.

Rule-based programming reached a pinnacle in the 1980s during the AI boom. At this time many vendors marketed, and many organizations purchased, commercial rule engines. However, the combination of poor performance, an inability to integrate the technology into mainstream computer architectures and the realization that rule-based declarative programming was not the panacea it was purported to be left many organizations disenchanted with the technology.

Although the hype surrounding rule-based programming and expert systems died in the late '80s, the technology continued to be used effectively and quietly for certain types of applications. The current trend toward developing business rule applications is once again leading many mainstream organizations to evaluate the use of rule-based technology more than 20 years after its introduction.

Among the first users of the rules technology was the telecommunications industry, particularly for network management. System and network management applications are typically developed using rules. The following are examples of rules in a telecom network management application:

• Related alarms: When a switch raises an equipment failure alarm, ignore all communication failure alarms on the associated port.
• Maintenance activity scheduled: When maintenance activity has been scheduled on a network element, ignore all alarms raised on this piece of hardware between the maintenance start and end time.
• Critical alarms on sensitive devices: When more than 15 alarms are detected on a network element, notify the network operator by pager. When more than five alarms are detected on a switch, notify the network operator by pager.

The class diagram associated with these rules is shown in Figure 1. If you were to develop an application to implement these rules, how would you do it? Chances are you'd code them into the methods of one or more objects. Listing 1 contains the Java code to implement these rules using a correlateAlarm() method on the Network class. The Network generates the alarms and events, which queue and are processed by the AlarmCorrelator class. The AlarmCorrelator class executes the correlateAlarm() method each time an alarm is processed.

The "correlate Alarm" method contains complex logic that becomes difficult to maintain as the number of rules increases. Typically, hundreds of such rules are implemented in a network management application. The processing time to handle the generated alarms becomes significant since all tests must be evaluated each time an alarm is received. To reduce processing time, rules are often combined into the same "IF" or "SWITCH" statement. This further obscures the code since the one-to-one relationship between the rule specification and the implementation is lost.

This type of application is difficult to develop and maintain using Java or any other procedural programming language. Java objects consist of methods for executing procedures and data members to hold the inputs and outputs of these procedures. They lack a mechanism for capturing rules that determine when and how procedures should be executed.

Enter Rule Engines
A rule engine is a software component designed to evaluate and execute rules. Since it implements all of the logic necessary to perform rule evaluation and execution, the rules can be coded as stand-alone atomic units, separate from and independent of the rest of the application logic. This makes them easier to develop and maintain. Rule engines have a proprietary rule language for writing rules. To implement an application using a rule engine, you write the rules in the rule language and embed the rule engine into your application. The rule engine integrates with the application through an API that controls the loading of rules into the rule engine, the monitoring of application objects referenced by rules and the execution of rules.

As shown in Figure 2, the rule engine as a software component is an object with attributes and methods. An application consists of the application objects and the rule engine object. The rules are loaded into the rule engine by invoking a method on the rule engine object and passing the rules ­ in a file, stream, XML representation or some other form ­ to the rule engine. To evaluate the rules, the rule engine must have visibility to the application objects referenced by rules. To provide this type of visibility, the object data members and methods referenced by rules are usually specified as public. Through a process called asserting, the rule engine's assert method introduces the objects referenced by the rules. Once the objects have been asserted to the rule engine, the rule engine maintains a set of references to the objects. The rule engine's fire rules method is then invoked to cause the rule engine to evaluate all of the loaded rules. Following evaluation, when the conditions of rules are met, the rules are executed or fired, causing their action statements to execute. The action statements of rules can modify the objects referenced by the rule engine, thereby causing more rules to become eligible to fire. The process continues until no more rules are eligible to fire, at which point control returns to the application statement following the invocation of the fire rules method.

Let's go back to the network management example. The network management rules would be implemented using a rule engine by coding the rules shown in Listing 2. These rules are shown using the Java-like syntax of JRules, a rule engine from ILOG Inc. Notice that the syntax of the rule language is declarative and has a one-to-one correspondence with the English-like rule specifications. The rule engine would be integrated into the application as an object and the rules would be loaded, objects asserted and rules fired as described previously.

The rule engine implementation results in a flexible and maintainable application design since the rules are separated from the application logic and can be maintained in a single place. The rule engine implementation is straightforward, with the evaluation of rules automatically performed by the rule engine, eliminating the need for the complex conditional logic required in the application to monitor the network objects. The use of a rule engine improves application performance since the rule engine implements an efficient pattern-matching algorithm to optimize rule evaluation. In this algorithm, known as the RETE algorithm, rules are compiled into a discrimination network that enables conditions shared by multiple rules to be evaluated just once. This enables the processing of thousands of network alarms per second.

Table 1 lists several commercial and shareware rule engines that integrate with the Java language. The rule languages implemented by the rule engines and their mechanisms of integration differ slightly.

Rule engines have been used for event-driven applications such as system and network management and workflow for some time. As we mentioned before, these applications benefit from the RETE pattern-matching algorithm implemented by the rule engine to efficiently evaluate rules against the set of referenced objects. However, rule engines are rapidly gaining acceptance as the preferred approach for implementing a new class of applications known as business rule applications.

Business Rules
The term business rule has been used to define business policies and procedures that describe or constrain the way an organization conducts business. Organizations have thousands of such business rules that define and direct how they manufacture, sell, buy and otherwise transact business. Business rules are everywhere ­ in your corporate charter, your marketing strategies, pricing policies, product and service offerings, and customer relationship management practices as well as in the legal documents that regulate your business and industry.

Business rules can be differentiated from the executable rules coded in the rule language of the rule engine since they directly represent business policy. Other types of rules, such as rules to perform data manipulation or control application-processing flow, can be coded in the rule engine. Furthermore, business rules don't require a rule engine for implementation. They can be implemented in computer systems using a variety of different approaches: for example, they can be implemented in middle-tier application servers in the methods of objects or in database stored procedures. In fact, business rules are implemented throughout computer systems.

To express and model business rules, it's desirable to use an English-like, implementation-independent representation. Such a representation allows nontechnical business people, those responsible for defining and maintaining the business rules, to understand and use them. Minimally, an English-like representation for business rules can help in creating better requirements specifications. However, some applications require that the business rules be represented and externalized in a way that permits business people to create and modify them at execution time. In other words, the application should allow the business rules to be added and changed dynamically by nontechnical users.

For the purposes of this article, we'll refer to applications with these requirements as "business rule applications." This could be clarified further as follows: in order to be considered a business rule application, the application must allow business people to define business rules using an English-like representation. Thus a claims-processing application that allows the user to modify the business rules specifying the handling of auto insurance claims and a portfolio management application that allows the user to create guidelines for buying and selling investments are both business rule applications.

Implementing Business Rules
One method of allowing business rules to be managed by business people at execution time is to create a set of parameter tables that can be stored in databases and edited via a GUI. This method is often used for applications implementing product pricing and bundling. The flexibility gained by this method is very restricted in scope, and when business policy changes fall outside the original application boundaries, substantial programming changes to the application's front end and back end are required.

As stated, a more adaptable approach is to implement the business rules using a rule engine. Since the rule languages offered by the commercial and shareware rule engines are extensive and powerful, this approach provides a more flexible architecture that is unlikely to require change when the scope of the business rules change. Some of the rule engines have an English-like, readable rule language and a rule editor that can be embedded in the application's GUI to provide runtime access to business rules. However, this approach is feasible only for technically savvy business people because the rule languages provided by rule engines are complex and extensive whether they have an English-like or a codelike representation. When users modify business rules, it's difficult for them to determine whether the rule will execute as expected. Using the full syntax of a rule language, users can create a rule that will cause the application to loop endlessly or crash.

To avoid these problems, the application must be designed to restrict the syntax and features of the rule language to a safe subset of the rule language provided by the rule engine. The restricted rule language, known as the business rule language, is usually specific to the application's business domain and uses business terminology particular to that domain. Developing a custom rule editor GUI to guide the user through the specification of rules using the business rule syntax normally provides the capability to define and modify business rules. Two types of rule editors are commonly created for business rule applications. In the first, the business rules are represented as predefined templates that allow the user to specify only the parameters of the business rule. Also used are more sophisticated rule editors that allow the user to define a rule using a business rule syntax and step the user through the rule creation process based on previous choices.

Using either approach, business rules created through the custom business rule editor can then be represented in objects or stored in a parsed format, a text string or XML representation. Executable business rules in the language of the rule engine are then generated from this intermediate representation.

For example, in a customer resource management (CRM), the business user from the marketing department may define a special new promotion for a certain group of customers. The business user creates the rule in an English-like representation using the business rule editor. An executable business rule, in the language of the rule engine, is generated from the business rule language and introduced to the rule engine. The rule engine executes in a CRM Web server-based application, as illustrated in Figure 3.

This approach, although challenging to implement, results in a powerful and flexible application in which the business rules can be changed dynamically while the application executes to immediately implement new sales policies or pricing strategies or to respond to changing regulations imposed by government or regulatory agencies.

Applications Requiring Business Rules
In today's highly competitive business environment, it's becoming increasingly necessary to externalize business rules and put them in the hands of business people. Organizations can no longer afford to wait for IT to implement changes in business policy. To gain and maintain a competitive advantage, companies must be able to immediately respond to the requirements of their customers and partners and to the initiatives and actions of their competitors.

Business rule applications exist in virtually every business domain. Let's look at a selection of typical business rule applications in the areas of e-commerce personalization, loan underwriting and customer relationship management.

E-Commerce Personalization
As more companies extend their sales and marketing functions from traditional channels to the Web, the capability of personalizing each customer's experience becomes essential in order to attract, satisfy and retain customers. With the Web comes the ability to apply the concepts of one-to-one marketing and to replace the old "one size fits all" approach with individually tailored offers.

Rule-based personalization uses specific information about individual Web site visitors to precisely tailor the content displayed. By capturing the needs, interests, preferences and motivations of the individuals that visit a Web site, and applying business rules against that information, visitors can be provided with information and recommendations that will be relevant to them. Web merchants can make visitors aware of interesting promotions, offer them discounts based on their purchasing history and take advantage of opportunities to cross-sell and upsell without offending them. Here are some typical rules:

• If Shopping Cart contains more than $100 worth of CDs, give $5 off the next purchase.
• If Customer purchased a Pilot III last week, show all Pilot accessories.
• If Customer traveled to Europe within the last year, send notification of European travel promotions.

Some larger merchants are developing their own personalization solutions using business rules. By externalizing the business rules, they create a more flexible solution that can be changed by their marketing personnel, enabling them to immediately implement new promotions or offer new products. Vendors such as BEA and IBM are offering flexible personalization solutions that allow the merchant to define and modify these types of rules in their respective WebLogic Commerce Server and WebSphere Commerce Suite. Using these personalization solutions, merchants can create Web sites that intelligently interact with customers.

Mortgage Loan Underwriting
Lenders have been developing rule-based underwriting applications for the last decade. In these systems, rules are used to simulate the decision-making process of a human underwriter. As competitive pressures have increased in the mortgage industry, lenders have developed more loan products to offer flexible alternatives to homebuyers. At the same time, the credit policy organizations within lending institutions are defining new rules to ensure that risk is managed at an acceptable level for these new loan products. Additionally, lenders must frequently comply with regulations imposed by the federal government and the policies of the secondary mortgage institutions.

To implement and maintain the large number of rules required in these underwriting applications, many lenders are developing business rule applications that allow the marketing department to define new loan products and credit policy to define new risk management rules. For example:

• If borrower is a first-time homebuyer, offer the no-down-payment option.
• If the lien type is a second mortgage, the borrower's occupancy status must be principal residence.
• If the transaction is a cash-out refinance, the loan-to-value ratio must be less than or equal to 85%.

Telecom Customer Care and Billing
Competition and deregulation have combined to make the customer all-important to the telecom industry. In order to excel, service providers must continually offer the customer new services at competitive prices. Moreover, they must be able to react immediately to market changes from competition, customer demand or technological advances. These market pressures force the companies to constantly search for new ways to stimulate business through service packages and pricing schemes, and to run aggressive sales campaigns with attractive promotions and discounts.

The most innovative applications for customer care and billing are business rule applications because they offer time-saving, cost-effective ways to impart outstanding flexibility and customization for managing ever-changing rates and promotions. Business rules help companies secure customer loyalty by allowing them to target individual needs.

The long distance market is extremely competitive. To attract and keep customers, companies are offering special rates and discounts. For example:

• If destination is a preferred number, give a 50% discount on call.
• If customer is a member of nickel nights plan and call time is after 5 p.m., billing rate is $0.05 per minute.

To be effective, these promotions must be incorporated into the billing system. Externalizing the business rules in the billing system and allowing the marketing department to define and modify them provides this flexibility.

Summary
Implementing business rules using a rule engine is an increasingly popular approach due to their ability to create a flexible, adaptable, high-performance application. In this article we discussed rules and rule engines and how to integrate the rule engine into a Java application. We also examined how business rules applications are developed using a rule engine. In the second installment of this series we'll examine in more depth the implemention of business rules using Java rule engines.