Arquitectura de software dirigida por eventos

Cada vez que iniciamos un nuevo proyecto software, una de las preguntas principales que debemos hacernos es: ¿cómo estructuro mi sistema? es decir, ¿qué arquitectura uso para mi desarrollo?

Una arquitectura software es el diseño a más alto nivel de la estructura de un sistema. Esta decisión debe ser tomada en función de nuestros requisitos y nuestras limitaciones. Algunas de las arquitecturas más conocidas y usadas son: la descomposición en módulos y cliente-servidor. Pero en este artículo vamos a hablar de una arquitectura algo menos conocida, la arquitectura dirigida por evento o EDA por sus siglas en inglés.

La arquitectura dirigida por eventos es un tipo de arquitectura software que se basa en la producción, detención y procesamiento de eventos y, si se considera oportuno, la reacción ante ellos. En la mayoría de los casos, el dispositivo que genera un evento no es el mismo que el que lo recibe y procesa. Por ejemplo, un sensor lanza un evento cuando detecta movimiento y lo envía a un servidor que lo recibe y actúa según se haya programado anteriormente o según unas reglas.

Dichos eventos son asíncronos, pueden ocurrir en cualquier momento. Por lo que el servidor no puede predecir cuándo va a recibir uno ni cuántos van a llegar en un periodo corto de tiempo. Por este motivo, en muchas ocasiones se hace necesario usar un sistema de colas para mantener un evento en espera hasta que el servidor pueda atenderlo.

Eventos

Bueno, pero ¿qué es un evento? Según la RAE, un evento es un «acaecimiento» y acaecimiento es «cosa que sucede». Definiremos un evento como un proceso instantáneo sin duración en el tiempo que ocurre en un momento en concreto. Para que el evento tenga utilidad en esta arquitectura, se debe enviar una notificación a un servidor en el momento en el que sucede. En realidad, al servidor no llega el evento, llega la notificación del evento, pero por facilidad, cuando hablemos de evento nos referiremos directamente a la notificación de dicho evento.

Cada evento se compone de cabecera y cuerpo. La cabecera contiene información importante como su tipo, su nombre, su generador y el momento en el que ha ocurrido. Y el cuerpo contiene los datos. Por ejemplo, tenemos un termostato que envía un evento cada 30 minutos con la temperatura ambiente. Una posible estructura sería:

• Cabecera:
  • Tipo: Temperatura.
  • Nombre: Temperatura periódica
  • Generador: Termostato1
  • Timestamp: 2019-03-05 9:23:00
• Cuerpo:
  • Temperatura: 23°C

Procesamiento de eventos 

Cuando el evento llega al servidor, hay que procesarlo. Para estudiar cómo se procesa uno o varios eventos, podemos diferenciar en cuatro capas, el flujo total desde la emisión del evento hasta el desencadenamiento de la acción correspondiente. Estas cuatro capas son:

• Generador del evento: Es la fuente que arroja el evento. Cualquier tipo de dispositivo o aplicación podría ser el generador, el único requisito es que sea entendible, es decir, que se use la misma estructura. Un generador puede crear un evento notable (se envía directamente al procesador) u ordinario (primero debe pasar por un preprocesador donde se decide si se convierte en notable). En el ejemplo anterior, el termostato sería nuestro generador.
• Canal del evento: Es el medio de unión entre el generador y el procesador. Su objetivo es transportar los mensajes.
• Procesador del evento: Es el servidor que recibe los eventos, los procesa, los compara con reglas preestablecidas y realiza las acciones. Las reglas, y por tanto las acciones, no son definidas por los generadores de evento, sino por la persona que lo programe. Una posible regla para el ejemplo anterior sería, que si se superan los 35°C se encienda el aire acondicionado. Como vemos, el termostato no decide esa temperatura límite, únicamente se dedica a enviar lo que lee.
• Actividad de respuesta: Es la acción que se hace si se cumple alguna de las reglas. Puede ser cualquier tipo de acción, desde un aviso a una persona hasta un proceso interno totalmente transparente al usuario. En algunos casos, los usuarios se deben subscribir para ser avisados de dicha actividad.

En esta arquitectura, podemos distinguir tres tipos diferentes de procesamiento de eventos:

• Procesamiento simple: Evalúa un evento e inmediatamente se inicia una actividad de respuesta. Suele ser utilizado para controlar el flujo de trabajo en tiempo real.
• Procesamiento complejo: Evalúa una serie de eventos y después se inicia una actividad de respuesta. En este tipo de procesamiento se comparan eventos que llegan a lo largo de un periodo de tiempo buscando patrones y se responde en consecuencia.
• Procesamiento stream: Se utiliza una plataforma de transmisión de datos intermedia a la que le llegan los eventos y reenvía a los procesadores de flujo. Los procesadores tratan el flujo o lo transforman. Se utiliza cuando hay un tráfico constante de datos.

Ventajas e inconvenientes

Como cualquier arquitectura que elijamos, tiene sus ventajas e inconvenientes. Dependerá de nuestros requisitos el peso que estas van a tener:

Las principales ventajas de esta arquitectura son:

• Desacoplo de servidor y clientes: Los servidores y los clientes únicamente deberán usar la misma estructura en los mensajes de los eventos, pero se pueden programar en distintos lenguajes de programación y ser totalmente independientes.
• Desacoplo entre dispositivos: EDA presenta una topología en estrella en la cual, cada dispositivo solo tiene que comunicarse con el servidor. De esta manera, se puede relacionar cualquier dispositivo entre sí sin límite. Por ejemplo, se podría conectar un sensor de movimiento directamente a una luz para encenderla, lo que limitaría mucho las posibles acciones. Sin embargo, si el sensor envía un evento a un servidor, este podría realizar cualquier acción con cualquier dispositivo: encender la luz, mostrar un mensaje de bienvenida en la televisión, poner música,…
• Altamente escalable: Gracias al desacoplo entre dispositivos se puede añadir fácilmente cualquier nuevo servicio al sistema.

Los principales inconvenientes son:

• El servidor no podría saber nunca si un servicio se ha caído, ya que no hay ninguna conexión real entre ellos. Del mismo modo, un dispositivo tampoco sabe si el servidor está caído.
• No se puede comprobar si un evento ha sido atendido.

Artículo redactado por: Carlos Moro