Escribiendo reglas de negocio con motores de reglas

Hace ya algunos años que el paradigma de motores de reglas está aceptado como algo más allá del concepto de inteligencia artificial. Hoy por hoy el mercado entiende a los motores de reglas como una forma de aislar la lógica negocio por fuera del desarrollo de código.

¿Que virtudes guarda el desarrollar las reglas de negocio en un motor de reglas?

En primera instancia los motores de reglas nos permiten pasar de un modelo imperativo de desarrollo a un modelo declarativo, este modelo es más simple en la codificación porque describimos que hacer no como…. en teoría.

¿Por qué los programadores tienen la tendencia a usar mecanismos provistos por el software para ordenar la ejecución de las reglas?, priorizaciones, agrupaciones, banderas (todos elementos para el control de flujo de las reglas). Simplemente porque estamos acostumbrados a programar dando instrucciones a las máquinas de CÓMO actuar.

Independientemente del modo de programación nos encontramos con que los motores de reglas nos ilusionan con que vamos a poder poner al experto delante de una aplicación administradora de reglas y podremos adaptar el negocio sin necesidad de programación. Aquí surgen dos inconvenientes:

1 .- La interfaz entre el sistema y las reglas no se ajusta a los cambios que necesitamos

En la mayoría de los cambios de reglas se requiere nuevos datos o nuevas acciones, si estos no están predefinidos en la invocación al motor de reglas difícilmente podamos hacer inferencia sobre ellos.

2.- La interfaz de usuario para escribir las reglas requiere de conocimientos de programación.

Las tecnologías disponibles hoy en día facilitan pero no resuelven las problemáticas de requerir conocimiento técnico para la escritura de reglas. Se están realizando muchas investigaciones para la interpretación del lenguaje natural, hay investigaciones muy interesantes respecto a la interpretación en dominios específicos, como por ejemplo “Rule extraction in gene–disease relationship discovery” by Wen-Juan Hou and Hsiao-Yuan Chen from Department of Computer Science and Information Engineering, National Taiwan Normal University, Taipei, Taiwan

Ante estos inconvenientes ¿por qué utilizaríamos un motor de reglas?

Esta es mi versión de la respuesta basado en mi experiencia.

Respecto a la dudosa proposición “las reglas las escribe el experto” mi postura es que debemos buscar patrones de uso que nos permitan agrupar las reglas de modo tal que pueda segmentar conjuntos de reglas simples modificables por el experto y otro conjunto de reglas complejas que son modificadas por el desarrollador, un patrón que suelo aplicar y que me ha sido útil en muchos escenarios es el de tener un conjunto de reglas que generan el contexto y un conjunto reducido de reglas que ejecutan las consecuencias. (Separate context inference from validation pattern)

Ejemplo de separación de inferencia y validación

Separate context inference from validation pattern example

Este enfoque nos permite hacer uso de diferentes técnicas que limitarían a un programador pero que facilitan mucho la escritura de reglas (tablas de decisión, lenguajes específicos de dominio, interfaces gráficas de escritura de reglas, traductores automáticos).

Si prestamos atención a la problemática de modificación del código cuándo cambio las reglas el enfoque que más resultado me ha dado es “inserta todo lo que puedas al contexto”, a partir de eso y de la mano de lo hablado en el párrafo anterior es una buena estrategia que exista un conjunto de reglas que inicialmente armen el contexto. La variable a tener en cuenta aquí es: MEMORIA, cuántos elementos podemos mantener con los recursos de hardware disponibles.

Por otro lado el hecho de tener separadas las reglas nos facilitan el mostrarlas y el relacionarlas con la definición formal que tenga la compañía. Mostrarlas desde el punto de vista que es mucho más legible una regla que un segmento de código, por lo que aunque necesitemos un programador al lado un experto puede leer las reglas.

Respecto a la trazabilidad desde la documentación a la regla es más simple enumerar las reglas relacionadas a un documento funcional, proceso, etc que indicar las líneas de código.

 

Conclusión

  • Debemos establecer lineamientos de uso que impidan desarrollar reglas en forma imperativa, debe evitarse a toda costa el uso de priorizaciones (toda intención de uso debe verse como un posible error o una excepción).
  • Podemos tener real acercamiento del experto a las reglas de negocio, en el peor de los casos de la mano de un desarrollador que le dé soporte.
  • Las reglas están aisladas y por ende más fácil de gobernar.
  • Puedo tener traza de la definición a la implementación.

