Un modelo conceptual para los sistemas de procesamiento de eventos

Este artículo introduce un Modelo Conceptual para el procesamiento de eventos. Esto se describe en términos de una Red de Procesamiento de Eventos fundamental y una Arquitectura Conceptual para el Procesamiento de Eventos asociada, que ofrece un panorama conceptual de la arquitectura de procesamiento de eventos y los componentes clave requeridos para crear sistemas útiles de procesamiento de eventos

Mike Edwards, Strategist, IBM

Mike Edwards es Strategist in Emerging Technologies para el Hursley Lab en el Reino Unido. Además, es co-presidente de la comisión técnica de OASIS SCA Assembly y director del proyecto Apache Tuscany. Mike también contribuye con las especificaciones del proyecto PEPPOL en Europa.



Opher Etzion, STSM, Event Processing Scientific Leader, IBM

Opher Etzion es IBM Senior Technical Staff Member y Master Inventor. También es el Event Processing Scientific Leader del IBM Research Lab en Haifa y encabeza la comisión directiva de Event Process Technical Society (EPTS).



Mamdouh Ibrahim, Distinguished Engineer, IBM

El Dr. Ibrahim es IBM Distinguished Engineer y CTO de la práctica denominada Enterprise Architecture and Technology. Entre sus responsabilidades se incluyen el desarrollo de activos EA y SOA y la entrega de experiencia profesional en arquitectura y consultoría a los clientes. El Dr. Ibrahim tiene dos licenciaturas en Ingeniería Electrónica y Matemática, tres maestrías en Matemática, Ciencia del Estado Sólido y Ciencias de la Computación, y un doctorado en Ciencias de la Computación. Además, es miembro de IEEE y ACM y profesor adjunto en la Universidad Central Michigan.



Sreekanth Iyer, Senior IT Architect, IBM

Sreekanth Iyer es Senior IT Architect para el equipo de IBM India Software Lab Services and Solutions, y crea soluciones IBM SOA para clientes y socios.



Hubert Lalanne, Distinguished Engineer, IBM

Hubert Lalanne reside en Francia y es IBM Distinguished Engineer y Software Information Technology Architect (SWITA). Además, es miembro del IBM Software Group WW Technical Leadership Council y del IBM Technical Expert Council de Francia y Noroeste de África.



Mweene Monze, Executive IT Architect, IBM

Mweene Monze es Executive IT Architect para el IBM Software Group, con sede en Johannesburgo , Sudáfrica. También es responsable del área de Ventas Técnicas para el Sector Público.



Catherine Moxey, STSM, CICS Transaction Server for z/OS, IBM

Catherine Moxey es IBM Senior Technical Staff Member para el CICS Transaction Server en el equipo de z/OS, con sede en Hursley, Reino Unido. Además, es una de las arquitectas que proveen soporte para el procesamiento de eventos en CICS. Catherine es miembro de Event Processing Technical Society y tiene participación activa en su grupo de trabajo de Reference Architecture.



Marc Peters, Senior IT Architect, IBM

Marc Peters es Senior Software IT Architects for Energy and Utility Customers. Está radicado en Colonia, Alemania, y encabeza oportunidades y proyectos en SOA, Event Processing e IoD, vinculados con los requerimientos de negocios de las industrias de Energía y Servicios Públicos. Además, tiene más de 17 años de experiencia en TI para proyectos internacionales. Marc suele ser uno de los disertantes que participan de eventos internos y para clientes.



Yuri Rabinovich, Researcher, IBM

Yuri Rabinovich es investigador del grupo Event-based Middleware and Solutions en el IBM Haifa Research Lab de Israel. Recibió su Licenciatura en Ciencias de Gestión de Sistemas de Información en Technion, el Instituto de Tecnología de Israel. Yuri comenzó a trabajar para el IBM Haifa Research Lab en 2006 concentrándose en el desarrollo de la AMiT (Active Middleware Technology) del motor de reglas expresivo de Complex Event Processing Además, también encabezó los proyectos de investigación sobre Scalable and Distributed Event Processing y desarrolló técnicas nuevas que mejoran el rendimiento del procesamiento de eventos apuntando hacia el motor de WebSphere Business Events.



Guy Sharon, Manager Event Based Middleware, IBM

Guy Sharon es gerente del grupo de Event-based Middleware and Solutions en el Haifa Research Lab de Israel. Recibió su Licenciatura en Ciencias de Gestión de Sistemas de Información en Technion, el Instituto de Tecnología de Israel. Su tesis se ocupó del modelo conceptual de Event Processing Networks. Guy comenzó a trabajar para el IBM Haifa Research Lab en el año 2000, concentrándose en Active Technologies, y fue uno de los miembros del equipo de AMIT (Active Middleware Technology) Research and Development, un motor de reglas expresivo de Complex Event Processing.



05-08-2011

Introducción

En muchos ámbitos, el comportamiento de las empresas siempre se basó en eventos y, por lo tanto, éstas siempre tuvieron que ocuparse de un volumen de transacciones y eventos de negocios que crece día a día. El Procesamiento de Eventos (EP) es un área emergente impulsada, en primer lugar, por la mayor necesidad que tienen las empresas para poder responder rápidamente a este gran volumen de negocios y eventos de TI. EP reconoce la necesidad de brindar soporte para el ciclo de toma de decisiones mediante el procesamiento de eventos significativos para las empresas de una forma más efectiva. Por lo tanto, EP es una parte cada vez más importante de las estrategias de las empresas en relación con las Arquitecturas Orientadas a Servicios (SOAs).

En primer lugar, este artículo discute la necesidad de realizar el procesamiento de eventos, los diferentes tipos de procesamientos de eventos y el valor que tiene la adopción del procesamiento de eventos para los negocios. Luego de esto, el presente artículo detalla un modelo conceptual de procesamiento de eventos que se puede usar para materializar una Arquitectura Impulsada por Eventos (EDA). Los conceptos se elaboran mediante la discusión de tres escenarios de negocios que implementan el procesamiento de eventos para lograr tomar mejores decisiones.


Generalidades del Procesamiento de Eventos

Un Evento es cualquier cosa significativa que ocurre o que se considera que puede llegar a ocurrir. Un evento ocurre o no y es significativo porque puede llegar a afectar alguna acción. Se considera que un evento puede llegar a ocurrir como algo que podría hacerse realidad o como la transición de una entidad en el mundo real. Puede formar parte de un proceso de negocios (por ejemplo: se emitió una orden de transacción, aterrizó el avión correspondiente a un vuelo específico, se registró la lectura de un sensor de datos) o puede monitorear información sobre la infraestructura de TI, middleware, aplicaciones y procesos de negocios). La Figura 1 le muestra las generalidades detalladas del procesamiento de eventos.

Figura 1. Generalidades del Procesamiento de Eventos
Generalidades del Procesamiento de Eventos

Un evento (una cosa relevante que ocurre dentro o fuera del negocio) puede provocar la invocación de un servicio, la iniciación de un proceso de negocios y / o la publicación o la sindicación de más información. El Procesamiento de Eventos se ocupa de la tarea de procesar uno o varios eventos con el objetivo de identificar aquellos eventos que sean más importantes dentro de la nube de eventos. Desde la perspectiva del valor de negocios, el procesamiento de eventos es la capacidad de detectar y responder a eventos que indican situaciones que impactan sobre los negocios y ocurren en toda la empresa. Por ejemplo, un mensaje de evento podría indicar que se agregó un cliente nuevo, que se vendió un producto, que se recibió un envío, que se abrió una puerta de seguridad, que se informó la ubicación actual de un activo por medio de un GPS, etc.

Un productor (o una fuente) de eventos produce eventos. Por ejemplo, un productor de eventos puede ser una aplicación, un almacenamiento de datos, un servicio, un proceso de negocios, un transmisor, un sensor o una herramienta de colaboración (como una aplicación de mensajería instantánea o correo electrónico). Al recibir estos eventos del productor, los eventos pueden provocar resultados de manera directa o se los puede evaluar según los patrones de procesamiento de eventos. Los patrones de procesamiento de eventos se definen de acuerdo con las necesidades de las partes interesadas, y no de acuerdo con las necesidades de los productores de eventos. Los resultados del procesamiento de eventos incluyen, pero no se limitan a, la invocación de un servicio, la iniciación de un proceso de negocios, la publicación de un evento en un hub de subscripción, la notificación directa a humanos o sistemas, la generación de un evento nuevo y / o la captura de los propósitos históricos del evento. Se suele hacer referencia a los eventos y su interacción con los servicios de negocios de la siguiente manera: sistema de información impulsada por eventos o arquitectura impulsada por eventos.


Fundamentos conceptuales

Los bloques de construcción conceptuales de una arquitectura que soporta el procesamiento de eventos (es decir, un sistema de procesamiento de eventos) debería ofrecer funciones centrales (como, por ejemplo, la lógica del procesamiento de eventos) y conectar a los consumidores y a los productores de eventos por medio de eventos. Un modelo muy útil para pensar en dichas arquitecturas y en dicho sistema es la construcción denominada Red de Procesamiento de Eventos (EPN): un fundamento conceptual que describe la estructura de los sistemas de procesamiento de eventos y las características comunes que todos deberían soportar. La EPN describe al sistema de procesamiento de eventos como un conjunto de consumidores, agentes de procesamiento y productores de eventos que interactúan. En este contexto, la responsabilidad principal de la EPN consiste en recibir eventos de los productores, enviarlos a la combinación correcta de agentes de procesamiento de eventos para que los procesen y entregar los eventos ya procesados a los consumidores correctos. La construcción denominada Red de Procesamiento de Eventos se describe en mayor detalle en la Sección II de este artículo, que describe el Modelo conceptual para el procesamiento de eventos. El modelo conceptual abarca la virtualización, las bases de datos de eventos, el middleware impulsado por eventos, los lenguajes de procesamiento de eventos y todo aquello que soporta la gestión de eventos a lo largo de su ciclo de vida (desde el modelado y la programación hasta el monitoreo y la respuesta).

Tipos de Procesamiento de Eventos

Las funciones de Procesamiento de Eventos se pueden categorizar en simples y complejas según la complejidad y la sofisticación del procesamiento:

  • Procesamiento de Eventos Simples: Se filtran y rutean eventos simples (es decir, eventos que no resumen, representan o denotan un conjunto de otros eventos) sin ninguna modificación. Por lo tanto, ocurre un evento relevante, que inicia una acción o varias acciones descendentes, y cada evento que ocurre se procesa de manera independiente. Aunque se los denomina "simples", estos eventos pueden ofrecerle un gran valor e información de negocios muy importante. Se transforman los eventos, lo que involucra eventos de conversión y división, y se fusionan uno o más eventos. El procesamiento simple incluye el procesamiento que involucra la modificación de la forma del esquema de los eventos, el aumento de la carga útil de los eventos mediante datos adicionales, el redireccionamiento del evento de un canal o flujo a otro y la generación de múltiples eventos basados en la carga útil de un solo evento. A este tipo de procesamiento de eventos no siempre se lo suele distinguir como un tipo específico.
  • Procesamiento de Eventos Complejos: Se detectan patrones que abarcan múltiples eventos independientes con el objetivo de crear nuevos "eventos complejos". Un evento complejo es un evento que resume, representa o denota un conjunto de otros eventos. El procesamiento de eventos complejos incluye el procesamiento de un conjunto de eventos con el objetivo de detectar una situación relevante para el negocio. Generalmente, este procesamiento involucra la aplicación de un conjunto de limitaciones o condiciones de evaluación en un conjunto de eventos. Los eventos (relevantes u ordinarios) pueden abarcar diferentes tipos de eventos y pueden ocurrir durante un período de tiempo determinado. Es posible correlacionar los eventos en múltiples dimensiones de interés, entre las que podemos incluir las siguientes: causal, temporal, espacial y otras. Se debería hacer una distinción entre la naturaleza compleja y rica de la información disponible a partir del Procesamiento de Eventos Complejos y el hecho de que no es, o no debería ser, algo complejo para los usuarios.

