ILOG JRules Version 6.5 is primarily a refinement of the architecture and features first introduced in Version 6.0. With the 6.x line, ILOG adopted the basic architecture seen across the BRMS (Business Rules Management System) industry. As such, JRules combines a rule engine deployed and managed as a stand-alone module (Rule Execution Server); a rule repository for sharing, versioning, and reporting on rules (Rule Team Server); and a set of authoring tools for both business users and technical staff to interact with the repository (Rule Studio).

Click for larger view.

This application architecture reflects the commoditization of the rule execution engines: Dozens of rule engines are on the market these days. The difference between the major vendors (ILOG, Fair Isaac, and a few others) and the open-source engines is the maturity of the tools supplied for integrating business rules into the enterprise and managing the rules, and the ease with which nontechnical analysts can use them.

The 6.5.2 release of ILOG JRules I tested contains the usual slew of bug fixes, some refinements to existing features, and adds the capability of building, deploying, and managing rule-based decision services within an SOA environment. Note: At the time this went to press, ILOG released Version 6.6.

Rule services made simpleI'll start with the most exciting feature first: the capability of easily deploying rule services as part of an SOA. Although this had been possible in previous versions, it required a rather involved deployment process and was beyond the abilities of most technical analysts. With 6.5, business rules may be deployed into a SOA with zero code development and then updated by business users from the browser using Team Server. This feature, referred to as TDS (Transparent Decision Services)by ILOG, elevates business decision services to first-class citizens within a service-oriented architecture.

There are a few limitations to TDS: It provides only SOAP/HTTP based services, and it only works if the Business Object Model has been defined in XML. These days, with SOA being adopted more widely, the latter isn't a significant limitation. On the other hand, having only SOAP/HTTP limits the usefulness of TDS to point-to-point solutions. With a bit of programming, developers can create a JMX (Java Management Exension) MBean (Managed Bean) that will appear in the Rule Execution Server console as a JMS (Java Message Service)-based decision service, but it's not the kind of zero-coding option that TDS provides for point-to-point Web services.

Click for larger view.

All that said, this is still a big step in the right direction, and I hope that ILOG will continue to improve TDS. Allowing business users to directly manage rule services in an SOA, without relying on developers to make changes, makes the business much more responsive to a changing environment.

The flip side of putting rule management into the hands of business owners is increased risk of mistakes. Testing becomes more important. RSM (Rule Scenario Manager), the optional testing module for JRules, sees a few minor enhancements to usability. RSM has great potential, although I hope to see further improvements to usability in future versions. Having a mechanism to test business rules to ensure operational compliance (BASEL II, SOX, etc.) is essential, and RSM makes this much easier than writing JUnit tests. However, the tool is still suitable only for technical staff. In order to be truly useful, RSM should allow business analysts -- the folks who truly own the business rules -- to test rules and run simulations and scenarios on their own. RSM is also inflexible in its methodology. For example, rule-testing artifacts should be stored and versioned along with the rules themselves, but RSM handles them separately.

RTS (Rule Team Server), the authoring environment, contains improvements to the way business analysts locate business rules during the maintenance cycle of business rules. This "Semantic Query" feature allows users to write simple rules that locate other rules, and to find rules without knowing the structure of the repository. Users may search for rules that have a particular condition ("Find all business rules such that each business rule uses the value of loan amount") or action ("Find all business rules such that each business rule may lead to a state where a loan is rejected). Plus, the queries may be authored using a GUI environment very similar to that used to author business rules.

Click for larger view.

Performance ranking for JRules has not changed since the review of JRules 6.1 by James Owen. In optimized mode, JRules has good performance overall, but it is not at the top of the pack. For example, see the accompanying chart of WaltzDB test results, which shows optimized JRules ahead of JBoss Rules and Jess but behind Blaze Advisor and CLIPS. We performed all of our tests on a machine with an Intel Pentium 4 CPU 2.40GHz processor and 1GB of RAM, with all figures averaged over five runs of the benchmark. We tested on Linux, Solaris, and Windows, and no significant differences emerged across operating systems. The results shown come from tests on Solaris.

Bumps in the roadA few areas still need smoothing. I've mentioned the documentation before, and this hasn't improved in 6.5.2. Although ILOG provides an applet for searching the documentation, this search mechanism just doesn't do as good a job as the old CHM (Microsoft Compiled HTML Help)manuals did. With such a large documentation set it's essential to allow users to easily find what they need, when they need it. A documentation road map would be a nice start. Tuning the search engine to identify higher-level, rule-oriented concepts (through metatags or good old-fashioned indexing) would also be helpful. The existing search engine is just too rudimentary, and it returns many pages of the same keyword. ILOG is aware of the problem and does have several people working to on it, so we can look forward to some improvement in future versions.

My other minor gripe is with the ruleflow and decision table editors. These two components still have some of the same quirks from JRules 5.x, and I hoped they'd be straightened out by now. The ruleflow editor especially could use some improvement. The current system of click and point for some artifacts and drag and drop for others, combined with menus that appear in odd places and icons that lose focus, not only impairs usability but is downright annoying. The ruleflow editor is also quite memory intensive; when used on Team Server, memory usage soared to 345MB of real RAM and 1.45GB of virtual memory. CPU usage also shot up to nearly 100 percent.

One welcome addition would be a floating palette that allows you to drag and drop all components onto the diagram. In the end, the ruleflow editor and decision tables work well enough to do the job, but they stand out as lacking polish in what is otherwise a very usable interface.

JRules6.5 brings a significant enhancement with the introduction of Transparent Decision Services, albeit only for SOAP over HTTP. Most parts of the system have received additional polish and improvements over 6.1, with the exception of the documentation. For those organizations implementing SOA, the transparent decision services alone are worth the upgrade. For any JRules shop still running 5.x, the enhancements to the Team Server warrant a serious look at the 6.x line.