ibm - un modelo conceptual para los sistemas de procesamiento de eventos

35
ibm.com https://www.ibm.com/developerworks/ssa/webservices/library/ws-eventprocessing/ Un modelo conceptual para los sistemas de procesamiento de eventos Introducción En muchos ámbitos, el comportamiento de las empresas siempre se basó en eventos y, por lo tanto, éstas siempre tuvieron que ocuparse de un volumen de transacciones y eventos de negocios que crece día a día. El Procesamiento de Eventos (EP) es un área emergente impulsada, en primer lugar, por la mayor necesidad que tienen las empresas para poder responder rápidamente a este gran volumen de negocios y eventos de TI. EP reconoce la necesidad de brindar soporte para el ciclo de toma de decisiones mediante el procesamiento de eventos significativos para las empresas de una forma más efectiva. Por lo tanto, EP es una parte cada vez más importante de las estrategias de las empresas en relación con las Arquitecturas Orientadas a Servicios (SOAs). En primer lugar, este artículo discute la necesidad de realizar el procesamiento de eventos, los diferentes tipos de procesamientos de eventos y el valor que tiene la adopción del procesamiento de eventos para los negocios. Luego de esto, el presente artículo detalla un modelo conceptual de procesamiento de eventos que se puede usar para materializar una Arquitectura Impulsada por Eventos (EDA). Los conceptos se elaboran mediante la discusión de tres escenarios de negocios que implementan el procesamiento de eventos para lograr tomar mejores decisiones. Generalidades del Procesamiento de Eventos Un Evento es cualquier cosa significativa que ocurre o que se considera que puede llegar a ocurrir. Un evento ocurre o no y es significativo porque puede llegar a afectar alguna acción. Se considera que un evento puede llegar a ocurrir como algo que podría hacerse realidad o como la transición de una entidad en el mundo real. Puede formar parte de un proceso de negocios (por ejemplo: se emitió una orden de transacción, aterrizó el avión correspondiente a un vuelo específico, se registró la lectura de un sensor de datos) o puede monitorear información sobre la infraestructura de TI, middleware, aplicaciones y procesos de negocios). La Figura 1 le muestra las generalidades detalladas del procesamiento de eventos. Figura 1. Generalidades del Procesamiento de Eventos

Upload: hboveri

Post on 04-Oct-2015

4 views

Category:

Documents


0 download

DESCRIPTION

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

