Introducción al motor de reglas Drools

Esta publicación de blog es la segunda parte de una serie sobre motores de reglas de negocio. La Parte 1 cubrió en detalle los motores de reglas de negocio: qué son, cómo funcionan y por qué podrías necesitar uno. Esta publicación ofrece una visión general de un motor de reglas específico llamado Drools y cómo construir un sistema moderno de gestión de reglas de negocio utilizándolo:

• Glosario básico de Drools

• Desafíos con Drools

• Soporte deficiente para reglas y datos relacionados que cambian con frecuencia

• Redundancia y gestión ineficiente de reglas

• Expresividad limitada y curva de aprendizaje pronunciada

• Construcción de un sistema moderno de gestión de reglas de negocio basado en Drools

• Conclusión

• Ver Oscilar en acción, programar una demostración

¿Qué es Drools?

Drools es una biblioteca de reglas con un motor de reglas basado en encadenamiento hacia adelante y hacia atrás. Utiliza una implementación mejorada del algoritmo Rete y es compatible con el estándar Java Rules Engine API para su motor de reglas.

Una breve historia

El proyecto Drools fue iniciado por Bob McWhirter en 2001 como un proyecto de SourceForge. En 2005, Drools se integró en JBoss como parte de su oferta JEMS y pasó a llamarse JBoss Rules. En 2006, JBoss fue adquirida por Red Hat y en 2007 volvió a llamarse Drools.

Glosario básico de Drools

Estos son algunos de los conceptos básicos en Drools:

Drools Rule Language (Lenguaje de reglas de Drools)

El lenguaje de reglas de Drools o reglas DRL son reglas de negocio definidas en archivos de texto .drl. Un archivo DRL puede tener una o más reglas que definen las condiciones y acciones en un formato "si/entonces" (when-then).

Regla

Una regla consta de una condición que la activa (when) y una consecuencia que ejecuta acciones (then) cuando se activa. Asocia hechos con acciones correspondientes. Como mencionamos en el blog anterior, las reglas de negocio solo pueden ser verdaderas o falsas.

Hechos (Facts)

Las reglas de negocio se componen de hechos, y los hechos representan datos que sirven como información para las reglas.

Memoria de trabajo (Working Memory)

La memoria de trabajo es el almacenamiento que contiene los hechos. Permite que el motor de negocio utilice hechos para la coincidencia de patrones. Los hechos también se pueden modificar, insertar y eliminar de la memoria de trabajo.

Base de conocimientos (Knowledge Base)

La base de conocimientos es una interfaz que gestiona una colección de reglas, tipos internos y procesos, y representa el conocimiento del ecosistema de Drools. Las sesiones de conocimiento se crean utilizando la base de conocimientos.

Sesión de conocimiento (Knowledge Session)

La sesión de conocimiento contiene todos los recursos necesarios para activar las reglas. Los hechos se insertan en una sesión y luego se activan las reglas correspondientes.

Puede haber sesiones de conocimiento sin estado (stateless) y con estado (stateful).

Las sesiones de conocimiento sin estado reciben hechos o una memoria de trabajo y crean una nueva sesión para cada solicitud, mientras que las sesiones con estado mantienen las sesiones anteriores, continuando donde quedó la anterior.

Módulo

Un módulo contiene múltiples bases de conocimientos, las cuales ayudan a crear sesiones de conocimiento.

Desafíos con Drools

Aunque Drools te permite definir y gestionar las reglas de negocio fuera de tu código, también presenta algunos desafíos.

Soporte deficiente para reglas y datos relacionados que cambian con frecuencia

El principal desafío con Drools es la falta de soporte para reglas que cambian con frecuencia. Generalmente, una aplicación Java basada en Drools requiere que todos los artefactos de reglas (como archivos DRL o tablas de decisión en Excel) formen parte del binario de la aplicación. Esto significa que los artefactos deben estar en el repositorio de código fuente o descargarse de él durante el proceso de compilación. Esto se vuelve tedioso cuando las reglas cambian a menudo, ya que cada modificación requiere añadir o cambiar los artefactos de reglas, compilar el código de la aplicación y desplegarlo en los servidores de producción.

Las reglas DRL utilizan objetos de datos de Java para recuperar hechos o un conjunto de resultados. Al igual que con las reglas DRL, crear y utilizar nuevos objetos de datos también requiere modificar el código y realizar un despliegue. Como resultado, Drools suele funcionar bien con conjuntos de datos estáticos en lugar de dinámicos. Sin embargo, la mayoría de los casos de uso reales requieren datos dinámicos para tomar decisiones precisas. Por ejemplo, la mayoría de las decisiones sobre robo de cuentas requieren datos multidimensionales sobre el historial de actividad y las acciones recientes del usuario, los cuales cambian rápidamente de fondo.

