Deploying Rule Applications with ILOG JRules

http://logic.stanford.edu/POEM/externalpapers/iRules/WP-JRules6Deployment.pdf

Useful review concerning the three main aspects of rule applications including ZERO development/deployment/administration.

Changing the business rules that govern rating can be done through a “hot deploy” process directly to the production application server, with zero application downtime. Typically, the new business rules will have gone through an extensive testing cycle on a staging server prior to hot deployment to the production server. The support for hot-deployment of rulesets is one of the key features of the Rule Execution Server, and discussed in detail in a subsequent section.

Creating a simple rules engine using the Java scripting API

http://mcqueeney.com/blog/creating-a-simple-rules-engine-using-the-java-scripting-api/

Invoke dynamic languages dynamically, Part 1: Introducing the Java scripting API

Use the javax.script API to change a running application
http://www.ibm.com/developerworks/java/library/j-javascripting1/

Guideline for Deciding WHETHER to use a Rules Engine

Some Guidelines For Deciding Whether To Use A Rules Engine

1. Is your algorithm primarily compute-intensive or is there significant decision-making capability involved?
   • If your basic algorithm is compute-intensive or a table-lookup, without much conditional branching or decision-making involved, then don't use a rules engine.
   • If however, the algorithm involves significant conditional branching or decision-making, then consider using a rules engine.
2. Once you've determined that your algorithm involves significant decision-making capability, you ought to be able to write some rules specifying the decisions that need to be made. Are the decisions that need to be made relatively simple, or potentially complex?
   • If you find that you can't write the decision rules, for whatever reason, then stop here until you can, or use some other tool instead that will help you discover the rules you need. Put another way, if you can't state some rules, don't use a rules engine.
   • If you have 2, or fewer, conditions in your rules (or, for example, a block with 2 nested if-statements or less), don't use a rules engine-it's probably overkill.
   • If you have 3 or more conditions in your rules (or, for example, a block with 3 or more nested if-statements in pseudo-code), then consider using a rules engine.
3. Once you've determined that the decisions are complex enough, is your algorithm basically static, or are the rules likely to change reasonably often over time?
   • If the rules/logic are well-defined and static, then don't use a rules engine-you probably don't need the overhead or flexibility.
   • If the rules are likely to change over time due to the nature of the application, then consider using a rules engine-the flexibility is worth the overhead.
4. Once you've determined that rules may need to be flexible, are you going to maintain the code or finished product over time, or is this effort a one-shot effort?
   • If the code is not going to be maintained over time, then don't use a rules engine-you probably won't gain any significant advantage from it.
   • If the code is going to be maintained over time, consider using a rules engine-the ROI will be worth it (see question #6).
5. Rules engines continue to get faster and faster, but some applications simply require every bit of speed and performance optimization you can reasonably give. Does your customer require a custom solution or do you need to hard-wire the algorithm for absolute high-end performance, or can the solution accommodate a rules engine?
   • If you need to optimize for speed and memory, or your customer requires a custom solution, then don't use a rules engine.
   • If the performance requirements will accommodate a rules engine solution, then consider using one.
6. If you answered all the other questions appropriately, can the project/product line afford the overall cost of using a rules engine over the project/product lifecycle?
   • There are a number of costs typically associated with using rules engine tools:
     • Licensing fees for development and deployment of the engine
     • Training developers and (if necessary) end-users (time and money)
     • ROI (return on investment)-financial analysts have shown that you don't begin to break even monetarily on the typical investment in rules engine technology until at least 1 year after deployment to your customer. However, at that point, the flexibility and ease-of-maintenance begin to show significant returns.
   • If the project schedule or product lifecycle can't accommodate the cost of a rules engine, in terms of time and money, then don't use one.
   • If you can't afford to wait at least a year to break even and begin to see a significant ROI, don't use a rules engine.
   • If you can't afford to train your developers and end-users, and you can't afford to hire a consultant, don't use a rules engine.
   • If, however, your project/product lifecycle costs can accommodate the use of a rules engine, it would be well worth the investment, so use one.

Additional Note

A rules engine tool can be very helpful during software development, regardless of other considerations:

• For simulation and prototyping.
• In cases where you find you may not really know or understand the rules you are trying to encode in your algorithm, a rules engine can provide a flexible way to encode and modify the rules over time as they are discovered.
• A rules engine architecture also provides a convenient structure for separating "business logic" from the rest of the system, aiding in the effort to clearly "separate concerns".