Arquitectura dirigida por eventos

La arquitectura dirigida por eventos (en inglés: event-driven architecture, abreviado EDA) es un paradigma de arquitectura de software orientado a la producción y detección de eventos.

Las arquitecturas dirigidas por eventos son de naturaleza evolutiva y proporcionan un alto grado de tolerancia a fallos, rendimiento y escalabilidad. Sin embargo, son complejas e inherentemente difíciles de probar. Las EDA son una buena solución para cargas de trabajo complejas y dinámicas.

Visión general

Un evento puede ser definido como "un cambio significativo de estado".^[1] Por ejemplo, cuando un consumidor compra un coche, el estado del coche pasa de "en venta" a "vendido". La arquitectura del sistema del vendedor de coches debe tratar este cambio de estado como un evento cuya ocurrencia puede darse a conocer a otras aplicaciones en la misma arquitectura. Desde una perspectiva formal, lo que es producido, publicado, propagado, detectado o consumido es un mensaje (típicamente asíncrono) denominado notificación del evento, y no el evento en sí mismo, que es el cambio de estado que disparó la emisión del mensaje. Los eventos no viajan, solamente ocurren. Por otro lado, el término evento se utiliza habitualmente de forma metonímica para denotar el mensaje de notificación en sí mismo, lo cual puede llevar a algún tipo de confusión. Esto se debe a que las arquitecturas dirigidas por eventos suelen estar diseñadas sobre arquitecturas dirigidas por mensajes, donde este patrón de comunicación requiere que una de las entradas sea exclusivamente en forma de texto, el mensaje, para diferenciar la manera en que debe manejarse cada comunicación.

Se puede aplicar este patrón arquitectónico a través del diseño y de la implementación de aplicaciones y sistemas que transmiten eventos entre componentes de software débilmente acoplados y servicios. Un sistema dirigido por eventos está compuesto típicamente de emisores de eventos (o agentes), consumidores de eventos (o sumideros, sinks en inglés) y canales de eventos.

Los emisores tienen la responsabilidad de detectar, recolectar y transferir eventos. Un emisor de eventos no conoce los consumidores del evento, de hecho, ni siquiera sabe si existe algún consumidor del evento, y, en caso de que exista, no sabe cómo se va a utilizar o procesar ulteriormente el evento.
Los consumidores tienen la responsabilidad de llevar a cabo una reacción tan pronto como el evento esté presente. La reacción puede o no puede ser completamente proporcionada por el consumidor en sí mismo. Por ejemplo, el consumidor debe tener solamente la responsabilidad de filtrar, transformar y reenviar el evento a otro componente o debe proporcionar una reacción propia a algún evento, o puede proporcionar una reacción autocontenida al mismo.
Los canales de eventos son conductos por los que los eventos son transmitidos de los emisores a los consumidores. El conocimiento de la correcta distribución de eventos está exclusivamente presente en el canal.^{[cita requerida]} La implementación física de los canales de eventos puede estar basada en componentes tradicionales como el middleware orientado a mensajes o en la comunicación punto a punto.

Construir aplicaciones y sistemas en torno a una arquitectura dirigida por eventos simplifica la escalabilidad horizontal en los modelos de computación distribuida y los hace más resilientes frente a fallos. Esto se debe a que el estado de la aplicación se puede copiar en varias instantáneas para asegurar una alta disponibilidad.^[2] Se pueden iniciar eventos nuevos en cualquier lugar, pero, lo que es más importante, se pueden propagar por la red de almacenes de datos actualizando cada uno a medida que llegan. Añadir nuevos nodos también resulta trivial: basta con tomar una copia del estado de la aplicación, alimentarla con un flujo de eventos y ejecutarla.^[3]

La arquitectura dirigida por eventos puede complementar la arquitectura orientada a servicios (SOA) porque los servicios pueden ser activados por disparadores que se encuentran en eventos entrantes.^[4]^[5] Este paradigma es particularmente útil cuando el consumidor no proporciona ninguna ejecutiva autocontenida.^{[aclaración requerida]}

SOA 2.0 engloba las implicaciones de las arquitecturas SOA y EDA proporcionando a un nivel más rico y robusto al aprovechar relaciones causales desconocidas para formar un nuevo patrón de eventos.^{[aclaración requerida]} Este nuevo patrón de inteligencia empresarial desencadena un mayor procesamiento humano o automatizado que aporta un mayor valor a la empresa al inyectar información de valor añadido en el patrón reconocido, lo que no se habría podido lograr anteriormente.^{[aclaración requerida]}^{[cita requerida]}

Estructura de un evento

Un evento puede componerse de dos partes, el encabezado (header) y el cuerpo o carga útil (body, payload). El encabezado de evento puede incluir información como el nombre del evento, el tipo de evento y la marca de tiempo. La carga útil del evento es la parte que describe el cambio de estado que se ha producido. El cuerpo del evento no se debe confundir con el patrón o la lógica que se puede aplicar en reacción a la ocurrencia del evento en sí.

