Ibm - Un Modelo Conceptual para Los Sistemas de Procesamiento de Eventos

ibm.
com
https://www.ibm.com/developerworks/ssa/webservices/library/ws-eventprocessing/
Un modelo conceptual para los sistemas de procesamiento de

eventos
Introduccin
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 da a da. El Procesamiento de Eventos (EP) es un rea emergente impulsada, en primer
lugar, por la mayor necesidad que tienen las empresas para poder responder rpidamente 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 ms efectiva. Por lo tanto,
EP es una parte cada vez ms importante de las estrategias de las empresas en relacin con las Arquitecturas
Orientadas a Servicios (SOAs).
En primer lugar, este artculo discute la necesidad de realizar el procesamiento de eventos, los diferentes tipos
de procesamientos de eventos y el valor que tiene la adopcin del procesamiento de eventos para los negocios.
Luego de esto, el presente artculo 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
discusin 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 accin. Se considera que un evento puede
llegar a ocurrir como algo que podra hacerse realidad o como la transicin de una entidad en el mundo real.
Puede formar parte de un proceso de negocios (por ejemplo: se emiti una orden de transaccin, aterriz el
avin correspondiente a un vuelo especfico, se registr la lectura de un sensor de datos) o puede monitorear
informacin 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
Un evento (una cosa relevante que ocurre dentro o fuera del negocio) puede provocar la invocacin de un
servicio, la iniciacin de un proceso de negocios y / o la publicacin o la sindicacin de ms informacin. El
Procesamiento de Eventos se ocupa de la tarea de procesar uno o varios eventos con el objetivo de identificar
aquellos eventos que sean ms 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
podra indicar que se agreg un cliente nuevo, que se vendi un producto, que se recibi un envo, que se abri
una puerta de seguridad, que se inform la ubicacin 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
aplicacin, un almacenamiento de datos, un servicio, un proceso de negocios, un transmisor, un sensor o una
herramienta de colaboracin (como una aplicacin de mensajera instantnea o correo electrnico). Al recibir
estos eventos del productor, los eventos pueden provocar resultados de manera directa o se los puede evaluar
segn 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 invocacin de un
servicio, la iniciacin de un proceso de negocios, la publicacin de un evento en un hub de subscripcin, la
notificacin directa a humanos o sistemas, la generacin de un evento nuevo y / o la captura de los propsitos
histricos del evento. Se suele hacer referencia a los eventos y su interaccin con los servicios de negocios de la
siguiente manera: sistema de informacin impulsada por eventos o arquitectura impulsada por eventos.
Fundamentos conceptuales
Los bloques de construccin conceptuales de una arquitectura que soporta el procesamiento de eventos (es
decir, un sistema de procesamiento de eventos) debera ofrecer funciones centrales (como, por ejemplo, la lgica
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 construccin
denominada Red de Procesamiento de Eventos (EPN): un fundamento conceptual que describe la estructura de
los sistemas de procesamiento de eventos y las caractersticas comunes que todos deberan soportar. La EPN
describe al sistema de procesamiento de eventos como un conjunto de consumidores, agentes de
procesamiento y productores de eventos que interactan. En este contexto, la responsabilidad principal de la
EPN consiste en recibir eventos de los productores, enviarlos a la combinacin correcta de agentes de
procesamiento de eventos para que los procesen y entregar los eventos ya procesados a los consumidores
correctos. La construccin denominada Red de Procesamiento de Eventos se describe en mayor detalle en la
Seccin II de este artculo, que describe el Modelo conceptual para el procesamiento de eventos. El modelo
conceptual abarca la virtualizacin, las bases de datos de eventos, el middleware impulsado por eventos, los
lenguajes de procesamiento de eventos y todo aquello que soporta la gestin de eventos a lo largo de su ciclo de
vida (desde el modelado y la programacin hasta el monitoreo y la respuesta).
Tipos de Procesamiento de Eventos

Las funciones de Procesamiento de Eventos se pueden categorizar en simples y complejas segn la complejidad
y la sofisticacin 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 modificacin. Por lo tanto,
ocurre un evento relevante, que inicia una accin 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 informacin de negocios muy importante. Se transforman los eventos, lo que
involucra eventos de conversin y divisin, y se fusionan uno o ms eventos. El procesamiento simple
incluye el procesamiento que involucra la modificacin 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 generacin de mltiples 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 especfico.
Procesamiento de Eventos Complejos: Se detectan patrones que abarcan mltiples 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 situacin relevante
para el negocio. Generalmente, este procesamiento involucra la aplicacin de un conjunto de limitaciones
o condiciones de evaluacin en un conjunto de eventos. Los eventos (relevantes u ordinarios) pueden
abarcar diferentes tipos de eventos y pueden ocurrir durante un perodo de tiempo determinado. Es posible
correlacionar los eventos en mltiples dimensiones de inters, entre las que podemos incluir las
siguientes: causal, temporal, espacial y otras. Se debera hacer una distincin entre la naturaleza
compleja y rica de la informacin disponible a partir del Procesamiento de Eventos Complejos y el hecho
de que no es, o no debera ser, algo complejo para los usuarios.
El modelado y la implementacin de las construcciones de procesamiento de eventos estn respaldados por el
middleware de integracin de aplicacin y por una gran variedad de plataformas de gestin de sistemas y redes,
aunque una gran variedad de modelos de programacin se usan para expresar estas construcciones. Las
herramientas y los motores de Procesamiento de Eventos Complejos vieron la luz en los ltimos aos. El
procesamiento de eventos se puede combinar con tcnicas analticas para predecir eventos, minar patrones e
incrustar analtica en tiempo real en las decisiones de ruteo y en las derivaciones de eventos. El uso de estas
tcnicas para realizar el anlisis en tiempo real le ofrece la capacidad de tomar decisiones ms 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 aplicacin de tecnologas para
construir sistemas de informacin impulsados por eventos que contribuyen con el negocio. La capacidad de
percibir cuando un evento ocurri (o no ocurri), lo que indica una situacin de negocios procesable, hace que el
negocio pueda responder de manera rpida 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
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 cundo 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 travs de la infraestructura de TI hoy en da, para soportar la
funcionalidad de procesamiento de eventos avanzados, se requiere un conjunto especializado de capacidades.
Pero la mayora de las organizaciones de TI no cuentan con la tecnologa necesaria para soportar estos
requisitos de manera efectiva y eficiente. Se dise el Procesamiento de Eventos de Negocios especficamente
para que se ocupe de este desafo (es decir, para que potencie la informacin que fluye a travs 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
situacin de negocios procesable y coordinar la accin 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 informacin sobre el evento en cuestin
para iniciar las respuestas que sean apropiadas. Cuando se lo incluye como parte de una solucin de Gestin de
Procesos de Negocios, el Procesamiento de Eventos de Negocios le ofrece una poderosa combinacin de
deteccin de patrones de eventos en tiempo y forma y una ejecucin dinmica 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.
Adems, mediante la inclusin de interfaces de usuario grficas 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 bsicos de procesamiento de eventos, en middleware
de integracin de aplicacin y en varias otras formas de software de sistema (como, por ejemplo, los sistemas
operativos), redes y software de gestin 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
identificacin de las respuestas adecuadas que se deben asociar con dicho evento. Todo esto puede ayudar a un
negocio a responder de manera rpida ante nuevas oportunidades y amenazas de competencia, a diseminar
informacin relevante en tiempo y forma entre las personas adecuadas, a permitir el diagnstico activo de
problemas y a contribuir con la creacin 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 percepcin 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 evalan flujos de datos provenientes de satlites y sensores para
determinar las acciones ofensivas y defensivas que se deben adoptar.
Negocios de transporte y logstica que utilizan telemetra de vehculos en tiempo real para gestionar sus
flotas de vehculos de manera ms 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 comunicacin que buscan minimizar el tiempo promedio que lleva reparar las
fallas en la red.
Compaas petroleras que determinan la profundidad y el ancho de las perforaciones de manera
dinmica, basndose en datos operacionales en tiempo real.
Proveedores de repuestos automotrices que utilizan complejas decisiones de fabricacin para entregar
repuestos a los fabricantes de manera tal que se permita una produccin "justo a tiempo".
En todos estos casos y en muchos ms, existe un requisito inherente a manejar grandes volmenes 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 caractersticas de las cargas de trabajo emergentes tambin 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 visin y afirman que los eventos en sus
diferentes formas desde eventos simples hasta eventos complejos se comenzarn a usar cada vez ms en
aplicaciones de negocios. La implementacin de procesos de negocios impulsados por eventos tiene enormes
beneficios financieros y estratgicos, ya que se adecan 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 caractersticas especficas 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 diseo impulsado por eventos se est comenzando a
usar cada vez ms. Las empresas estn logrando beneficios mediante la implementacin de procesos de
negocios impulsados por eventos, porque se adecan a la naturaleza inherentemente impulsada por eventos de
los negocios y porque les confiere una ventaja competitiva en trminos de los costos y los tiempos involucrados
en la realizacin del trabajo.
Generalidades de diferentes escenarios de procesamiento de eventos

Para ilustrar los conceptos que se describen en este artculo, 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 gestin de la flota
Escenario de alerta de salud pblica
Escenario de un proveedor de servicios de comunicacin
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 (gestin de la flota) se analiza en mayor detalle, ya que algunos de los aspectos ms
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.

Este escenario describe la situacin de la compaa "Fast Delivers", que se especializa en entregar paquetes
pequeos, en un radio de operacin relativamente reducido, mediante el uso de su flota de vehculos. Cada
vehculo tiene un GPS que transmite su ubicacin de manera constante. Adems, los paquetes estn etiquetados
con rtulos RFID. De acuerdo con el nivel de servicio deseado, el paquete se enva de manera inmediata de un
lugar a otro o se enva a una central donde (posiblemente) otro vehculo 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 raz de los
pedidos que hacen los clientes por telfono (o por la pgina Web).
Figura 3. Generalidades de la gestin de la flota
Las ideas para este escenario se basaron en las soluciones de IBM para la optimizacin 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 vehculos y conductores.
Ofrecer informacin minuto a minuto a los clientes.
Encontrar el punto justo para mejorar los procesos de carga, descarga y planificacin de ruta.
Incrementar la utilizacin de activos.
Mejorar la atencin 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 compaa opt por usar el procesamiento de eventos dentro
de su sistema. Por lo tanto, la compaa 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 compaa tambin puede reaccionar ante los riesgos a medida que se van materializando y
mitigar la situacin realizando reasignaciones antes de que se incumpla algn contrato. Gracias al
procesamiento de eventos, la compaa 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 situacin actual de todos los vehculos, los pedidos, etc. se monitorea de
forma constante y se anticipa por medio de los eventos. La compaa tambin puede realizar cambios e
implementarlos en el proceso con gran rapidez y confianza simplemente cambiando la aplicacin o la lgica de
procesamiento de eventos sin pasar por procesos de desarrollo prolongados y propensos a errores.
En las prximas secciones, analizaremos los eventos involucrados y los conceptos de procesamiento de eventos
para este escenario.

El escenario de alerta de salud pblica describe el sistema de alerta en casos que indican brotes epidemiolgicos
reales o posibles que presentan un riesgo para la poblacin. El Sndrome Agudo Respiratorio Severo (SARS) y la
gripe aviar (H5N1) o ataques terroristas que empleen agentes biolgicos o qumicos son slo algunos de los
ejemplos de brotes epidemiolgicos que nos interesan.
El escenario elegido considera un brote epidemiolgico de influenza aviar (gripe aviar) y de influenza aviar A
(H5N1), aunque se podra aplicar a otros brotes epidemiolgicos (como a la gripe H1N1).
Las etapas o los estados de las pandemias, segn la definicin correspondiente de la Organizacin Mundial de la
Salud, nos muestra la progresin desde el estado interpandmico (donde no se detecta el virus de la influenza
en los seres humanos) hasta el estado pandmico (donde se registra el contagio de gran parte de la poblacin
general). Para este escenario, se consideran tres etapas fundamentalmente: no se detecta el virus, estado
epidmico y, por ltimo, estado pandmico.
Figura 4. Generalidades de la alerta de salud pblica
Ahora, describimos lo que ocurre en este escenario. Un laboratorio que realiza anlisis de sangre detecta el
virus. De acuerdo con las reglamentaciones vigentes, la deteccin de un virus especfico se publica como un
evento. El receptor del evento en cuestin (en nuestro caso, el emisor del evento) normaliza el evento y realiza
algunas verificaciones bsicas de calidad y origen antes de enviar el evento a los agentes de procesamiento,
donde se enriquecer al evento con informacin adicional. Luego de esto, la deteccin del patrn verifica si es
necesario presentar un alerta de brote epidemiolgico. En el caso de que se trate de un brote epidemiolgico,
ser necesario enriquecer el evento todava ms y aplicar otra lgica de deteccin de patrones para verificar si
se trata de un brote pandmico. En el caso de alertas epidmicas y pandmicas, se envan notificaciones como
eventos correspondientes. En el caso de alertas de brotes pandmicos emitidas por productos de eventos
externos (como, por ejemplo, organizaciones internacionales de salud o gobiernos extranjeros), se acta de
manera similar.
Las secciones posteriores del presente artculo, se ocupan de los eventos involucrados y la forma en la que este
escenario se relaciona con el modelo conceptual de procesamiento de eventos.

Este escenario describes la situacin de la compaa "YourCSP" (una proveedora de servicios de comunicacin).
La compaa ofrece una gran variedad de servicios de comunicacin no inalmbrica a clientes locales y a
pequeas y medianas empresas (que van desde acceso a Internet por banda ancha hasta VOIP y servicios de
Virtual Private Network). La red MPLS (Conmutacin de Rtulo Multiprotocolo) central de la compaa se
compone de elementos de red de muchos fabricantes diferentes soportados por un conjunto de Element
Management Systems. Estos emplean una amplia gama de tecnologas de red (incluso Dial-Up, DSL y
tecnologas 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 compaa ofrece diversos
Acuerdos de Nivel de Servicio (SLA). Estos SLA se componen de contratos que garantizan los niveles acordados
de servicio segn las mtricas especificadas (por ejemplo, la continuidad del servicio o el ancho de banda de red
disponible). Los SLA que no se cumplan podrn resultar en multas econmicas que YourCSP deber pagar y
hasta podra llegar a perjudicar la reputacin de la compaa. Sus clientes estn 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 compaa
y de los servicios que ofrece. Entre sus objetivos principales, podemos incluir los siguientes:
Minimizacin del tiempo promedio de reparacin de las fallas en la red que puedan ocasionar la
degradacin o interrupciones del servicio provisto a los clientes de la compaa.
Priorizacin de la remediacin 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 exposicin financiera de la compaa.
Maximizacin de la utilizacin de los activos de red.
Minimizacin de los costos operativos (como, por ejemplo, la mano de obra y el consumo energtico).
Provisin de comunicacin 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 tecnologas de gestin 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 deteccin automtica de la resolucin 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 segn un formato comn para lograr un procesamiento y una visualizacin
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 automticamente los modelos de la red central con el objetivo de:
Conservar la visibilidad de los activos implementados.
Conservar los modelos de la topologa de la red fsica y lgica y su relacin con los servicios de red
provistos.
Ofrecer paneles de control del mapa de red al personal de operacin para el diagnstico y la
resolucin de problemas.
Realizar el anlisis de la causa raz de los eventos basndose en la topologa de red en relacin
con los eventos de red y las interrupciones del servicio.
Brindar soporte al proceso de aprovisionamiento de servicios nuevos.
Ofrecer respuesta, diagnstico y remediacin automtica de una gran cantidad de escenarios de falla de
red.
Realizar el anlisis de patrones de los eventos y sacar conclusiones en relacin con las causas y el
impacto de negocios de los eventos de red.
Enriquecer los eventos de red basndose en el contexto tcnico, topolgico y de negocios.
Definir polticas para la creacin automtica de tickets de problemas en la aplicacin de mesa de ayuda de
YourCSP, lo que resultar en la instigacin de actividades de mantenimiento fsico.
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) especfico en cada una de las
instalaciones de MediumCo para realizar la conexin 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 indicarn fallas fsicas y lgicas enviadas desde el equipamiento y los
sistemas de gestin de elementos en la red circundante. Esto incluye fallas de ping ICMP (Internet Control
Message Protocol), alarmas de vnculo roto y fallas de adyacencia del protocolo de ruteo. En esta situacin, el
sistema de procesamiento de eventos debe hacer lo siguiente:
Identificar la causa raz del evento y hacrsela 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 interrupcin del servicio de acuerdo con los SLA aplicables y en
comparacin con otras interrupciones del servicio en la red y priorizar de manera adecuada la resolucin
del problema. En este caso, la resolucin tiene una alta prioridad debido al SLA agresivo que se firm con
MediumCo.
Informar al cliente afectado sobre la identificacin de la falla y ejecutar una solicitud de elemento de
trabajo para asignar un tcnico a la resolucin de la falla.
Detectar la resolucin de la falla e informar al operador y al cliente sobre la restauracin del servicio
normal.
En las prximas 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 relacin con un nivel abstracto, sin mencionar ningn detalle
tcnico. La Red de Procesamiento de Eventos (EPN) resume las caractersticas 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 arquitectnicos abstractos, o componentes, que se
pueden involucrar en la materializacin 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
tecnologas, los protocolos y los productos que se podran 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 comn para especificar,
comparar y contrastar las diferentes implementaciones y arquitecturas de solucin de procesamiento de eventos.
Nuestra intencin 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
ningn requisito que exija implementar ningn componente que no sea necesario en un sistema en particular. De
igual forma, tampoco existe ningn concepto implcito de cumplimiento con el modelo.
Red de Procesamiento de Eventos

Nuestra abstraccin de alto nivel de sistemas de procesamiento de eventos aplica conceptos de la construccin
de la red de procesamiento de eventos (vea la Figura 5). Como lo indicamos con anterioridad, una Red de
Procesamiento de Eventos es una formulacin conceptual que describe la estructura de los sistemas de
procesamiento de eventos y las caractersticas comunes que todos deberan soportar.
Figura 5. 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 conexin).
Una EPN describe cmo los eventos recibidos de los productores se direccionan hacia los consumidores por
medio de agentes que procesan estos eventos (por ejemplo, realizando su transformacin, su validacin 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 relacin 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 travs de la EPN). Esta Figura tambin 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 abstraccin, no se colocan
limitaciones ni sobre las propiedades del canal de eventos (como, por ejemplo, si cada canal puede mover o no
ms de un tipo diferente de evento) ni sobre el mecanismo que mueve los eventos.
El canal de eventos puede llegar a recibir mltiples eventos desde diferentes productores de eventos y EPAs y
puede llegar a transferir eventos combinados desde varias fuentes hasta mltiples EPAs y consumidores. El
orden entre los eventos provenientes de diferentes EPAs y productores de eventos para crear el conjunto
combinado de eventos es especfico a la implementacin y el modelo conceptual no se ocupa de ello. En
algunos casos, no se requiere ningn 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 polticas de retencin que determinan la
duracin 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 cuestin.
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 travs 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 restriccin 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,
slo 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 recibirn los eventos. El mismo evento se puede publicar o hacer que est disponible por
medio del productor de eventos para ms de un canal de eventos. Sin embargo, a modo de prctica de diseo,
siempre conviene dejar que los EPAs tomen las decisiones de ruteo, para as permitir el mejor control, el mejor
diseo y la mejor comprensin 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 slo
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 cuestin. El mismo
evento se puede recibir a travs de ms de un canal de eventos. Sin embargo, conviene que el EPA se ocupe de
la lgica de dnde, cundo y cmo recibir eventos, para as permitir el mejor control, el mejor diseo y la mejor
comprensin 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 funcin mencionada, aparecera como un productor de eventos dentro de la EPN.
Agente de procesamiento de eventos

En un sistema distribuido y heterogneo, 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 semntico o a ambos aspectos. Tambin hay casos en los que un
solo evento no disparar una accin realizada por un consumidor de eventos. En cambio, la accin se disparar
por medio de una composicin 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 travs del enriquecimiento, la transformacin y
la validacin y, por ltimo, para derivar eventos nuevos y publicarlos. Un EPA es responsable de producir estos
eventos derivados y decide dnde y cmo se debera hacer que estos eventos estn disponibles.
El EPA tiene tres etapas posibles:
Comparacin de patrones: De ser requerida, esta etapa es la responsable de seleccionar los eventos que
se procesarn de acuerdo con un patrn especificado. A los EPA que realizan la comparacin de patrones
se los conoce como "EPAs de deteccin de patrones".
Procesamiento: De ser requerida, esta etapa es la responsable de aplicar las funciones de procesamiento
en los eventos seleccionados que satisfacen el patrn (lo que resulta en la creacin de eventos
derivados).
Emisin: 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 deteccin de su patrn 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 enva eventos por medio de canales de eventos cuando
emite eventos, casi como un productor de eventos enva 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 deteccin de patrones). La cantidad de
bordes direccionados desde l es la cantidad de canales de eventos diferentes a travs de los que el agente
enva eventos basados en las definiciones de emisin y procesamiento.
En resumen, una Red de Procesamiento de Eventos (EPN) es un grfico 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 ms
eventos como entrada, realizan algn tipo de procesamiento y devuelven un conjunto (posiblemente nuevo) de
cero o ms 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 combinacin 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 definicin de la red de procesamiento de eventos hacia los escenarios
descriptos en la Introduccin.