TRANSCRIPT

  • ibm.com https://www.ibm.com/developerworks/ssa/webservices/library/ws-eventprocessing/

    Un modelo conceptual para los sistemas de procesamiento deeventosIntroduccinEn muchos mbitos, el comportamiento de las empresas siempre se bas en eventos y, por lotanto, stas siempre tuvieron que ocuparse de un volumen de transacciones y eventos de negociosque crece da a da. El Procesamiento de Eventos (EP) es un rea emergente impulsada, en primerlugar, por la mayor necesidad que tienen las empresas para poder responder rpidamente a este gran volumende negocios y eventos de TI. EP reconoce la necesidad de brindar soporte para el ciclo de toma de decisionesmediante 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 ArquitecturasOrientadas a Servicios (SOAs).

    En primer lugar, este artculo discute la necesidad de realizar el procesamiento de eventos, los diferentes tiposde 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 puedeusar para materializar una Arquitectura Impulsada por Eventos (EDA). Los conceptos se elaboran mediante ladiscusin de tres escenarios de negocios que implementan el procesamiento de eventos para lograr tomarmejores decisiones.

    Generalidades del Procesamiento de EventosUn Evento es cualquier cosa significativa que ocurre o que se considera que puede llegar a ocurrir. Un eventoocurre o no y es significativo porque puede llegar a afectar alguna accin. Se considera que un evento puedellegar 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 elavin correspondiente a un vuelo especfico, se registr la lectura de un sensor de datos) o puede monitorearinformacin sobre la infraestructura de TI, middleware, aplicaciones y procesos de negocios). La Figura 1 lemuestra 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 unservicio, la iniciacin de un proceso de negocios y / o la publicacin o la sindicacin de ms informacin. ElProcesamiento de Eventos se ocupa de la tarea de procesar uno o varios eventos con el objetivo de identificaraquellos eventos que sean ms importantes dentro de la nube de eventos. Desde la perspectiva del valor denegocios, el procesamiento de eventos es la capacidad de detectar y responder a eventos que indicansituaciones que impactan sobre los negocios y ocurren en toda la empresa. Por ejemplo, un mensaje de eventopodra indicar que se agreg un cliente nuevo, que se vendi un producto, que se recibi un envo, que se abriuna 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 unaaplicacin, un almacenamiento de datos, un servicio, un proceso de negocios, un transmisor, un sensor o unaherramienta de colaboracin (como una aplicacin de mensajera instantnea o correo electrnico). Al recibirestos eventos del productor, los eventos pueden provocar resultados de manera directa o se los puede evaluarsegn los patrones de procesamiento de eventos. Los patrones de procesamiento de eventos se definen deacuerdo con las necesidades de las partes interesadas, y no de acuerdo con las necesidades de los productoresde eventos. Los resultados del procesamiento de eventos incluyen, pero no se limitan a, la invocacin de unservicio, la iniciacin de un proceso de negocios, la publicacin de un evento en un hub de subscripcin, lanotificacin directa a humanos o sistemas, la generacin de un evento nuevo y / o la captura de los propsitoshistricos del evento. Se suele hacer referencia a los eventos y su interaccin con los servicios de negocios de lasiguiente manera: sistema de informacin impulsada por eventos o arquitectura impulsada por eventos.

    Fundamentos conceptualesLos bloques de construccin conceptuales de una arquitectura que soporta el procesamiento de eventos (esdecir, un sistema de procesamiento de eventos) debera ofrecer funciones centrales (como, por ejemplo, la lgicadel procesamiento de eventos) y conectar a los consumidores y a los productores de eventos por medio deeventos. Un modelo muy til para pensar en dichas arquitecturas y en dicho sistema es la construccindenominada Red de Procesamiento de Eventos (EPN): un fundamento conceptual que describe la estructura delos sistemas de procesamiento de eventos y las caractersticas comunes que todos deberan soportar. La EPNdescribe al sistema de procesamiento de eventos como un conjunto de consumidores, agentes deprocesamiento y productores de eventos que interactan. En este contexto, la responsabilidad principal de laEPN 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 consumidorescorrectos. La construccin denominada Red de Procesamiento de Eventos se describe en mayor detalle en laSeccin II de este artculo, que describe el Modelo conceptual para el procesamiento de eventos. El modeloconceptual abarca la virtualizacin, las bases de datos de eventos, el middleware impulsado por eventos, loslenguajes de procesamiento de eventos y todo aquello que soporta la gestin de eventos a lo largo de su ciclo devida (desde el modelado y la programacin hasta el monitoreo y la respuesta).

    Tipos de Procesamiento de EventosLas funciones de Procesamiento de Eventos se pueden categorizar en simples y complejas segn la complejidady la sofisticacin del procesamiento:

    Procesamiento de Eventos Simples : Se filtran y rutean eventos simples (es decir, eventos que noresumen, 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 queocurre se procesa de manera independiente. Aunque se los denomina "simples", estos eventos puedenofrecerle un gran valor e informacin de negocios muy importante. Se transforman los eventos, lo queinvolucra eventos de conversin y divisin, y se fusionan uno o ms eventos. El procesamiento simpleincluye el procesamiento que involucra la modificacin de la forma del esquema de los eventos, elaumento de la carga til de los eventos mediante datos adicionales, el redireccionamiento del evento deun canal o flujo a otro y la generacin de mltiples eventos basados en la carga til de un solo evento. Aeste 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 eventosindependientes con el objetivo de crear nuevos "eventos complejos". Un evento complejo es un eventoque resume, representa o denota un conjunto de otros eventos. El procesamiento de eventos complejosincluye el procesamiento de un conjunto de eventos con el objetivo de detectar una situacin relevantepara el negocio. Generalmente, este procesamiento involucra la aplicacin de un conjunto de limitacioneso condiciones de evaluacin en un conjunto de eventos. Los eventos (relevantes u ordinarios) puedenabarcar diferentes tipos de eventos y pueden ocurrir durante un perodo de tiempo determinado. Es posiblecorrelacionar los eventos en mltiples dimensiones de inters, entre las que podemos incluir lassiguientes: causal, temporal, espacial y otras. Se debera hacer una distincin entre la naturalezacompleja y rica de la informacin disponible a partir del Procesamiento de Eventos Complejos y el hechode 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 elmiddleware 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. Lasherramientas y los motores de Procesamiento de Eventos Complejos vieron la luz en los ltimos aos. Elprocesamiento de eventos se puede combinar con tcnicas analticas para predecir eventos, minar patrones eincrustar analtica en tiempo real en las decisiones de ruteo y en las derivaciones de eventos. El uso de estastcnicas para realizar el anlisis en tiempo real le ofrece la capacidad de tomar decisiones ms inteligentesdentro del ciclo de toma de decisiones.

    Procesamiento de Eventos de NegociosProcesamiento de Eventos de Negocios extiende y mejora el procesamiento de eventos haciendo que estdisponible para los usuarios de negocios de forma consumible. Procesamiento de Eventos de Negocios extiendelas capacidades y las herramientas de los usuarios de negocios, lo que permite la aplicacin de tecnologas paraconstruir sistemas de informacin impulsados por eventos que contribuyen con el negocio. La capacidad depercibir cuando un evento ocurri (o no ocurri), lo que indica una situacin de negocios procesable, hace que elnegocio pueda responder de manera rpida a las oportunidades y a las amenazas.

  • Figura 2. Procesamiento de Eventos de Negocios: Agrega una perspectiva de negocios alas capacidades de procesamiento de eventos

    Los analistas y los gerentes de negocios comprenden las situaciones procesables (es decir, aquellos eventos ocombinaciones de eventos clave y las acciones que se deben tomar en respuesta a dichos eventos). Ellos seocupan de estas situaciones a diario y son directamente responsables de conocer cundo ocurren y de gestionarla respuesta correspondiente. Sin embargo, no cuentan con las soluciones disponibles para poder identificar yresponder al volumen y la complejidad de estas situaciones. Al mismo tiempo, aunque millones de eventos quepueden llegar a ser procesados fluyen libremente a travs de la infraestructura de TI hoy en da, para soportar lafuncionalidad 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 estosrequisitos de manera efectiva y eficiente. Se dise el Procesamiento de Eventos de Negocios especficamentepara que se ocupe de este desafo (es decir, para que potencie la informacin que fluye a travs de los sistemasde 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 unasituacin de negocios procesable y coordinar la accin de respuesta adecuada en el momento indicado. ElProcesamiento de Eventos de Negocios le ofrece un conjunto integrado de sistemas e infraestructura quemonitorea los eventos que ocurren en toda la empresa. Este tipo de procesamiento reconoce las ocurrenciassignificativas en el momento que acontecen y activa alertas y disemina informacin sobre el evento en cuestinpara iniciar las respuestas que sean apropiadas. Cuando se lo incluye como parte de una solucin de Gestin deProcesos de Negocios, el Procesamiento de Eventos de Negocios le ofrece una poderosa combinacin dedeteccin de patrones de eventos en tiempo y forma y una ejecucin dinmica de procesos de negocios. ElProcesamiento de Eventos de Negocios le ofrece TI con la funcionalidad necesaria para soportar los requisitosavanzados 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 Eventosde Negocios equipa a los usuarios de negocios con todo lo necesario para que puedan definir las acciones y lasinteracciones de procesamiento de eventos.

    Valor del procesamiento de eventosDesde hace ya bastante tiempo que se usan los principios bsicos de procesamiento de eventos, en middlewarede integracin de aplicacin y en varias otras formas de software de sistema (como, por ejemplo, los sistemasoperativos), redes y software de gestin de sistemas. Sin embargo, el creciente valor del procesamiento deeventos se basa en el reconocimiento de la importancia de un evento desde un contexto de negocios y en laidentificacin de las respuestas adecuadas que se deben asociar con dicho evento. Todo esto puede ayudar a unnegocio a responder de manera rpida ante nuevas oportunidades y amenazas de competencia, a diseminarinformacin relevante en tiempo y forma entre las personas adecuadas, a permitir el diagnstico activo deproblemas 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 aoportunidades para mitigar los riesgos, a promover un menor tiempo para realizar el trabajo y a disminuir lostiempos del ciclo de percepcin y respuesta. Por ejemplo:

  • Comerciantes que operan en los mercados de capital y desean reaccionar ante las oportunidades dearbitraje.Analistas militares o de inteligencia que evalan flujos de datos provenientes de satlites y sensores paradeterminar las acciones ofensivas y defensivas que se deben adoptar.Negocios de transporte y logstica que utilizan telemetra de vehculos en tiempo real para gestionar susflotas de vehculos de manera ms efectiva.Empleados bancarios que realizan el seguimiento continuo de transacciones para detectar casos defraude, lavado de dinero o incumplimiento de las reglamentaciones financieras.Proveedores de servicios de comunicacin que buscan minimizar el tiempo promedio que lleva reparar lasfallas en la red.Compaas petroleras que determinan la profundidad y el ancho de las perforaciones de maneradinmica, basndose en datos operacionales en tiempo real.Proveedores de repuestos automotrices que utilizan complejas decisiones de fabricacin para entregarrepuestos 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 datoscomplejos en tiempo real. El procesamiento de eventos le ofrece la capacidad de hacer esto. La necesidad quetienen las empresas de pasar del procesamiento por lote al procesamiento en tiempo real para as poder tomardecisiones con mayor rapidez es otras de las razones que hace que aumente la demanda del procesamiento deeventos. Las caractersticas de las cargas de trabajo emergentes tambin requieren el procesamiento deeventos complejos en casi tiempo real, lo que involucra eventos de datos y eventos que se originan a partir defuentes no convencionales (como, por ejemplo, voz y video).

    Los analistas industriales, como por ejemplo Gartner, comparten esta visin y afirman que los eventos en susdiferentes formas desde eventos simples hasta eventos complejos se comenzarn a usar cada vez ms enaplicaciones de negocios. La implementacin de procesos de negocios impulsados por eventos tiene enormesbeneficios financieros y estratgicos, ya que se adecan a una naturaleza inherentemente impulsada poreventos de muchos aspectos del mundo real.

    Los procesos de negocios impulsados por eventos no son simplemente procesos tradicionales que se ejecutan amayor 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 pararesponder a errores y a condiciones excepcionales que alteran los procesos convencionales. A medida que lasempresas 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 ausar cada vez ms. Las empresas estn logrando beneficios mediante la implementacin de procesos denegocios impulsados por eventos, porque se adecan a la naturaleza inherentemente impulsada por eventos delos negocios y porque les confiere una ventaja competitiva en trminos de los costos y los tiempos involucradosen la realizacin del trabajo.

    Generalidades de diferentes escenarios de procesamiento de eventosPara ilustrar los conceptos que se describen en este artculo, desarrollaremos tres escenarios diferentes deprocesamiento de eventos a lo largo de las diversas secciones del presente. Estos escenarios demuestranalgunos de los valores descriptos en las generalidades.

    Escenario de gestin de la flotaEscenario de alerta de salud pblicaEscenario de un proveedor de servicios de comunicacin

    Luego de presentar los escenarios, mapearemos los diversos conceptos de procesamiento de eventos hacia elescenario 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 mscomunes se presentan en este escenario.

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

    Escenario de gestin de la flotaEste escenario describe la situacin de la compaa "Fast Delivers", que se especializa en entregar paquetespequeos, en un radio de operacin relativamente reducido, mediante el uso de su flota de vehculos. Cadavehculo tiene un GPS que transmite su ubicacin de manera constante. Adems, los paquetes estn etiquetadoscon rtulos RFID. De acuerdo con el nivel de servicio deseado, el paquete se enva de manera inmediata de unlugar 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 todaslas demoras. Algunas entregas son fijas (de acuerdo con un cronograma mensual) y otras surgen a raz de lospedidos 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 delos gerentes de flotas de camiones y autos, mencionamos algunos de los objetivos que ellos suelen tener almomento 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 dentrode su sistema. Por lo tanto, la compaa est capacitada para reaccionar a la brevedad y reasignar rutas con elobjetivo de satisfacer las demandas de los clientes en el momento sin descuidar el acuerdo hecho con cada unode sus clientes. La compaa tambin puede reaccionar ante los riesgos a medida que se van materializando ymitigar la situacin realizando reasignaciones antes de que se incumpla algn contrato. Gracias alprocesamiento de eventos, la compaa puede reaccionar ante oportunidades y riesgos a medida que se vanmaterializando y decidir qu hacer al respecto (para mantener todos los indicadores que se mencionan conanterioridad bajo control), ya que la situacin actual de todos los vehculos, los pedidos, etc. se monitorea deforma constante y se anticipa por medio de los eventos. La compaa tambin puede realizar cambios eimplementarlos en el proceso con gran rapidez y confianza simplemente cambiando la aplicacin o la lgica deprocesamiento 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 eventospara este escenario.

    Escenario de alerta de salud pblicaEl escenario de alerta de salud pblica describe el sistema de alerta en casos que indican brotes epidemiolgicosreales o posibles que presentan un riesgo para la poblacin. El Sndrome Agudo Respiratorio Severo (SARS) y lagripe aviar (H5N1) o ataques terroristas que empleen agentes biolgicos o qumicos son slo algunos de losejemplos 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 laSalud, nos muestra la progresin desde el estado interpandmico (donde no se detecta el virus de la influenzaen los seres humanos) hasta el estado pandmico (donde se registra el contagio de gran parte de la poblacingeneral). Para este escenario, se consideran tres etapas fundamentalmente: no se detecta el virus, estadoepidmico 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 elvirus. 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 realizaalgunas 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 esnecesario 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 sise trata de un brote pandmico. En el caso de alertas epidmicas y pandmicas, se envan notificaciones comoeventos correspondientes. En el caso de alertas de brotes pandmicos emitidas por productos de eventosexternos (como, por ejemplo, organizaciones internacionales de salud o gobiernos extranjeros), se acta demanera similar.

    Las secciones posteriores del presente artculo, se ocupan de los eventos involucrados y la forma en la que esteescenario se relaciona con el modelo conceptual de procesamiento de eventos.

    Escenario de un proveedor de servicios de comunicacinEste 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 apequeas y medianas empresas (que van desde acceso a Internet por banda ancha hasta VOIP y servicios deVirtual Private Network). La red MPLS (Conmutacin de Rtulo Multiprotocolo) central de la compaa secompone de elementos de red de muchos fabricantes diferentes soportados por un conjunto de ElementManagement Systems. Estos emplean una amplia gama de tecnologas de red (incluso Dial-Up, DSL ytecnologas 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 diversosAcuerdos de Nivel de Servicio (SLA). Estos SLA se componen de contratos que garantizan los niveles acordadosde servicio segn las mtricas especificadas (por ejemplo, la continuidad del servicio o el ancho de banda de reddisponible). Los SLA que no se cumplan podrn resultar en multas econmicas que YourCSP deber pagar yhasta podra llegar a perjudicar la reputacin de la compaa. Sus clientes estn jerarquizados de acuerdo consus acuerdos de nivel de servicio individuales.

    YourCSP, al igual que todas las CSP, emplean un Centro de Operaciones de Red que se compone de empleadosy activos de hardware y software dedicados a favorecer el buen funcionamiento de la red central de la compaay 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 ladegradacin 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 SLAvigentes 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 paramantenerlos 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 eventospara estos fines. Estos sistemas procesan muchos tipos diferentes de eventos, incluso eventos que representanlo 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 reden 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 Operacionesde 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 visualizacinconsistente.Ofrecer vistas interactivas actualizadas de los eventos que ocurrieron en la red a los operadores delCentro 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 redprovistos.Ofrecer paneles de control del mapa de red al personal de operacin para el diagnstico y laresolucin de problemas.Realizar el anlisis de la causa raz de los eventos basndose en la topologa de red en relacincon 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 dered.Realizar el anlisis de patrones de los eventos y sacar conclusiones en relacin con las causas y elimpacto 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 deYourCSP, 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 serviciosde VPN entre las instalaciones distribuidas de MediumCo. El contrato est sujeto a altos niveles de disponibilidadcon un SLA asociado. YourCSP brinda y gestiona un router Customer Edge (CE) especfico en cada una de lasinstalaciones de MediumCo para realizar la conexin con la red central de YourCSP. Cada CE se conecta a unrouter 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 deeventos recibir muchos eventos que le indicarn fallas fsicas y lgicas enviadas desde el equipamiento y lossistemas de gestin de elementos en la red circundante. Esto incluye fallas de ping ICMP (Internet ControlMessage Protocol), alarmas de vnculo roto y fallas de adyacencia del protocolo de ruteo. En esta situacin, elsistema 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 (eneste caso, la falla de la tarjeta).Inferir si algunos servicios de los clientes resultan afectados (en este caso, si el servicio de VPN deMediumCo funciona o no).Determinar la prioridad relativa de la interrupcin del servicio de acuerdo con los SLA aplicables y encomparacin con otras interrupciones del servicio en la red y priorizar de manera adecuada la resolucindel problema. En este caso, la resolucin tiene una alta prioridad debido al SLA agresivo que se firm conMediumCo.

  • Informar al cliente afectado sobre la identificacin de la falla y ejecutar una solicitud de elemento detrabajo 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 servicionormal.

    En las prximas secciones, se analizan los eventos involucrados en este escenario y el mapeo hacia el modeloconceptual.

    Modelo conceptualNuestro Modelo conceptual presenta dos vistas diferentes de los sistemas de procesamiento de eventos quebuscan describir los conceptos importantes y su relacin con un nivel abstracto, sin mencionar ningn detalletcnico. La Red de Procesamiento de Eventos (EPN) resume las caractersticas esenciales de los elementos deentrada, 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 sepueden involucrar en la materializacin de un sistema de procesamiento de eventos y las interrelaciones entreellos con el objetivo de brindar valor de negocios. Esto es a nivel abstracto, lo que es independiente de lastecnologas, 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 deprocesamiento 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 anivel conceptual, a partir del que se pueda construir un sistema de procesamiento de eventos. Pero no existeningn requisito que exija implementar ningn componente que no sea necesario en un sistema en particular. Deigual forma, tampoco existe ningn concepto implcito de cumplimiento con el modelo.

    Red de Procesamiento de EventosNuestra abstraccin de alto nivel de sistemas de procesamiento de eventos aplica conceptos de la construccinde la red de procesamiento de eventos (vea la Figura 5). Como lo indicamos con anterioridad, una Red deProcesamiento de Eventos es una formulacin conceptual que describe la estructura de los sistemas deprocesamiento 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 deprocesamiento 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 suenriquecimiento). Un evento que fluye desde un componente hacia otro debe hacerlo por medio de un canal deeventos (como se puede observar en la Figura 5, que le muestra la relacin existente entre los diferentescanales de eventos, consumidores, productores y agentes de procesamiento). Los canales de eventos son nodosque conectan a los productores de eventos con los EPAs dentro de la EPN, que conectan los EPAs siempre queesto sea necesario y que conectan los EPAs a los consumidores (lo que resulta en eventos que pasan desde losproductores de eventos hasta los consumidores de eventos a travs de la EPN). Esta Figura tambin ilustra elhecho de que los diversos eventos producidos por los productores de eventos en la EPN se pueden procesar pormedio de grupos apropiados de EPAs, conectados por medio de canales, con el objetivo de que los diversosconsumidores de eventos en la EPN consuman dichos eventos (o los eventos que de ellos deriven).

    Canal de eventosUn canal de eventos es un mecanismo para entregar agentes o flujos de eventos desde los productores deeventos y los EPA hasta los consumidores de eventos y los EPA. En este nivel de abstraccin, no se colocanlimitaciones ni sobre las propiedades del canal de eventos (como, por ejemplo, si cada canal puede mover o noms 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 ypuede llegar a transferir eventos combinados desde varias fuentes hasta mltiples EPAs y consumidores. Elorden entre los eventos provenientes de diferentes EPAs y productores de eventos para crear el conjuntocombinado de eventos es especfico a la implementacin y el modelo conceptual no se ocupa de ello. Enalgunos casos, no se requiere ningn orden en particular. Sin embargo, el canal de eventos es responsable detomar eventos de los productores de eventos y/o los EPA, ordenarlos (de ser necesario) y combinarlos y entregaresto 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 parapermitir el procesamiento retrospectivo de eventos (de acuerdo con las polticas de retencin que determinan laduracin y las condiciones de filtrado para los eventos retenidos). El procesamiento retrospectivo de eventosconsiste 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 deeventos 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 elnodo. Cada borde entrante representa eventos desde un productor de eventos o un agente de procesamiento deeventos que coloca eventos en el canal. Cada borde saliente representa eventos hacia un consumidor deeventos o un agente de procesamiento de eventos que recibe eventos del canal.

    Productor y consumidor de eventosUn productor de eventos produce eventos a travs de canales de eventos para que cualquier parte interesadalos consuma. La parte interesada puede ser un consumidor de eventos o un EPA. El modelo conceptual nocoloca ninguna restriccin sobre el mecanismo por medio del que se obtienen los eventos desde un productor deeventos 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 lacantidad de canales de eventos diferentes involucrados en mover eventos desde el productor hacia los EPAs olos consumidores que recibirn los eventos. El mismo evento se puede publicar o hacer que est disponible pormedio 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 mejordiseo 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 slobordes se direccionan hacia l. La cantidad de bordes que se direccionan hacia l es la cantidad de canales deeventos diferentes involucrados en el movimiento de los eventos hacia el consumidor en cuestin. El mismoevento se puede recibir a travs de ms de un canal de eventos. Sin embargo, conviene que el EPA se ocupe dela lgica de dnde, cundo y cmo recibir eventos, para as permitir el mejor control, el mejor diseo y la mejorcomprensin 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 laltima funcin mencionada, aparecera como un productor de eventos dentro de la EPN.

    Agente de procesamiento de eventosEn un sistema distribuido y heterogneo, es posible que los productores de eventos no puedan producir loseventos que un consumidor de eventos espera recibir. Estos eventos pueden llegar a diferir en lo que hace a lasintaxis esperada (estructura), al significado semntico o a ambos aspectos. Tambin hay casos en los que unsolo evento no disparar una accin realizada por un consumidor de eventos. En cambio, la accin se dispararpor medio de una composicin compleja de eventos que ocurren en diferentes momentos y en diferentescontextos. Los EPA, a los que a veces se conoce como mediadores de eventos, son necesarios para detectarpatrones en eventos sin procesar, para procesar estos eventos a travs del enriquecimiento, la transformacin yla validacin y, por ltimo, para derivar eventos nuevos y publicarlos. Un EPA es responsable de producir estoseventos 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 quese procesarn de acuerdo con un patrn especificado. A los EPA que realizan la comparacin de patronesse los conoce como "EPAs de deteccin de patrones".Procesamiento: De ser requerida, esta etapa es la responsable de aplicar las funciones de procesamientoen los eventos seleccionados que satisfacen el patrn (lo que resulta en la creacin de eventosderivados).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 eventospara actuar de acuerdo con estos eventos. Un EPA enva eventos por medio de canales de eventos cuandoemite eventos, casi como un productor de eventos enva los eventos que produce por medio de un canal deeventos. Dentro de una red de nodos y bordes, un EPA se representa como un nodo con bordes direccionadosdesde y hacia el nodo. La cantidad de bordes direccionados hacia l es la cantidad de canales de eventosdiferentes que el agente usa para sus funciones (como, por ejemplo, la deteccin de patrones). La cantidad debordes direccionados desde l es la cantidad de canales de eventos diferentes a travs de los que el agenteenva eventos basados en las definiciones de emisin y procesamiento.

    En resumen, una Red de Procesamiento de Eventos (EPN) es un grfico dirigido de operaciones deprocesamiento de eventos conectadas por medio de canales de eventos. Los EPA dentro de la red le ofrecenmediaciones y servicios de procesamiento de eventos. Esto significa que obtienen un conjunto de uno o mseventos como entrada, realizan algn tipo de procesamiento y devuelven un conjunto (posiblemente nuevo) decero o ms eventos como datos de salida. La responsabilidad primordial de una Red de Procesamiento deEventos consiste en recibir eventos de los productores, transferirlos a una combinacin de agentes deprocesamiento de eventos para que los procesen y entregarlos a los consumidores adecuados.

    Escenarios de Red de Procesamiento de EventosAhora, mapeemos los componentes y la definicin de la red de procesamiento de eventos hacia los escenarios

  • descriptos en la Introduccin.

    Escenario de gestin de la flotaA 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 describenslo 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 ciertasreglamentaciones para garantizar la seguridad de sus conductores y para evitar accidentes. Por lo tanto, lajornada laboral de los conductores nunca debe exceder las 8 horas. Todo conductor que exceda esta limitacinhoraria se ver obligado a descansar y, para evitar todo tipo de demoras en las entregas a los clientes y que asla compaa no tenga que pagar ninguna multa, otros conductores se debern encargar de realizar todas lasentregas afectadas. Este proceso de reasignacin de tareas requiere el establecimiento de un punto de reuninadecuado en las instalaciones de la compaa, donde los productos se transferirn de un vehculo a otro(s) y serecalcularn las rutas para que las demoras, si fuesen inevitables, fuese lo menores posibles. Existe un sistemade informacin del conductor desde el que se producen eventos de inicio y de finalizacin de la jornada laboraldel 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 enriquecimientode eventos, la deteccin del patrn de "tiempo excesivo de manejo" y el establecimiento de rutas (a los que sedescribe como agentes de procesamiento de eventos).

    Tabla 1. Productores de eventos

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

    peso, etc.)Driver Report System(Sistema de informacindel conductor)

    Tarjeta perforada electrnica

    Delivery System (Sistemade entrega)

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

    Package RFID System(Sistema RFID parapaquetes)

    Sistema de seguimiento de paquetes con lectores en estaciones y lectores mvilespara el personal (por ejemplo, que los conductores usan al recolectar, transferir yentregar los paquetes)

    Tabla 2. Consumidores de eventos

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

    rutas, los cambios en las entregas y las alertasDelivery Management Dashboard (Panel decontrol 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 recibirnotificaciones o buscar sus pedidos

    Tabla 3. Eventos

  • ID deltipo deevento Tipo de evento Atributos Comentarios

    E1 El conductor comienzaa trabajar

    Fecha y hora; ID del conductor -

    E2 El conductor comienzaa trabajar (versinenriquecida)

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

    -

    E3 El conductor termina detrabajar

    Fecha y hora; ID del conductor Se puede basaren la estructurade E1

    E4 El conductor excedi eltiempo de manejopermitido

    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; IDdel conductor 2; ID del vehculo 2; ID del emisor; IDdel receptor

    -

    Tabla 4. Canales de eventos

    ID del canal deeventos

    Tipo deevento Productores Consumidores

    Poltica deretencin

    EC1 E1 Driver ReportSystem

    A1 -

    EC2 E2 A1 A2 -EC3 E3 Driver Report

    SystemA2 -

    EC4 E4 A2 A3, Delivery Management Dashboard -EC5 E5 A3 A4 -EC6 E5 A4 Clientes, Driver Display, Delivery

    Management Dashboard1 semana

    Tabla 5. Agentes de procesamiento de eventos: Ejemplo 1

    Propiedad delagente Especificacin

    ID del agente A1Nombre del agente Enriquecer "El conductor comienza a trabajar"Tipo de agente EnriquecerContexto delagente

    -

    Eventos de entrada E1

  • Especificacin delagente

    Enriquecer por ID del conductor con la ID del vehculo y el Nombre del conductor desdeDetalles del conductor

    Eventos de salida E2Comentario delagente

    Se enriquece el evento con detalles del conductor (como, por ejemplo, la ID delvehculo)

    Propiedad delagente Especificacin

    Tabla 6. Agentes de procesamiento de eventos: Ejemplo 2

    Propiedad del agente EspecificacinID del agente A2Nombre del agente El conductor excedi el tiempo de manejo permitidoTipo de agente Detectar patrnContexto del agente intervalo (E2,+8h) por ID del conductorEventos de entrada E3Especificacin del agente Ausencia de E3Eventos de salida -

    Tabla 7. Agentes de procesamiento de eventos: Ejemplo 3

    Propiedaddel agente Especificacin

    ID del agente A3Nombre delagente

    Reasignacin de la entrega

    Tipo deagente

    Detectar patrn

    Contexto delagente

    -

    Eventos deentrada

    E4, Ex

    Especificacindel agente

    Enriquecer por ID del conductor con la ID del vehculo y el Nombre del conductor desdeDetalles del conductor

    Eventos desalida

    E5

    Comentariodel agente

    Este agente recibe diferentes tipos de eventos para inferir los requisitos de cambio en laentregas. Este agente es responsable de decidir qu vehculo debera hacerse cargo de laentrega y cmo reunir a ambos vehculos en una misma estacin o en otro lugar.

  • Tabla 8. Agentes de procesamiento de eventos: Ejemplo 4

    Propiedaddel agente Especificacin

    ID del agente A4Nombre delagente

    Notificacin de reasignacin de ruta a los consumidores requeridos

    Tipo deagente

    Router

    Contexto delagente

    -

    Eventos deentrada

    E5

    Especificacindel agente

    -

    Eventos desalida

    E5

    Comentariodel 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 lasoperaciones 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 ReportSystem produce el evento E1 y lo publica en el canal EC1 como "el conductor comienza a trabajar". El Eventosde procesamiento de agentes A1 enriquece el evento E1 y se produce el evento E2. Luego de 8 horas, el agenteA2 produce el evento E4 como "el conductor excedi el tiempo de manejo permitido" antes de que termine sujornada de trabajo. El Delivery Management Dashboard recibe el evento E4 para controlarlo. El agente A3tambin 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 manejopermitidos. La instruccin de reasignacin se informa a travs del evento E5, que A4 rutea y redirecciona haciavarios consumidores que deben ser notificados: el conductor que excedi el tiempo de manejo permitido, elconductor o los conductores que deben hacerse cargo de entregar sus pedidos, el cliente (que debe conocer loscambios 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 aotros conductores y, en dicho momento, se produce el evento E3 (que no tiene efecto directo sobre los agentesdescriptos).

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

    Escenario de alerta de salud pblica

  • Las siguientes Tablas mencionan los componentes de la red de procesamiento de eventos correspondientes alescenario de alerta de salud pblica que se describi en la Introduccin. Los EPA para este escenario no sedescriben de manera detallada.

    Tabla 9. Productores de eventos

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

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

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

    eventoOrganismo gubernamentalextranjero

    El Organismo gubernamental extranjero emite un evento

    Tabla 10. Consumidores de eventos

    Consumidorde eventos Descripcin

    Compaafarmacutica

    La compaa farmacutica se subscribe a los eventos de alertas de salud

    Organismogubernamental

    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, resultenenriquecidos con ms detalles sobre las caractersticas y los patrones de deteccin

    Compaa deseguros desalud

    La compaa de seguros de salud se subscribe a los eventos de alertas de salud

    Agencia denoticias

    La agencia de noticias se subscribe a los eventos de alertas de salud

    Departamentode SeguridadNacional

    El Departamento de Seguridad Nacional se subscribe a los eventos de alertas de salud que,posiblemente, resulten enriquecidos con informacin sobre precauciones especficas ypatrones 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 harcon l) de los consumidores de eventos (que ignoran el origen del evento y la forma original o el significado delevento inicial).

    Aparte de esta relacin entre el Productor de eventos y la EPN y el Consumidor y la EPN, tambin nos podemosimaginar algunos casos en los que los productores hagan que el evento est disponible para todo el mundo (atravs de una pgina web o una fuente) y en los que la EPN recupera esta informacin. Por otro lado, la EPNtambin hace que el evento est disponible (probablemente, mediante los mismos mecanismos) para todos losconsumidores de eventos. Luego de esto, se puede observar una desvinculacin entre el productor y la EPN y elconsumidor y la EPN y tambin se puede considerar la existencia de un escenario desvinculado directo queprescinda de los servicios del intermediario.

  • Tabla 11. Eventos

    ID del tipode evento Tipo de evento Atributos Comentarios

    E1 Alerta de posiblebrote epidmico

    ID; Detalles El evento opuesto es "No hay posibilidad deque exista un brote epidmico"

    E2 Posible broteepidmiconormalizado

    ID; Fecha y hora;Ubicacin; Detalles

    Evento normalizado / transformado desde elevento original

    E3 Posible broteepidmicoenriquecido

    ID; Fecha y hora;Ubicacin; Ms detalles

    Evento enriquecido

    E4 Alerta de broteepidmico detectado

    ID; Fecha y hora;Ubicacin; Detalles

    Se detect un brote epidmico (deteccin depatrn)

    E5 Alerta de broteepidmico

    ID; Fecha y hora;Ubicacin; Detalles

    -

    E6 Alerta de posiblebrote pandmico

    ID; Fecha y hora;Ubicacin; Detalles

    -

    E7 Posible brotepandmiconormalizado

    ID; Fecha y hora;Ubicacin; Detalles

    Se detect un brote epidmico (deteccin depatrones)

    E8 Posible brotepandmicoenriquecido

    ID; Fecha y hora;Ubicacin; Ms detalles

    Evento enriquecido

    E9 Alerta de brotepandmico detectado

    ID; Fecha y hora;Ubicacin; Detalles

    Se detect un brote pandmico (deteccin depatrones)

    E10 Alerta de brotepandmico

    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

    Escenario de un proveedor de servicios de comunicacinA 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.

    Tabla 12. Productores de eventos

    Productorde

    eventos DescripcinMonitor deredes

    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 representancambios notables en los elementos de red y excepciones a la operacin normal.

    Sondas deelementosde red

    Reciben alertas desde los elementos de red y generan eventos que representan cambiosnotables y fallas en los elementos de red y en sus vecinos lgicos y fsicos. Generalmente, usaprotocolos como SNMP para escuchar las alertas.

    Sonda delsistema degestin deelementos

    Recibe alertas desde los Sistemas de Gestin de Elementos que representan fallas y cambiosnotables en los elementos de red que se estn gestionando. Puede usar formatos de eventoestndar o exclusivos en una gran variedad de protocolos estndar o exclusivos (entre los quepodemos incluir SNMP, SOAP, CORBA y archivos planos).

    Panel decontrol deloperadorde eventos

    Produce eventos basados en acciones de operadores (entre las que podemos incluir elreconocimiento, la resolucin y la eliminacin de eventos desde los equipos de red y lasinterrupciones del servicio).

    Tabla 13. Consumidores de eventos

    Consumidor deeventos Descripcin

    Paneles de controlde operadores

    Vista interactiva de eventos significativos para los operadores del Centro deOperaciones de Red (entre los que podemos incluir las herramientas de diagnsticopersonalizables y las capacidades de filtrado).

    Telfonos y sistemade email delIngeniero de Redes

    Reciben mensajes SMS y correos electrnicos que son el resultado de eventos crticosque el sistema hizo escalar

    Vistas de los clientes Vistas actualizadas y de slo lectura de las interrupciones del servicio detectadas en losservicios filtrados para los clientes afectados.

    Sistema TroubleTicket

    Recibe eventos del sistema que requieren la toma de medidas por parte del equipo demantenimiento e ingeniera de redes.

    Tabla 14. Tipos de eventos

    IngresarID Tipo de eventos Atributos Comentarios

    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; Identificadorde tarjeta

    -

  • E4 Evento de causaraz

    Como E3 Copia de E3, identificadacomo causa raz

    E5 Eventossintomticos

    Como E1 y E2; Causa raz asociada Copias de E1 y E2,identificadas comosntomas

    E6 Servicio VPNafectado

    Fecha y hora; Identificador de VPN -

    E7 Servicio VPNafectadoenriquecido

    Como E6; Detalles de contacto del cliente -

    E8 Tcnicodespachado

    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; Identificadorde tarjeta

    -

    E12 Servicio VPNactivo

    Fecha y hora; Identificador de VPN -

    IngresarID Tipo de eventos Atributos Comentarios

    Tabla 15. Agentes de procesamiento de eventos: Ejemplo 1

    Propiedad delagente Especificacin

    ID del agente A2Nombre delagente

    Service Impact Analyzer (Analizador de impacto del servicio)

    Tipo de agente Deteccin de patronesContexto delagente

    -

    Eventos deentrada

    E4, E5

    Especificacindel agente

    Genera un evento afectado por el servicio incluso si el servicio de red del cliente estinterrumpido

    Eventos de salida E6Comentarios delagente

    Usa relaciones modeladas entre elementos de red y servicios aprovisionados paradeterminar si el servicio se ve afectado o no

    Tabla 16. Agentes de procesamiento de eventos: Ejemplo 2

  • Propiedaddel agente Especificacin

    ID del agente A3Nombre delagente

    Customer Impact Analyzer (Analizador de impacto sobre el cliente)

    Tipo deagente

    Ruteo, Enriquecimiento

    Contexto delagente

    -

    Eventos deentrada

    E6

    Especificacindel 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 desalida

    E7

    Comentariosdel agente

    -

    Tabla 17. Agentes de procesamiento de eventos: Ejemplo 3

    Propiedad del agente EspecificacinID del agente A4Nombre del agente Prioritization Module (Mdulo de

    priorizacin)Tipo de agente Ruteo, EnriquecimientoContexto del agente -Eventos de entrada E7Especificacin del agente Enriquece eventos con la prioridad

    relativaRutea eventos hacia los consumidores segn la prioridad -Instiga la toma de acciones correctivas por medio del sistemaTrouble Ticket

    -

    Eventos de salida E4, E5, E7, E8Comentarios del agente -

    La Figura 8 le ofrece una descripcin grfica de la parte de la red de procesamiento de eventos que se usa en elescenario, hasta el momento en el que se despacha el tcnico.

    Figura 8. EPN para el escenario de un proveedor de servicios de comunicacin

  • Arquitectura conceptualLa Arquitectura conceptual se fundamenta en los conceptos de la EPN mediante la definicin de varioscomponentes que se pueden involucrar en una solucin de procesamiento de eventos. Algunos de estoscomponentes son equivalentes a un EPA, o a un conjunto de EPAs conectados, a nivel de la EPN, mientras queotros estn ms relacionados con el flujo de eventos y equivalen a los canales en la EPN. Una de las figuras queincluimos ms adelante en esta seccin, la Figura 11, le muestra cmo la Arquitectura conceptual realiza elmapeo hacia la EPN.

    Todas las arquitecturas de sistema que soportan el procesamiento de eventos de negocios deberan permitir ladefinicin flexible de la lgica de procesamiento de eventos: deteccin de patrones de eventos, derivacin deeventos nuevos, transformacin y ruteo desde los productores hasta los consumidores basndose en la lgica denegocios requerida. Por lo tanto, los negocios pueden reaccionar a los cambios, ejecutar los procesos que seanrelevantes e influenciar los procesos que se estn desarrollando basndose en los cambios. Adems, dichadefinicin del procesamiento de eventos debera ser fcil de modificar y se la debera poder implementarrpidamente de acuerdo con las necesidades de negocios (como, por ejemplo, los cambios en los procesos y laspolticas de negocios).

    Para poder comprender cmo se puede derivar este valor de negocios desde los sistemas de procesamiento deeventos, es importante considerar un nivel ms de granularidad que la red de procesamiento de eventos, paraas tener en cuenta componentes que se pueden usar para construir un sistema de procesamiento de eventos ysus interacciones. El resultado de este proceso es lo que denominamos una arquitectura conceptual para lossistemas 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 asociadosy un intermediario: el nivel del Bus de eventos), es necesario que la arquitectura conceptual incluya componentespara 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 deprocesamiento de eventos: un nivel de Event Emitter (Emisor de eventos), para que emita eventos desde losproductores de eventos, un Event Bus (Bus de eventos) y un Event Handler (Administrador de eventos), para quese ocupe de los eventos que consumirn los consumidores de eventos. Esto se ilustra en la Figura 9, quetambin 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 Busde eventos Bus y el Administrador de eventos (o receptor). En la prctica, los eventos que genera un productorde eventos no siempre se pueden compartir de manera inmediata con los consumidores de eventos. Como elproductor de eventos no debera requerir la conciencia de los consumidores de eventos en un sistema deprocesamiento de eventos, suele existir la necesidad de un nivel de middleware entre el productor y elconsumidor. Este nivel de middleware realiza tareas adicionales relacionadas con los eventos y hace que elconsumidor pueda recibir los eventos que le interesan, o sus derivados. El productor no genera todos los eventosen 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 deeventos (router, filtro) puede evaluar la importancia de un evento ordinario, lo que resulta en la generacin de unevento notable nuevo. Adems, un productor de eventos puede optar por no emitir todos los eventos. Losagentes de procesamiento de eventos pueden filtrar y mediar los eventos sin procesar dentro del dominio delproductor.

    De manera similar, no todos los eventos que recibe el consumidor estn listos para usar. Por lo tanto, es posibleque 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 delconsumidor. El consumidor puede optar por ignorar algunos de los eventos que recibe. Los servicios deprocesamiento de eventos cumplen con estos requisitos de procesamiento de eventos anteriores a la publicaciny 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. Todaimplementacin de procesamiento de eventos se debera de poder lograr con este conjunto base decomponentes a nivel conceptual (aunque esto no significa que todos los componentes van a ser necesarios paratodas las implementaciones). De manera similar, no todos los componentes sern necesarios para un escenarioen particular. Como analizaremos ms adelante cuando volvamos a ocuparnos de los escenarios y veamos cmorealizan el mapeo hacia la arquitectura conceptual, en la mayora de los casos, no se usan todos loscomponentes.

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

  • Componentes arquitectnicosEl flujo de eventos en la arquitectura conceptual es de productor a consumidor, y los componentes que figuran enel diagrama de arquitectura conceptual se resumen aqu en dicho orden. La prxima seccin le ofrece unadescripcin ms detallada del flujo de procesamiento en el modelo conceptual. A nivel de la implementacin, losconsumidores de eventos, generalmente, tambin sern productores de eventos. Pero a nivel conceptual, losroles de los consumidores y los productores son diferentes.

    Productor de eventos. El productor de eventos emite un evento cuando ocurre (o no ocurre) algo deinters. El productor de eventos no incluye la lgica para manipular eventos. Tampoco incluye ningunalgica de decisin sobre qu emitir en qu momento y los eventos generados podran ser redundantes oirrelevantes. A continuacin, mencionamos algunos ejemplos tpicos de productores de eventos:

    Sensores de eventos, que detectan situaciones (cosas que ocurren) y generan eventos sinprocesar u originan eventos a partir de flujos de datos o de flujos de negocios. Un ejemplo de estosera 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 (porejemplo, durante los hitos o los puntos de control) o cuando se llega a (o se inicia) una tarea de unproceso especfico.Servicios y aplicaciones, que producen eventos en puntos clave del procesamiento (como, porejemplo, 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 elproductor de eventos y es responsable de convertir y empaquetar eventos sin procesar de los productorespara entregarlos al Bus de eventos. El Emisor de eventos puede incluir un Event Instantiator (Instanciadorde eventos), que crea las instancias de eventos, Servicios de procesamiento de eventos simples, como elfiltrado y la mediacin de eventos emitidos por un solo productor, lo que enriquece el evento coninformacin 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 necesariohacer algo) para hacer que est disponible para ms tareas de procesamiento o para su entrega, lo quepuede incluir la agregacin, el cacheo y la serializacin de eventos. Es posible que sea necesario que elinstanciador de eventos manipule el encabezado del evento para incrustar "metadatos semnticos" en elmensaje del evento y as hacerlo autodescriptivo (con informacin como, por ejemplo, hora, fecha, tipo deinstrumento, ID del proceso, etc.). El Emisor de eventos puede realizar la optimizacin mediante elprocesamiento simple de eventos en esta etapa en vez de luego de que los eventos lleguen al Bus deeventos. Los adaptadores de eventos puede ofrecer el formateo y la conversin de protocolo del eventopara crear algo que lo recibir la red de procesamiento de eventos (como, por ejemplo, la contencin deregistros de eventos como mensajes de evento y el envo de los mensajes de evento hacia el Bus deeventos).Bus de eventos. El bus de eventos recibe eventos (posiblemente, en gran volumen) de los emisores deeventos e invoca consumidores por medio de administradores de eventos como un resultado de loseventos. Entre las capacidades de un bus de eventos, podemos mencionar el procesamiento para producirun menor volumen de eventos ms informativos a partir de los eventos entrantes. Los componentes delBus de eventos no tienen que estar coubicados. La prxima subseccin le ofrece ms detalles sobre elBus de eventos.Administrador de eventos. Este componente prepara los eventos del Bus de eventos para el consumo porparte de los consumidores de eventos, recibiendo eventos y decidiendo cmo reaccionar ante ellos. Eladministrador de eventos tiene Adaptadores de eventos para recibir mensajes de eventos desde el bus deeventos y separarlos para obtener registros de eventos. El administrador de eventos tambin puedeofrecer Servicios de procesamiento de eventos simples, que se ocupan del procesamiento por parte delconsumidor para filtrar y mediar los eventos recibidos del Bus de eventos. Los Administradores de eventostambin pueden determinar el / los consumidor(es) apropiados para reaccionar ante un evento e invocarel / los consumidor(es) con un contexto derivado del evento. Por ltimo, un Administrador de eventos lepuede ofrecer servicios de orquestacin de eventos para gestionar la distribucin de eventos entre losconsumidores.Consumidor de eventos. El consumidor de eventos realiza tareas en reaccin a un evento. Al consumidorde eventos no le incumbe el origen del evento y slo sabe que se lo invoca como resultado del eventojunto con el contexto relativo al evento en cuestin. A continuacin, mencionamos algunos ejemplostpicos de consumidores de eventos:

    Activadores de eventos, que se los invoca para que realicen tareas fsicas (como, por ejemplo, laoperacin de vlvulas, interruptores o alarmas).Paneles de control del operador, que visualizan informacin sobre el comportamiento de lossistemas de TI y los servicios afectados.Paneles de control de negocios, que visualizan informacin sobre el comportamiento de losprocesos 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 sistemasexternos 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 unparticipante 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 estiloPublicar/Subscribir.

    Se puede considerar a la arquitectura conceptual como "anidada", ya que un participante podra incluir una redde componentes adicionales. Por ejemplo: Un productor de eventos podra emitir un evento y enviarlo hacia elbus 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 conotros eventos en un "mini" bus de eventos, que resida lgicamente dentro del productor de eventos general.

    Componentes del bus de eventosEl bus de eventos transmite eventos desde los productores hasta los consumidores y puede ofrecerle serviciosadicionales para el procesamiento y el ruteo de eventos. El bus de eventos puede tener un registro de eventosasociado y la capacidad de realizar el almacenamiento transaccional de eventos en desarrollo (pasajeros opersistentes) usando un repositorio de eventos.

    El bus de eventos puede ser local o implementarse a nivel de la empresa, y es necesario que los eventosrecibidos se procesen basndose en los requisitos de negocios. Esto se logra usando servicios simples ycomplejos de procesamiento de eventos. Agentes de procesamiento de eventos, que estn conectados pormedio 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, porejemplo, permitir que los Administradores de eventos encuentren los canales apropiados y se subscribanpara recibir eventos de dichos canales).Servicios de notificacin, para notificar a los Administradores de eventos subscriptos cuando los eventosestn 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. Porejemplo, para controlar la autorizacin para agregar y eliminar eventos del bus de eventos, al igual que laprivacidad y la no repudiacin de los contenidos de los eventos.Servicios de procesamiento de eventos, que ofrecen el filtrado, la transformacin y el enriquecimiento deeventos, y que tambin pueden ofrecer la comparacin de patrones y la derivacin de eventos. Estopuede incluir el procesamiento de eventos complejos, que procesa eventos desde mltiples fuentes ypuede 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 organizarcanales con el objetivo de organizar los metadatos del tipo de evento (la sintaxis y la semntica) yalmacenar los datos del evento de manera alternativa en un formato relacional en vez de usando unapersistencia 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 lasrelaciones entre los eventos.Un Repositorio de eventos, para almacenar eventos y as ofrecer una persistencia de eventos a mediano oa largo plazo.

    A continuacin, se enumeran los tipos de funciones ms importantes que el procesamiento debe ofrecer dentrodel 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 desdemltiples fuentes posibles.Validacin: Funcin que le ofrece validacin segn los criterios requeridos.Deteccin de patrones: Funcin que reconoce patrones reales y retrospectivos (una combinacin demltiples eventos que caracterizan una situacin de negocios importante).Filtrado: Funcin sin estado que filtra eventos basndose en sus contenidos (es decir, la informacin quetransporta 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 subscripcino decisiones de ruteo "inteligentes").

    La arquitectura conceptual tambin incluye los Event Governance and Security Services (Servicios de seguridady gobernabilidad de eventos) para gestionar y controlar el ciclo de vida de los eventos y los metadatos de loseventos. Event Monitoring and Analytic Infrastructure (Monitoreo de eventos e infraestructura analtica) esnecesario principalmente para tareas administrativas, para notificar sobre fallos en la infraestructura del evento ypara reunir y visualizar informacin estadstica sobre el flujo de eventos. Estas capacidades deben abarcar latotalidad 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 elbus de eventos, donde se los puede procesar y los consumidores de eventos terminan consumindolos. Comoresultado de un evento, un consumidor puede producir otro evento o reaccionar de otra forma con otrocomponente 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 queofrecen servicios de canal de eventos.

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

  • Flujo de procesamiento en la arquitectura conceptualEl propsito de esta subseccin consiste en describir el Modelo conceptual en accin. Existen tres fases quedebemos considerar:

    Fase de emisin del eventoFase de procesamiento del eventoFase de consumo del evento

    No se trata de un flujo de procesamiento nico y consistente y existe muy poco acoplamiento entre estas tresfases (en especial, cuando se trata del procesamiento de eventos complejos; en cuyo caso, las tres fases puedenocurrir en perodos de tiempo completamente diferentes y slo existe una relacin de causa y efecto entre elevento emitido y el evento consumido).

    Para poder ofrecerle ejemplos concretos, esta seccin se refiere a los escenarios que se describen en msdetalle en otras secciones.

    Fase de emisin del eventoLos componentes de la Arquitectura conceptual involucrados en esta fase son, principalmente, los componentesdel 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, aunquetambin se pueden orientar a los negocios; es decir que se puede llegar a implementar una lgica deprocesamiento 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 deevento al Bus de eventos usando su nivel local de Emisor de eventos. El subnivel de Instanciador de eventos esun componente tcnico a cargo de detectar esta situacin de negocios especfica y de reunir toda la informacinnecesaria. Luego de esto, los Servicios locales de procesamiento de eventos pueden procesar la informacinpara 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 eventoal Bus de eventos, que se encarga de adaptar el mensaje de evento de acuerdo con los protocolos de transporteque soporta el Bus de eventos.

    Ejemplo: En el escenario de gestin de una flota, consideramos el Sistema de entrega y, en especial, elsubsistema de despacho de vehculos como el Proveedor de eventos. Asumamos que el subsistema dedespacho 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 elconductor o el vehculo a cargo de la entrega en cuestin se modifican en esta aplicacin. Se implementa elInstanciador de eventos como un disparador en la Tabla que almacena los datos de entrega. Este disparador seactiva cada vez que se actualiza una instancia de entrega en la Tabla. Este disparador implementa los servicioslocales de procesamiento de eventos. Adems, valida que la actualizacin se relacione con una modificacin delvehculo o el conductor a cargo de la entrega. Si esta prueba resulta exitosa, la lgica de activacin rene toda lainformacin 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 deeventos de Cambio en la entrega. Se implementa el subnivel de Adaptador de eventos usando un adaptadorJDBC, a cargo de analizar esta Tabla y de iniciar la lgica externa de procesamiento de eventos a nivel del Busde eventos.

    Perspectiva de negocios

    En implementaciones ms avanzadas, el nivel de Emisor de eventos puede soportar patrones de deteccin deeventos 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 eventoselementales 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 yal 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 maneracontinua, ya que se los vincula con una infeccin especfica. La ocurrencia de esta situacin es un eventoelemental. Para detectar un Posible brote epidmico, es necesario comparar (localmente en el hospital) varioseventos elementales similares que afectan a muchos pacientes y durante un perodo de tiempo limitado. Por lotanto, el Instanciador de eventos y los servicios locales de Procesamiento de eventos implementan un Agente deprocesamiento 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 dela Red de Procesamiento de Eventos.

    Fase de procesamiento del eventoEsta fase se lleva a cabo en el Bus de eventos. Pueden existir diferentes flujos de procesamiento, que involucrendiferentes 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 anivel del Bus de Eventos, el subnivel de los Servicios de Publicacin lo intercepta y lo distribuye entre losdiversos Canales configurados por el Administrador del bus de eventos. Estos Canales se publican en el Registrode eventos, para que estn disponibles para los Consumidores de Eventos o el componente de Servicios deSubscripcin. Los consumidores de eventos acceden al Registro de eventos para obtener informacin sobre losCanales 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 Panelde Control de gestin de la entrega como un Consumidor de Eventos. Cada vez que el Bus de eventos detectaun evento de Cambio en la Entrega, se hace que el mensaje de evento relacionado est disponible en un Canalde Eventos especfico. El Panel de Control de gestin de la entrega escucha a este canal. Cuando se recibe unmensaje de evento nuevo, el Panel de control de gestin de la entrega lo procesa usando su Administrador localde 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 formatosdiferentes, dependiendo de su carga til y las solicitudes de subscripcin expresadas para l. Los Consumidoresde 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 selos 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 notificacinCanal por medio del que se recibir este mensajeCriterios de filtrado de eventos

    Cuando se recibe un evento de mensaje en el Bus de eventos, el subnivel de Servicios de publicacin procesacada solicitud individual de subscripcin para este tipo de evento. Los servicios necesarios de procesamiento deeventos 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 eventoresultante 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 deEventos y al evento de "Posible alerta de brote epidmico" que emite. El Mdico clnico se subscribe a loseventos de alerta de salud, ya que desea recibir notificaciones en su casilla de correo electrnico cada vez quese genere una alerta de Posible brote epidmico en su rea de trabajo especfica. Adems, tambin deseaobtener informacin adicional sobre la enfermedad relacionada. Los servicios de subscripcin del bus de eventosdeberan ofrecer ciertas facilidades que le permitan navegar por la lista de alertas disponibles para colocar unfiltro en la ubicacin geogrfica, para elegir los datos adicionales que le puedan llegar a interesar y paraseleccionar su canal de entrega preferido. El Bus de Eventos usar estos parmetros para filtrar los eventosentrantes de alerta de Posible brote epidmico con el objetivo de enriquecerlos con toda la informacin adicionalsolicitada y para darle formato de correo electrnico con el objetivo de enviarla al consumidor a travs de losServicios de notificacin.

    Procesamiento de mltiples eventos entrantes

    En este caso, se considera la existencia de mltiples eventos entrantes, que posiblemente abarcan diferentestipos y fueron emitidos por diferentes sectores durante un perodo de tiempo determinado, al que se denomina unconjunto 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 Eventosimplementa uno o varios Agentes de procesamiento de eventos a cargo de realizar esta deteccin. Eladministrador del Bus de eventos ya habr configurado uno o varios patrones (posiblemente, usando losServicios de Subscripcin o los Servicios de Gestin de Informacin de Eventos) y los habr almacenado en elRegistro de Eventos. Estos patrones pueden abarcar mltiples dimensiones (entre las que podemos incluir lacausalidad, la hora, la ubicacin y muchas otras). Cuando se recibe un evento, se pueden usar los Servicios deconsulta de eventos para controlar con el Registro de Eventos si pertenece o no a un conjunto de eventosasociado con reglas vlidas de comparacin de patrones. De ser as, el subnivel de Servicios de Procesamientode 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 recibidopor lo menos un evento del mismo conjunto de eventos, o se podra iniciar un flujo de procesamiento nuevo sitodava 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 patronescrea un Flujo de Procesamiento de Eventos. El perodo de tiempo suele ser una caracterstica importante delconjunto de eventos. Adems, la hora tambin es un factor importante al momento de considerar laimplementacin 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, enel caso del procesamiento de eventos complejos). ste conserva el registro de los eventos procesados en Flujosde 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 deeventos produjo este resultado?).En segundo lugar, como es posible considerar a un conjunto de eventos durante un perodo de tiempoprolongado, quiz resulte necesario persistir los eventos relacionados.

    Ejemplo: En el escenario de gestin de la flota, consideremos el agente denominado "El conductor excedi eltiempo de manejo permitido" y los eventos asociados: "El conductor comienza a trabajar" y "El conductor terminade trabajar". Estos dos tipos de evento y un perodo de tiempo de ms de 8 horas caracterizan al Conjunto deEventos. Cada vez que se recibe un evento "El conductor comienza a trabajar" a nivel del Bus de eventos parauna ID del conductor especfica, se debera iniciar un EPA para que espere un evento "El conductor termina detrabajar" correspondiente a la misma ID del conductor. Si este evento ocurre ms de ocho horas despus delevento 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, comoConsumidor del evento, consideremos al agente "Comparar alertas de posible brote epidmico". El tipo de eventodenominado Alerta de posible brote epidmico y un perodo de tiempo de 2 semanas caracterizan al Conjunto deEventos. Cada vez que el Bus de eventos recibe un mensaje de evento de este tipo, se lo transfiere a un EPAque implementa la lgica de comparacin de patrones del agente. Por ejemplo: Si se recibe una Alerta de posiblebrote epidmico de diez fuentes diferentes en menos de dos semanas, se debera generar una Alerta de brotepandmico.

    Fase de consumo del eventoEsta fase se lleva a cabo, principalmente, en el nivel de Administrador de Eventos asociado con el Consumidordel evento. Al igual que en el caso de la fase de emisin del evento, este nivel puede cumplir un rol tcnico uorientado 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 derecibir el mensaje de evento y crear una interfaz con los proto