Capas del flujo del evento

Una arquitectura dirigida por eventos se puede construir sobre cuatro capas lógicas. Se inicia con la detección de un hecho, su representación técnica mediante una estructura de evento y termina con un conjunto no 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 representa el mismo con 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 o algún tipo de sensor.

Convertir los diversos datos recogidos por los sensores en una sola estructura estandarizada de datos que se pueda evaluar es una tarea importante en el diseño e implementación de esta primera capa lógica.^[6] Sin embargo, teniendo en cuenta que un evento es un marco muy declarativo, se puede aplicar fácilmente cualquier operación de transformación, 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 evento es un mecanismo mediante el cual se transfiere la información desde un generador de eventos hasta el motor de eventos^[6] o consumidor. Esto podría ser una conexión TCP/IP o cualquier tipo de archivo de entrada (texto plano, formato XML, correo electrónico, etc.). Varios canales de eventos pueden estar abiertos al mismo tiempo. Por lo general, debido a que el motor de procesamiento de eventos tiene que procesar casi en tiempo real, los canales de eventos se pueden leer de forma asíncrona. Los eventos son almacenados en una cola, en espera de ser procesados posteriormente 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 el evento y ejecutar la reacción adecuada. Esto también puede desencadenar una serie de aserciones. Por ejemplo, si el evento que entra en el motor de procesamiento de eventos es el identificador de un producto con pocas existencias, esto puede desencadenar reacciones tales como, "Pedir ID del producto al proveedor" y "Notificar al personal".^[6]

Actividad de descarga dirigida por eventos

Esta es la capa lógica donde se muestran las consecuencias del suceso. 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 consumidor (el motor de procesamiento de eventos), puede que la actividad en el flujo descendente no sea necesaria.

Estilos de procesamiento de evento

Hay tres estilos generales de procesamiento de eventos: simple, flujo, y complejo. Los tres estilos se utilizan a menudo juntos en una arquitectura madura orientada a eventos.^[6]

Procesamiento de eventos simples

El procesamiento de eventos simples concierne los eventos que están directamente relacionados con cambios de condición específicos y medibles. En el procesamiento de eventos simples, tiene lugar un evento notable que inicia una o más acciones descendentes. Se utiliza habitualmente para conducir el flujo de trabajo en tiempo real, reduciendo así el tiempo de retardo y el coste.^[6]

Por ejemplo, los eventos simples pueden ser creados por un sensor que detecte cambios en la presión de los neumáticos o en la temperatura ambiente. Al detectar el sensor una presión incorrecta en los neumáticos, genera un evento simple que provoca que se encienda una luz amarilla que avise al conductor del estado de los neumáticos.

Procesamiento de flujos de eventos

En el procesamiento de flujos de eventos, tienen lugar tanto eventos ordinarios como eventos notables. Los eventos ordinarios (como los pedidos o las transmisiones RFID) son examinados para detectar su notabilidad y transmitidos a los suscriptores de información. El procesamiento de flujos de eventos se utiliza habitualmente para conducir el flujo de la 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 permite considerar patrones de eventos simples y ordinarios para inferir que se ha producido un evento complejo. El procesamiento de eventos complejos evalúa una confluencia de eventos y luego entra en acción. Los eventos (notables u ordinarios) pueden cruzar distintos tipos de eventos y pueden producirse a lo largo de un largo período de tiempo. La correlación de eventos puede ser causal, temporal o espacial.

El procesamiento de eventos complejos requiere del empleo de sofisticados intérpretes de eventos, definiciones y correspondencias entre patrones de eventos y técnicas de correlación. Se utiliza habitualmente para detectar y responder a las anomalías de negocio, amenazas y oportunidades.^[6]

Procesamiento de eventos en línea

El procesamiento de eventos en línea utiliza registros de eventos asíncronos y distribuidos para procesar eventos complejos y gestionar datos persistentes.^[7] Permite componer con gran fiabilidad eventos de un escenario complejo que implica sistemas heterogéneos, por lo que permite patrones de distribución muy flexibles con alta escalabilidad y ofrece una fuerte consistencia. Sin embargo, no puede garantizar una cota superior en el tiempo de procesamiento.

Acoplamiento extremadamente débil y buena distribución

Una arquitectura orientada a eventos presenta un acoplamiento extremadamente débil y está bien distribuida. La buena distribución se debe a que un evento puede ser casi cualquier cosa y puede existir en casi cualquier lugar. Y el débil acoplamiento se debe a que el evento en sí mismo no sabe nada de las consecuencias de su causa. Por ejemplo, si tenemos un sistema de alarma que registra la información cuando se abre la puerta, la propia puerta no sabe que el sistema de alarma añadirá información cuando se abra la puerta, sino solo que la puerta se ha abierto.^[6]

