Lab test: ILOG Rules for .Net meshes well with Microsoft

ILOG brings business rules to .Net while delivering deep integration with Office and SharePoint

JRules, the Java version of ILOG's BRMS (business rules management system), has always run on Microsoft platforms -- and it's done so quite well. Now, with the latest version of ILOG Rules for .Net, ILOG demonstrates that it's truly taken a large gulp of Kool-Aid, having partnered with Microsoft to build a product set that completely embraces .Net.

Built from the ground up with .Net in mind, ILOG Rules for .Net Version 3.0 is a full-featured BRMS that closely follows the Microsoft paradigm: Based on Windows Communication Framework (WCF), it looks and acts just like an enterprise-class application straight out of Redmond -- and delivers tight integration with Microsoft products such as Office and SharePoint. Rules for .Net borrows many of the best features of JRules and is well suited to Microsoft shops.

[For more about ILOG JRules, consult the InfoWorld Test Center review "ILOG JRules 6.5 brings rules to SOA."]

This latest version extends the feature set of its predecessors with the introduction of the Rule Execution Server (RES) and Rule Studio, already present in JRules. Rule Studio is an environment for software developers. RES is the place where business logic is executed. Both products also boast an environment for nontechnical users to maintain rules.

Here, the similarities end, however. Each product is maintained by a separate team within ILOG, and the only component code that is shared is the rule engine itself. Interestingly, ILOG has used a Java-to-C# translator to produce the .Net version of the rule engine. This gives the .Net version of the engine the benefit of the many years of development that went into JRules. They also graciously donated the translator source code to the open source community.

Installation on Windows Server 2003 was straightforward, but there are a number of dependencies. Installing all the prerequisites took the better part of two days, and the process entailed a bit of backtracking: It turns out you need to perform required upgrades in a certain order -- one that doesn't happen to be documented. That said, any shop already using .Net will have gone through this pain and can probably start using Rules.Net with less trouble than I encountered.

Enter the Studio

Based on Microsoft Visual Studio, the Rule Studio provides developers a place to model a business domain and to create and maintain rules. ILOG has added templates, menus, and project types that extend this environment to support creation of business-rule projects, much the same way the company did with Eclipse environment for JRules. Developers familiar with modeling their business domain in Visual Studio can continue to use these tools and easily import .Net class libraries into a rule project. The process of creating business-user-friendly terminology, called "verbalisation," is straightforward and, in some ways, easier than in JRules.

Nearly every feature available in the JRules Rule Studio is available in Rule Studio for .Net. In some cases, I found the .Net versions of these features easier to use than their JRules counterparts. The rule-flow editor, for example, is simpler, allowing drag-and-drop onto a palette; by comparison, the JRules version has an awkward point-move-click paradigm. A minor issue, but illustrative of the fact that these really are two separate product lines.

There are a few notable features lacking in the .Net version of Rule Studio, among them templates and the ability to trace rule execution in Visual Studio. Templates allow developers to set up different classes of rule types, which business analysts can then customize. Rule execution tracing allows developers to watch as rules are being executed. Both of these features are very useful in JRules.

Killer rule execution

The Rule Execution Server (screen image) is a central component to execute and manage business rules in the .Net environment. JRules adopts a J2EE-centric approach to enterprise-class rule engine services by providing JMX, JCA, and other J2EE components. RES for .Net, meanwhile, adopts a Microsoft-centric approach. It uses Windows Communication Foundation (WCF) to provide a reliable communications infrastructure based on the Web services architecture and Microsoft Management Console for administration.

RES is composed of three services: management, persistence, and execution, which are administered just like any other services on a Microsoft platform. These services perform exactly the functions you think they would. Rule sets and data may be persisted to the file system or a database. There are numerous deployment options for the execution service: local, remote, within IIS, single server, multiple servers. All the services are glued together using standard Microsoft technologies, such as Windows Management Instrumentation.

Office integration
Rules for .Net exposes business logic to business analysts using tools they're already familiar with: the Microsoft Office suite. They can manage decision tables in Excel and other decision metaphors in Word (screen image). Version 3.0 of Rules.Net requires Microsoft Office 2007, to which many users may not have upgraded; the integration, however, makes excellent use of 2007 features.

These heavily customized Microsoft Office documents include property panels and extensive error-checking against the business object models created by the IT department, reducing the change that a nontechnical user will make a mistake. Errors are highlighted, both in the text and in an error panel, and include suggestions for corrections. The BOM (Business Object Model) vocabulary is also available for browsing within the documents, simplifying the rule editing task.

Rules requiring team interactions and versioning are managed through SharePoint, already in widespread use in many organizations that have adopted Microsoft Office. Versioning takes place in exactly the same way it does in SharePoint, and permissions can likewise be managed.

Also new in Version 3.0: the use of Microsoft's IntelliSense to create an intelligent, guided editor to help lead business analyst users through the creation and maintenance of business rules.

This Microsoft Office integration, with business rules embedded in the same document as their supporting documentation, is a real boon. Consider the ubiquitous travel policy. Nearly every organization has one. Thanks to the tight integration of Microsoft Office and Rules for .Net, the travel department could specify the travel policy in English for publication to human readers, right alongside the rules that will be implemented by the rules engine that processes the expense reports. This is a very powerful mechanism to keep business policies in sync with the rules that are executed by the engine.

Although the Office integration tools are well put together and appear to be a good idea, time will tell if this feature gains widespread adoption. The idea of business rules spread out into a number of separate documents and managed in SharePoint is one that's going to take some getting used to, and I'm unaware of any large-scale implementations of this feature.

ILOG Rules for .Net 3.0 brings one of the industry's most advanced rules engines to the .Net platform. The combination of .Net integration, Visual Studio, and the capability to author rules directly in Microsoft Office make this one of the best BRMSes in the market for the Microsoft platform. While still a bit rough around the edges, and not quite as full featured as JRules, ILOG and team are making great improvements in this product. I look forward to future versions.

InfoWorld Scorecard
Performance (20.0%)
Value (10.0%)
Documentation (10.0%)
Developer tools (20.0%)
Setup (10.0%)
Rule Management (30.0%)
Overall Score (100%)
ILOG Rules for .Net 3.0 8.0 8.0 9.0 9.0 7.0 8.0 8.2
Join the discussion
Be the first to comment on this article. Our Commenting Policies