Esta entrada forma parte de una serie de artículos sobre Introducción al Procesamiento de Eventos Complejos. Puedes leer los artículos anteriores aquí:
- Introducción al procesamiento de Eventos Complejos I: qué es y principios
- Introducción al procesamiento de Eventos Complejos II: conceptos básicos
Entonces, ¿qué ideas son las importantes?
A riesgo de insistir en algunos temas, terminemos esta introducción a CEP con un resumen de las ideas más importantes sobre las que trabaja el procesamiento de eventos complejos.
Inmutabilidad de eventos
Un evento no puede ser modificado ni eliminado. Si un evento tiene algún tipo de significado para el sistema que lo procesa debe estar siempre disponible. |
En CEP todos los eventos de los que se parte son inmutables. Un sistema que modifique los eventos según los va recibiendo, eliminando el objeto original, no está implementando procesamiento de eventos, sino procesamiento de objetos al estilo clásico.
Por otro lado, si los modifica para crear nuevos eventos – eventos enriquecidos – manteniendo los originales, podemos decir que seguiría dentro de los parámetros CEP. Y en muchas ocasiones con un enfoque acertado.
Supongamos que una persona, por ejemplo un juez, quiere disponer de toda la información que distintos eventos de introducción manual de datos alojaron en una serie de ficheros Excel. Esta persona desea disponer de esa información para correlacionarla, buscar patrones de eventos y con la ayuda de un sistema de reglas de negocio decidir si esos patrones de eventos una vez que se producen pueden llegar a representar un fraude, un delito fiscal, …
Un sistema CEP mantendría esas hojas Excel originales y crearía, mediante adaptadores, objetos de negocio con información “preprocesada” que permitiese al sistema de reglas interpretar la información y tomar sus decisiones. Un sistema CEP mediocre, más bien erróneo, “preprocesaría” esa información, borrando las pestañas originales de las hojas Excel. Un sistema CER (Complex Event Removal)* vertería ácido sulfúrico sobre el disco duro de tal modo que el modelo de objetos que llegase al sistema de reglas fuese vacío.
* CER es un término inventado.
Al paso de transformar los eventos de entrada en otros formatos que sean entendibles por el software que los va a tratar se le suele llamar pre procesamiento de eventos. Es muy habitual y la lógica de transformación se encapsula dentro de componentes adaptadores.
El tema de la inmutabilidad, no obstante, está sujeto a cierta controversia.
Filtrado
Es un paso crucial para descartar aquellos eventos irrelevantes en el procesamiento y de este modo reducir todo lo posible el tamaño de los datos de entrada. El objetivo es claro: reducir el tiempo de procesamiento al máximo así como los recursos necesarios para llevarlo a cabo. Pero esto no significa reducirlo a cero: de ningún modo se pueden filtrar eventos que resulten significativos para el procesamiento del sistema. Me remito al ejemplo anterior.
Priorización
Situar en orden de importancia los eventos según van llegando. Los eventos de alta prioridad son aquellos que requieren respuesta inmediata de la capa de negocio. Incluso se puede crear un circuito de procesamiento más rápido solamente para aquellos eventos que superen un determinado nivel de importancia.
Por ejemplo, un sistema de atención y gestión de llamadas de socorro debería tener la suficiente inteligencia como para discernir aquellas situaciones más urgentes y redirigirlas de tal modo que fuesen atendidas con más celeridad.
Detección de patrones de eventos
Se podría pensar en un patrón de eventos como una plantilla a la que se ajustan un conjunto de eventos por ocurrencia o ausencia de los mismos.
Por ejemplo, pensemos en los ataques de Denegación de Servicio tan habituales en estos tiempos que corren: un atacante de Anonymous en lo más oscuro de su dormitorio envía desde su ordenador una secuencia de paquetes a determinados puertos de los sistemas software de un banco, después intenta autenticarse en un conjunto de servidores y aplicaciones de ese banco, deja pasar un tiempo prudencial sin hacer ningún movimiento, vuelve a enviar otra secuencia de paquetes, intenta de nuevo la autenticación ahora en un subconjunto de servidores más reducido y así hasta detectar qué sistema es vulnerable e introducirse dentro. Al director de sistemas de este banco no le quedará más remedio que ser capaz de detectar estas secuencias repetitivas de eventos que suceden y que no suceden si quiere ser capaz de evitarlos y mantener su puesto de trabajo. También puede echar la culpa a la coyuntura económica siguiendo el estilo de sus superiores, pero parece difícil que esta estrategia le funcione.
Gestión de excepciones
El procesamiento de eventos también puede ser válido para detectar errores y anomalías, excepciones en general, en los procesos de negocio. En CEP las excepciones se detectan por presencia o ausencia de eventos (o de patrones de eventos). Cuando un patrón de eventos no encaja con ninguna secuencia de eventos entrantes, dentro de los límites de una ventana de tiempo, podemos decir que hemos detectado una ausencia. La forma de afrontar una excepción cuando aparece implica crear nuevos eventos que tienen que ver con el error (de negocio) que ha sucedido. En este sentido CEP se suele utilizar en conjunción con BPM para llevar a cabo el procesamiento de excepciones.
Un ejemplo claro de esta integración consistiría en disparar un proceso de negocio que gestione las tareas a llevar a cabo cuando se detecta un patrón de eventos similar al de un fraude (excepción de negocio) en tarjetas bancarias. Un proceso de negocio que primero hiciera una comprobación manual, telefónica o con ayuda de otros sistemas (policía) sobre la autenticidad del fraude. Que una vez confirmado inmediatamente anulara la tarjeta y remitiese la información del fraude a la policía,…
Abstracción de patrones de eventos
Si se detecta que un conjunto de eventos forma un patrón, suele ser muy útil crear nuevos eventos, normalmente más simples, que contengan sólo las características más significativas de dicho conjunto de eventos.
Supongamos que estamos monitorizando una infraestructura hardware y software que alberga un sistema de gestión automatizada de compras electrónicas. Esta infraestructura se compone de máquinas Linux, servidores de aplicaciones en clúster de Weblogic, aplicaciones Java/JEE desplegadas, bases de datos Oracle, sistemas de ficheros compartidos tipo NAS, etc. Si nuestro sistema de monitorización empieza a detectar eventos que informan que la memoria de cada proceso Java/Weblogic está alcanzando su límite superior y la CPU de todas las máquinas involucradas tiene un porcentaje de uso cercano al 100% es muy posible que este tipo de alertas lleguen a los administradores de sistemas de tal modo que sean conscientes de que se tienen que poner manos a la obra. Pero nuestro sistema de monitorización podría tener igualmente la capacidad de convertir este conjunto de eventos/problemas técnicos en un único “botonazo rojo” que avise al responsable de compras de la empresa de que su sistema corre el riesgo de quedar fuera de juego. Estamos ante una típica situación de abstracción de eventos.
Las abstracción de eventos es una de las formas más habituales de organizar los eventos en jerarquías.
Epílogo
Encontraréis que estos primeros posts sobre el procesamiento de eventos complejos no tienen un detalle técnico profundo. La intención del mismo ha sido poner en claro los conceptos más relevantes de CEP y qué problemáticas resuelven. Por decirlo de una manera informal, se ha intentado obtener una foto del mundo de los eventos complejos.
A día de hoy no todo está dicho ni mucho menos sobre esta tecnología. Queda mucho conocimiento por adquirir, muchas normas por establecer y un montón de implementaciones que descubrir. De hecho se puede decir que está muy lejos de ser una tecnología madura.
Si quieres saber más sobre CEP o arquitectura software, contáctanos o síguenos en las redes sociales (Linkedin, Twitter, Youtube).