La arquitectura impulsada por eventos ( EDA ) es un paradigma de arquitectura de software que promueve la producción, detección, consumo y reacción a eventos .
Un evento puede definirse como "un cambio significativo de estado ". [1] Por ejemplo, cuando un consumidor compra un automóvil, el estado del automóvil cambia de "a la venta" a "vendido". La arquitectura del sistema de un concesionario de automóviles puede tratar este cambio de estado como un evento cuya ocurrencia puede darse a conocer a otras aplicaciones dentro de la arquitectura. Desde una perspectiva formal, lo que se produce, publica, propaga, detecta o consume es un mensaje (típicamente asíncrono) llamado notificación de evento, y no el evento en sí, que es el cambio de estado que desencadenó la emisión del mensaje. Los eventos no viajan, simplemente ocurren. Sin embargo, el término evento se usa a menudo metonímicamentepara indicar el mensaje de notificación en sí, lo que puede generar cierta confusión. Esto se debe a que las arquitecturas impulsadas por eventos a menudo se diseñan sobre arquitecturas impulsadas por mensajes , donde dicho patrón de comunicación requiere que una de las entradas sea solo de texto, el mensaje, para diferenciar cómo se debe manejar cada comunicación.
Este patrón arquitectónico se puede aplicar mediante el diseño y la implementación de aplicaciones y sistemas que transmiten eventos entre servicios y componentes de software débilmente acoplados . Un sistema impulsado por eventos generalmente consta de emisores (o agentes) de eventos, consumidores (o receptores) de eventos y canales de eventos. Los emisores tienen la responsabilidad de detectar, recopilar y transferir eventos. Un emisor de eventos no conoce a los consumidores del evento, ni siquiera sabe si existe un consumidor y, en caso de que exista, no sabe cómo se utiliza o procesa el evento. Los lavabos tienen la responsabilidad de aplicar una reacción tan pronto como se presente un evento. La reacción puede o no ser proporcionada completamente por el propio fregadero. Por ejemplo, el sumidero podría tener la responsabilidad de filtrar, transformar y reenviar el evento a otro componente o podría proporcionar una reacción autónoma a dicho evento. Los canales de eventos son conductos en los que los eventos se transmiten desde los emisores de eventos a los consumidores de eventos. El conocimiento de la correcta distribución de los eventos está presente exclusivamente dentro del canal de eventos. [ cita requerida ] La implementación física de los canales de eventos puede basarse en componentes tradicionales como el middleware orientado a mensajes o la comunicación punto a punto, que podrían requerir un marco ejecutivo transaccional más apropiado [ aclarar ] .
La construcción de sistemas alrededor de una arquitectura impulsada por eventos simplifica la escalabilidad horizontal en modelos de computación distribuida y los hace más resistentes a fallas. Esto se debe a que el estado de la aplicación se puede copiar en varias instantáneas paralelas para lograr una alta disponibilidad. [2] Los nuevos eventos se pueden iniciar en cualquier lugar, pero lo que es más importante, se propagan a través de la red de almacenes de datos actualizando cada uno a medida que llegan. Agregar nodos adicionales también se vuelve trivial: simplemente puede tomar una copia del estado de la aplicación, alimentarla con un flujo de eventos y ejecutarla. [3]
La arquitectura impulsada por eventos puede complementar la arquitectura orientada a servicios (SOA) porque los servicios pueden activarse mediante desencadenantes que se disparan en eventos entrantes. [4] [5] Este paradigma es particularmente útil cuando el sumidero no proporciona ningún ejecutivo autónomo [ aclarar ] .
SOA 2.0 evoluciona las implicaciones que brindan las arquitecturas SOA y EDA a un nivel más rico y robusto al aprovechar relaciones causales previamente desconocidas para formar un nuevo patrón de eventos. [ vago ] Este nuevo patrón de inteligencia empresarial desencadena un procesamiento humano o automatizado más autónomo que agrega valor exponencial a la empresa al inyectar información de valor agregado en el patrón reconocido que no se podría haber logrado anteriormente. [ vago ]
Estructura del evento
Un evento puede constar de dos partes, el encabezado del evento y el cuerpo del evento. El encabezado del evento puede incluir información como el nombre del evento, la marca de tiempo del evento y el tipo de evento. El cuerpo del evento proporciona los detalles del cambio de estado detectado. El cuerpo de un evento no debe confundirse con el patrón o la lógica que se puede aplicar en reacción a la ocurrencia del evento en sí.
Capas de flujo de eventos
Una arquitectura impulsada por eventos puede construirse en cuatro capas lógicas, comenzando con la detección de un evento (es decir, un estado o hecho temporal significativo), procediendo a la creación de su representación técnica en la forma de una estructura de evento y terminando con una no -conjunto vacío de reacciones a ese evento. [6]
Generador de eventos
La primera capa lógica es el generador de eventos, que detecta un hecho y lo representa como un mensaje de evento. Por ejemplo, un generador de eventos podría ser un cliente de correo electrónico, un sistema de comercio electrónico, un agente de monitoreo o algún tipo de sensor físico.
Convertir los datos recopilados de un conjunto tan diverso de fuentes de datos en una única forma estandarizada de datos para la evaluación es una tarea importante en el diseño e implementación de esta primera capa lógica. [6] Sin embargo, considerando que un evento es un marco fuertemente declarativo, cualquier operación informativa se puede aplicar fácilmente, eliminando así la necesidad de un alto nivel de estandarización. [ cita requerida ]
Canal de eventos
Esta es la segunda capa lógica. Un canal de eventos es un mecanismo de propagación de la información recopilada de un generador de eventos al motor de eventos [6] o sumidero. Puede ser una conexión TCP / IP o cualquier tipo de archivo de entrada (plano, formato XML, correo electrónico, etc.). Se pueden abrir varios canales de eventos al mismo tiempo. Por lo general, debido a que el motor de procesamiento de eventos tiene que procesarlos casi en tiempo real, los canales de eventos se leerán de forma asincrónica. Los eventos se almacenan en una cola, a la espera de ser procesados más tarde por el motor de procesamiento de eventos.
Motor de procesamiento de eventos
El motor de procesamiento de eventos es la capa lógica responsable de identificar un evento y luego seleccionar y ejecutar la reacción adecuada. También puede desencadenar una serie de afirmaciones. Por ejemplo, si el evento que entra en el motor de procesamiento de eventos es un ID de producto con pocas existencias, esto puede desencadenar reacciones como “Solicitar ID de producto” y “Notificar al personal”. [6]
Actividad impulsada por eventos descendentes
Esta es la capa lógica donde se muestran las consecuencias del evento. Esto se puede hacer de muchas formas y formas diferentes; por ejemplo, se envía un correo electrónico a alguien y una aplicación puede mostrar algún tipo de advertencia en la pantalla. [6] Dependiendo del nivel de automatización proporcionado por el sumidero (motor de procesamiento de eventos), es posible que la actividad posterior no sea necesaria.
Estilos de procesamiento de eventos
Hay tres estilos generales de procesamiento de eventos: simple, continuo y complejo. Los tres estilos se utilizan a menudo juntos en una arquitectura madura impulsada por eventos. [6]
Procesamiento de eventos simple
El procesamiento de eventos simple se refiere a eventos que están directamente relacionados con cambios de condición específicos y mensurables. En el procesamiento de eventos simple, ocurre un evento notable que inicia acciones posteriores. El procesamiento de eventos simple se usa comúnmente para impulsar el flujo de trabajo en tiempo real, lo que reduce el tiempo de retraso y el costo. [6]
Por ejemplo, un sensor puede crear eventos simples que detecten cambios en la presión de los neumáticos o en la temperatura ambiente. La presión incorrecta de la llanta del automóvil generará un evento simple del sensor que activará una luz amarilla que informa al conductor sobre el estado de una llanta.
Procesamiento de flujo de eventos
En el procesamiento de flujo de eventos (ESP), ocurren eventos ordinarios y notables. Los eventos ordinarios (pedidos, transmisiones RFID) se examinan para determinar su notoriedad y se transmiten a los suscriptores de información. El procesamiento de flujo de eventos se usa comúnmente para impulsar el flujo de información en tiempo real dentro y alrededor de la empresa, lo que permite la toma de decisiones a tiempo. [6]
Procesamiento de eventos complejos
El procesamiento de eventos complejos (CEP) permite considerar patrones de eventos simples y ordinarios para inferir que ha ocurrido un evento complejo. El procesamiento de eventos complejos evalúa una confluencia de eventos y luego toma medidas. Los eventos (notables u ordinarios) pueden cruzar tipos de eventos y ocurrir durante un largo período de tiempo. La correlación de eventos puede ser causal, temporal o espacial. CEP requiere el empleo de intérpretes de eventos sofisticados, definición y comparación de patrones de eventos y técnicas de correlación. CEP se usa comúnmente para detectar y responder a anomalías, amenazas y oportunidades comerciales. [6]
Procesamiento de eventos en línea
El procesamiento de eventos en línea (OLEP) utiliza registros de eventos distribuidos asíncronos para procesar eventos complejos y administrar datos persistentes. [7] OLEP permite componer de manera confiable eventos relacionados de un escenario complejo en sistemas heterogéneos. Por lo tanto, permite patrones de distribución muy flexibles con alta escalabilidad y ofrece una gran consistencia. Sin embargo, no puede garantizar un límite superior al tiempo de procesamiento.
Acoplamiento extremadamente flojo y bien distribuido
Una arquitectura impulsada por eventos está muy poco acoplada y bien distribuida. La gran distribución de esta arquitectura existe porque un evento puede ser casi cualquier cosa y existir en casi cualquier lugar. La arquitectura está muy poco acoplada porque el evento en sí no conoce las consecuencias de su causa. Por ejemplo, si tenemos un sistema de alarma que registra información cuando se abre la puerta principal, la puerta misma no sabe que el sistema de alarma agregará información cuando se abra la puerta, solo que la puerta se ha abierto. [6]
Acoplamiento semántico y más investigación
Las arquitecturas impulsadas por eventos tienen un acoplamiento flexible en el espacio, el tiempo y la sincronización, lo que proporciona una infraestructura escalable para el intercambio de información y los flujos de trabajo distribuidos. Sin embargo, las arquitecturas de eventos están estrechamente acopladas, a través de suscripciones y patrones de eventos, a la semántica de los valores y el esquema de eventos subyacentes. El alto grado de heterogeneidad semántica de los eventos en implementaciones grandes y abiertas, como las ciudades inteligentes y la red de sensores, dificulta el desarrollo y el mantenimiento de sistemas basados en eventos. Para abordar el acoplamiento semántico dentro de los sistemas basados en eventos, el uso de la correspondencia semántica aproximada de eventos es un área activa de investigación. [8]
Implementaciones y ejemplos
Oscilación de Java
La API de Java Swing se basa en una arquitectura impulsada por eventos. Esto funciona particularmente bien con la motivación detrás de Swing para proporcionar componentes y funcionalidad relacionados con la interfaz de usuario. La API utiliza una convención de nomenclatura (por ejemplo, "ActionListener" y "ActionEvent") para relacionar y organizar las preocupaciones del evento. Una clase que necesita ser consciente de un evento en particular simplemente implementa el oyente apropiado, anula los métodos heredados y luego se agrega al objeto que dispara el evento. Un ejemplo muy simple podría ser:
público de clase FooPanel extiende JPanel implementos ActionListener { público FooPanel () { super (); JButton btn = new JButton ( "¡Haz clic en mí!" ); btn . addActionListener ( esto ); esto . añadir ( btn ); } @Override public void actionPerformed ( ActionEvent ae ) { System . fuera . println ( "¡Se ha hecho clic en el botón!" ); } }
Alternativamente, otra opción de implementación es agregar el oyente al objeto como una clase anónima y así usar la notación lambda (desde Java 1.8). A continuación se muestra un ejemplo.
público de clase FooPanel extiende JPanel { público FooPanel () { super (); JButton btn = new JButton ( "¡Haz clic en mí!" ); btn . addActionListener ( ae -> System . out . println ( "¡Se ha hecho clic en el botón!" )); esto . añadir ( btn ); } }
JavaScript
(() => { 'usar estricto' ; class EventEmitter { constructor () { this . eventos = nuevo Mapa (); } en ( evento , oyente ) { si ( typeof oyente ==! 'función' ) { lanzar nuevos TypeError ( 'El oyente debe ser una función' ); } dejar que los oyentes = esto . eventos . obtener ( evento ); if ( ! oyentes ) { oyentes = nuevo Conjunto (); esto . eventos . set ( evento , oyentes ); } oyentes . agregar ( oyente ); devuelve esto ; } off ( evento , oyente ) { if ( ! argumentos . longitud ) { this . eventos . claro (); } else if ( argumentos . longitud === 1 ) { esto . eventos . eliminar ( evento ); } else { const oyentes = esto . eventos . obtener ( evento ); if ( oyentes ) { oyentes . eliminar ( oyente ); } } devuelve esto ; } emit ( evento , ... args ) { const listeners = this . eventos . obtener ( evento ); if ( oyentes ) { para ( deje que el oyente de los oyentes ) { oyente . aplicar ( esto , argumentos ); } } devuelve esto ; } } esto . EventEmitter = EventEmitter ; }) ();
Uso:
eventos const = new EventEmitter (); eventos . on ( 'foo' , () => { consola . log ( 'foo' ); }); eventos . emitir ( 'foo' ); // Imprime eventos "foo" . apagado ( 'foo' ); eventos . emitir ( 'foo' ); // Nada pasará
Ver también
- Programación impulsada por eventos
- Servicio de mensajería basado en procesos
- Arquitectura orientada a Servicios
- SOA impulsada por eventos
- Arquitectura basada en el espacio
- Procesamiento de eventos complejos
- Procesamiento de flujo de eventos
- Sociedad Técnica de Procesamiento de Eventos
- Arquitectura basada en eventos por etapas (SEDA)
- Patrón de reactor
- Operación periférica autónoma
Artículos
- Artículo que define las diferencias entre EDA y SOA: cómo EDA extiende SOA y por qué es importante por Jack van Hoof.
- Ejemplo del mundo real de eventos empresariales que fluyen en una SOA: SOA, EDA y CEP: una combinación ganadora de Udi Dahan.
- Artículo que describe el concepto de datos de eventos: análisis para piratas informáticos, cómo pensar en los datos de eventos por Michelle Wetzler. (Archivo web)
Referencias
- ^ K. Mani Chandy Aplicaciones impulsadas por eventos: costos, beneficios y enfoques de diseño, Instituto de Tecnología de California , 2006
- ^ Martin Fowler, Event Sourcing , diciembre de 2005
- ^ Martin Fowler, Parallel Model , diciembre de 2005
- ^ Hanson, Jeff (31 de enero de 2005). "Servicios impulsados por eventos en SOA" . JavaWorld . Consultado el 21 de julio de 2020 .
- ^ Sliwa, Carol (12 de mayo de 2003). "Arquitectura impulsada por eventos preparada para una amplia adopción" . Computerworld . Consultado el 21 de julio de 2020 .
- ^ a b c d e f g h i j Brenda M. Michelson, Descripción general de la arquitectura impulsada por eventos, Patricia Seybold Group , 2 de febrero de 2006
- ^ "Procesamiento de eventos en línea - Cola de ACM" . queue.acm.org . Consultado el 30 de mayo de 2019 .
- ^ Hasan, Souleiman, Sean O'Riain y Edward Curry. 2012. "Coincidencia semántica aproximada de eventos heterogéneos". En la 6ª Conferencia internacional de ACM sobre sistemas distribuidos basados en eventos (DEBS 2012), 252–263. Berlín, Alemania: ACM. "DOI" .
enlaces externos
- Aplicaciones impulsadas por eventos: costos, beneficios y enfoques de diseño
- Sitio web de la industria sobre procesamiento de eventos complejos e inteligencia en tiempo real
- Sitio web de la Sociedad Técnica de Procesamiento de Eventos
- Edición del quinto aniversario: Descripción general de la arquitectura impulsada por eventos, Brenda M. Michelson
- Procesamiento de eventos complejos y arquitectura orientada a servicios
- Cómo EDA extiende SOA y por qué es importante por Jack van Hoof
- Cómo implementar una arquitectura impulsada por eventos (con las especificaciones de RabbitMQ)
- Arquitectura impulsada por eventos, eventos y API asíncronas. ¿Qué diablos?
- CloudEvents: una especificación de código abierto para describir datos de eventos de una manera común