A continuacin, mencionamos los componentes de la red de procesamiento de eventos (productores,
consumidores, canales de eventos, agentes de procesamiento de eventos y tambin los eventos) que describen
slo uno de los aspectos importantes al momento de realizar el seguimiento de los vehculos y los conductores
(es decir, uno de los objetivos que se mencionan con anterioridad). La compaa 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 limitacin
horaria se ver obligado a descansar y, para evitar todo tipo de demoras en las entregas a los clientes y que as
la compaa no tenga que pagar ninguna multa, otros conductores se debern encargar de realizar todas las
entregas afectadas. Este proceso de reasignacin de tareas requiere el establecimiento de un punto de reunin
adecuado en las instalaciones de la compaa, donde los productos se transferirn de un vehculo a otro(s) y se
recalcularn las rutas para que las demoras, si fuesen inevitables, fuese lo menores posibles. Existe un sistema
de informacin del conductor desde el que se producen eventos de inicio y de finalizacin de la jornada laboral
del conductor. Basndose en estos eventos y en el conocimiento constante de las ubicaciones de los vehculos,
se pueden llevar a cabo los procesos de reubicacin. Adems, existen algunos requisitos para el enriquecimiento
de eventos, la deteccin del patrn 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 eventos
Descripcin
Vehculo
Transmisin de ubicacin por GPS, sensores en el vehculo (combustible, emisin,

peso, etc.)
Driver Report System

