Feeds

An introduction to rules engines

And why not

3 Big data security analytics techniques

Businesses run on rules. They define business processes, and describe just what happens if something goes right - or if it goes wrong. Do all the gold-rated customers get a 10% discount, and what happens if one calls customer support? Business rules are part of the decision support systems that underpin every business process.

You can write the rules into your application business logic, but they quickly become spaghetti code, as you try to wrap each and every rule into a self-referential chain of "if then else", "case endcase" and "do while" statements (depending on your language of choice). Business rules change more often than the applications behind them. Debugging every case can add days and complexity to application tests, and meanwhile the business process owner is waiting for you to make the last set of rule changes...

You don't have to write the rules code yourself. It's often easier to employ a business rules engine to handle the rules, orchestrating and managing your applications and services. Rules engines are declarative, allowing you to put together quickly groups of rules that trigger events and services, without having to resort to procedural programming. If the engine offers sufficiently high level tools (which could be anything from simple text editors to complex graphical rule and workflow diagrams), responsibility for rules creation or editing could even be passed over to the business process owner. This means that your development team doesn't have to change its code every time the discount rate changes by .5%, or marketing defines a new class of customer.

The move to SOA and a process-centric way of thinking about IT makes it easier to implement a rules engine as a key part of you enterprise architecture. You can make it part of either an enterprise service bus, using rules to handle content-based routing of messages, or part of a process orchestration tool, with rules choreographing service interactions. In an ideal world, IT departments and development teams would build business services and work with the business to define the processes that link them together, with the process owners defining the rules with a rules engine. As rules are declarative, they can be defined in simple statements: "IF customer_type IS gold THEN discount is 10%". Rules can then be weighted and given dependencies, modelling the decisions made during a business process.

Rules engines work by evaluating collections of facts, and using the results to determine new facts. One approach uses rules to infer the answers to questions of the form "given these facts is this customer a good credit risk?" Others respond to patterns of events, and then act on them. The order the rules are applied doesn't matter - it's the aggregate result that matters.

Some systems work by chaining rules and capturing exceptions, while others "sieve" information through rules and then work with the information that's been left after all the rules have been applied (and of course, it's possible to do both). It's also possible to weight rules so that one set has a higher priority than others. This could be as simple as "300 instances of SKU item A have been sold" triggering an out of stock alert. A more complex reactive engine could be handling multiple information sources (which could include external information sources) to help automate purchasing or sales decisions.

The biggest problem facing anyone wanting to implement a rules engine isn't finding the right technology - there are plenty of tools on the market - instead it's getting the right rules definitions. It's important to capture all the rules currently used (usually as part of a “business process re-engineering” exercise linked to an SOA implementation). However, rules capture isn't simple - rules are as often implicit as they are explicit, relying on experience as well as defined processes.

It's a problem that's been around since the early days of knowledge management and knowledge-based system design. While business rules are often part of a closed domain, so easier to codify, the process of defining the rules that manage a business process can still be slow and tricky. It's important to make sure that rules are agreed, and tested, before they're deployed. While some basic rules and rule sets may work across industries, verticals will often need to develop their own specific sets, relating them to specific business processes and industry standards.

Rules engines are rapidly becoming key components of development frameworks. Java EE has one in the shape of the Java rules engine, defined in JSR 94. Meanwhile .NET developers can take advantage of the Rules Engine that will be delivered with the Windows Workflow Foundation (WF) components of the 3.0 release of the .NET Framework later this year. WF will add a graphical rules development tool to Visual Studio.NET.

If you don't want to roll your own rules code, you can implement any one of many off-the-shelf engines. JBoss Rules is the supported release of the open source Drools project. Built into the Eclipse IDE, its rules can be embedded directly in your Java applications. NET developers don't need to wait for the release of .NET 3.0 and WF, as Ilog has .NET and Java versions of its Rules package, as well as a set of C++ class libraries. At a higher level, Microsoft includes a rules engine in its Biztalk process orchestration platform. Similarly, Fair Isaac's Enterprise Decision Management tools include its Blaze Advisor tool, which adds the ability to work with predictive models to your rule sets.

The world of rules engines is a complex one, but one that will become more and more important to businesses. By mixing declarative programming with a service oriented approach, a business will be able to build flexible infrastructures that can be quickly reconfigured in response to changing business needs. Simple rule changes won't even need the intervention of developers, who'll be able to concentrate on service, workflow and application development and enhancements.

In the next part of this article, we will compare and contrast the commercial rules engines from Ilog and Fair Isaac; together with a side look at JBoss Rules. ®

Top three mobile application threats

More from The Register

next story
This time it's 'Personal': new Office 365 sub covers just two devices
Redmond also brings Office into Google's back yard
Oh no, Joe: WinPhone users already griping over 8.1 mega-update
Hang on. Which bit of Developer Preview don't you understand?
Inside the Hekaton: SQL Server 2014's database engine deconstructed
Nadella's database sqares the circle of cheap memory vs speed
Microsoft lobs pre-release Windows Phone 8.1 at devs who dare
App makers can load it before anyone else, but if they do they're stuck with it
Half of Twitter's 'active users' are SILENT STALKERS
Nearly 50% have NEVER tweeted a word
Internet-of-stuff startup dumps NoSQL for ... SQL?
NoSQL taste great at first but lacks proper nutrients, says startup cloud whiz
Batten down the hatches, Ubuntu 14.04 LTS due in TWO DAYS
Admins dab straining server brows in advance of Trusty Tahr's long-term support landing
IRS boss on XP migration: 'Classic fix the airplane while you're flying it attempt'
Plus: Condoleezza Rice at Dropbox 'maybe she can find ... weapons of mass destruction'
OpenSSL Heartbleed: Bloody nose for open-source bleeding hearts
Bloke behind the cockup says not enough people are helping crucial crypto project
prev story

Whitepapers

Top three mobile application threats
Learn about three of the top mobile application security threats facing businesses today and recommendations on how to mitigate the risk.
Combat fraud and increase customer satisfaction
Based on their experience using HP ArcSight Enterprise Security Manager for IT security operations, Finansbank moved to HP ArcSight ESM for fraud management.
The benefits of software based PBX
Why you should break free from your proprietary PBX and how to leverage your existing server hardware.
Five 3D headsets to be won!
We were so impressed by the Durovis Dive headset we’ve asked the company to give some away to Reg readers.
SANS - Survey on application security programs
In this whitepaper learn about the state of application security programs and practices of 488 surveyed respondents, and discover how mature and effective these programs are.