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

• Glosario básico de Drools

• Desafíos con Drools

• Soporte débil para reglas y datos relacionados que cambian frecuentemente

• Redundancia y gestión ineficiente de reglas

• Expresividad limitada y curva de aprendizaje pronunciada

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

• Conclusión

• Ve Oscilar en acción, agenda 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 soporta el estándar API de motor de reglas Java 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 fue integrado en JBoss como parte de su oferta JEMS y rebautizado como JBoss Rules. En 2006, JBoss fue adquirido por Red Hat y en 2007 fue renombrado nuevamente a Drools.

Glosario básico de Drools

A continuación se presentan algunos de los conceptos básicos en Drools:

Lenguaje de Reglas de Drools

El Lenguaje de Reglas de Drools o 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 de la regla en una forma cuando-entonces.

Regla

Una Regla consiste en una condición que activa la regla (cuando) y una consecuencia que realiza acciones (entonces) cuando se activa. Asocia hechos con acciones coincidentes. Como mencionamos en el blog anterior, las reglas de negocio solo pueden ser verdaderas o falsas.

Hechos

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

Memoria de trabajo

La memoria de trabajo es el almacenamiento que contiene hechos. La memoria de trabajo permite que un motor de negocio use los hechos para el emparejamiento de patrones. Los hechos también pueden modificarse, insertarse y eliminarse de la memoria de trabajo.

Base de conocimiento

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

Sesión de conocimiento

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

Pueden haber sesiones de conocimiento sin estado y con estado.

Las sesiones de conocimiento sin estado tienen hechos o una memoria de trabajo insertada en ellas, lo que significa que se crea una nueva sesión para cada solicitud, mientras que las sesiones de conocimiento con estado mantienen las sesiones antiguas, continuando donde la anterior lo dejó.

Módulo

Un módulo contiene múltiples bases de conocimiento, que 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, presenta algunos desafíos también.

Soporte débil para reglas y datos relacionados que cambian frecuentemente

El desafío principal 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 tales como DRLs, archivos excel de tablas de decisión formen parte del binario de la aplicación en sí. Eso significa que los artefactos deben estar presentes en el repositorio de código fuente o extraerse de él durante el proceso de construcción de la aplicación. Esto se vuelve engorroso con reglas que cambian frecuentemente; cada cambio de regla requiere agregar o modificar los artefactos de reglas, construir el código de la aplicación y desplegarlo en servidores de producción.

La regla DRL usa objetos de datos Java para recuperar hechos o un conjunto de resultados. Al igual que las reglas DRL, crear y usar nuevos objetos de datos también requiere modificación de código y despliegue. Como resultado, Drools generalmente funciona bien con un conjunto de datos estáticos en lugar de uno dinámico. Sin embargo, la mayoría de los casos de uso del mundo real requieren conjuntos de datos dinámicos para una toma de decisiones precisa. Por ejemplo, la mayoría de las decisiones de suplantación de cuentas requieren datos multidimensionales sobre el historial de actividades del usuario y acciones recientes, que cambian rápidamente tras bastidores.

Esta dependencia del código—y la consecuente construcción y despliegue—tanto para las reglas como para los datos relacionados, ralentiza significativamente la velocidad de iteración de 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 la toma de decisiones empresariales.

Redundancia y gestión ineficiente de reglas

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

Expresividad limitada y curva de aprendizaje pronunciada

Drools tiene su propio DSL basado en Java con una curva de aprendizaje no trivial, mientras que la mayoría de la comunidad de ciencia de datos tiene antecedentes en Python. El DSL de Drools también es limitado en su poder expresivo. Por ejemplo, Drools tiene soporte limitado para algunas funciones matemáticas comunes como factoriales, máximo común divisor que son útiles en la práctica. Para abordar este desafío, Drools permite el desarrollo de "DSLs personalizados", pero nuevamente, están limitados por el soporte de reglas subyacente.

Construyendo un sistema moderno de gestión de reglas basado en Drools

Dado el entendimiento de los desafíos impuestos por Drools, veamos qué falta en Drools para facilitar su aplicación pragmática:

• Base de datos de reglas: Una manera 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 reconstruya programáticamente los objetos de Drools basados en cambios en las reglas, eliminando así la necesidad de modificar el código. Tal servicio de reglas también debe permitir el despliegue rápido de nuevos cambios en las reglas sin desplegar o reiniciar aplicaciones. Así, debe construir la gestión del código fuente de las reglas junto con una pipeline CI/CD para hacer cambios en la base de datos central de reglas.

• Base de datos de conocimiento o características: Una manera de integrar datos de características a través de herramientas de terceros, bases de datos, lagos de datos y otras aplicaciones en una base de datos central de características, eliminando la necesidad de almacenar todos los hechos que usan las reglas en la memoria y potenciando la capacidad de probar con datos históricos nuevos cambios de reglas.

• Servicio de características: Una base de conocimiento central o servicio de características con una API REST que acepte características o hechos en un formato común y responda con cualquier dato requerido por las reglas.

• Análisis de reglas: Gestión y monitoreo central de reglas para evaluar su rendimiento a lo largo del tiempo y saber cuándo evolucionarlas.

• Despliegue canario: Cualquier uso pragmático de un motor de reglas para producción requiere un despliegue cuidadoso de nuevas reglas. Este proceso comienza con pruebas con datos históricos, seguido por el despliegue de la regla en modo sombra, seguido por un despliegue gradual canario de la regla antes de que procese el 100% de los datos disponibles.

• Automatización sin código: Una interfaz que permita a los analistas de negocio y cualquier persona que no sea desarrolladora evolucionar fácilmente reglas basadas en nuevas señales y casos de uso, sin escribir código.

Como podría quedar claro en la descripción anterior, construir un sistema moderno de gestión de reglas de negocio—o motor de decisión—es una proposición sustancial que requiere experiencia profunda.

Conclusión

Drools es una buena pero baja abstracción para un motor de reglas y no un sistema moderno de gestión de reglas de negocio. Como tal, requiere construir numerosas capacidades para convertirlo en una solución de decisión integral.

Oscilar es un motor de decisión moderno en tiempo real sin código. Automatiza la creación, enriquecimiento y análisis de hechos o características personalizadas, combinado con un motor de reglas que ejecuta reglas de manera sincrónica o asincrónica, y ofrece una interfaz fácil de usar para pasar de una nueva característica a una nueva regla en minutos.