Original URL: http://www.theregister.co.uk/2007/02/05/writing_rules/
Writing the Rules
The rules engine that's best for your business
Hands on Rules engines are now a common business tool, helping automate what are often complex decision-making processes. Now with web front-ends and business language IDEs, there's a lot to look at when choosing your software.
While some tools help transfer business logic change responsibilities from developers to business users, others mean learning a whole new way of programming, using declarative languages to separate business logic from data – without changing the essential object-oriented nature of your applications.
Like many recent developer tools, ILOG's JRules 6 uses an Eclipse-based IDE to give developers access to its Rule Team Server. The heart of the JRules platform, the Rule Team Server is a content management system, where rules are developed and stored, prior to being deployed on ILOG's Rule Execution Server. There's a lot in JRules, and ILOG has tried very hard to simplify rule development and management. This has been distilled into what ILOG refers to as "Rule Care" and "Rule Tech".
If you're a developer, then you'll be working with Rule Tech. Most developers will use JRules to design and build rule applications, using the ILOG's Rule Studio Eclipse-based IDE alongside their preferred Java development tools. With Eclipse support for multiple perspective layers, developers can switch between developing rules, the Java code to use them, and the web UI to deliver the application (or even use Adobe's Flex to tie Flash to rules-based systems), without leaving their one IDE.
ILOG uses a standard object model to build new rule projects from Java classes or XML files – so you can start with existing data models. This approach speeds up rule development, as existing code becomes the basis of any rules you need to deploy. The resulting rule artefacts use an extensible
if then else structure to define a business rule language, with decision tables for more complex rule structures. The development environment lets you control how decision tables are used, and how error cases are handled. Code completion and error notification tools help get new rule applications out the door quickly, while a graphical rule flow editor helps structure rules into a business process.
Rules can be embedded in templates, which allow non-technical users to make changes quickly. Templates can be locked down and definitions frozen, allowing only specific sections to be changed. This means a business user could be allowed to change a trigger value with changing business needs, but the rest of a rule or rule flow can be kept unchanged (and that this can be enforced). Business users can edit rules using a relatively simple business action language, which can also be constrained in templates or rule projects. It's relatively easy to get started with JRules. Tutorials in the help files mean you can quickly see how to build key rules artefacts, along with deployment and management techniques.
Once deployed, JRules' rule modules run on top of an application server. ILOG bundles JBoss with its installer, though you can run JRules on any JEE server. The Rule Team Server loads rules on the Rules Execution Server, and a scenario manager lets you test rules before you run them – and lets you keep control of rules if processes need to change. The Rules Team Server also holds configuration information for the Rules Execution Server, minimising the time needed to deploy additional rules servers. You'll be able to get timing information from the Rules Execution Server, which helps debug operations – and helps you fine tune your rules and processes.
ILOG's Rule Care concept hands rule maintenance to business owners, rather than overworked developers. It uses a web front end to the Rule Team Server to let business teams edit and manage existing rule libraries. New rules can be deployed using this UI, and existing rules validated. The Rule Team Server provides a repository for all rules and is populated from a separate development repository. Having a repository of record is important as it helps keep any rules-based business processes compliant with the appropriate regulations – as well as providing an audit trail for any changes to your rules.
There's a lot of functionality in ILOG's JRules, with a powerful rules language, a credible IDE, and a large selection of management and business user tools. With its own rules execution server, it's also very scalable, and ready for large deployments. If you're running a large scale ecommerce service and need to reduce risk and automate key business processes, ILOG has a tool for you. It may be overkill for some smaller businesses – but there are other tools more suited for that market. ILOG doesn't limit you to Java [although Daniel Selman of ILOG is Spec Lead for the JSR 94 Java Rule Engine API – Ed] either, as a .NET version of its rules engine is also available.
JBoss's Rules technologies are part of its JEMS (JBoss Enterprise Middleware Suite) SOA platform, and are already in wide use. JBoss sees customers using the tools to help implement service architectures, as rules can be used to link and orchestrate services. Version 3.0.5 was released in November 2006, and while it may not have all the features of some of its competitors, it has the advantage of offering a range of interfaces and is small enough to be embedded in existing applications – rather than requiring its own server. It's also open source, so you can tailor it to work just the way you want. There are some useful publications on the technologies used in JBoss Rules here.
Developing new rules is relatively easy, and JBoss provides an Eclipse plug-in to add rules development features to existing IDEs. As JBoss Rules is an extension of the Drools project [the Drools project voted to join forces with JBoss at the end of 2005 – Ed], you'll need to become familiar with JBoss' Drools business engine language (and you'll find plenty of references to Drools in the copious online documentation). Drools provides forward chaining, using fact propagation to provide a conclusion which is then acted on by an application. The Eclipse IDE hides Drools' XML syntax, providing a more readable UI; you can still edit the XML by hand, but we&'d recommend using the IDE tools. You can use the JBoss site as an update server, making sure you always have the latest version of the IDE installed in your copy of Eclipse.
While it may not be as business-user-friendly as ILOG's JRules, JBoss Rules can be used by non-developers. Its business language offers BASIC-like functions, and hides the Java and XML code needed to implement rules in your applications. The application is JSR 94 compliant, simplifying integration with existing applications and application servers. One significant omission is a rule repository. While you can use existing source control tools, like CVS, to manage rules, this approach adds an extra layer of complexity, and could discourage business users.
Building rules is relatively easy. Like languages on other rules engines, the Drools language is declarative, and decouples business logic from data. Left hand and right hand sides link facts to actions. Rule sets are delivered as packages, and include declarations, variables, functions and rule definitions.
While Drools uses the Rete algorithm to execute rules, developers don't need to be familiar with the approach – though it can help in defining rule sets when filtering facts. There's also support for Leaps, an algorithm which can speed up rules processing. You can define activation groups in JRules, which will group several rules so that if one fires, the rest will be ignored; an approach which works well when managing rule priorities. JBoss's documentation shows the open source nature of the project, with lots of theoretical detail alongside sample code.
Rules are first authored, and then parsed to ensure the rule grammar is correct. Once parsed, the rules are packaged and can be deployed in a runtime RuleBase. You can access the resulting RuleBase from your Java code: facts are delivered as Java objects, and can be asserted or retracted. If you're using decision tables, you can build them in Excel or other spreadsheets – a useful approach which helps business users get to grips with rule definitions in a familiar environment.
Like most JBoss tools, JBoss Rules is free to download. Community support is available online and through a wiki. If you need more support, you can purchase support from JBoss, which will give you access to the development team. If you're customising JBoss Rules or building it into your applications, you'll probably need this level of support.
Development is fast, with new versions released regularly. The next major update, JBoss Rules 3.2 will be released in Q1 2007, and will add new elements to JBoss' rules language, as well as improving the IDE and adding new debugging tools. Future versions will add the missing rule repository, along with a web-based rule development UI.
The ultimate aim of the JBoss team is to deliver a full business management suite. JBoss Rules is part of this vision, though it still falls short of delivering the whole picture. While the current rules engine may not have as many features as its competition, JBoss Rules is a powerful tool, and one that can be used by any Java developer who wants to add a rules engine to an existing application without significant investment. JBoss Rules isn't quite ready for enterprise heavy-lifting, but it certainly packs a hefty middleweight punch.
Fair Isaac is probably best known for its credit scoring applications and the FICO consumer credit rating system. The technology it uses to help determining credit scoring goes into its Blaze Advisor rules engine, recently upgraded to version 6.1.
Like JBoss Rules, Blaze Advisor uses Rete-based algorithms to handle rules, and it claims that Advisor 6.1's Rete III solution engine (acquired with RulesPower) is 100 times faster than its previous Rete I engine when dealing with complex rule sets. This is good, as if you're dealing with large data sets slow computation times can be a problem, especially if a quick decision needs to be made as part of a workflow. This new approach can help improve customer experiences – reducing call centre hold times or increasing ecommerce throughput.
Blaze Advisor gives you two ways of building rules – first, using a natural language approach (intended for business users) and, second, with a dotted notation for developers. Fair Isaac's SRL (Structured Rule Language) uses a simplified English grammar to convert policies into rules, though other common rule development features are available – including decision tables and scorecards. Once a rule has been implemented, it can be modified on the fly using a web interface. This means business users can change rules on running systems without requiring developer assistance.
The same web UI can also be used to test rules before they're deployed, and a full debugger is also available. Updated rules can be scheduled, or installed on the fly. Business users can be provided with reusable templates that help manage the changes they can make – making sure that all your rules are consistent, and reducing the risk of error. A visual editor can be used to help design rule flows, and rule sets can be used to collect together steps for reuse.
Developers can use Blaze Advisor with Java and COM, and it comes with deployment tools that can deliver rules as web services, enterprise Java Beans, COM+ and .NET. It's an approach that should simplify integration with existing applications, and development of new business tools. A decision containing many rules can be used as a component in any application. Blaze Advisor also comes with tools to help manage your rules, and a rule repository that can be used to hold and share rules, using XML data. Alternatively, rules can be stored in databases or on a LDAP directory.
The XML format used is compatible with Blaze Advisor's SRL, and existing rule sets can be converted to and from XML. As rules engines can easily become critical business systems, Blaze Advisor is able to use its repository to handle access controls. The same approach is used for audit – critically important if you're deploying a rules engine in financial systems. You can also tag rule steps with metadata, to help organise and document your rules – and use the built-in query engine to find specific rule entities.
Fair Isaac supports JSR 94, and is part of the JSR process, so you can use Blaze Advisor with J2EE 1.2 and higher. You can also use JDBC or web services to integrate with existing applications. Blaze Advisor's rules server can also be deployed with .NET systems, and is able to work with relational databases, XML files, and message queues (among many other information sources), using them as rule inputs. Outputs can be returned by the same mechanisms.
Fair Isaac describes the Blaze Advisor as an Enterprise Decision Management (EDM) tool, and its overall EDM vision is extremely interesting. It's a future where rules engines and machine learning come together, giving us systems that generate business rules on the fly – and in real-time. It's not the only company looking at the automated, model-driven rules engine of tomorrow – but it seems to be the closest to delivering it.
The world of business rules is a complex one, with many products vying for your attention. Businesses that want to develop applications which need to work extremely fast and with large rule sets should consider Fair Isaac's Blaze Advisor. It has benefited from the work needed to run the FICO credit scoring platform, and has the speed and volume needed to handle complex rule sets.
Most businesses won't need that much power, and ILOG's JRules is more than suitable for their needs. It too handles large rule sets and high user volumes and, while Blaze Advisor has the edge on speed, JRules is easier to use. Rule development and rule management tools are mixed to great effect, and both traditional developers and business analysts will be able to develop and manage rules relatively easily.
JBoss Rules is really for smaller problems, and for developers that want to be much more hands on. You'll get a lot of experience working with JBoss Rules, and you'll be able to build your solutions into your applications. ®