El modelado y la implementación de las construcciones de procesamiento de eventos están respaldados por el middleware de integración de aplicación y por una gran variedad de plataformas de gestión de sistemas y redes, aunque una gran variedad de modelos de programación se usan para expresar estas construcciones. Las herramientas y los motores de Procesamiento de Eventos Complejos vieron la luz en los últimos años. El procesamiento de eventos se puede combinar con técnicas analíticas para predecir eventos, minar patrones e incrustar analítica en tiempo real en las decisiones de ruteo y en las derivaciones de eventos. El uso de estas técnicas para realizar el análisis en tiempo real le ofrece la capacidad de tomar decisiones más inteligentes dentro del ciclo de toma de decisiones.

Procesamiento de Eventos de Negocios

Procesamiento de Eventos de Negocios extiende y mejora el procesamiento de eventos haciendo que esté disponible para los usuarios de negocios de forma consumible. Procesamiento de Eventos de Negocios extiende las capacidades y las herramientas de los usuarios de negocios, lo que permite la aplicación de tecnologías para construir sistemas de información impulsados por eventos que contribuyen con el negocio. La capacidad de percibir cuando un evento ocurrió (o no ocurrió), lo que indica una situación de negocios procesable, hace que el negocio pueda responder de manera rápida a las oportunidades y a las amenazas.

Figura 2. Procesamiento de Eventos de Negocios: Agrega una perspectiva de negocios a las capacidades de procesamiento de eventos
Procesamiento de Eventos de Negocios: Agrega una perspectiva de negocios a las capacidades de procesamiento de eventos

Los analistas y los gerentes de negocios comprenden las situaciones procesables (es decir, aquellos eventos o combinaciones de eventos clave y las acciones que se deben tomar en respuesta a dichos eventos). Ellos se ocupan de estas situaciones a diario y son directamente responsables de conocer cuándo ocurren y de gestionar la respuesta correspondiente. Sin embargo, no cuentan con las soluciones disponibles para poder identificar y responder al volumen y la complejidad de estas situaciones. Al mismo tiempo, aunque millones de eventos que pueden llegar a ser procesados fluyen libremente a través de la infraestructura de TI hoy en día, para soportar la funcionalidad de procesamiento de eventos avanzados, se requiere un conjunto especializado de capacidades. Pero la mayoría de las organizaciones de TI no cuentan con la tecnología necesaria para soportar estos requisitos de manera efectiva y eficiente. Se diseñó el Procesamiento de Eventos de Negocios específicamente para que se ocupe de este desafío (es decir, para que potencie la información que fluye a través de los sistemas de negocios con el objetivo de soportar los procesos de toma de decisiones de negocios).

El Procesamiento de Eventos de Negocios es la capacidad de percibir un evento, indicar que ocurrió una situación de negocios procesable y coordinar la acción de respuesta adecuada en el momento indicado. El Procesamiento de Eventos de Negocios le ofrece un conjunto integrado de sistemas e infraestructura que monitorea los eventos que ocurren en toda la empresa. Este tipo de procesamiento reconoce las ocurrencias significativas en el momento que acontecen y activa alertas y disemina información sobre el evento en cuestión para iniciar las respuestas que sean apropiadas. Cuando se lo incluye como parte de una solución de Gestión de Procesos de Negocios, el Procesamiento de Eventos de Negocios le ofrece una poderosa combinación de detección de patrones de eventos en tiempo y forma y una ejecución dinámica de procesos de negocios. El Procesamiento de Eventos de Negocios le ofrece TI con la funcionalidad necesaria para soportar los requisitos avanzados de procesamiento de eventos dentro de un entorno gestionable, escalable y de alto rendimiento. Además, mediante la inclusión de interfaces de usuario gráficas y no procedurales, el Procesamiento de Eventos de Negocios equipa a los usuarios de negocios con todo lo necesario para que puedan definir las acciones y las interacciones de procesamiento de eventos.

Valor del procesamiento de eventos

Desde hace ya bastante tiempo que se usan los principios básicos de procesamiento de eventos, en middleware de integración de aplicación y en varias otras formas de software de sistema (como, por ejemplo, los sistemas operativos), redes y software de gestión de sistemas. Sin embargo, el creciente valor del procesamiento de eventos se basa en el reconocimiento de la importancia de un evento desde un contexto de negocios y en la identificación de las respuestas adecuadas que se deben asociar con dicho evento. Todo esto puede ayudar a un negocio a responder de manera rápida ante nuevas oportunidades y amenazas de competencia, a diseminar información relevante en tiempo y forma entre las personas adecuadas, a permitir el diagnóstico activo de problemas y a contribuir con la creación de una vista en tiempo real del estado general del negocio.

El procesamiento de eventos puede ayudar a los negocios a identificar tendencias y amenazas, a aferrarse a oportunidades para mitigar los riesgos, a promover un menor tiempo para realizar el trabajo y a disminuir los tiempos del ciclo de percepción y respuesta. Por ejemplo:

  • Comerciantes que operan en los mercados de capital y desean reaccionar ante las oportunidades de arbitraje.
  • Analistas militares o de inteligencia que evalúan flujos de datos provenientes de satélites y sensores para determinar las acciones ofensivas y defensivas que se deben adoptar.
  • Negocios de transporte y logística que utilizan telemetría de vehículos en tiempo real para gestionar sus flotas de vehículos de manera más efectiva.
  • Empleados bancarios que realizan el seguimiento continuo de transacciones para detectar casos de fraude, lavado de dinero o incumplimiento de las reglamentaciones financieras.
  • Proveedores de servicios de comunicación que buscan minimizar el tiempo promedio que lleva reparar las fallas en la red.
  • Compañías petroleras que determinan la profundidad y el ancho de las perforaciones de manera dinámica, basándose en datos operacionales en tiempo real.
  • Proveedores de repuestos automotrices que utilizan complejas decisiones de fabricación para entregar repuestos a los fabricantes de manera tal que se permita una producción "justo a tiempo".

En todos estos casos y en muchos más, existe un requisito inherente a manejar grandes volúmenes de datos complejos en tiempo real. El procesamiento de eventos le ofrece la capacidad de hacer esto. La necesidad que tienen las empresas de pasar del procesamiento por lote al procesamiento en tiempo real para así poder tomar decisiones con mayor rapidez es otras de las razones que hace que aumente la demanda del procesamiento de eventos. Las características de las cargas de trabajo emergentes también requieren el procesamiento de eventos complejos en casi tiempo real, lo que involucra eventos de datos y eventos que se originan a partir de fuentes no convencionales (como, por ejemplo, voz y video).

Los analistas industriales, como por ejemplo Gartner, comparten esta visión y afirman que los eventos en sus diferentes formas –desde eventos simples hasta eventos complejos– se comenzarán a usar cada vez más en aplicaciones de negocios. La implementación de procesos de negocios impulsados por eventos tiene enormes beneficios financieros y estratégicos, ya que se adecúan a una naturaleza inherentemente impulsada por eventos de muchos aspectos del mundo real.

Los procesos de negocios impulsados por eventos no son simplemente procesos tradicionales que se ejecutan a mayor velocidad. En realidad, tienen características específicas que los distinguen de los "negocios normales". Las aplicaciones impulsadas por eventos hacen que se puedan modificar los procesos a la brevedad para responder a errores y a condiciones excepcionales que alteran los procesos convencionales. A medida que las empresas hacen grandes esfuerzos para recortar costos y mejorar su capacidad de respuesta ante los clientes, los proveedores y el resto del mundo, el concepto de un diseño impulsado por eventos se está comenzando a usar cada vez más. Las empresas están logrando beneficios mediante la implementación de procesos de negocios impulsados por eventos, porque se adecúan a la naturaleza inherentemente impulsada por eventos de los negocios y porque les confiere una ventaja competitiva en términos de los costos y los tiempos involucrados en la realización del trabajo.


Generalidades de diferentes escenarios de procesamiento de eventos

Para ilustrar los conceptos que se describen en este artículo, desarrollaremos tres escenarios diferentes de procesamiento de eventos a lo largo de las diversas secciones del presente. Estos escenarios demuestran algunos de los valores descriptos en las generalidades.

  • Escenario de gestión de la flota
  • Escenario de alerta de salud pública
  • Escenario de un proveedor de servicios de comunicación

Luego de presentar los escenarios, mapearemos los diversos conceptos de procesamiento de eventos hacia el escenario adecuado y explicaremos el valor agregado del procesamiento de eventos para este tipo de escenario. El primer escenario (gestión de la flota) se analiza en mayor detalle, ya que algunos de los aspectos más comunes se presentan en este escenario.

Comenzamos por describir el contexto de negocios de los escenarios y, luego de esto en el presente, discutimos los eventos involucrados y mapeamos los aspectos del modelo conceptual.

Escenario de gestión de la flota

Este escenario describe la situación de la compañía "Fast Delivers", que se especializa en entregar paquetes pequeños, en un radio de operación relativamente reducido, mediante el uso de su flota de vehículos. Cada vehículo tiene un GPS que transmite su ubicación de manera constante. Además, los paquetes están etiquetados con rótulos RFID. De acuerdo con el nivel de servicio deseado, el paquete se envía de manera inmediata de un lugar a otro o se envía a una central donde (posiblemente) otro vehículo lo recogerá para entregarlo en destino. Se garantiza un tiempo de entrega determinado para cada paquete y se establecen multas para penalizar todas las demoras. Algunas entregas son fijas (de acuerdo con un cronograma mensual) y otras surgen a raíz de los pedidos que hacen los clientes por teléfono (o por la página Web).

Figura 3. Generalidades de la gestión de la flota
Generalidades de la gestión de la flota

Las ideas para este escenario se basaron en las soluciones de IBM para la optimización de flotas. En el caso de los gerentes de flotas de camiones y autos, mencionamos algunos de los objetivos que ellos suelen tener al momento de gestionar y mantener su negocio:

  • Reducir los gastos en combustible.
  • Realizar el seguimiento de vehículos y conductores.
  • Ofrecer información minuto a minuto a los clientes.
  • Encontrar el punto justo para mejorar los procesos de carga, descarga y planificación de ruta.
  • Incrementar la utilización de activos.
  • Mejorar la atención al cliente.
  • Disminuir los costos operativos.
  • Reducir los costos de mantenimiento no programados.
  • Mitigar los riesgos para reducir los costos de los seguros.

Para poder gestionar la flota en tiempo y forma, la compañía optó por usar el procesamiento de eventos dentro de su sistema. Por lo tanto, la compañía está capacitada para reaccionar a la brevedad y reasignar rutas con el objetivo de satisfacer las demandas de los clientes en el momento sin descuidar el acuerdo hecho con cada uno de sus clientes. La compañía también puede reaccionar ante los riesgos a medida que se van materializando y mitigar la situación realizando reasignaciones antes de que se incumpla algún contrato. Gracias al procesamiento de eventos, la compañía puede reaccionar ante oportunidades y riesgos a medida que se van materializando y decidir qué hacer al respecto (para mantener todos los indicadores que se mencionan con anterioridad bajo control), ya que la situación actual de todos los vehículos, los pedidos, etc. se monitorea de forma constante y se anticipa por medio de los eventos. La compañía también puede realizar cambios e implementarlos en el proceso con gran rapidez y confianza simplemente cambiando la aplicación o la lógica de procesamiento de eventos sin pasar por procesos de desarrollo prolongados y propensos a errores.

En las próximas secciones, analizaremos los eventos involucrados y los conceptos de procesamiento de eventos para este escenario.

Escenario de alerta de salud pública

El escenario de alerta de salud pública describe el sistema de alerta en casos que indican brotes epidemiológicos reales o posibles que presentan un riesgo para la población. El Síndrome Agudo Respiratorio Severo (SARS) y la gripe aviar (H5N1) o ataques terroristas que empleen agentes biológicos o químicos son sólo algunos de los ejemplos de brotes epidemiológicos que nos interesan.

El escenario elegido considera un brote epidemiológico de influenza aviar (gripe aviar) y de influenza aviar A (H5N1), aunque se podría aplicar a otros brotes epidemiológicos (como a la gripe H1N1).

Las etapas o los estados de las pandemias, según la definición correspondiente de la Organización Mundial de la Salud, nos muestra la progresión desde el estado interpandémico (donde no se detecta el virus de la influenza en los seres humanos) hasta el estado pandémico (donde se registra el contagio de gran parte de la población general). Para este escenario, se consideran tres etapas fundamentalmente: no se detecta el virus, estado epidémico y, por último, estado pandémico.