Esta dependencia del código —y la compilación y despliegue resultantes— tanto para las reglas como para los datos relacionados, ralentiza significativamente el ritmo de iteración en la toma de decisiones.

Además de limitar su efectividad para resolver problemas del mundo real, esto también ralentiza el tiempo de respuesta para las decisiones de negocio.

Redundancia y gestión ineficiente de reglas

Las mismas reglas de negocio pueden aplicarse en diferentes aplicaciones y servicios, lo que genera redundancia y desafíos de gobernanza. Drools traslada al usuario la carga de mantener sincronizados las reglas y los archivos DRL. Esto obliga a construir herramientas para gestionar las reglas en un repositorio de código fuente, junto con un servicio de reglas que gestione las actualizaciones y las distribuya, lo que requiere la propiedad y el mantenimiento de un servicio de reglas centralizado. Además, este servicio de reglas debe probar y evaluar los posibles efectos secundarios de cada cambio en las reglas, lo que representa una carga considerable para el usuario de Drools.

Expresividad limitada y curva de aprendizaje pronunciada

Drools tiene su propio DSL basado en Java con una curva de aprendizaje importante, mientras que la mayoría de la comunidad de ciencia de datos utiliza Python. El DSL de Drools también tiene un poder expresivo limitado. Por ejemplo, Drools ofrece un soporte limitado para algunas funciones matemáticas comunes como factoriales o el máximo común divisor, que son útiles en la práctica. Para solucionar este problema, Drools permite el desarrollo de "DSLs personalizados", pero estos siguen estando limitados por el soporte de reglas subyacente.

Construcción de un sistema moderno de gestión de reglas de negocio basado en Drools

Teniendo en cuenta los desafíos que presenta Drools, veamos qué le falta para facilitar su aplicación práctica:

• Base de datos de reglas: Una forma de almacenar todas las reglas fuera del binario de la aplicación en un sistema externo como una base de datos.

• Servicio de reglas: Un servicio de reglas con una API REST que vuelva a compilar mediante programación los objetos de Drools según los cambios en las reglas, eliminando la necesidad de modificar el código. Este servicio también debe permitir implementar rápidamente nuevos cambios en las reglas sin necesidad de desplegar o reiniciar aplicaciones. Por lo tanto, debe integrar la gestión del código fuente de las reglas con un flujo de CI/CD para enviar los cambios a la base de datos de reglas central.

• Base de datos de conocimientos o variables (Features): Una forma de integrar datos de variables de herramientas de terceros, bases de datos, lagos de datos y otras aplicaciones en una base de datos centralizada, eliminando la necesidad de almacenar en memoria todos los hechos que utilizan las reglas y permitiendo realizar pruebas retrospectivas (backtesting) de los nuevos cambios.

• Servicio de variables (Features): Una base de conocimientos central o servicio de variables con una API REST que reciba variables o hechos en un formato común y responda con cualquier dato requerido por las reglas.

• Analítica de reglas: Gestión y supervisión centralizada de las reglas para evaluar su rendimiento a lo largo del tiempo y saber cuándo deben actualizarse o evolucionar.

• Despliegue canary (Canary rollout): Cualquier uso práctico de un motor de reglas en producción requiere un despliegue cuidadoso de las nuevas reglas. Este proceso comienza probando las reglas con datos históricos, seguido de la implementación de la regla en modo espejo (shadow mode) y, finalmente, un despliegue gradual (canary) de la regla antes de que procese el 100% de los datos disponibles.

• Automatización sin código (No-code): Una interfaz de usuario que permita a los analistas de negocio y a cualquier persona sin conocimientos técnicos actualizar fácilmente las reglas en función de nuevas señales y casos de uso, sin tener que escribir código.

Como se puede ver en la descripción anterior, construir un sistema moderno de gestión de reglas de negocio (o motor de decisiones) es un proyecto de gran envergadura que requiere una profunda experiencia técnica.

Conclusión

Drools es una abstracción buena pero de bajo nivel para un motor de reglas, y no un sistema moderno de gestión de reglas de negocio. Por lo tanto, requiere construir múltiples funcionalidades adicionales para convertirlo en una solución integral de toma de decisiones.

Oscilar es un motor de decisiones moderno en tiempo real y sin código. Automatiza la creación, enriquecimiento y analítica de variables o hechos personalizados, combinándolo con un motor de reglas que las ejecuta de forma síncrona o asíncrona, y ofrece una interfaz de usuario fácil de usar para pasar de una nueva variable a una nueva regla en cuestión de minutos.