title: Prefered methods for interacting with a rules engine
body: <p>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.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p><strong>Question:</strong> 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?</p>