R – Prefered methods for interacting with a rules engine

rule-enginewebsphere

I am about to dive into a rules oriented project (using ILOGs Rules for .NET – now IBM). And I have read a couple different perspectives regarding how to set up the rules processing and how to interact with the rule engine.

The two main thoughts I have seen is to centralize the rule engine (into its own farm of servers) and program against the farm via a web service API (or in ILOG's case via WCF). The other side is to run an instance of the rule engine on each of your app servers and interact with it locally with each instance having its own copy of the rules.

The up side to centralization is the ease of deployment of the rules to a centralized location. The rules scale as they need to rather than scaling each time you expand your application server configuration. This reduces waste from a purchased license perspective. The down side to this set up is the added overhead of making service calls, network latency, etc.

The upside/downside to locally running the rule engine is the exact opposite of the centralized configuration's upside/downside. No slow service calls (fast API calls), no network issues, each app server relies on it self. Managing deployment of rules becomes more complex. Each time you add a node to your app cloud you will need more licenses for rule engines.

In reading white papers I see that Amazon is running the rule engine per app server configuration. They appear to do a slow deployment of rules and recognize that the lag in rule publishing is "acceptable" even though business logic is out of a sync for a given period of time.

Question: From your experiences, what is the best way to start integrating rules into a .net based web app for a shop that has not yet spent much time working in a rules driven world?

Best Answer

We're using ILOG For DotNet and have a deployed pilot project.

Here's a summary of our immature Rules Architecture:

  1. All data-access done outside of rules.
  2. Rules are deployed the same way as code (source control, release process, yada yada).
  3. Projects (services) that use Rules have a reference to ILOG.Rules.dll and new-up RuleEngines via a custom pooling class. RuleEngines are pooled because it is expensive to bind a RuleSet to a RuleEngine.
  4. Almost all rules are written to expect Assert'd objects, rather than RuleFlow parameters.
  5. Since the rules run in the same memory space, instances that are modified by the rules are the same instances in the program - which is immediate propagation of state.
  6. Almost all rules are run via RuleFlow (even if it is a single RuleStep in the RuleFlow).

We're looking at RuleExecutionServer as an hosting platform as well as RuleTeamServerForSharePoint to be the host for rules source. Eventually, we will have Rules deployed to production outside of the code release process.

The primary obstacle in all our Rule endeavors is Modeling and Rule Authoring skillsets.

Related Topic