Figura 4. Generalidades de la alerta de salud pública
Generalidades de la alerta de salud pública

Ahora, describimos lo que ocurre en este escenario. Un laboratorio que realiza análisis de sangre detecta el virus. De acuerdo con las reglamentaciones vigentes, la detección de un virus específico se publica como un evento. El receptor del evento en cuestión (en nuestro caso, el emisor del evento) normaliza el evento y realiza algunas verificaciones básicas de calidad y origen antes de enviar el evento a los agentes de procesamiento, donde se enriquecerá al evento con información adicional. Luego de esto, la detección del patrón verifica si es necesario presentar un alerta de brote epidemiológico. En el caso de que se trate de un brote epidemiológico, será necesario enriquecer el evento todavía más y aplicar otra lógica de detección de patrones para verificar si se trata de un brote pandémico. En el caso de alertas epidémicas y pandémicas, se envían notificaciones como eventos correspondientes. En el caso de alertas de brotes pandémicos emitidas por productos de eventos externos (como, por ejemplo, organizaciones internacionales de salud o gobiernos extranjeros), se actúa de manera similar.

Las secciones posteriores del presente artículo, se ocupan de los eventos involucrados y la forma en la que este escenario se relaciona con el modelo conceptual de procesamiento de eventos.

Escenario de un proveedor de servicios de comunicación

Este escenario describes la situación de la compañía "YourCSP" (una proveedora de servicios de comunicación). La compañía ofrece una gran variedad de servicios de comunicación no inalámbrica a clientes locales y a pequeñas y medianas empresas (que van desde acceso a Internet por banda ancha hasta VOIP y servicios de Virtual Private Network). La red MPLS (Conmutación de Rótulo Multiprotocolo) central de la compañía se compone de elementos de red de muchos fabricantes diferentes soportados por un conjunto de Element Management Systems. Estos emplean una amplia gama de tecnologías de red (incluso Dial-Up, DSL y tecnologías que soportan VPNs de nivel 2 y 3) para realizar la conectividad con las instalaciones de los clientes.

Dependiendo del paquete de servicios en particular que el cliente haya adquirido, la compañía ofrece diversos Acuerdos de Nivel de Servicio (SLA). Estos SLA se componen de contratos que garantizan los niveles acordados de servicio según las métricas especificadas (por ejemplo, la continuidad del servicio o el ancho de banda de red disponible). Los SLA que no se cumplan podrán resultar en multas económicas que YourCSP deberá pagar y hasta podría llegar a perjudicar la reputación de la compañía. Sus clientes están jerarquizados de acuerdo con sus acuerdos de nivel de servicio individuales.

YourCSP, al igual que todas las CSP, emplean un Centro de Operaciones de Red que se compone de empleados y activos de hardware y software dedicados a favorecer el buen funcionamiento de la red central de la compañía y de los servicios que ofrece. Entre sus objetivos principales, podemos incluir los siguientes:

  • Minimización del tiempo promedio de reparación de las fallas en la red que puedan ocasionar la degradación o interrupciones del servicio provisto a los clientes de la compañía.
  • Priorización de la remediación de las interrupciones del servicio y las fallas de acuerdo con los SLA vigentes con los clientes afectados, de forma tal que se minimice la exposición financiera de la compañía.
  • Maximización de la utilización de los activos de red.
  • Minimización de los costos operativos (como, por ejemplo, la mano de obra y el consumo energético).
  • Provisión de comunicación proactiva con los clientes en el caso de fallas que afecten al servicio y para mantenerlos informados sobre todos los progresos realizados para corregir estas fallas.

El Centro de Operaciones de Red de YourCSP usa tecnologías de gestión de red y de procesamiento de eventos para estos fines. Estos sistemas procesan muchos tipos diferentes de eventos, incluso eventos que representan lo siguiente:

  • Fallas detectadas en la red.
  • Cambios en el estado de los elementos de red.
  • Condiciones medioambientales en las instalaciones que albergan equipos de red y el equipamiento de red en sí mismo.
  • Los resultados de las respuestas automatizadas a los eventos.
  • Las acciones de los operadores humanos que responden a los eventos de red.
  • La detección automática de la resolución de fallas.

El acceso a estos datos de los eventos y a las herramientas para procesarlos hace que el Centro de Operaciones de Red pueda hacer lo siguiente:

  • Monitorear los elementos que la red central usa para controlar su estado, disponibilidad y rendimiento.
  • Normalizar los eventos de red según un formato común para lograr un procesamiento y una visualización consistente.
  • Ofrecer vistas interactivas actualizadas de los eventos que ocurrieron en la red a los operadores del Centro de Operaciones de Red.
  • Descubrir y actualizar automáticamente los modelos de la red central con el objetivo de:
    • Conservar la visibilidad de los activos implementados.
    • Conservar los modelos de la topología de la red física y lógica y su relación con los servicios de red provistos.
    • Ofrecer paneles de control del mapa de red al personal de operación para el diagnóstico y la resolución de problemas.
    • Realizar el análisis de la causa raíz de los eventos basándose en la topología de red en relación con los eventos de red y las interrupciones del servicio.
    • Brindar soporte al proceso de aprovisionamiento de servicios nuevos.
  • Ofrecer respuesta, diagnóstico y remediación automática de una gran cantidad de escenarios de falla de red.
  • Realizar el análisis de patrones de los eventos y sacar conclusiones en relación con las causas y el impacto de negocios de los eventos de red.
  • Enriquecer los eventos de red basándose en el contexto técnico, topológico y de negocios.
  • Definir políticas para la creación automática de tickets de problemas en la aplicación de mesa de ayuda de YourCSP, lo que resultará en la instigación de actividades de mantenimiento físico.

YourCSP tiene un contrato vigente con una empresa de mediana envergadura, MediumCo, para proveer servicios de VPN entre las instalaciones distribuidas de MediumCo. El contrato está sujeto a altos niveles de disponibilidad con un SLA asociado. YourCSP brinda y gestiona un router Customer Edge (CE) específico en cada una de las instalaciones de MediumCo para realizar la conexión con la red central de YourCSP. Cada CE se conecta a un router Provider Edge (PE) en las instalaciones de YourCSP.

Si ocurriese una falla en el router PE (como, por ejemplo, una tarjeta fallida), el sistema de procesamiento de eventos recibirá muchos eventos que le indicarán fallas físicas y lógicas enviadas desde el equipamiento y los sistemas de gestión de elementos en la red circundante. Esto incluye fallas de ping ICMP (Internet Control Message Protocol), alarmas de vínculo roto y fallas de adyacencia del protocolo de ruteo. En esta situación, el sistema de procesamiento de eventos debe hacer lo siguiente:

  • Identificar la causa raíz del evento y hacérsela notar a un operador del Centro de Operaciones de Red (en este caso, la falla de la tarjeta).
  • Inferir si algunos servicios de los clientes resultan afectados (en este caso, si el servicio de VPN de MediumCo funciona o no).
  • Determinar la prioridad relativa de la interrupción del servicio de acuerdo con los SLA aplicables y en comparación con otras interrupciones del servicio en la red y priorizar de manera adecuada la resolución del problema. En este caso, la resolución tiene una alta prioridad debido al SLA agresivo que se firmó con MediumCo.
  • Informar al cliente afectado sobre la identificación de la falla y ejecutar una solicitud de elemento de trabajo para asignar un técnico a la resolución de la falla.
  • Detectar la resolución de la falla e informar al operador y al cliente sobre la restauración del servicio normal.

En las próximas secciones, se analizan los eventos involucrados en este escenario y el mapeo hacia el modelo conceptual.


Modelo conceptual

Nuestro Modelo conceptual presenta dos vistas diferentes de los sistemas de procesamiento de eventos que buscan describir los conceptos importantes y su relación con un nivel abstracto, sin mencionar ningún detalle técnico. La Red de Procesamiento de Eventos (EPN) resume las características esenciales de los elementos de entrada, procesamiento y salida de un sistema de procesamiento de eventos. Guiada por conceptos de la EPN, nuestra Arquitectura conceptual identifica los elementos arquitectónicos abstractos, o componentes, que se pueden involucrar en la materialización de un sistema de procesamiento de eventos y las interrelaciones entre ellos con el objetivo de brindar valor de negocios. Esto es a nivel abstracto, lo que es independiente de las tecnologías, los protocolos y los productos que se podrían usar para brindar los componentes.

El objetivo de la Arquitectura conceptual es crear la base para las implementaciones de sistemas de procesamiento de eventos y aplicaciones impulsadas por eventos y ofrecer un marco común para especificar, comparar y contrastar las diferentes implementaciones y arquitecturas de solución de procesamiento de eventos.

Nuestra intención es que la arquitectura conceptual le ofrezca un conjunto de componentes, que sea suficiente a nivel conceptual, a partir del que se pueda construir un sistema de procesamiento de eventos. Pero no existe ningún requisito que exija implementar ningún componente que no sea necesario en un sistema en particular. De igual forma, tampoco existe ningún concepto implícito de cumplimiento con el modelo.


Red de Procesamiento de Eventos

Nuestra abstracción de alto nivel de sistemas de procesamiento de eventos aplica conceptos de la construcción de la red de procesamiento de eventos (vea la Figura 5). Como lo indicamos con anterioridad, una Red de Procesamiento de Eventos es una formulación conceptual que describe la estructura de los sistemas de procesamiento de eventos y las características comunes que todos deberían soportar.

Figura 5. Red de Procesamiento de Eventos
Red de Procesamiento de Eventos

Una EPN consiste de cuatro componentes: el productor del evento, el consumidor del evento, el agente de procesamiento de eventos (al que abreviamos EPA) y un canal de eventos (que es un componente de conexión). Una EPN describe cómo los eventos recibidos de los productores se direccionan hacia los consumidores por medio de agentes que procesan estos eventos (por ejemplo, realizando su transformación, su validación o su enriquecimiento). Un evento que fluye desde un componente hacia otro debe hacerlo por medio de un canal de eventos (como se puede observar en la Figura 5, que le muestra la relación existente entre los diferentes canales de eventos, consumidores, productores y agentes de procesamiento). Los canales de eventos son nodos que conectan a los productores de eventos con los EPAs dentro de la EPN, que conectan los EPAs siempre que esto sea necesario y que conectan los EPAs a los consumidores (lo que resulta en eventos que pasan desde los productores de eventos hasta los consumidores de eventos a través de la EPN). Esta Figura también ilustra el hecho de que los diversos eventos producidos por los productores de eventos en la EPN se pueden procesar por medio de grupos apropiados de EPAs, conectados por medio de canales, con el objetivo de que los diversos consumidores de eventos en la EPN consuman dichos eventos (o los eventos que de ellos deriven).

Canal de eventos

Un canal de eventos es un mecanismo para entregar agentes o flujos de eventos desde los productores de eventos y los EPA hasta los consumidores de eventos y los EPA. En este nivel de abstracción, no se colocan limitaciones ni sobre las propiedades del canal de eventos (como, por ejemplo, si cada canal puede mover o no más de un tipo diferente de evento) ni sobre el mecanismo que mueve los eventos.

El canal de eventos puede llegar a recibir múltiples eventos desde diferentes productores de eventos y EPAs y puede llegar a transferir eventos combinados desde varias fuentes hasta múltiples EPAs y consumidores. El orden entre los eventos provenientes de diferentes EPAs y productores de eventos para crear el conjunto combinado de eventos es específico a la implementación y el modelo conceptual no se ocupa de ello. En algunos casos, no se requiere ningún orden en particular. Sin embargo, el canal de eventos es responsable de tomar eventos de los productores de eventos y/o los EPA, ordenarlos (de ser necesario) y combinarlos y entregar esto a los consumidores de eventos y/o EPAs apropiados.

Otra responsabilidad de un canal de eventos puede consistir en retener la historia de los eventos que fluyen para permitir el procesamiento retrospectivo de eventos (de acuerdo con las políticas de retención que determinan la duración y las condiciones de filtrado para los eventos retenidos). El procesamiento retrospectivo de eventos consiste en el descubrimiento de patrones de eventos a lo largo de toda la historia de los eventos en cuestión. Esto se opone al procesamiento online de eventos, que se encarga de detectar los patrones predefinidos de eventos a medida que los eventos nuevos pasan a estar disponibles.

