ILOG JRules 6.5 brings rules to SOA

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 simple
I'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.