Jeff, My two cents worth and likely stating the obvious...
Once you decide that you want to use a rule engine, be sure your execution is as good as your decision. Some things that can help are: Make a clear distinction between policy and mechanism -- which is just another way of saying that you need good rule design. This is true whether or not you implement your rules using java or jess code and is the most important design constraint you can make. For obvious reasons, your policy belongs in the rules and the mechanisms to support them belong in java. To make the argument to management, and to the team, identify the most complex part of your system and create two quick and dirty prototypes, one using java only and one using jess -- often the jess implementation can reuse the java-only components. Next, go through the process of adding another requirement or aspect to the system. Compare the process and first convince yourself that moving forward using jess is simpler and more transparent. Pay careful attention to how the design might enhance parallel development and validation and to what kinds of defects you introduce and fix as you proceed. Then, and only then, take your case to others. FUD can be hard to fight without a concrete example on your side. Try not to let your rules don't rely too much on implicit control structures, like salience for example. Take the time to design some explicit system/computation state components, or use modules or other strategies that can be employed to partition your rules and to control their activation, etc. This advice may be controversial among some rule purists but it has helped me immeasurably. Also, you need a clear strategy, or pattern, for interaction between your jess code and your java code. This invariably includes control strategies, threading requirements, data modeling, synchronous vs. asynchronous operations, etc. Think long and hard about your architectural requirements and how they might affect this strategy. If you have done your homework right, the java code in your system will not even be aware that a rule engine is being employed. Doing this will reduce the frustration that can arise in the java-only camp. Those engineers who do not take to the jess coding style would be more effective if they built the java code to support the other engineers who are adept at using jess. This often includes persistent storage, interfaces to external systems, complex calculations, data centric manipulations, high performance components, etc. Depending on your talent pool and target system, you are better off with fewer rule engineers and more java support than the other way around. Also, no matter what, be sure everyone is or becomes competent in java first. Especially, don't try to throw in an EJB container for good measure unless your goal is to home grow a number expert EJB engineers in-house. There are simpler alternatives to EJB if your requirements allow them. Good luck! alan -----Original Message----- From: Jeff Richley [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 01, 2003 6:22 AM To: [EMAIL PROTECTED] Subject: JESS: Is it for me... I have a project that has roughly 10,000 business rules. Another major factor is that there are 13 programmers (not including myself) and I am the only one that has ever programmed in Java. The powers that be have decided that we are going to write the entire program in Java. There are some very good reasons for this decisions that I won't go into right now. My question is, would JESS be a good solution for all of these rules. I haven't really gotten a good handle on exactly what is required to use Jess. Is this something that I would be able to give a statement like "if all of the planes were unmanned then field x must be equal to 'q'"? Or is it something that I would actually have to program that statement? __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://platinum.yahoo.com -------------------------------------------------------------------- To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]' in the BODY of a message to [EMAIL PROTECTED], NOT to the list (use your own address!) List problems? Notify [EMAIL PROTECTED] -------------------------------------------------------------------- -------------------------------------------------------------------- To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]' in the BODY of a message to [EMAIL PROTECTED], NOT to the list (use your own address!) List problems? Notify [EMAIL PROTECTED] --------------------------------------------------------------------