Un canal de eventos se representa en la EPN como un nodo con bordes que se direccionan desde y hacia el nodo. Cada borde entrante representa eventos desde un productor de eventos o un agente de procesamiento de eventos que coloca eventos en el canal. Cada borde saliente representa eventos hacia un consumidor de eventos o un agente de procesamiento de eventos que recibe eventos del canal.

Productor y consumidor de eventos

Un productor de eventos produce eventos a través de canales de eventos para que cualquier parte interesada los consuma. La parte interesada puede ser un consumidor de eventos o un EPA. El modelo conceptual no coloca ninguna restricción sobre el mecanismo por medio del que se obtienen los eventos desde un productor de eventos o un EPA, que puede invocar modelos de "push" (insertar) o "pull" (extraer).

Dentro de una red de nodos y bordes, se representa a un productor de eventos como un nodo fuente (es decir, sólo existen bordes que se direccionan desde él). La cantidad de bordes que se direccionan desde él es la cantidad de canales de eventos diferentes involucrados en mover eventos desde el productor hacia los EPAs o los consumidores que recibirán los eventos. El mismo evento se puede publicar o hacer que esté disponible por medio del productor de eventos para más de un canal de eventos. Sin embargo, a modo de práctica de diseño, siempre conviene dejar que los EPAs tomen las decisiones de ruteo, para así permitir el mejor control, el mejor diseño y la mejor comprensión de la totalidad de las necesidades de procesamiento de eventos.

Un consumidor de eventos se interesa en aquellos eventos que le permiten cumplir con sus responsabilidades. Luego de que el consumidor de eventos recibe el evento que le interesa, dicho consumidor realiza una tarea o tareas determinadas asociadas con este evento.

Un consumidor de eventos se representa como un "sink point" (punto de hundimiento), lo que significa que sólo bordes se direccionan hacia él. La cantidad de bordes que se direccionan hacia él es la cantidad de canales de eventos diferentes involucrados en el movimiento de los eventos hacia el consumidor en cuestión. El mismo evento se puede recibir a través de más de un canal de eventos. Sin embargo, conviene que el EPA se ocupe de la lógica de dónde, cuándo y cómo recibir eventos, para así permitir el mejor control, el mejor diseño y la mejor comprensión de la totalidad de las necesidades de procesamiento de eventos.

Esto no significa que un consumidor de eventos no puede ser un productor de eventos. Pero al cumplir con la última función mencionada, aparecería como un productor de eventos dentro de la EPN.

Agente de procesamiento de eventos

En un sistema distribuido y heterogéneo, es posible que los productores de eventos no puedan producir los eventos que un consumidor de eventos espera recibir. Estos eventos pueden llegar a diferir en lo que hace a la sintaxis esperada (estructura), al significado semántico o a ambos aspectos. También hay casos en los que un solo evento no disparará una acción realizada por un consumidor de eventos. En cambio, la acción se disparará por medio de una composición compleja de eventos que ocurren en diferentes momentos y en diferentes contextos. Los EPA, a los que a veces se conoce como mediadores de eventos, son necesarios para detectar patrones en eventos sin procesar, para procesar estos eventos a través del enriquecimiento, la transformación y la validación y, por último, para derivar eventos nuevos y publicarlos. Un EPA es responsable de producir estos eventos derivados y decide dónde y cómo se debería hacer que estos eventos estén disponibles.

El EPA tiene tres etapas posibles:

  • Comparación de patrones: De ser requerida, esta etapa es la responsable de seleccionar los eventos que se procesarán de acuerdo con un patrón especificado. A los EPA que realizan la comparación de patrones se los conoce como "EPAs de detección de patrones".
  • Procesamiento: De ser requerida, esta etapa es la responsable de aplicar las funciones de procesamiento en los eventos seleccionados que satisfacen el patrón (lo que resulta en la creación de eventos derivados).
  • Emisión: Esta etapa es la responsable de emitir los eventos o los eventos derivados en un canal.

El EPA recibe eventos desde canales de eventos para la detección de su patrón u otra tarea de procesamiento. Esto es muy parecido a la forma en la que un consumidor de eventos recibe eventos desde canales de eventos para actuar de acuerdo con estos eventos. Un EPA envía eventos por medio de canales de eventos cuando emite eventos, casi como un productor de eventos envía los eventos que produce por medio de un canal de eventos. Dentro de una red de nodos y bordes, un EPA se representa como un nodo con bordes direccionados desde y hacia el nodo. La cantidad de bordes direccionados hacia él es la cantidad de canales de eventos diferentes que el agente usa para sus funciones (como, por ejemplo, la detección de patrones). La cantidad de bordes direccionados desde él es la cantidad de canales de eventos diferentes a través de los que el agente envía eventos basados en las definiciones de emisión y procesamiento.

En resumen, una Red de Procesamiento de Eventos (EPN) es un gráfico dirigido de operaciones de procesamiento de eventos conectadas por medio de canales de eventos. Los EPA dentro de la red le ofrecen mediaciones y servicios de procesamiento de eventos. Esto significa que obtienen un conjunto de uno o más eventos como entrada, realizan algún tipo de procesamiento y devuelven un conjunto (posiblemente nuevo) de cero o más eventos como datos de salida. La responsabilidad primordial de una Red de Procesamiento de Eventos consiste en recibir eventos de los productores, transferirlos a una combinación de agentes de procesamiento de eventos para que los procesen y entregarlos a los consumidores adecuados.


Escenarios de Red de Procesamiento de Eventos

Ahora, mapeemos los componentes y la definición de la red de procesamiento de eventos hacia los escenarios descriptos en la Introducción.

Escenario de gestión de la flota

A continuación, mencionamos los componentes de la red de procesamiento de eventos (productores, consumidores, canales de eventos, agentes de procesamiento de eventos y también los eventos) que describen sólo uno de los aspectos importantes al momento de realizar el seguimiento de los vehículos y los conductores (es decir, uno de los objetivos que se mencionan con anterioridad). La compañía implementa ciertas reglamentaciones para garantizar la seguridad de sus conductores y para evitar accidentes. Por lo tanto, la jornada laboral de los conductores nunca debe exceder las 8 horas. Todo conductor que exceda esta limitación horaria se verá obligado a descansar y, para evitar todo tipo de demoras en las entregas a los clientes y que así la compañía no tenga que pagar ninguna multa, otros conductores se deberán encargar de realizar todas las entregas afectadas. Este proceso de reasignación de tareas requiere el establecimiento de un punto de reunión adecuado en las instalaciones de la compañía, donde los productos se transferirán de un vehículo a otro(s) y se recalcularán las rutas para que las demoras, si fuesen inevitables, fuese lo menores posibles. Existe un sistema de información del conductor desde el que se producen eventos de inicio y de finalización de la jornada laboral del conductor. Basándose en estos eventos y en el conocimiento constante de las ubicaciones de los vehículos, se pueden llevar a cabo los procesos de reubicación. Además, existen algunos requisitos para el enriquecimiento de eventos, la detección del patrón de "tiempo excesivo de manejo" y el establecimiento de rutas (a los que se describe como agentes de procesamiento de eventos).

