Respuestas:
¿Cuáles son los pros y los contras de adoptar los motores de reglas Java JESS y Drools?
Utilice un motor de reglas si necesita separar las reglas comerciales de la lógica de la aplicación. El artículo ¿Necesita su proyecto un motor de reglas? Tiene un buen ejemplo:
Por ejemplo, un sistema de escaparate típico puede incluir un código para calcular un descuento:
if (product.quantity > 100 && product.quantity < 500) { product.discount = 2; } else if (product.quantity >= 500 && product.quantity < 2000) { product.discount = 5; } else if (product.quantity >= 2000) { product.discount = 10; }Un motor de reglas reemplaza lo anterior con un código que se ve así:
ruleEngine.applyRules(product);
Depende de usted decidir si poner una consola de administración de reglas en manos de personas sin conocimientos técnicos es algo bueno o no :)
Más detalles en ¿Debería usar un motor de reglas? , ¿Por qué utilizar un motor de reglas? , Algunas pautas para decidir si usar un motor de reglas y en Google .
¿Hay otros jugadores?
Otros jugadores incluyen JRules, Corticon (JRules es el IMO más famoso, lo que no significa el mejor).
¿Cómo se comparan en otras áreas como facilidad de uso, rendimiento, nivel de integración con su código?
No puedo decirte con precisión, solo tengo una pequeña experiencia (positiva) con Drools. Pero obtendrá algunos comentarios de publicaciones de blogs como JBoss Drools vs ILog JRules: una historia anecdótica (asegúrese de leerla) o Trabajar con Drools desde la perspectiva de JRules . Estoy seguro de que puedes encontrar más de ellos en Google (pero le daría una oportunidad a Drools).
Estamos evaluando reglas ahora para su uso con nuestro servidor de aplicaciones. Nos hemos encontrado con OpenRules , que es fácil de integrar con Java y, según han demostrado nuestras pruebas, lo suficientemente rápido. La principal ventaja de OpenRules sobre las demás es la forma en que se modifican y manejan las reglas. Todo sucede en tablas de Excel, que es la forma más sencilla para los no programadores. Todos los involucrados, incluso las personas no técnicas, entendieron todo perfectamente :-)
También tenemos babas integradas, pero las reglas son mucho más complicadas de entender ya que es un enfoque más programático. Es por eso que, muy probablemente, nos ceñiremos a OpenRules.
Tuvimos una pregunta similar con nosotros, finalmente recogimos Drools, uno debe usar babeo si tiene lo siguiente:
Tenga más detalles en la siguiente URL
Solo agrego que muchas personas buscan algo más parecido a administrar si se cumplen ciertas condiciones para habilitar o deshabilitar ciertas funciones en una aplicación.
Me cansé de volver a implementar el mismo patrón una y otra vez en todos los lugares a los que iba, así que decidí hacer un proyecto de OSS para él llamado Roolie http://sourceforge.net/projects/roolie/
Lo acabo de mejorar y, dado que no se han informado errores desde 2010 cuando se lanzó, lo actualicé a la versión 1.0 sin cambios más que los necesarios para alojarlo en Maven Central (que estoy en proceso de hacer ).
Básicamente, JSR-94 es excesivo para la mayoría de las cosas, y hay una gran curva de aprendizaje y gastos generales que van de la mano con las ofertas actuales. Está bien si eso es lo que quieres. Pero si solo desea encadenar reglas simples escritas en Java junto con XML para mantener sus pruebas de estado, Roolie es una forma muy rápida de hacerlo. Sin dependencias y sin curva de aprendizaje.
Cuando necesitábamos un motor de reglas, decidimos lanzar el nuestro, porque los disponibles eran demasiado complicados para nuestras tareas simples. Si tiene experiencia incluso remotamente con el análisis de expresiones que los usuarios pueden introducir, esto no es muy difícil de hacer. En nuestro caso, la mayor parte de las especificaciones son manejadas por un XSD y solo algunos de los campos se analizan más.