Un tema importante es que estamos dejando de lado la principal fortaleza de los motores de reglas que es su uso como motor de inferencia. Podemos decir en consecuencia que bajo criterios de gobernabilidad, uso y potencialidad el escribir las reglas de negocio de la compañía utilizando motores de reglas no debería generar dudas.

Advertisements

Great PaaS comparison between OpenShift and Google AppEngine

Trabajando con un equipo de profesionales me encontré con la necesidad de entender las diferencias y beneficios de dos de las tecnologías de Paas más importantes del mercado.

Dentro de ese trabajo se analizó uno de los aspectos  por los cuales las soluciones de cloud son las adecuadas, la elasticidad, es decir la capacidad de ajustar la infraestructura a la demanda que tiene el software en un determinado momento.

Este trabajo se basó en plantear una serie de escenarios y comprobar el comportamiento del servicio. Se obtuvieron métricas de comportamiento y capacidad por instancia y tiempos de disponibilidad de nueva infraestructura por ende el tradeoff e estas tecnologías reside (dejando de lado temas de compatibilidad de frameworks y/o lenguajes y limitaciones funcionales) entre costo y tiempo de puesta a disposición.

A futuro vamos a complementar este análisis con qué tecnologíaas se adaptan mas a una y otra plataforma, el concepto de cartridge y comparación de las APIs.

Espero les guste…..   https://arquitecturacdt.wordpress.com/about/elasticidad-en-cloud-computing/

 

 

 

 

 

CQRS perspective over Infinispan and A-MQ

Cuándo avanzamos hacia la integración de sistemas son muchas las barreras con las cuales nos encontramos y son muchas las tecnologías a las cuales podemos acudir para dar sustento a la estrategia. Los paradigmas ideales sobre el cuál se basa una estrategia de integración son SOA (Service oriented architecture) y EDA (Event Driven Architecture). Ambos paradigmas presentan una situación nueva a la cuál administradores y desarrolladores deben enfrentarse. Compartir datos ya no es concurrir en una base de datos, replicaciones nocturnas o procesar ETLs. Ahora cuando desarrollo mi aplicación debo pensar también que mi universo de usuarios se expande a todos los procesos de la compañía que necesitan de la información administrada por mí.

El problema

El definir un responsable de la información presenta un problema:

La administración del impacto de la integración.

  ¿Es responsabilidad de un transaccional servir de sustento a otro para brindarle servicio? ¿Es la aplicación consumidora del servicio responsable del uso que hace? ¿Puede el gobierno controlar y limitar eso?

Una alternativa

Independientemente de que el gobierno permita establecer reglas de convivencia existe la posibilidad de deslindar esas responsabilidades.  Casualmente a través de un patrón arquitectónico que se basa en la segregación de responsabilidades CQRS. Fue a través de un artículo de Greg Young que me encontré con este concepto. Ahora, sería simple pedirle a las aplicaciones que diseñen, armen y mantengan una segunda estructura de datos (no tanto que lo hagan), y ¿qué pasa con las aplicaciones no desarrolladas por nosotros?, ¿qué pasa con las aplicaciones ya productivas?. Aquí el planteo que nos hacemos es que modificarlas tiene un impacto muy alto o es imposible hacerlo. pero puedo aprovechar puntos de integración como….. eventos.

¿Como aplicamos este patrón?

Podemos extender el patrón y delegar la responsabilidad en una aplicación externa. Esta aplicación debería estar enfocada puramente en la consulta y tener la capacidad de escalar fuertemente en ese aspecto.
¿Como escalaríamos en datos?, apostando a la innovación y aprovechar una tecnología como bases de datos en memoria para la cual la escalabilidad es una fortaleza. En mi experiencia he usado Infinispan, es fácil de usar y realmente permite la escalar muy fácilmente. Las últimas versiones corrigieron problemas de manejo transaccional y solucionaron problemas de locks en la sincronización de instancias. Esto me permite tener una base de datos con plena capacidad de escalamiento horizontal estructurada de tal manera que puedo satisfacer las necesidades de consulta. La alimentación de la estructura de consultas se realiza mediante eventos lo que comúnmente se denomina event sourcing, las ventajas claras de este diseño son:

  • Componentización de datos que permite armar estructuras a partir de múltiples orígenes
  • Desacople total

Como todo tiene sus desventajas

  • Inconsistencia temporal, es decir podemos tener lecturas durante un período de tiempo.

Infinispan