Tabla 1. Productores de eventos
Productor de eventosDescripción
VehículoTransmisión de ubicación por GPS, sensores en el vehículo (combustible, emisión, peso, etc.)
Driver Report System (Sistema de información del conductor)Tarjeta perforada electrónica
Delivery System (Sistema de entrega)Gestión de órdenes, Ordenamiento y asignación de paquetes y Sistema de despacho de vehículos
Package RFID System (Sistema RFID para paquetes)Sistema de seguimiento de paquetes con lectores en estaciones y lectores móviles para el personal (por ejemplo, que los conductores usan al recolectar, transferir y entregar los paquetes)
Tabla 2. Consumidores de eventos
Consumidor de eventosDescripción
Driver Display (Pantalla del conductor)Pantalla del conductor móvil y en el vehículo que muestra las rutas, los cambios en las entregas y las alertas
Delivery Management Dashboard (Panel de control de gestión de entregas)Vista completa de las operaciones (ubicación de los vehículos, rutas, pedidos, paquetes, etc.
ClientesLos emisores o los receptores de pedidos pueden recibir notificaciones o buscar sus pedidos
Tabla 3. Eventos
ID del tipo de eventoTipo de eventoAtributosComentarios
E1El conductor comienza a trabajarFecha y hora; ID del conductor-
E2El conductor comienza a trabajar (versión enriquecida)Fecha y hora; ID del conductor; ID del vehículo; Nombre del conductor-
E3El conductor termina de trabajarFecha y hora; ID del conductorSe puede basar en la estructura de E1
E4El conductor excedió el tiempo de manejo permitidoFecha y hora; ID del conductor; ID del vehículo; Nombre del conductor-
E5Cambio en la entregaFecha y hora; ID del conductor 1; ID del vehículo 1; ID del conductor 2; ID del vehículo 2; ID del emisor; ID del receptor-
Tabla 4. Canales de eventos
ID del canal de eventosTipo de eventoProductoresConsumidoresPolítica de retención
EC1E1Driver Report SystemA1-
EC2E2A1A2-
EC3E3Driver Report SystemA2-
EC4E4A2A3, Delivery Management Dashboard-
EC5E5A3A4-
EC6E5A4Clientes, Driver Display, Delivery Management Dashboard1 semana
Tabla 5. Agentes de procesamiento de eventos: Ejemplo 1
Propiedad del agenteEspecificación
ID del agenteA1
Nombre del agenteEnriquecer "El conductor comienza a trabajar"
Tipo de agenteEnriquecer
Contexto del agente-
Eventos de entradaE1
Especificación del agenteEnriquecer por ID del conductor con la ID del vehículo y el Nombre del conductor desde Detalles del conductor
Eventos de salidaE2
Comentario del agenteSe enriquece el evento con detalles del conductor (como, por ejemplo, la ID del vehículo)
Tabla 6. Agentes de procesamiento de eventos: Ejemplo 2
Propiedad del agenteEspecificación
ID del agenteA2
Nombre del agenteEl conductor excedió el tiempo de manejo permitido
Tipo de agenteDetectar patrón
Contexto del agenteintervalo (E2,+8h) por ID del conductor
Eventos de entradaE3
Especificación del agenteAusencia de E3
Eventos de salida-
Tabla 7. Agentes de procesamiento de eventos: Ejemplo 3
Propiedad del agenteEspecificación
ID del agenteA3
Nombre del agenteReasignación de la entrega
Tipo de agenteDetectar patrón
Contexto del agente-
Eventos de entradaE4, Ex
Especificación del agenteEnriquecer por ID del conductor con la ID del vehículo y el Nombre del conductor desde Detalles del conductor
Eventos de salidaE5
Comentario del agenteEste agente recibe diferentes tipos de eventos para inferir los requisitos de cambio en la entregas. Este agente es responsable de decidir qué vehículo debería hacerse cargo de la entrega y cómo reunir a ambos vehículos en una misma estación o en otro lugar.
Tabla 8. Agentes de procesamiento de eventos: Ejemplo 4
Propiedad del agenteEspecificación
ID del agenteA4
Nombre del agenteNotificación de reasignación de ruta a los consumidores requeridos
Tipo de agenteRouter
Contexto del agente-
Eventos de entradaE5
Especificación del agente-
Eventos de salidaE5
Comentario del agenteRutea el cambio en la entrega a los diferentes consumidores. Es posible notificar a los clientes (se reintentará durante 1 semana), los conductores recibirán las instrucciones nuevas y las operaciones podrán realizar el seguimiento de estas instrucciones nuevas

A continuación, la Figura 6 le muestra los componentes de esta EPN en forma de diagrama. El Driver Report System produce el evento E1 y lo publica en el canal EC1 como "el conductor comienza a trabajar". El Eventos de procesamiento de agentes A1 enriquece el evento E1 y se produce el evento E2. Luego de 8 horas, el agente A2 produce el evento E4 como "el conductor excedió el tiempo de manejo permitido" antes de que termine su jornada de trabajo. El Delivery Management Dashboard recibe el evento E4 para controlarlo. El agente A3 también recibe este evento por medio del canal EC4 y reasigna los pedidos del conductor a otros conductores, para que las entregas se realicen en tiempo y forma sin que los conductores excedan los tiempos de manejo permitidos. La instrucción de reasignación se informa a través del evento E5, que A4 rutea y redirecciona hacia varios consumidores que deben ser notificados: el conductor que excedió el tiempo de manejo permitido, el conductor o los conductores que deben hacerse cargo de entregar sus pedidos, el cliente (que debe conocer los cambios efectuados a la ruta de entrega y la hora de llegada esperada) y el Delivery Management Dashboard (para propósitos de control). La jornada laboral de un conductor termina cuando transfiere sus entregables a otros conductores y, en dicho momento, se produce el evento E3 (que no tiene efecto directo sobre los agentes descriptos).

Figura 6. Representación gráfica de la EPN para la gestión de la flota
Representación gráfica de la EPN para la gestión de la flota

Escenario de alerta de salud pública

Las siguientes Tablas mencionan los componentes de la red de procesamiento de eventos correspondientes al escenario de alerta de salud pública que se describió en la Introducción. Los EPA para este escenario no se describen de manera detallada.

Tabla 9. Productores de eventos
Productor de eventosDescripción
HospitalEs probable que el hospital detecte posibles virus o indicios de ellos y emita un evento
LaboratorioEs probable que el laboratorio detecte posibles virus o indicios de ellos y emita un evento
DoctorEs probable que el doctor detecte indicios de posibles virus y emita un evento
Organismo gubernamental extranjeroEl Organismo gubernamental extranjero emite un evento
Tabla 10. Consumidores de eventos
Consumidor de eventosDescripción
Compañía farmacéuticaLa compañía farmacéutica se subscribe a los eventos de alertas de salud
Organismo gubernamentalEl organismo gubernamental se subscribe a los eventos de alertas de salud
MédicoEl médico se subscribe a los eventos de alertas de salud que, posiblemente, resulten enriquecidos con más detalles sobre las características y los patrones de detección
Compañía de seguros de saludLa compañía de seguros de salud se subscribe a los eventos de alertas de salud
Agencia de noticiasLa agencia de noticias se subscribe a los eventos de alertas de salud
Departamento de Seguridad NacionalEl Departamento de Seguridad Nacional se subscribe a los eventos de alertas de salud que, posiblemente, resulten enriquecidos con información sobre precauciones específicas y patrones de detección

También existe la noción de una especie de intermediario que implementa la Red de Procesamiento de Eventos (EPN) y desvincula a los productores de eventos (que desconocen quiénes consumirán el evento y qué se hará con él) de los consumidores de eventos (que ignoran el origen del evento y la forma original o el significado del evento inicial).

Aparte de esta relación entre el Productor de eventos y la EPN y el Consumidor y la EPN, también nos podemos imaginar algunos casos en los que los productores hagan que el evento esté disponible para todo el mundo (a través de una página web o una fuente) y en los que la EPN recupera esta información. Por otro lado, la EPN también hace que el evento esté disponible (probablemente, mediante los mismos mecanismos) para todos los consumidores de eventos. Luego de esto, se puede observar una desvinculación entre el productor y la EPN y el consumidor y la EPN y también se puede considerar la existencia de un escenario desvinculado directo que prescinda de los servicios del intermediario.

Tabla 11. Eventos
ID del tipo de eventoTipo de eventoAtributosComentarios
E1Alerta de posible brote epidémicoID; DetallesEl evento opuesto es "No hay posibilidad de que exista un brote epidémico"
E2Posible brote epidémico normalizadoID; Fecha y hora; Ubicación; DetallesEvento normalizado / transformado desde el evento original
E3Posible brote epidémico enriquecidoID; Fecha y hora; Ubicación; Más detallesEvento enriquecido
E4Alerta de brote epidémico detectadoID; Fecha y hora; Ubicación; DetallesSe detectó un brote epidémico (detección de patrón)
E5Alerta de brote epidémicoID; Fecha y hora; Ubicación; Detalles-
E6Alerta de posible brote pandémicoID; Fecha y hora; Ubicación; Detalles-
E7Posible brote pandémico normalizadoID; Fecha y hora; Ubicación; DetallesSe detectó un brote epidémico (detección de patrones)
E8Posible brote pandémico enriquecidoID; Fecha y hora; Ubicación; Más detallesEvento enriquecido
E9Alerta de brote pandémico detectadoID; Fecha y hora; Ubicación; DetallesSe detectó un brote pandémico (detección de patrones)
E10Alerta de brote pandémicoID; Fecha y hora; Ubicación; Detalles-

La Figura 7 le ofrece una representación gráfica de esta EPN.

Figura 7. EPN para el escenario de alerta de salud pública
EPN para el escenario de alerta de salud pública

Escenario de un proveedor de servicios de comunicación

A continuación, describimos un subgrupo de los componentes de la red de procesamiento de eventos (productores de eventos, agentes de procesamiento de eventos, consumidores de eventos y eventos) en el escenario de un proveedor de servicios de comunicación que se describió en la Introducción.

Tabla 12. Productores de eventos
Productor de eventosDescripción
Monitor de redesEs un software que analiza el equipamiento en busca de datos de rendimiento y disponibilidad, generalmente usando protocolos como ICMP y SNMP. Además, genera eventos que representan cambios notables en los elementos de red y excepciones a la operación normal.
Sondas de elementos de redReciben alertas desde los elementos de red y generan eventos que representan cambios notables y fallas en los elementos de red y en sus vecinos lógicos y físicos. Generalmente, usa protocolos como SNMP para escuchar las alertas.
Sonda del sistema de gestión de elementosRecibe alertas desde los Sistemas de Gestión de Elementos que representan fallas y cambios notables en los elementos de red que se están gestionando. Puede usar formatos de evento estándar o exclusivos en una gran variedad de protocolos estándar o exclusivos (entre los que podemos incluir SNMP, SOAP, CORBA y archivos planos).
Panel de control del operador de eventosProduce eventos basados en acciones de operadores (entre las que podemos incluir el reconocimiento, la resolución y la eliminación de eventos desde los equipos de red y las interrupciones del servicio).
Tabla 13. Consumidores de eventos
Consumidor de eventosDescripción
Paneles de control de operadoresVista interactiva de eventos significativos para los operadores del Centro de Operaciones de Red (entre los que podemos incluir las herramientas de diagnóstico personalizables y las capacidades de filtrado).
Teléfonos y sistema de email del Ingeniero de RedesReciben mensajes SMS y correos electrónicos que son el resultado de eventos críticos que el sistema hizo escalar
Vistas de los clientesVistas actualizadas y de sólo lectura de las interrupciones del servicio detectadas en los servicios filtrados para los clientes afectados.
Sistema Trouble TicketRecibe eventos del sistema que requieren la toma de medidas por parte del equipo de mantenimiento e ingeniería de redes.
Tabla 14. Tipos de eventos
Ingresar IDTipo de eventosAtributosComentarios
E1Falló el pingFecha y hora; Dirección inaccesible-
E2Vínculo rotoFecha y hora; Nombre del puerto del vínculo roto en el router PE; Dirección del router PE-
E3Falla de la tarjetaFecha y hora; Dirección del router PE; Identificador de tarjeta-
E4Evento de causa raízComo E3Copia de E3, identificada como causa raíz
E5Eventos sintomáticosComo E1 y E2; Causa raíz asociadaCopias de E1 y E2, identificadas como síntomas
E6Servicio VPN afectadoFecha y hora; Identificador de VPN-
E7Servicio VPN afectado enriquecidoComo E6; Detalles de contacto del cliente-
E8Técnico despachadoFecha y hora; Detalles de contacto del técnico-
E9Ping exitosoFecha y hora; Dirección a la que se hizo ping-
E10Vínculo activoFecha y hora; Nombre del puerto del vínculo restablecido en el router PE; Dirección del router PE-
E11Tarjeta activaFecha y hora; Dirección del router PE; Identificador de tarjeta-
E12Servicio VPN activoFecha y hora; Identificador de VPN-
Tabla 15. Agentes de procesamiento de eventos: Ejemplo 1
Propiedad del agenteEspecificación
ID del agenteA2
Nombre del agenteService Impact Analyzer (Analizador de impacto del servicio)
Tipo de agenteDetección de patrones
Contexto del agente-
Eventos de entradaE4, E5
Especificación del agenteGenera un evento afectado por el servicio incluso si el servicio de red del cliente está interrumpido
Eventos de salidaE6
Comentarios del agenteUsa relaciones modeladas entre elementos de red y servicios aprovisionados para determinar si el servicio se ve afectado o no
Tabla 16. Agentes de procesamiento de eventos: Ejemplo 2
Propiedad del agenteEspecificación
ID del agenteA3
Nombre del agenteCustomer Impact Analyzer (Analizador de impacto sobre el cliente)
Tipo de agenteRuteo, Enriquecimiento
Contexto del agente-
Eventos de entradaE6
Especificación del agenteEscala un evento afectado por el servicio de acuerdo con la política asociada con el SLA; Realiza el enriquecimiento con los detalles de contacto del cliente
Eventos de salidaE7
Comentarios del agente-
Tabla 17. Agentes de procesamiento de eventos: Ejemplo 3
Propiedad del agenteEspecificación
ID del agenteA4
Nombre del agentePrioritization Module (Módulo de priorización)
Tipo de agenteRuteo, Enriquecimiento
Contexto del agente-
Eventos de entradaE7
Especificación del agenteEnriquece eventos con la prioridad relativa
Rutea eventos hacia los consumidores según la prioridad-
Instiga la toma de acciones correctivas por medio del sistema Trouble Ticket-
Eventos de salidaE4, E5, E7, E8
Comentarios del agente-

La Figura 8 le ofrece una descripción gráfica de la parte de la red de procesamiento de eventos que se usa en el escenario, hasta el momento en el que se despacha el técnico.

Figura 8. EPN para el escenario de un proveedor de servicios de comunicación
EPN para el escenario de un proveedor de servicios de comunicación

Arquitectura conceptual

La Arquitectura conceptual se fundamenta en los conceptos de la EPN mediante la definición de varios componentes que se pueden involucrar en una solución de procesamiento de eventos. Algunos de estos componentes son equivalentes a un EPA, o a un conjunto de EPAs conectados, a nivel de la EPN, mientras que otros están más relacionados con el flujo de eventos y equivalen a los canales en la EPN. Una de las figuras que incluimos más adelante en esta sección, la Figura 11, le muestra cómo la Arquitectura conceptual realiza el mapeo hacia la EPN.

Todas las arquitecturas de sistema que soportan el procesamiento de eventos de negocios deberían permitir la definición flexible de la lógica de procesamiento de eventos: detección de patrones de eventos, derivación de eventos nuevos, transformación y ruteo desde los productores hasta los consumidores basándose en la lógica de negocios requerida. Por lo tanto, los negocios pueden reaccionar a los cambios, ejecutar los procesos que sean relevantes e influenciar los procesos que se estén desarrollando basándose en los cambios. Además, dicha definición del procesamiento de eventos debería ser fácil de modificar y se la debería poder implementar rápidamente de acuerdo con las necesidades de negocios (como, por ejemplo, los cambios en los procesos y las políticas de negocios).

Para poder comprender cómo se puede derivar este valor de negocios desde los sistemas de procesamiento de eventos, es importante considerar un nivel más de granularidad que la red de procesamiento de eventos, para así tener en cuenta componentes que se pueden usar para construir un sistema de procesamiento de eventos y sus interacciones. El resultado de este proceso es lo que denominamos una arquitectura conceptual para los sistemas de procesamiento de eventos. Además de los tres niveles típicos de un sistema impulsado por eventos (el productor de eventos y los componentes asociados, el consumidor de eventos y los componentes asociados y un intermediario: el nivel del Bus de eventos), es necesario que la arquitectura conceptual incluya componentes para la seguridad, el monitoreo, la analítica y la gestión de eventos y flujos de eventos.

En el nivel más simple, se necesita un conjunto mínimo de componentes conceptuales para un sistema de procesamiento de eventos: un nivel de Event Emitter (Emisor de eventos), para que emita eventos desde los productores de eventos, un Event Bus (Bus de eventos) y un Event Handler (Administrador de eventos), para que se ocupe de los eventos que consumirán los consumidores de eventos. Esto se ilustra en la Figura 9, que también incluye algunos ejemplos de productores de eventos y de consumidores de eventos.

Figura 9. Arquitectura conceptual mínima de procesamiento de eventos
Arquitectura conceptual mínima de procesamiento de eventos

Es posible que sea necesario contar con capacidades adicionales dentro del nivel del Emisor de eventos, el Bus de eventos Bus y el Administrador de eventos (o receptor). En la práctica, los eventos que genera un productor de eventos no siempre se pueden compartir de manera inmediata con los consumidores de eventos. Como el productor de eventos no debería requerir la conciencia de los consumidores de eventos en un sistema de procesamiento de eventos, suele existir la necesidad de un nivel de middleware entre el productor y el consumidor. Este nivel de middleware realiza tareas adicionales relacionadas con los eventos y hace que el consumidor pueda recibir los eventos que le interesan, o sus derivados. El productor no genera todos los eventos en el formato requerido y, en tales casos, es necesario transformar dichos eventos en el formato requerido (estándar empresarial) antes de publicarlos en el nivel intermedio. En algunos casos, un pre procesador de eventos (router, filtro) puede evaluar la importancia de un evento ordinario, lo que resulta en la generación de un evento notable nuevo. Además, un productor de eventos puede optar por no emitir todos los eventos. Los agentes de procesamiento de eventos pueden filtrar y mediar los eventos sin procesar dentro del dominio del productor.

De manera similar, no todos los eventos que recibe el consumidor están listos para usar. Por lo tanto, es posible que el consumidor deba realizar algún tipo de procesamiento o mediación. Un pre procesador de eventos (filtro) puede evaluar la importancia de un evento ordinario antes de su administración detallada por parte del consumidor. El consumidor puede optar por ignorar algunos de los eventos que recibe. Los servicios de procesamiento de eventos cumplen con estos requisitos de procesamiento de eventos anteriores a la publicación y a la recepción de los mismos a nivel del administrador de eventos.

La Figura 10 le muestra todos los componentes de la Arquitectura conceptual de procesamiento de eventos. Toda implementación de procesamiento de eventos se debería de poder lograr con este conjunto base de componentes a nivel conceptual (aunque esto no significa que todos los componentes van a ser necesarios para todas las implementaciones). De manera similar, no todos los componentes serán necesarios para un escenario en particular. Como analizaremos más adelante cuando volvamos a ocuparnos de los escenarios y veamos cómo realizan el mapeo hacia la arquitectura conceptual, en la mayoría de los casos, no se usan todos los componentes.

Figura 10. Arquitectura conceptual de procesamiento de eventos: Componentes que se pueden involucrar en un sistema de procesamiento de eventos
Arquitectura conceptual de procesamiento de eventos: Componentes que se pueden involucrar en un sistema de procesamiento de eventos

Componentes arquitectónicos

El flujo de eventos en la arquitectura conceptual es de productor a consumidor, y los componentes que figuran en el diagrama de arquitectura conceptual se resumen aquí en dicho orden. La próxima sección le ofrece una descripción más detallada del flujo de procesamiento en el modelo conceptual. A nivel de la implementación, los consumidores de eventos, generalmente, también serán productores de eventos. Pero a nivel conceptual, los roles de los consumidores y los productores son diferentes.

  • Productor de eventos. El productor de eventos emite un evento cuando ocurre (o no ocurre) algo de interés. El productor de eventos no incluye la lógica para manipular eventos. Tampoco incluye ninguna lógica de decisión sobre qué emitir en qué momento y los eventos generados podrían ser redundantes o irrelevantes. A continuación, mencionamos algunos ejemplos típicos de productores de eventos:
    • Sensores de eventos, que detectan situaciones (cosas que ocurren) y generan eventos sin procesar u originan eventos a partir de flujos de datos o de flujos de negocios. Un ejemplo de esto sería la transmisión de temperatura.
    • Monitores y sondas, que producen eventos sobre la disponibilidad y los problemas de los sistemas (como, por ejemplo, las fallas en las redes de TI).
    • Procesos de negocios, que producen eventos en puntos significativos del procesamiento (por ejemplo, durante los hitos o los puntos de control) o cuando se llega a (o se inicia) una tarea de un proceso específico.
    • Servicios y aplicaciones, que producen eventos en puntos clave del procesamiento (como, por ejemplo, cuando el servicio se invoca y se completa o cuando fracasa).
    • Máquinas de estado, que generan eventos cuando se cambia de estado.
  • Emisor de eventos. Éste se asocia lógicamente (aunque no necesariamente de manera física) con el productor de eventos y es responsable de convertir y empaquetar eventos sin procesar de los productores para entregarlos al Bus de eventos. El Emisor de eventos puede incluir un Event Instantiator (Instanciador de eventos), que crea las instancias de eventos, Servicios de procesamiento de eventos simples, como el filtrado y la mediación de eventos emitidos por un solo productor, lo que enriquece el evento con información disponible en el momento que el evento ocurre, y Event Adapters (Adaptadores de eventos). El Instanciador de eventos toma eventos del productor y hace todo lo necesario (si es que es necesario hacer algo) para hacer que esté disponible para más tareas de procesamiento o para su entrega, lo que puede incluir la agregación, el cacheo y la serialización de eventos. Es posible que sea necesario que el instanciador de eventos manipule el encabezado del evento para incrustar "metadatos semánticos" en el mensaje del evento y así hacerlo autodescriptivo (con información como, por ejemplo, hora, fecha, tipo de instrumento, ID del proceso, etc.). El Emisor de eventos puede realizar la optimización mediante el procesamiento simple de eventos en esta etapa en vez de luego de que los eventos lleguen al Bus de eventos. Los adaptadores de eventos puede ofrecer el formateo y la conversión de protocolo del evento para crear algo que lo recibirá la red de procesamiento de eventos (como, por ejemplo, la contención de registros de eventos como mensajes de evento y el envío de los mensajes de evento hacia el Bus de eventos).
  • Bus de eventos. El bus de eventos recibe eventos (posiblemente, en gran volumen) de los emisores de eventos e invoca consumidores por medio de administradores de eventos como un resultado de los eventos. Entre las capacidades de un bus de eventos, podemos mencionar el procesamiento para producir un menor volumen de eventos más informativos a partir de los eventos entrantes. Los componentes del Bus de eventos no tienen que estar coubicados. La próxima subsección le ofrece más detalles sobre el Bus de eventos.
  • Administrador de eventos. Este componente prepara los eventos del Bus de eventos para el consumo por parte de los consumidores de eventos, recibiendo eventos y decidiendo cómo reaccionar ante ellos. El administrador de eventos tiene Adaptadores de eventos para recibir mensajes de eventos desde el bus de eventos y separarlos para obtener registros de eventos. El administrador de eventos también puede ofrecer Servicios de procesamiento de eventos simples, que se ocupan del procesamiento por parte del consumidor para filtrar y mediar los eventos recibidos del Bus de eventos. Los Administradores de eventos también pueden determinar el / los consumidor(es) apropiados para reaccionar ante un evento e invocar el / los consumidor(es) con un contexto derivado del evento. Por último, un Administrador de eventos le puede ofrecer servicios de orquestación de eventos para gestionar la distribución de eventos entre los consumidores.
  • Consumidor de eventos. El consumidor de eventos realiza tareas en reacción a un evento. Al consumidor de eventos no le incumbe el origen del evento y sólo sabe que se lo invoca como resultado del evento junto con el contexto relativo al evento en cuestión. A continuación, mencionamos algunos ejemplos típicos de consumidores de eventos:
    • Activadores de eventos, que se los invoca para que realicen tareas físicas (como, por ejemplo, la operación de válvulas, interruptores o alarmas).
    • Paneles de control del operador, que visualizan información sobre el comportamiento de los sistemas de TI y los servicios afectados.
    • Paneles de control de negocios, que visualizan información sobre el comportamiento de los procesos de negocios.
    • Procesos de negocios, que se pueden iniciar o reanudar en respuesta a un evento.
    • Servicios y aplicaciones, que se pueden invocar en reacción a un evento y pueden incluir sistemas externos de gestión de contenidos o repositorios de eventos.
    • Máquinas de estado, cuyo estado se puede cambiar en reacción a un evento.

Esta vista de la arquitectura conceptual se basa en los roles de cada componente, pero ello no significa que un participante de la arquitectura en particular no puede cumplir con más de un rol: un productor de eventos también podría encargase del procesamiento de eventos y desempeñarse como consumidor de eventos. En particular, sólo se requieren los Servicios de publicación y subscripción cuando se usa un modelo del estilo Publicar/Subscribir.

Se puede considerar a la arquitectura conceptual como "anidada", ya que un participante podría incluir una red de componentes adicionales. Por ejemplo: Un productor de eventos podría emitir un evento y enviarlo hacia el bus de eventos principal. Pero, en el proceso de producción de dicho evento, uno podría prever una versión "mini" del modelo general, en la que un productor emita un evento simple inicial para comparar patrones con otros eventos en un "mini" bus de eventos, que resida lógicamente dentro del productor de eventos general.

Componentes del bus de eventos

El bus de eventos transmite eventos desde los productores hasta los consumidores y puede ofrecerle servicios adicionales para el procesamiento y el ruteo de eventos. El bus de eventos puede tener un registro de eventos asociado y la capacidad de realizar el almacenamiento transaccional de eventos en desarrollo (pasajeros o persistentes) usando un repositorio de eventos.

El bus de eventos puede ser local o implementarse a nivel de la empresa, y es necesario que los eventos recibidos se procesen basándose en los requisitos de negocios. Esto se logra usando servicios simples y complejos de procesamiento de eventos. Agentes de procesamiento de eventos, que están conectados por medio de canales de eventos, se encargan de ofrecer estos servicios.

Los servicios, o bloques de construcción, que el bus de eventos puede ofrecer son los siguientes:

  • Canales de eventos, que transmiten eventos desde los Emisores de eventos hasta el Bus de eventos, entre componentes del Bus de eventos y hasta los Administradores de eventos.
  • Servicios de publicación, para hacer que los productores puedan enviar eventos a los canales adecuados.
  • Servicios de subscripción, para permitir el registro dinámico de productores y consumidores (como, por ejemplo, permitir que los Administradores de eventos encuentren los canales apropiados y se subscriban para recibir eventos de dichos canales).
  • Servicios de notificación, para notificar a los Administradores de eventos subscriptos cuando los eventos estén disponibles (soportando tanto la inserción como la eliminación de eventos).
  • Servicios de consulta, para permitir la consulta de un repositorio en busca de eventos (y metadatos).
  • Servicios de seguridad de eventos, para controlar el acceso y la autoridad relativa a los eventos. Por ejemplo, para controlar la autorización para agregar y eliminar eventos del bus de eventos, al igual que la privacidad y la no repudiación de los contenidos de los eventos.
  • Servicios de procesamiento de eventos, que ofrecen el filtrado, la transformación y el enriquecimiento de eventos, y que también pueden ofrecer la comparación de patrones y la derivación de eventos. Esto puede incluir el procesamiento de eventos complejos, que procesa eventos desde múltiples fuentes y puede realizar la comparación de patrones que se ejecutan por un largo período de tiempo entre eventos.
  • Servicios de información de eventos, que permiten a los administradores agregar, eliminar y organizar canales con el objetivo de organizar los metadatos del tipo de evento (la sintaxis y la semántica) y almacenar los datos del evento de manera alternativa en un formato relacional en vez de usando una persistencia basada en el mensaje del evento (es decir, atómica).
  • Un Registro de eventos, para ofrecerle una taxonomía de los tipos de eventos y una ontología de las relaciones entre los eventos.
  • Un Repositorio de eventos, para almacenar eventos y así ofrecer una persistencia de eventos a mediano o a largo plazo.

A continuación, se enumeran los tipos de funciones más importantes que el procesamiento debe ofrecer dentro del Bus de eventos.

  • Transformación: Función que transforma el evento entrante mediante su traducción o división.
  • Enriquecimiento: Función que enriquece los contenidos de los eventos con datos de referencia desde múltiples fuentes posibles.
  • Validación: Función que le ofrece validación según los criterios requeridos.
  • Detección de patrones: Función que reconoce patrones reales y retrospectivos (una combinación de múltiples eventos que caracterizan una situación de negocios importante).
  • Filtrado: Función sin estado que filtra eventos basándose en sus contenidos (es decir, la información que transporta el mensaje generado cuando el evento ocurrió).
  • Agregación: Función que puede agrupar eventos de ser necesario.
  • Ruteo: Función que rutea eventos hacia su destino basándose en varios patrones posibles de ruteo (como, por ejemplo, un itinerario preestablecido, una decisión basada en un calendario, una subscripción o decisiones de ruteo "inteligentes").

La arquitectura conceptual también incluye los Event Governance and Security Services (Servicios de seguridad y gobernabilidad de eventos) para gestionar y controlar el ciclo de vida de los eventos y los metadatos de los eventos. Event Monitoring and Analytic Infrastructure (Monitoreo de eventos e infraestructura analítica) es necesario principalmente para tareas administrativas, para notificar sobre fallos en la infraestructura del evento y para reunir y visualizar información estadística sobre el flujo de eventos. Estas capacidades deben abarcar la totalidad del flujo de eventos y, por lo tanto, figuran a la derecha del diagrama del Modelo conceptual.

Por ende, la arquitectura conceptual representa productores de eventos que emiten eventos y los envían hacia el bus de eventos, donde se los puede procesar y los consumidores de eventos terminan consumiéndolos. Como resultado de un evento, un consumidor puede producir otro evento o reaccionar de otra forma con otro componente que produce un evento como resultado.

La Figura 11 le muestra un ejemplo de cómo la arquitectura conceptual trabaja sobre el concepto de una EPN, ilustrando los componentes equivalentes de los EPA, o conjunto de EPAs conectados, y otros componentes que ofrecen servicios de canal de eventos.

Figura 11. EPN que usa la arquitectura conceptual de procesamiento de eventos
EPN que usa la arquitectura conceptual de procesamiento de eventos

Flujo de procesamiento en la arquitectura conceptual

El propósito de esta subsección consiste en describir el Modelo conceptual en acción. Existen tres fases que debemos considerar:

  • Fase de emisión del evento
  • Fase de procesamiento del evento
  • Fase de consumo del evento

No se trata de un flujo de procesamiento único y consistente y existe muy poco acoplamiento entre estas tres fases (en especial, cuando se trata del procesamiento de eventos complejos; en cuyo caso, las tres fases pueden ocurrir en períodos de tiempo completamente diferentes y sólo existe una relación de causa y efecto entre el evento emitido y el evento consumido).

Para poder ofrecerle ejemplos concretos, esta sección se refiere a los escenarios que se describen en más detalle en otras secciones.

Fase de emisión del evento

Los componentes de la Arquitectura conceptual involucrados en esta fase son, principalmente, los componentes del Emisor de eventos. Su rol en la emisión del evento puede ser bastante técnico (es decir que, principalmente, se ocupan de ofrecer niveles de conectividad técnica entre el Productor de eventos y el Bus de eventos, aunque también se pueden orientar a los negocios; es decir que se puede llegar a implementar una lógica de procesamiento de eventos orientada a los negocios o Agentes de procesamiento de eventos locales).

Perspectiva técnica

Cuando ocurre un evento de negocios posiblemente significativo, el Productor de eventos envía un mensaje de evento al Bus de eventos usando su nivel local de Emisor de eventos. El subnivel de Instanciador de eventos es un componente técnico a cargo de detectar esta situación de negocios específica y de reunir toda la información necesaria. Luego de esto, los Servicios locales de procesamiento de eventos pueden procesar la información para crear el mensaje de evento, por ejemplo, formateándolo para que cumpla con un formato genérico publicado en el Registro de eventos. Luego, el subnivel de Adaptador de eventos envía este mensaje de evento al Bus de eventos, que se encarga de adaptar el mensaje de evento de acuerdo con los protocolos de transporte que soporta el Bus de eventos.

Ejemplo: En el escenario de gestión de una flota, consideramos el Sistema de entrega y, en especial, el subsistema de despacho de vehículos como el Proveedor de eventos. Asumamos que el subsistema de despacho de vehículos es una aplicación de negocios que almacena sus datos en una base de datos relacional. "Delivery Change" (Cambio en la entrega) es un evento de negocios que se debería emitir cada vez que el conductor o el vehículo a cargo de la entrega en cuestión se modifican en esta aplicación. Se implementa el Instanciador de eventos como un disparador en la Tabla que almacena los datos de entrega. Este disparador se activa cada vez que se actualiza una instancia de entrega en la Tabla. Este disparador implementa los servicios locales de procesamiento de eventos. Además, valida que la actualización se relacione con una modificación del vehículo o el conductor a cargo de la entrega. Si esta prueba resulta exitosa, la lógica de activación reúne toda la información necesaria (ID del conductor 1, ID del vehículo 1, ID del conductor 2, ID del vehículo 2, ID del emisor, ID del receptor) y crea una instancia del mensaje de evento de "Cambio en la entrega" en una Tabla exclusiva de eventos de Cambio en la entrega. Se implementa el subnivel de Adaptador de eventos usando un adaptador JDBC, a cargo de analizar esta Tabla y de iniciar la lógica externa de procesamiento de eventos a nivel del Bus de eventos.

Perspectiva de negocios

En implementaciones más avanzadas, el nivel de Emisor de eventos puede soportar patrones de detección de eventos del productor más avanzados y puede implementar Agentes locales de procesamiento de eventos. También se puede considerar el filtrado, la agregación, el enriquecimiento o incluso la validación de eventos elementales en el subnivel de Procesamiento de eventos con el objetivo de emitir, a través del Bus de eventos, un solo mensaje de evento que caracterice la ocurrencia de un Evento de negocios valioso.

Ejemplo: En el escenario de alerta de salud pública, consideremos al "Hospital" como el Proveedor de eventos y al evento de "Alerta de posible brote epidémico" que produce. Por medio del Sistema de información del hospital, se informa la situación de muchos pacientes. Resulta que es necesario monitorear a algunos de ellos de manera continua, ya que se los vincula con una infección específica. La ocurrencia de esta situación es un evento elemental. Para detectar un Posible brote epidémico, es necesario comparar (localmente en el hospital) varios eventos elementales similares que afectan a muchos pacientes y durante un período de tiempo limitado. Por lo tanto, el Instanciador de eventos y los servicios locales de Procesamiento de eventos implementan un Agente de procesamiento de eventos a cargo de todo lo siguiente:

  • Validar el origen y la calidad de estos eventos elementales.
  • Correlacionarlos.
  • Producir un evento de "Posible brote epidémico normalizado" como lo esperan todos los involucrados de la Red de Procesamiento de Eventos.

Fase de procesamiento del evento

Esta fase se lleva a cabo en el Bus de eventos. Pueden existir diferentes flujos de procesamiento, que involucren diferentes componentes del Bus de Eventos, dependiendo de la cantidad de eventos a procesar. En el presente, describimos dos comportamientos diferentes para procesar un solo evento o varios eventos.

Procesamiento de un solo evento entrante

Publicar/Subscribir es un patrón básico de procesamiento posible. Cuando se recibe un mensaje de evento a nivel del Bus de Eventos, el subnivel de los Servicios de Publicación lo intercepta y lo distribuye entre los diversos Canales configurados por el Administrador del bus de eventos. Estos Canales se publican en el Registro de eventos, para que estén disponibles para los Consumidores de Eventos o el componente de Servicios de Subscripción. Los consumidores de eventos acceden al Registro de eventos para obtener información sobre los Canales relacionados con el tipo de Evento en el que están interesados. Los Consumidores de eventos reciben el mensaje de evento simplemente escuchando a los Canales relevantes.

Ejemplo: En el escenario de gestión de la flota, consideremos el evento de Cambio en la Entrega, con el Panel de Control de gestión de la entrega como un Consumidor de Eventos. Cada vez que el Bus de eventos detecta un evento de Cambio en la Entrega, se hace que el mensaje de evento relacionado esté disponible en un Canal de Eventos específico. El Panel de Control de gestión de la entrega escucha a este canal. Cuando se recibe un mensaje de evento nuevo, el Panel de control de gestión de la entrega lo procesa usando su Administrador local de eventos (ver la fase de consumo del evento).

También se puede dar el caso de que un solo evento entrante genere múltiples eventos salientes con formatos diferentes, dependiendo de su carga útil y las solicitudes de subscripción expresadas para él. Los Consumidores de eventos pueden indicar su interés en un tipo de evento específico usando los Servicios de subscripción. Además, también pueden configurar parámetros adicionales para especificar la forma en la que desean que se los notifique sobre el evento relacionado. Estos parámetros pueden ser los siguientes (lista no exhaustiva):

  • Formato del mensaje de evento que se recibirá al momento de la notificación
  • Canal por medio del que se recibirá este mensaje
  • Criterios de filtrado de eventos

Cuando se recibe un evento de mensaje en el Bus de eventos, el subnivel de Servicios de publicación procesa cada solicitud individual de subscripción para este tipo de evento. Los servicios necesarios de procesamiento de eventos se procesan para mediar el mensaje de evento (principalmente, son servicios de filtrado, enriquecimiento y transformación). Luego de esto, los Servicios de notificación envían el mensaje de evento resultante hacia el Consumidor de Eventos a través del Canal solicitado.

Ejemplo: En el escenario de alerta de salud pública, consideremos al "Médico clínico" como el Consumidor de Eventos y al evento de "Posible alerta de brote epidémico" que emite. El Médico clínico se subscribe a los eventos de alerta de salud, ya que desea recibir notificaciones en su casilla de correo electrónico cada vez que se genere una alerta de Posible brote epidémico en su área de trabajo específica. Además, también desea obtener información adicional sobre la enfermedad relacionada. Los servicios de subscripción del bus de eventos deberían ofrecer ciertas facilidades que le permitan navegar por la lista de alertas disponibles para colocar un filtro en la ubicación geográfica, para elegir los datos adicionales que le puedan llegar a interesar y para seleccionar su canal de entrega preferido. El Bus de Eventos usará estos parámetros para filtrar los eventos entrantes de alerta de Posible brote epidémico con el objetivo de enriquecerlos con toda la información adicional solicitada y para darle formato de correo electrónico con el objetivo de enviarla al consumidor a través de los Servicios de notificación.

Procesamiento de múltiples eventos entrantes

En este caso, se considera la existencia de múltiples eventos entrantes, que posiblemente abarcan diferentes tipos y fueron emitidos por diferentes sectores durante un período de tiempo determinado, al que se denomina un conjunto de eventos. Las situaciones de negocios significativas no se detectan a nivel del Productor de eventos (pero sí dentro del Bus de Eventos) comparando múltiples eventos del conjunto de eventos. El Bus de Eventos implementa uno o varios Agentes de procesamiento de eventos a cargo de realizar esta detección. El administrador del Bus de eventos ya habrá configurado uno o varios patrones (posiblemente, usando los Servicios de Subscripción o los Servicios de Gestión de Información de Eventos) y los habrá almacenado en el Registro de Eventos. Estos patrones pueden abarcar múltiples dimensiones (entre las que podemos incluir la causalidad, la hora, la ubicación y muchas otras). Cuando se recibe un evento, se pueden usar los Servicios de consulta de eventos para controlar con el Registro de Eventos si pertenece o no a un conjunto de eventos asociado con reglas válidas de comparación de patrones. De ser así, el subnivel de Servicios de Procesamiento de Eventos estará a cargo de aplicar esta regla al evento recibido.

En este caso, el Bus de eventos ya puede estar esperando a un evento de este tipo, debido a que ya ha recibido por lo menos un evento del mismo conjunto de eventos, o se podría iniciar un flujo de procesamiento nuevo si todavía no se recibió ningún evento de dicho conjunto de eventos.

El procesamiento de esta regla de comparación de patrones produce un evento resultante, que puede ser:

  • Publicado directamente en los Canales relevantes.
  • Mediado y transmitido a través de los canales relevantes hacia los subscriptores interesados.
  • Transmitido a otro EPA a cargo de otra regla de procesamiento con la que se asocia a este tipo de evento.

Esto puede ser un comportamiento recursivo y el procesamiento encadenado de la comparación de patrones crea un Flujo de Procesamiento de Eventos. El período de tiempo suele ser una característica importante del conjunto de eventos. Además, la hora también es un factor importante al momento de considerar la implementación de los servicios de procesamiento de eventos en el Bus de Eventos.

El Repositorio de Eventos puede cumplir un rol fundamental en el procesamiento de eventos (especialmente, en el caso del procesamiento de eventos complejos). Éste conserva el registro de los eventos procesados en Flujos de Eventos (tanto eventos entrantes como eventos generados o eventos resultantes).

  • En primer lugar, esto resulta muy útil para el monitoreo. Por ejemplo, para responder a preguntas clave (como: ¿Qué combinación de eventos entrantes o qué secuencia de agentes de procesamiento de eventos produjo este resultado?).
  • En segundo lugar, como es posible considerar a un conjunto de eventos durante un período de tiempo prolongado, quizá resulte necesario persistir los eventos relacionados.

Ejemplo: En el escenario de gestión de la flota, consideremos el agente denominado "El conductor excedió el tiempo de manejo permitido" y los eventos asociados: "El conductor comienza a trabajar" y "El conductor termina de trabajar". Estos dos tipos de evento y un período de tiempo de más de 8 horas caracterizan al Conjunto de Eventos. Cada vez que se recibe un evento "El conductor comienza a trabajar" a nivel del Bus de eventos para una ID del conductor específica, se debería iniciar un EPA para que espere un evento "El conductor termina de trabajar" correspondiente a la misma ID del conductor. Si este evento ocurre más de ocho horas después del evento inicial, se debería emitir un evento resultante "El conductor excedió el tiempo de manejo permitido".

En el escenario de alerta de salud pública, consideremos el evento "Alerta de posible brote epidémico" y, como Consumidor del evento, consideremos al agente "Comparar alertas de posible brote epidémico". El tipo de evento denominado Alerta de posible brote epidémico y un período de tiempo de 2 semanas caracterizan al Conjunto de Eventos. Cada vez que el Bus de eventos recibe un mensaje de evento de este tipo, se lo transfiere a un EPA que implementa la lógica de comparación de patrones del agente. Por ejemplo: Si se recibe una Alerta de posible brote epidémico de diez fuentes diferentes en menos de dos semanas, se debería generar una Alerta de brote pandémico.

Fase de consumo del evento

Esta fase se lleva a cabo, principalmente, en el nivel de Administrador de Eventos asociado con el Consumidor del evento. Al igual que en el caso de la fase de emisión del evento, este nivel puede cumplir un rol técnico u orientado a los negocios.

Perspectiva técnica

En esta fase, el Consumidor del evento recibe un mensaje de evento desde el Bus de Eventos y lo procesa, confiando en su nivel local de Administrador del evento. El subnivel de Adaptador del evento está a cargo de recibir el mensaje de evento y crear una interfaz con los protocolos de transporte soportados por el Bus de eventos. Puede haber un procesamiento preliminar del mensaje de evento, implementado en el subnivel local de Procesamiento de Eventos. Esto puede ser, por ejemplo, una adaptación técnica de la carga útil del mensaje de evento para cumplir con los formatos de entrada específicos del Consumidor del evento. El subnivel de Orquestación de Eventos identifica la parte de la lógica de negocios que implementa la acción asociada con la recepción de este mensaje de evento específico. El subnivel de Orquestación de Eventos inicia la ejecución de esta lógica, con la carga útil opcionalmente transformada del mensaje de evento como parámetro de entrada.

Ejemplo: En el escenario de gestión de la flota, consideremos el evento denominado Cambio en la entrega y el Panel de Control de Gestión de Entregas como su Consumidor del evento. El Panel de Control de Gestión de Entregas se implementa como un portal. Se recibe un nuevo mensaje de evento de Cambio en la entrega en el Administrador de Eventos local por medio de una conexión de cola de mensaje WebSphere MQ (Adaptador del evento local) que es la interfaz con el Bus de eventos. La lógica local de procesamiento de eventos se implementa como un portlet, que recibe la carga útil del evento y la procesa para actualizar algunos indicadores y para modificar los gráficos que ve el consumidor final.

Perspectiva de negocios

El nivel de Administrador del evento se puede comportar, en implementaciones más avanzadas, como un punto de convergencia de múltiples mensajes de evento elementales. Estos mensajes de evento elementales se comparan en el subnivel local de procesamiento de eventos. Esto produce un evento local resultante asociado con una acción en el Consumidor del evento. Luego de esto, el evento resultante se transmite hacia el nivel de Orquestación de Eventos para iniciar la lógica de negocios relevante en el Consumidor del evento. Por otra parte, la recepción de un solo mensaje de evento puede generar múltiples procesamientos locales, ya que muchas partes del Consumidor del evento están interesadas en él de diferentes maneras.

Ejemplo: En el escenario de alerta de salud pública, consideremos al "Hospital" como el Consumidor del evento y al evento denominado "Alerta de brote pandémico" que consume. Cuando se notifica sobre dicho evento al Hospital, como se genera una situación muy crítica, pueden existir varias formas de procesamiento local de este evento que ocurren en paralelo.

  • La información se puede enviar directamente al portal de la Intranet del hospital por medio de un canal de noticias.
  • Es posible llamar a algunos profesionales clave por medio de un mensaje SMS.

El mensaje de evento se puede enviar a las aplicaciones de logística para iniciar procesos específicos a cargo de gestionar situaciones urgentes de salud.


Mapeo de los escenarios hacia el modelo conceptual

En esta sección, volvemos a analizar los diferentes escenarios de procesamiento de eventos y cómo realizan el mapeo hacia los diversos componentes de la arquitectura conceptual.

Escenario de gestión de la flota

Luego de definir todos los actores (productores de eventos y consumidores de eventos), los eventos y los agentes de procesamiento de eventos en una de las secciones anteriores, ahora es posible realizar un mapeo del escenario de gestión de la flota hacia la arquitectura conceptual de procesamiento de eventos (vea la Figura 12). La vinculación con los productores de eventos y los consumidores de eventos es bastante obvia. Todos los agentes (excepto A4, el agente de ruteo) se mapean hacia el componente de procesamiento de eventos en el bus de eventos. No existe ningún tipo de mapeo hacia el emisor de eventos o hacia la parte del administrador de eventos del modelo conceptual debido a que los dos eventos, E1 y E3, producidos por el Sistema de información del conductor no requieren ningún tratamiento especial y los agentes A1 y A2 los pueden procesar directamente. Además, todos los consumidores pueden consumir E5 en su estado actual.

Figura 12. Componentes de la arquitectura conceptual en el escenario de gestión de la flota
Componentes de la arquitectura conceptual en el escenario de gestión de la flota

El procesamiento de eventos es importante en el escenario de gestión de la flota, ya que permite que se responda en tiempo y forma a toda la información dispar en relación con las ubicaciones de los conductores, los tiempos de manejo y las rutas de entrega. También le ofrece el alcance necesario para modificar las reglas relacionadas con los tiempos de manejo permitidos, cómo se administran los cambios en las entregas, etc.

Escenario de alerta de salud pública

Luego de definir todos los actores (productores de eventos y consumidores de eventos), los eventos y los agentes de procesamiento de eventos, ahora es posible realizar un mapeo del escenario de alerta de salud pública hacia la arquitectura conceptual de procesamiento de eventos (vea la Figura 13). La vinculación con los productores de eventos y los consumidores de eventos es bastante obvia. Se realiza el mapeo de algunos agentes de procesamiento de eventos hacia el emisor de eventos, y el procesamiento principal se vincula con componentes específicos en el bus de eventos. No existe ningún tipo de mapeo hacia la parte del administrador de eventos del modelo conceptual debido a que los aspectos del escenario que hemos detallado aquí no lo requieren.

Figura 13. Componentes de la arquitectura conceptual usados en el escenario de alerta de salud pública
Componentes de la arquitectura conceptual usados en el escenario de alerta de salud pública

Luego de terminar de describir el escenario, consideremos la razón por la cual el procesamiento de eventos es importante para el ejemplo de la alerta de salud pública.

Como este escenario se relaciona con la salud pública, el tiempo es un factor importante, al igual que el historial de eventos, la cantidad de productores de eventos y la cantidad de consumidores de eventos. Tres factores principales son muy importantes para comprender esto y se los define de manera muy efectiva en el sistema de procesamiento de eventos:

  • Acoplamiento holgado entre el productor de eventos y el consumidor de eventos (el origen del evento no es importante, siempre que el consumidor de eventos pueda identificar la calidad y la fuente).
  • Un factor muy importante es dar inicio al procesamiento de eventos inmediatamente luego de detectar el evento y notificar inmediatamente luego de identificar un brote pandémico o epidémico.
  • Como el sistema de procesamiento de eventos no depende de los procesos de negocios del consumidor de eventos, esto permite una muy alta flexibilidad y una red dinámica de procesamiento de eventos que agrega valor a una gran cantidad de consumidores de eventos posibles.

Escenario de un proveedor de servicios de comunicación

La Figura 14 le muestra el mapeo del escenario de un proveedor de servicios de comunicación hacia los componentes de la Arquitectura conceptual de procesamiento de eventos.

Figura 14. Componentes de la arquitectura conceptual en el escenario de un proveedor de servicios de comunicación
Componentes de la arquitectura conceptual en el escenario de un proveedor de servicios de comunicación

Conclusión

Hemos introducido un Modelo Conceptual para el procesamiento de eventos que consiste de una arquitectura conceptual construida en base al concepto de una Red de Procesamiento de Eventos. Esta arquitectura conceptual le muestra cómo los eventos generados por los productores de eventos se pueden preparar y procesar para que los consuman los consumidores de eventos, con un Bus de eventos intermedio que ofrece servicios para el filtrado, el enriquecimiento, el formateo, el ruteado, la agregación o la división, etc. de eventos según lo que sea necesario. Esta arquitectura conceptual realiza la obtención de detalles descendente de las capacidades que tanto los productores como los consumidores pueden llegar a requerir (como, por ejemplo, algunas capacidades de procesamiento de eventos simples y algunos adaptadores de eventos). La arquitectura conceptual también indica los diversos servicios que se pueden llegar a requerir en el Bus de Eventos. La intención de esta arquitectura conceptual consiste en identificar todos los componentes que pueden llegar a ser necesarios para cumplir con la implementación del procesamiento de eventos. De todas formas, se espera que sólo algunos componentes sean necesarios para un escenario o una implementación en particular.

Este artículo introduce varios escenarios que ilustran el uso del procesamiento impulsado por eventos para agregar valor de negocios y mapea estos escenarios hacia el modelo conceptual (la red de procesamiento de eventos y la arquitectura conceptual) para mostrarle cómo este modelo conceptual se puede aplicar para la selección de diferentes situaciones prácticas. Hemos incluido una descripción de cada escenario, explicado por qué el procesamiento de eventos es importante para el escenario, enumerado los productores, los consumidores, los eventos y los agentes de procesamiento de eventos requeridos para ejecutar este escenario y demostrado el mapeo hacia la arquitectura conceptual.

A medida que el valor de negocios y las oportunidades provistas por el procesamiento de eventos de negocios van adquiriendo mayor reconocimiento, resultará muy importante contar con una arquitectura y un modelo conceptual en el que basar las arquitecturas lógicas y físicas que se usarán para implementar las soluciones de procesamiento de eventos de negocios.


Agradecimientos

Los autores desean agradecer a Christopher Ahrendt, Kyle Brown, Koteswara R Chejarla, Norman Cohen, John Dinger, Greg Flurry, Paul Giangarra, Kevin Hall, Robert Heuchert, Beth Hutchison, David H Janson, Jojo Joseph, Chung-Sheng Li, Rahul Narain, Peter Niblett, Dave Russell, Rob Sawyer, Boris Shulman, Michael Spicer y Bobby Woolf por su colaboración en el modelo conceptual y en este documento.

Recursos

Aprender

Obtener los productos y tecnologías

Comentar

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=SOA y servicios web
ArticleID=482022
ArticleTitle=Un modelo conceptual para los sistemas de procesamiento de eventos
publish-date=08052011