(Sistema de informacin
del conductor)
Tarjeta perforada electrnica
Delivery System (Sistema

de entrega)
Gestin de rdenes, Ordenamiento y asignacin de paquetes y Sistema de

despacho de vehculos
Package RFID System

(Sistema RFID para
paquetes)
Sistema de seguimiento de paquetes con lectores en estaciones y lectores mviles

para el personal (por ejemplo, que los conductores usan al recolectar, transferir y
entregar los paquetes)
Tabla 2. Consumidores de eventos

Consumidor de eventos
Descripcin
Driver Display (Pantalla del conductor)
Pantalla del conductor mvil y en el vehculo que muestra las

rutas, los cambios en las entregas y las alertas
Delivery Management Dashboard (Panel de

control de gestin de entregas)
Vista completa de las operaciones (ubicacin de los vehculos,

rutas, pedidos, paquetes, etc.
Clientes
Los emisores o los receptores de pedidos pueden recibir

notificaciones o buscar sus pedidos
Tabla 3. Eventos
ID del
tipo de
evento
Tipo de evento
Atributos
Comentarios
E1
El conductor comienza
a trabajar
Fecha y hora; ID del conductor
E2
El conductor comienza
a trabajar (versin
enriquecida)
Fecha y hora; ID del conductor; ID del vehculo;

Nombre del conductor
E3
El conductor termina de
trabajar
Fecha y hora; ID del conductor
Se puede basar
en la estructura
de E1
E4
El conductor excedi el
tiempo de manejo
permitido
Fecha y hora; ID del conductor; ID del vehculo;

Nombre del conductor
E5
Cambio en la entrega
Fecha y hora; ID del conductor 1; ID del vehculo 1; ID

del conductor 2; ID del vehculo 2; ID del emisor; ID
del receptor
Tabla 4. Canales de eventos

ID del canal de
eventos
Tipo de
evento
Productores
Poltica de
retencin
Consumidores
EC1
E1
Driver Report
System
A1
EC2
E2
A1
A2
EC3
E3
Driver Report
System
A2
EC4
E4
A2
A3, Delivery Management Dashboard
EC5
E5
A3
A4
EC6
E5
A4
Clientes, Driver Display, Delivery

Management Dashboard
1 semana
Tabla 5. Agentes de procesamiento de eventos: Ejemplo 1

Propiedad del
agente
Especificacin
ID del agente
A1
Nombre del agente
Enriquecer "El conductor comienza a trabajar"
Tipo de agente
Enriquecer
Contexto del
agente
Eventos de entrada
E1
Propiedad del
agente
Especificacin
Especificacin del
agente
Enriquecer por ID del conductor con la ID del vehculo y el Nombre del conductor desde
Detalles del conductor
Eventos de salida
E2
Comentario del
agente
Se enriquece el evento con detalles del conductor (como, por ejemplo, la ID del
vehculo)

Propiedad del agente
Especificacin
ID del agente
A2
Nombre del agente
El conductor excedi el tiempo de manejo permitido
Tipo de agente
Detectar patrn
Contexto del agente
intervalo (E2,+8h) por ID del conductor
Eventos de entrada
E3
Especificacin del agente
Ausencia de E3
Eventos de salida

Propiedad
del agente
Especificacin
ID del agente
A3
Nombre del
agente
Reasignacin de la entrega
Tipo de
agente
Detectar patrn
Contexto del
agente
Eventos de
entrada
E4, Ex
Especificacin Enriquecer por ID del conductor con la ID del vehculo y el Nombre del conductor desde
del agente
Detalles del conductor
Eventos de
salida
E5
Comentario
del agente
Este agente recibe diferentes tipos de eventos para inferir los requisitos de cambio en la
entregas. Este agente es responsable de decidir qu vehculo debera hacerse cargo de la
entrega y cmo reunir a ambos vehculos en una misma estacin o en otro lugar.

Propiedad
del agente
Especificacin
ID del agente
A4
Nombre del
agente
Notificacin de reasignacin de ruta a los consumidores requeridos
Tipo de
agente
Router
Contexto del
agente
Eventos de
entrada
E5

Eventos de
salida
E5
Comentario
del agente
Rutea el cambio en la entrega a los diferentes consumidores. Es posible notificar a los clientes
(se reintentar durante 1 semana), los conductores recibirn las instrucciones nuevas y las
operaciones podrn realizar el seguimiento de estas instrucciones nuevas
A continuacin, 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
tambin 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 instruccin de reasignacin se informa a travs 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 propsitos 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. Representacin grfica de la EPN para la gestin de la flota
Las siguientes Tablas mencionan los componentes de la red de procesamiento de eventos correspondientes al
escenario de alerta de salud pblica que se describi en la Introduccin. Los EPA para este escenario no se
describen de manera detallada.

Productor de eventos
Descripcin
Hospital
Es probable que el hospital detecte posibles virus o indicios de ellos y emita

un evento
Laboratorio
Es probable que el laboratorio detecte posibles virus o indicios de ellos y

emita un evento
Doctor
Es probable que el doctor detecte indicios de posibles virus y emita un

evento
Organismo gubernamental
extranjero
El Organismo gubernamental extranjero emite un evento

Consumidor
de eventos
Descripcin
Compaa
farmacutica
La compaa farmacutica se subscribe a los eventos de alertas de salud
Organismo
gubernamental
El organismo gubernamental se subscribe a los eventos de alertas de salud
Mdico
El mdico se subscribe a los eventos de alertas de salud que, posiblemente, resulten

enriquecidos con ms detalles sobre las caractersticas y los patrones de deteccin
Compaa de
seguros de
salud
La compaa de seguros de salud se subscribe a los eventos de alertas de salud
Agencia de
noticias
La agencia de noticias se subscribe a los eventos de alertas de salud
Departamento
de Seguridad
Nacional
El Departamento de Seguridad Nacional se subscribe a los eventos de alertas de salud que,

posiblemente, resulten enriquecidos con informacin sobre precauciones especficas y
patrones de deteccin
Tambin existe la nocin de una especie de intermediario que implementa la Red de Procesamiento de Eventos
(EPN) y desvincula a los productores de eventos (que desconocen quines consumirn 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 relacin entre el Productor de eventos y la EPN y el Consumidor y la EPN, tambin nos podemos
imaginar algunos casos en los que los productores hagan que el evento est disponible para todo el mundo (a
travs de una pgina web o una fuente) y en los que la EPN recupera esta informacin. Por otro lado, la EPN
tambin hace que el evento est disponible (probablemente, mediante los mismos mecanismos) para todos los
consumidores de eventos. Luego de esto, se puede observar una desvinculacin entre el productor y la EPN y el
consumidor y la EPN y tambin se puede considerar la existencia de un escenario desvinculado directo que
prescinda de los servicios del intermediario.
Tabla 11. Eventos

ID del tipo
de evento
Tipo de evento
Atributos
Comentarios
E1
Alerta de posible
brote epidmico
ID; Detalles
El evento opuesto es "No hay posibilidad de

que exista un brote epidmico"
E2
Posible brote
epidmico
normalizado
ID; Fecha y hora;

Ubicacin; Detalles
Evento normalizado / transformado desde el

evento original
E3
Posible brote
epidmico
enriquecido
ID; Fecha y hora;

Ubicacin; Ms detalles
Evento enriquecido
E4
Alerta de brote
epidmico detectado
ID; Fecha y hora;

Ubicacin; Detalles
Se detect un brote epidmico (deteccin de

patrn)
E5
Alerta de brote
epidmico
ID; Fecha y hora;

Ubicacin; Detalles
E6
Alerta de posible
brote pandmico
ID; Fecha y hora;

Ubicacin; Detalles
E7
Posible brote
pandmico
normalizado
ID; Fecha y hora;

Ubicacin; Detalles
Se detect un brote epidmico (deteccin de

patrones)
E8
Posible brote
pandmico
enriquecido
ID; Fecha y hora;

Ubicacin; Ms detalles
Evento enriquecido
E9
Alerta de brote
pandmico detectado
ID; Fecha y hora;

Ubicacin; Detalles
Se detect un brote pandmico (deteccin de

patrones)
E10
Alerta de brote
pandmico
ID; Fecha y hora;

Ubicacin; Detalles
La Figura 7 le ofrece una representacin grfica de esta EPN.
Figura 7. EPN para el escenario de alerta de salud pblica

A continuacin, 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 comunicacin que se describi en la Introduccin.

Productor
de
eventos
Descripcin
Monitor de
redes
Es un software que analiza el equipamiento en busca de datos de rendimiento y disponibilidad,

generalmente usando protocolos como ICMP y SNMP. Adems, genera eventos que representan
cambios notables en los elementos de red y excepciones a la operacin normal.
Sondas de
elementos
de red
Reciben alertas desde los elementos de red y generan eventos que representan cambios
notables y fallas en los elementos de red y en sus vecinos lgicos y fsicos. Generalmente, usa
protocolos como SNMP para escuchar las alertas.
Sonda del
sistema de
gestin de
elementos
Recibe alertas desde los Sistemas de Gestin de Elementos que representan fallas y cambios
notables en los elementos de red que se estn gestionando. Puede usar formatos de evento
estndar o exclusivos en una gran variedad de protocolos estndar o exclusivos (entre los que
podemos incluir SNMP, SOAP, CORBA y archivos planos).
Panel de
Produce eventos basados en acciones de operadores (entre las que podemos incluir el
control del reconocimiento, la resolucin y la eliminacin de eventos desde los equipos de red y las
operador
interrupciones del servicio).
de eventos

Consumidor de
eventos
Descripcin
Paneles de control
de operadores
Vista interactiva de eventos significativos para los operadores del Centro de

Operaciones de Red (entre los que podemos incluir las herramientas de diagnstico
personalizables y las capacidades de filtrado).
Telfonos y sistema
de email del
Ingeniero de Redes
Reciben mensajes SMS y correos electrnicos que son el resultado de eventos crticos
que el sistema hizo escalar
Vistas de los clientes
Vistas actualizadas y de slo lectura de las interrupciones del servicio detectadas en los
servicios filtrados para los clientes afectados.
Sistema Trouble
Ticket
Recibe eventos del sistema que requieren la toma de medidas por parte del equipo de
mantenimiento e ingeniera de redes.
Tabla 14. Tipos de eventos

Ingresar
ID
Tipo de eventos
E1
Fall el ping
Fecha y hora; Direccin inaccesible
E2
Vnculo roto
Fecha y hora; Nombre del puerto del vnculo roto en el router PE; Direccin del router PE
E3
Falla de la tarjeta
Fecha y hora; Direccin del router PE; Identificador

de tarjeta
Atributos
Comentarios
-
Ingresar
ID
Tipo de eventos
Atributos
Comentarios
E4
Evento de causa
raz
Como E3
Copia de E3, identificada

como causa raz
E5
Eventos
sintomticos
Como E1 y E2; Causa raz asociada
Copias de E1 y E2,
identificadas como
sntomas
E6
Servicio VPN
afectado
Fecha y hora; Identificador de VPN
E7
Servicio VPN
afectado
enriquecido
Como E6; Detalles de contacto del cliente
E8
Tcnico
despachado
Fecha y hora; Detalles de contacto del tcnico
E9
Ping exitoso
Fecha y hora; Direccin a la que se hizo ping
E10
Vnculo activo
Fecha y hora; Nombre del puerto del vnculo

restablecido en el router PE; Direccin del router PE
E11
Tarjeta activa
Fecha y hora; Direccin del router PE; Identificador

de tarjeta
E12
Servicio VPN
activo
Fecha y hora; Identificador de VPN

Propiedad del
agente
Especificacin
ID del agente
A2
Nombre del
agente
Service Impact Analyzer (Analizador de impacto del servicio)
Tipo de agente
Deteccin de patrones
Contexto del
agente
Eventos de
entrada
E4, E5
Especificacin
del agente
Genera un evento afectado por el servicio incluso si el servicio de red del cliente est
interrumpido
Eventos de salida E6
Comentarios del
agente
Usa relaciones modeladas entre elementos de red y servicios aprovisionados para

determinar si el servicio se ve afectado o no
Propiedad
del agente
Especificacin
ID del agente
A3
Nombre del
agente
Customer Impact Analyzer (Analizador de impacto sobre el cliente)
Tipo de
agente
Ruteo, Enriquecimiento
Contexto del
agente
Eventos de
entrada
E6
Especificacin
del agente
Escala un evento afectado por el servicio de acuerdo con la poltica asociada con el SLA;
Realiza el enriquecimiento con los detalles de contacto del cliente
Eventos de
salida
E7
Comentarios
del agente

Propiedad del agente
Especificacin
ID del agente
A4
Nombre del agente
Prioritization Module (Mdulo de

priorizacin)
Tipo de agente
Ruteo, Enriquecimiento
Contexto del agente
Eventos de entrada
E7
Enriquece eventos con la prioridad

relativa
Rutea eventos hacia los consumidores segn la prioridad
Instiga la toma de acciones correctivas por medio del sistema

Trouble Ticket
Eventos de salida
E4, E5, E7, E8
Comentarios del agente
La Figura 8 le ofrece una descripcin grfica 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 tcnico.
Figura 8. EPN para el escenario de un proveedor de servicios de comunicacin
Arquitectura conceptual
La Arquitectura conceptual se fundamenta en los conceptos de la EPN mediante la definicin de varios
componentes que se pueden involucrar en una solucin 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 estn ms relacionados con el flujo de eventos y equivalen a los canales en la EPN. Una de las figuras que
incluimos ms adelante en esta seccin, la Figura 11, le muestra cmo la Arquitectura conceptual realiza el
mapeo hacia la EPN.
Todas las arquitecturas de sistema que soportan el procesamiento de eventos de negocios deberan permitir la
definicin flexible de la lgica de procesamiento de eventos: deteccin de patrones de eventos, derivacin de
eventos nuevos, transformacin y ruteo desde los productores hasta los consumidores basndose en la lgica 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 estn desarrollando basndose en los cambios. Adems, dicha
definicin del procesamiento de eventos debera ser fcil de modificar y se la debera poder implementar
rpidamente de acuerdo con las necesidades de negocios (como, por ejemplo, los cambios en los procesos y las
polticas de negocios).
Para poder comprender cmo se puede derivar este valor de negocios desde los sistemas de procesamiento de
eventos, es importante considerar un nivel ms 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. Adems de los tres niveles tpicos 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 analtica y la gestin de eventos y flujos de eventos.
En el nivel ms simple, se necesita un conjunto mnimo 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 consumirn los consumidores de eventos. Esto se ilustra en la Figura 9, que
tambin incluye algunos ejemplos de productores de eventos y de consumidores de eventos.
Figura 9. Arquitectura conceptual mnima 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 prctica, 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 debera 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
(estndar 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 generacin de un
evento notable nuevo. Adems, 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 estn listos para usar. Por lo tanto, es posible
que el consumidor deba realizar algn tipo de procesamiento o mediacin. Un pre procesador de eventos (filtro)
puede evaluar la importancia de un evento ordinario antes de su administracin 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 publicacin
y a la recepcin 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
implementacin de procesamiento de eventos se debera 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 sern necesarios para un escenario
en particular. Como analizaremos ms adelante cuando volvamos a ocuparnos de los escenarios y veamos cmo
realizan el mapeo hacia la arquitectura conceptual, en la mayora 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
Componentes arquitectnicos
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 prxima seccin le ofrece una
descripcin ms detallada del flujo de procesamiento en el modelo conceptual. A nivel de la implementacin, los
consumidores de eventos, generalmente, tambin sern 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
inters. El productor de eventos no incluye la lgica para manipular eventos. Tampoco incluye ninguna
lgica de decisin sobre qu emitir en qu momento y los eventos generados podran ser redundantes o
irrelevantes. A continuacin, mencionamos algunos ejemplos tpicos 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
sera la transmisin 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 especfico.
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).
Mquinas de estado, que generan eventos cuando se cambia de estado.
Emisor de eventos. ste se asocia lgicamente (aunque no necesariamente de manera fsica) 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 mediacin de eventos emitidos por un solo productor, lo que enriquece el evento con
informacin 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 ms tareas de procesamiento o para su entrega, lo que
puede incluir la agregacin, el cacheo y la serializacin de eventos. Es posible que sea necesario que el
instanciador de eventos manipule el encabezado del evento para incrustar "metadatos semnticos" en el
mensaje del evento y as hacerlo autodescriptivo (con informacin como, por ejemplo, hora, fecha, tipo de
instrumento, ID del proceso, etc.). El Emisor de eventos puede realizar la optimizacin 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 conversin de protocolo del evento
para crear algo que lo recibir la red de procesamiento de eventos (como, por ejemplo, la contencin de
registros de eventos como mensajes de evento y el envo 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 ms informativos a partir de los eventos entrantes. Los componentes del
Bus de eventos no tienen que estar coubicados. La prxima subseccin le ofrece ms 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 cmo 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 tambin 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
tambin 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 orquestacin de eventos para gestionar la distribucin de eventos entre los
consumidores.
Consumidor de eventos. El consumidor de eventos realiza tareas en reaccin a un evento. Al consumidor
de eventos no le incumbe el origen del evento y slo sabe que se lo invoca como resultado del evento
junto con el contexto relativo al evento en cuestin. A continuacin, mencionamos algunos ejemplos
tpicos de consumidores de eventos:
Activadores de eventos, que se los invoca para que realicen tareas fsicas (como, por ejemplo, la
operacin de vlvulas, interruptores o alarmas).
Paneles de control del operador, que visualizan informacin sobre el comportamiento de los
sistemas de TI y los servicios afectados.
Paneles de control de negocios, que visualizan informacin 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 reaccin a un evento y pueden incluir sistemas
externos de gestin de contenidos o repositorios de eventos.
Mquinas de estado, cuyo estado se puede cambiar en reaccin 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 ms de un rol: un productor de eventos tambin
podra encargase del procesamiento de eventos y desempearse como consumidor de eventos. En particular,
slo se requieren los Servicios de publicacin y subscripcin cuando se usa un modelo del estilo
Publicar/Subscribir.
Se puede considerar a la arquitectura conceptual como "anidada", ya que un participante podra incluir una red
de componentes adicionales. Por ejemplo: Un productor de eventos podra emitir un evento y enviarlo hacia el
bus de eventos principal. Pero, en el proceso de produccin de dicho evento, uno podra prever una versin
"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 lgicamente 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 basndose en los requisitos de negocios. Esto se logra usando servicios simples y
complejos de procesamiento de eventos. Agentes de procesamiento de eventos, que estn conectados por
medio de canales de eventos, se encargan de ofrecer estos servicios.
Los servicios, o bloques de construccin, 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 publicacin, para hacer que los productores puedan enviar eventos a los canales adecuados.
Servicios de subscripcin, para permitir el registro dinmico 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 notificacin, para notificar a los Administradores de eventos subscriptos cuando los eventos
estn disponibles (soportando tanto la insercin como la eliminacin 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 autorizacin para agregar y eliminar eventos del bus de eventos, al igual que la
privacidad y la no repudiacin de los contenidos de los eventos.
Servicios de procesamiento de eventos, que ofrecen el filtrado, la transformacin y el enriquecimiento de
eventos, y que tambin pueden ofrecer la comparacin de patrones y la derivacin de eventos. Esto
puede incluir el procesamiento de eventos complejos, que procesa eventos desde mltiples fuentes y
puede realizar la comparacin de patrones que se ejecutan por un largo perodo de tiempo entre eventos.
Servicios de informacin 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 semntica) 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, atmica).
Un Registro de eventos, para ofrecerle una taxonoma de los tipos de eventos y una ontologa 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 continuacin, se enumeran los tipos de funciones ms importantes que el procesamiento debe ofrecer dentro
del Bus de eventos.
Transformacin: Funcin que transforma el evento entrante mediante su traduccin o divisin.

Enriquecimiento: Funcin que enriquece los contenidos de los eventos con datos de referencia desde
mltiples fuentes posibles.
Validacin: Funcin que le ofrece validacin segn los criterios requeridos.
Deteccin de patrones: Funcin que reconoce patrones reales y retrospectivos (una combinacin de
mltiples eventos que caracterizan una situacin de negocios importante).
Filtrado: Funcin sin estado que filtra eventos basndose en sus contenidos (es decir, la informacin que
transporta el mensaje generado cuando el evento ocurri).
Agregacin: Funcin que puede agrupar eventos de ser necesario.
Ruteo: Funcin que rutea eventos hacia su destino basndose en varios patrones posibles de ruteo
(como, por ejemplo, un itinerario preestablecido, una decisin basada en un calendario, una subscripcin
o decisiones de ruteo "inteligentes").
La arquitectura conceptual tambin 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 analtica) es
necesario principalmente para tareas administrativas, para notificar sobre fallos en la infraestructura del evento y
para reunir y visualizar informacin estadstica 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 envan hacia el
bus de eventos, donde se los puede procesar y los consumidores de eventos terminan consumindolos. 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 cmo 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
Flujo de procesamiento en la arquitectura conceptual

El propsito de esta subseccin consiste en describir el Modelo conceptual en accin. Existen tres fases que
debemos considerar:
Fase de emisin 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 perodos de tiempo completamente diferentes y slo existe una relacin de causa y efecto entre el
evento emitido y el evento consumido).
Para poder ofrecerle ejemplos concretos, esta seccin se refiere a los escenarios que se describen en ms
detalle en otras secciones.
Fase de emisin del evento

