Arquitectura impulsada por eventos

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

Esta sección puede resultar confusa o poco clara para los lectores . En particular, algunos términos no son claros para los nuevos en EDA. Por favor ayude a aclarar la sección . Puede haber una discusión sobre esto en la página de discusión . ( Julio de 2013 ) ( Obtenga información sobre cómo y cuándo eliminar este mensaje de plantilla )

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 maneras 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 simple de eventos

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

Java Swing

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  listeners  =  this . eventos . obtener ( evento);  if  ( oyentes )  {  oyentes . eliminar ( oyente );  }  }  devuelve  esto ;  } emit(event, ...args) { const listeners = this.events.get(event); if (listeners) { for (let listener of listeners) { listener.apply(this, args); } } return this; } } this.EventEmitter = EventEmitter;})();

Usage:

const events = new EventEmitter();events.on('foo', () => { console.log('foo'); });events.emit('foo'); // Prints "foo"events.off('foo');events.emit('foo'); // Nothing will happen

See also

• Event-driven programming
• Process Driven Messaging Service
• Service-oriented architecture
• Event-driven SOA
• Space-based architecture
• Complex event processing
• Event stream processing
• Event Processing Technical Society
• Staged event-driven architecture (SEDA)
• Reactor pattern
• Autonomous peripheral operation

Articles

• Article defining the differences between EDA and SOA: How EDA extends SOA and why it is important by Jack van Hoof.
• Real-world example of business events flowing in an SOA: SOA, EDA, and CEP - a winning combo by Udi Dahan.
• Article describing the concept of event data: Analytics for hackers, how to think about event data by Michelle Wetzler. (Web archive)

References

1. K. Mani Chandy Event-Driven Applications: Costs, Benefits and Design Approaches, California Institute of Technology, 2006
2. Martin Fowler, Event Sourcing, December, 2005
3. Martin Fowler, Parallel Model, December, 2005
4. Hanson, Jeff (January 31, 2005). "Event-driven services in SOA". JavaWorld. Retrieved 2020-07-21.
5. Sliwa, Carol (May 12, 2003). "Event-driven architecture poised for wide adoption". Computerworld. Retrieved 2020-07-21.
6. Brenda M. Michelson, Event-Driven Architecture Overview, Patricia Seybold Group, February 2, 2006
7. "Online Event Processing - ACM Queue". queue.acm.org. Retrieved 2019-05-30.
8. Hasan, Souleiman, Sean O’Riain, and Edward Curry. 2012. “Approximate Semantic Matching of Heterogeneous Events.” In 6th ACM International Conference on Distributed Event-Based Systems (DEBS 2012), 252–263. Berlin, Germany: ACM. “DOI”.

External links

• Event-Driven Applications: Costs, Benefits and Design Approaches
• Industry website on Complex Event Processing & Real Time Intelligence
• Website for the Event Processing Technical Society
• 5th Anniversary Edition: Event-Driven Architecture Overview, Brenda M. Michelson
• Complex Event Processing and Service Oriented Architecture
• How EDA extends SOA and why it is important by Jack van Hoof
• How to implement event-driven architecture (with RabbitMQ specifics)
• Event-Driven Architecture, Events and Async APIs. What the fork?
• CloudEvents: An Open Source specification for describing event data in a common way