Acoplamiento semántico

Las arquitecturas basadas en eventos presentan un débil acoplamiento en el espacio, en el tiempo y en la sincronización, proporcionando una infraestructura escalable para el intercambio de información y los flujos de trabajo distribuidos. Sin embargo, presentan un acoplamiento fuerte, mediante las suscripciones y los patrones de eventos, a la semántica del esquema de eventos subyacente y sus valores. El alto grado de heterogeneidad semántica en despliegues abiertos y de gran tamaño, como las ciudades inteligentes y la red de sensores hace que sea difícil desarrollar y mantener sistemas basados en eventos. Para poder abordar la problemática del acoplamiento semántico en los sistemas basados en eventos, el uso de correspondencias semánticas aproximadas de eventos es un área activa de investigación.^[8]

Ventajas y desventajas

Ventajas

Simplicidad
Evolución: se pueden reemplazar componentes suscriptores
Modularidad: una sola modalidad para eventos diversos
Puede mejorar la eficiencia, eliminando la necesidad de polling por ocurrencia de evento

Desventajas

Posibilidad de desborde
Potencial imprevisión de escalabilidad
Pobre comprensibilidad: Puede ser difícil prever qué pasará en respuesta a una acción
No hay garantía del lado del publicador, que el suscriptor responderá al evento
No hay mucho soporte de recuperación en caso de falla parcial

Implementaciones y ejemplos

Java Swing

El Java Swing API se basa en una arquitectura orientada a eventos. Esto funciona particularmente bien con la motivación tras swing para proporcionar componentes relacionados con la interfaz de usuario y la funcionalidad. La API utiliza una convención de nomenclatura (por ejemplo, "ActionListener" y "ActionEvent") relacionar y organizar eventos que tengan que ver. Una clase que tiene que ser consciente de un evento en particular, simplemente implementa el oyente apropiado, anula los métodos heredados, y se añade a continuación al objeto que dispara el evento. Un ejemplo muy sencillo podría ser:

public class FooPanel extends JPanel implements ActionListener {
    public FooPanel() {
        super();

        JButton btn = new JButton("Click Me!");
        btn.addActionListener(this);

        this.add(btn);
    }

    @Override
    public void actionPerformed(ActionEvent ae) {
        System.out.println("Button has been clicked!");
    }
}

Por otra parte, otra opción implementación es añadir el detector al objeto como una clase anónima. A continuación se muestra un ejemplo.

public class FooPanel extends JPanel {
    public FooPanel() {
        super();

        JButton btn = new JButton("Click Me!");
        btn.addActionListener(new ActionListener() {
            public void actionPerformed(ActionEvent ae) {
                System.out.println("Button has been clicked!");
            }
        });
    }
}

Véase también

Referencias

↑ K. Mani Chandy Event-driven Applications: Costs, Benefits and Design Approaches, California Institute of Technology, 2006
↑ Martin Fowler, Event Sourcing, December, 2005
↑ Martin Fowler, Parallel Model, December, 2005
↑ Hanson, Jeff (31 de enero de 2005). «Event-driven services in SOA». JavaWorld. Consultado el 21 de julio de 2020.
↑ Sliwa, Carol (12 de mayo de 2003). «Event-driven architecture poised for wide adoption». Computerworld. Consultado el 21 de julio de 2020.
↑ ^a ^b ^c ^d ^e ^f ^g ^h ⁱ ^j Brenda M. Michelson, Event-Driven Architecture Overview, Patricia Seybold Group, February 2, 2006
↑ «Online Event Processing - ACM Queue». queue.acm.org. Consultado el 30 de mayo de 2019.
↑ 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”.

Enlaces externos

Datos: Q991296

[1] K. Mani Chandy Event-driven Applications: Costs, Benefits and Design Approaches, California Institute of Technology, 2006

[Fowler1-2] Martin Fowler, Event Sourcing, December, 2005

[Fowler2-3] Martin Fowler, Parallel Model, December, 2005

[Hanson1-4] Hanson, Jeff (31 de enero de 2005). «Event-driven services in SOA». JavaWorld. Consultado el 21 de julio de 2020.

[5] Sliwa, Carol (12 de mayo de 2003). «Event-driven architecture poised for wide adoption». Computerworld. Consultado el 21 de julio de 2020.

[Michelson1-6] ↑ ^a ^b ^c ^d ^e ^f ^g ^h ⁱ ^j Brenda M. Michelson, Event-Driven Architecture Overview, Patricia Seybold Group, February 2, 2006

[7] «Online Event Processing - ACM Queue». queue.acm.org. Consultado el 30 de mayo de 2019.

[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”.

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]