Los componentes de la Arquitectura conceptual involucrados en esta fase son, principalmente, los componentes
del Emisor de eventos. Su rol en la emisin del evento puede ser bastante tcnico (es decir que, principalmente,
se ocupan de ofrecer niveles de conectividad tcnica entre el Productor de eventos y el Bus de eventos, aunque
tambin se pueden orientar a los negocios; es decir que se puede llegar a implementar una lgica de
procesamiento de eventos orientada a los negocios o Agentes de procesamiento de eventos locales).
Perspectiva tcnica
Cuando ocurre un evento de negocios posiblemente significativo, el Productor de eventos enva 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 tcnico a cargo de detectar esta situacin de negocios especfica y de reunir toda la informacin
necesaria. Luego de esto, los Servicios locales de procesamiento de eventos pueden procesar la informacin
para crear el mensaje de evento, por ejemplo, formatendolo para que cumpla con un formato genrico
publicado en el Registro de eventos. Luego, el subnivel de Adaptador de eventos enva 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 gestin de una flota, consideramos el Sistema de entrega y, en especial, el
subsistema de despacho de vehculos como el Proveedor de eventos. Asumamos que el subsistema de
despacho de vehculos es una aplicacin 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 debera emitir cada vez que el
conductor o el vehculo a cargo de la entrega en cuestin se modifican en esta aplicacin. 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. Adems, valida que la actualizacin se relacione con una modificacin del
vehculo o el conductor a cargo de la entrega. Si esta prueba resulta exitosa, la lgica de activacin rene toda la
informacin necesaria (ID del conductor 1, ID del vehculo 1, ID del conductor 2, ID del vehculo 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 lgica externa de procesamiento de eventos a nivel del Bus
de eventos.
Perspectiva de negocios
En implementaciones ms avanzadas, el nivel de Emisor de eventos puede soportar patrones de deteccin de
eventos del productor ms avanzados y puede implementar Agentes locales de procesamiento de eventos.
Tambin se puede considerar el filtrado, la agregacin, el enriquecimiento o incluso la validacin de eventos
elementales en el subnivel de Procesamiento de eventos con el objetivo de emitir, a travs 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 pblica, consideremos al "Hospital" como el Proveedor de eventos y
al evento de "Alerta de posible brote epidmico" que produce. Por medio del Sistema de informacin del hospital,
se informa la situacin de muchos pacientes. Resulta que es necesario monitorear a algunos de ellos de manera
continua, ya que se los vincula con una infeccin especfica. La ocurrencia de esta situacin es un evento
elemental. Para detectar un Posible brote epidmico, es necesario comparar (localmente en el hospital) varios
eventos elementales similares que afectan a muchos pacientes y durante un perodo 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 epidmico 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 patrn bsico de procesamiento posible. Cuando se recibe un mensaje de evento a
nivel del Bus de Eventos, el subnivel de los Servicios de Publicacin 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 estn disponibles para los Consumidores de Eventos o el componente de Servicios de
Subscripcin. Los consumidores de eventos acceden al Registro de eventos para obtener informacin sobre los
Canales relacionados con el tipo de Evento en el que estn interesados. Los Consumidores de eventos reciben el
mensaje de evento simplemente escuchando a los Canales relevantes.

Ejemplo: En el escenario de gestin de la flota, consideremos el evento de Cambio en la Entrega, con el Panel
de Control de gestin 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 especfico. El Panel de Control de gestin de la entrega escucha a este canal. Cuando se recibe un
mensaje de evento nuevo, el Panel de control de gestin de la entrega lo procesa usando su Administrador local
de eventos (ver la fase de consumo del evento).
Tambin se puede dar el caso de que un solo evento entrante genere mltiples eventos salientes con formatos
diferentes, dependiendo de su carga til y las solicitudes de subscripcin expresadas para l. Los Consumidores
de eventos pueden indicar su inters en un tipo de evento especfico usando los Servicios de subscripcin.
Adems, tambin pueden configurar parmetros adicionales para especificar la forma en la que desean que se
los notifique sobre el evento relacionado. Estos parmetros pueden ser los siguientes (lista no exhaustiva):
Formato del mensaje de evento que se recibir al momento de la notificacin
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 publicacin procesa
cada solicitud individual de subscripcin 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 transformacin). Luego de esto, los Servicios de notificacin envan el mensaje de evento
resultante hacia el Consumidor de Eventos a travs del Canal solicitado.
Ejemplo: En el escenario de alerta de salud pblica, consideremos al "Mdico clnico" como el Consumidor de
Eventos y al evento de "Posible alerta de brote epidmico" que emite. El Mdico clnico se subscribe a los
eventos de alerta de salud, ya que desea recibir notificaciones en su casilla de correo electrnico cada vez que
se genere una alerta de Posible brote epidmico en su rea de trabajo especfica. Adems, tambin desea
obtener informacin adicional sobre la enfermedad relacionada. Los servicios de subscripcin del bus de eventos
deberan ofrecer ciertas facilidades que le permitan navegar por la lista de alertas disponibles para colocar un
filtro en la ubicacin geogrfica, 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 parmetros para filtrar los eventos
entrantes de alerta de Posible brote epidmico con el objetivo de enriquecerlos con toda la informacin adicional
solicitada y para darle formato de correo electrnico con el objetivo de enviarla al consumidor a travs de los
Servicios de notificacin.
Procesamiento de mltiples eventos entrantes
En este caso, se considera la existencia de mltiples eventos entrantes, que posiblemente abarcan diferentes
tipos y fueron emitidos por diferentes sectores durante un perodo 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 mltiples eventos del conjunto de eventos. El Bus de Eventos
implementa uno o varios Agentes de procesamiento de eventos a cargo de realizar esta deteccin. El
administrador del Bus de eventos ya habr configurado uno o varios patrones (posiblemente, usando los
Servicios de Subscripcin o los Servicios de Gestin de Informacin de Eventos) y los habr almacenado en el
Registro de Eventos. Estos patrones pueden abarcar mltiples dimensiones (entre las que podemos incluir la
causalidad, la hora, la ubicacin 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 vlidas de comparacin 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 podra iniciar un flujo de procesamiento nuevo si
todava no se recibi ningn evento de dicho conjunto de eventos.
El procesamiento de esta regla de comparacin de patrones produce un evento resultante, que puede ser:
Publicado directamente en los Canales relevantes.
Mediado y transmitido a travs 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 comparacin de patrones
crea un Flujo de Procesamiento de Eventos. El perodo de tiempo suele ser una caracterstica importante del
conjunto de eventos. Adems, la hora tambin es un factor importante al momento de considerar la
implementacin 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 combinacin 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 perodo de tiempo
prolongado, quiz resulte necesario persistir los eventos relacionados.
Ejemplo: En el escenario de gestin 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 perodo de tiempo de ms 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 especfica, se debera iniciar un EPA para que espere un evento "El conductor termina de
trabajar" correspondiente a la misma ID del conductor. Si este evento ocurre ms de ocho horas despus del
evento inicial, se debera emitir un evento resultante "El conductor excedi el tiempo de manejo permitido".
En el escenario de alerta de salud pblica, consideremos el evento "Alerta de posible brote epidmico" y, como
Consumidor del evento, consideremos al agente "Comparar alertas de posible brote epidmico". El tipo de evento
denominado Alerta de posible brote epidmico y un perodo 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 lgica de comparacin de patrones del agente. Por ejemplo: Si se recibe una Alerta de posible
brote epidmico de diez fuentes diferentes en menos de dos semanas, se debera generar una Alerta de brote
pandmico.
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 emisin del evento, este nivel puede cumplir un rol tcnico u
orientado a los negocios.
Perspectiva tcnica
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 adaptacin tcnica de la carga til del mensaje de
evento para cumplir con los formatos de entrada especficos del Consumidor del evento. El subnivel de
Orquestacin de Eventos identifica la parte de la lgica de negocios que implementa la accin asociada con la
recepcin de este mensaje de evento especfico. El subnivel de Orquestacin de Eventos inicia la ejecucin de
esta lgica, con la carga til opcionalmente transformada del mensaje de evento como parmetro de entrada.
Ejemplo: En el escenario de gestin de la flota, consideremos el evento denominado Cambio en la entrega y el

Panel de Control de Gestin de Entregas como su Consumidor del evento. El Panel de Control de Gestin 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 conexin de cola de mensaje WebSphere MQ (Adaptador del
evento local) que es la interfaz con el Bus de eventos. La lgica 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 grficos que ve el consumidor final.
Perspectiva de negocios
El nivel de Administrador del evento se puede comportar, en implementaciones ms avanzadas, como un punto
de convergencia de mltiples 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 accin en el Consumidor del evento. Luego de esto, el evento resultante se transmite hacia el nivel de
Orquestacin de Eventos para iniciar la lgica de negocios relevante en el Consumidor del evento. Por otra parte,
la recepcin de un solo mensaje de evento puede generar mltiples procesamientos locales, ya que muchas
partes del Consumidor del evento estn interesadas en l de diferentes maneras.
Ejemplo: En el escenario de alerta de salud pblica, consideremos al "Hospital" como el Consumidor del evento y
al evento denominado "Alerta de brote pandmico" que consume. Cuando se notifica sobre dicho evento al
Hospital, como se genera una situacin muy crtica, pueden existir varias formas de procesamiento local de este
evento que ocurren en paralelo.
La informacin 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 logstica para iniciar procesos especficos a cargo
de gestionar situaciones urgentes de salud.
Mapeo de los escenarios hacia el modelo conceptual

En esta seccin, volvemos a analizar los diferentes escenarios de procesamiento de eventos y cmo realizan el
mapeo hacia los diversos componentes de la arquitectura conceptual.

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 gestin de la flota hacia la arquitectura conceptual de procesamiento de eventos (vea la Figura
12). La vinculacin 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 ningn 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 informacin
del conductor no requieren ningn tratamiento especial y los agentes A1 y A2 los pueden procesar directamente.
Adems, todos los consumidores pueden consumir E5 en su estado actual.
Figura 12. Componentes de la arquitectura conceptual en el escenario de gestin de la

flota
El procesamiento de eventos es importante en el escenario de gestin de la flota, ya que permite que se

responda en tiempo y forma a toda la informacin dispar en relacin con las ubicaciones de los conductores, los
tiempos de manejo y las rutas de entrega. Tambin le ofrece el alcance necesario para modificar las reglas
relacionadas con los tiempos de manejo permitidos, cmo se administran los cambios en las entregas, etc.

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
pblica hacia la arquitectura conceptual de procesamiento de eventos (vea la Figura 13). La vinculacin 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 especficos en el bus de eventos. No existe ningn 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 pblica
Luego de terminar de describir el escenario, consideremos la razn por la cual el procesamiento de eventos es
importante para el ejemplo de la alerta de salud pblica.
Como este escenario se relaciona con la salud pblica, 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 pandmico o epidmico.
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 dinmica de procesamiento de eventos que
agrega valor a una gran cantidad de consumidores de eventos posibles.

La Figura 14 le muestra el mapeo del escenario de un proveedor de servicios de comunicacin 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 comunicacin
Conclusin
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 cmo 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 agregacin o la divisin, etc. de eventos
segn lo que sea necesario. Esta arquitectura conceptual realiza la obtencin 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 tambin indica los diversos servicios que se pueden llegar a requerir en el Bus de Eventos. La
intencin de esta arquitectura conceptual consiste en identificar todos los componentes que pueden llegar a ser
necesarios para cumplir con la implementacin del procesamiento de eventos. De todas formas, se espera que
slo algunos componentes sean necesarios para un escenario o una implementacin en particular.
Este artculo 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 cmo este modelo conceptual se puede aplicar para la
seleccin de diferentes situaciones prcticas. Hemos incluido una descripcin 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 lgicas y fsicas que se usarn 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 colaboracin en el modelo conceptual y en este documento.

Ibm - Un Modelo Conceptual para Los Sistemas de Procesamiento de Eventos

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ibm - Un Modelo Conceptual para Los Sistemas de Procesamiento de Eventos

Uploaded by

Copyright:

Available Formats

ibm.

Un modelo conceptual para los sistemas de procesamiento de

Generalidades del Procesamiento de Eventos

Figura 1. Generalidades del Procesamiento de Eventos

Tipos de Procesamiento de Eventos

Procesamiento de Eventos de Negocios

Figura 2. Procesamiento de Eventos de Negocios: Agrega una perspectiva de negocios a

Valor del procesamiento de eventos

Generalidades de diferentes escenarios de procesamiento de eventos

Escenario de gestin de la flota

Figura 3. Generalidades de la gestin de la flota

Escenario de alerta de salud pblica

Figura 4. Generalidades de la alerta de salud pblica

Escenario de un proveedor de servicios de comunicacin

Red de Procesamiento de Eventos

Figura 5. Red de Procesamiento de Eventos

Productor y consumidor de eventos

tareas determinadas asociadas con este evento.

Agente de procesamiento de eventos

Escenarios de Red de Procesamiento de Eventos

Escenario de gestin de la flota

Tabla 1. Productores de eventos

Transmisin de ubicacin por GPS, sensores en el vehculo (combustible, emisin,

Driver Report System

Tarjeta perforada electrnica

Delivery System (Sistema

Gestin de rdenes, Ordenamiento y asignacin de paquetes y Sistema de

Package RFID System

Sistema de seguimiento de paquetes con lectores en estaciones y lectores mviles

Tabla 2. Consumidores de eventos

Driver Display (Pantalla del conductor)

Pantalla del conductor mvil y en el vehculo que muestra las

Delivery Management Dashboard (Panel de

Vista completa de las operaciones (ubicacin de los vehculos,

Los emisores o los receptores de pedidos pueden recibir

Fecha y hora; ID del conductor

Fecha y hora; ID del conductor; ID del vehculo;

Fecha y hora; ID del conductor

Fecha y hora; ID del conductor; ID del vehculo;

Fecha y hora; ID del conductor 1; ID del vehculo 1; ID

Tabla 4. Canales de eventos

A3, Delivery Management Dashboard

Clientes, Driver Display, Delivery

Tabla 5. Agentes de procesamiento de eventos: Ejemplo 1

Nombre del agente

Enriquecer "El conductor comienza a trabajar"

Tabla 6. Agentes de procesamiento de eventos: Ejemplo 2

Nombre del agente

El conductor excedi el tiempo de manejo permitido

Contexto del agente

intervalo (E2,+8h) por ID del conductor

Especificacin del agente

Tabla 7. Agentes de procesamiento de eventos: Ejemplo 3

Tabla 8. Agentes de procesamiento de eventos: Ejemplo 4

Notificacin de reasignacin de ruta a los consumidores requeridos

Especificacin del agente

Figura 6. Representacin grfica de la EPN para la gestin de la flota

Escenario de alerta de salud pblica

Tabla 9. Productores de eventos

Es probable que el hospital detecte posibles virus o indicios de ellos y emita

Es probable que el laboratorio detecte posibles virus o indicios de ellos y

Es probable que el doctor detecte indicios de posibles virus y emita un

El Organismo gubernamental extranjero emite un evento