Infinispan es una base de datos en memoria bajo el esquema clave/valor. Su poder reside en la velocidad de acceso a los datos no solo por estar en memoria si no por el acceso directo por clave. El acceso por clave representa una clara ventaja si los servicios que exponemos tienen en cuenta que la clave de búsqueda corresponda con la clave de almacenamiento del dato.
Infinispan puede utilizarse como API o como servidor.
En esta arquitectura vemos ISPN como un punto de concurrencia de muchas aplicaciones donde una escribe y todas las demás leen. De modo tal que hay una serie de servicios exponiendo la información.
Como API obtenemos
  • Menor uso de la red
  • Mayor flexibilidad para hacer procesamiento de datos combinados
  • Las lógicas de procesamiento de los datos escala con los nodos.
  • No genero carga sobre el ESB o una capa extra para accede a los datos.
  Como servidor obtenemos
  • Integración vía hotrod
  • Flexibilidad en el escalamiento de la infraestructura
  • Problemas, reinicio o deploy de nuevas versiones de la capa de servicios son independientes de la capa de persistencia en Infinispan.

Integración de aplicación legacy

    • Si la aplicación es comercial debemos analizar los puntos de integración que brinde. En caso de no tenerlos existe la posibilidad (aunque desagradable) de implementar un mecanismo de pooling sobre la base de datos (trigger, pooling daemon, etc) que permita informar las novedades.
    • ¿Cómo garantizamos la llegada de la totalidad de las novedades?
      1. Podemos hacer que la persistencia en la plataforma de eventos forme parte de la transacción.
      2. Podemos definir algún mecanismo de reintento manual o automático para la persistencia del evento.

 A partir del momento en que tenemos el mecanismo de carga de los datos, la configuración del cluster de datos en memoria es totalmente independiente.

  • Puede ser replicado o distribuido, dependiendo de la cantidad de datos a almacenar, la robustez que pretendamos y los tiempos de rehidratación.
  • El cache store asegura la posibilidad de recuperación ante caída o error en algún nodo o el cluster completo. Normalmente es ineficiente o imposible hacerlo desde el origen.

Bus de eventos

Por más que evalúo alternativas siempre llego a la misma conclusión, la mejor manera de implementarlo es a través de alguna plataforma JMS. El bus debe funcionar como buffer de eventos permitiendo cierto grado de elasticidad a los consumidores y logrando que la persistencia del evento tenga un mínimo impacto en la performance y costo de recursos del productor.

Para garantizar la llegada de los eventos al bus tenemos dos estrategias:
  1. Quién publica incorpora la publicación como parte de la transacción, lo cual implica:
    • Si el bus de eventos no está disponible la transacción no puede llevarse a cabo
    • La transacción se alarga
  2. Quién publica tiene un mecanismo de persistencia y reintento, esto implica:
    • Mayor infraestructura
    • Aumento de las responsabilidades de la aplicación que publica
Cualquiera sea la alternativa cuanto más podamos garantizar la disponibilidad de la plataforma y su escalabilidad mejor.Esto permitirá soportar el aumento del volumen de mensajería y su tiempo de disponibilidad (availability).
Estrategia JMS:
Esquema public-subscriber: permite escalar en el consumo de mensajes y permite también la incorporar consumidores sin reiniciar o configurar la infraestructura.
Subscriptores durables: garantiza la conservación del mensaje hasta que el consumidor lo tome.
Mensajes persistentes: garantiza la permanencia del mensaje aunque se reinicie la plataforma.
La estrategia consiste en armar un esquema pub-sub donde un publisher envía un mensaje a un tópico y n subscriptores lo toman. Esto permite escalabilidad en los subscriptores al registrarse con el mismo client-id y al ser persistente nos permite garantizar la llegada del mensaje.

Conclusión

La integración de aplicaciones mediante servicios y/o eventos genera problemas de impacto entre aplicaciones. El problema de administrar el impacto de la integración encuentra un buen atenuante en la segregación de responsabilidades. Las bases de datos en memoria y JMS son tecnologías que brindan las funcionalidades adecuadas para la implementación de una arquitectura CQRS y permiten abstraer consumidores de productores y almacenar estructuras de consulta. Particularmente mi experiencia con Infinispan para brindar servicios de consulta y JBoss A-MQ para administrar la mensajería ha sido más que satisfactoria permitiendo tener una infraestructura 7×24 con garantía de delivery de mensajes y brindar servicios de alto volumen reduciendo los tiempos de respuesta entre 10 y 100 veces.