SESION 4

2.3. Eventos distribuidos

El uso de eventos permite que un objeto pueda reaccionar a cambios que han ocurrido en
otro objeto. Un componente puede anunciar o difundir uno o más eventos y otros
componentes del sistema pueden registrar que están interesados en este tipo de eventos
y, cuando un evento se anuncia, el sistema invoca a todos los componentes interesados
que estén registrados.
Los sistemas basados en eventos tienen dos características principales: son
heterogéneos y son asíncronos. Por ello aunque inicialmente se parezcan a los sistemas
de publicación-suscripción, no tienen nada que ver, dado que los roles son muy diferentes
(en publicación-suscripción están diferenciados, aquí no), la frecuencia de la información
es muy variable (mucho mayor en los sistemas basados en eventos) y la cantidad también
(más elevada la información por publicación-suscripción que en eventos, que tiende a ser
mínima, frecuente, pero mínima).
Un evento puede ser definido como "un cambio significativo en un estado". Por ejemplo,
cuando un consumidor compra un coche, el estado del coche pasa de "se vende" a
"vendido". La arquitectura del sistema del vendedor de coches debe tratar este cambio de
estado como un evento, cuyo suceso puede ser conocido en otras aplicaciones en la
arquitectura. Desde una perspectiva formal, lo que es producido, publicado, propagado,
detectado o consumido es un mensaje (típicamente asíncrono) llamado notificación del
evento, y no el evento en sí mismo, el cuál es el cambio de estado que disparó la emisión
del evento. Los eventos no viajan, solamente ocurren. Por otro lado, el término evento es
frecuentemente usado para denotar el mensaje de notificación en sí mismo, lo cual puede
llevar a algún tipo de confusión.
Este patrón arquitectónico puede ser aplicado por el diseño e implementación de
aplicaciones y sistemas que transmitan eventos entre componentes software que estén
emparejados libremente y servicios. Un sistema dirigido por eventos está compuesto
típicamente de emisores de eventos (o agentes) y consumidores de eventos (o "sink" en
inglés). 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.
Construir aplicaciones y sistemas alrededor de una arquitectura dirigida por eventos
permite a estas aplicaciones y sistemas ser construidos de una manera que facilita un
mayor grado de reacción, debido a que los sistemas dirigidos por eventos están, por el
diseño, más normalizados para entornos no predecibles y asíncronos.
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. Este paradigma es particularmente útil cuando el
consumidor no proporciona algún contenedor ejecutivo propio.
SOA 2.0 engloba las implicaciones de las arquitecturas SOA y EDA proporcionando a un
más rico y más robusto nivel, creando un nuevo patrón de eventos. Este nuevo concepto
de disparadores de patrones de inteligencia promueve a humanos autónomos o
procesamiento automático que añade valor exponencial al negocio. Esto se debe a que se
inyecta información de valor añadido en patrón reconocido que no podía haber sido
obtenido previamente.
La maquinaría computacional y los sensores (como sensores de cualquier tipo,
actuadores, controladores,...) pueden detectar cambios de estado de objetos o
condiciones y crear eventos que pueden ser procesados por un servicio o un sistema. Los
disparadores de eventos son condiciones que tienen como resultado la creación de un
evento.

Estructura del Evento

Un evento puede estar hecho de dos partes, el encabezado evento y el cuerpo evento. El
encabezado de evento puede incluir información como el nombre del evento, fecha y hora
para el evento, y el tipo de evento. El texto del evento es la parte que describe lo que ha
ocurrido en realidad. El cuerpo del evento no debe ser confundido con el patrón o la lógica
que se puede aplicar en reacción al evento en sí.
Capas del flujo del evento

Una arquitectura de evento disparado se basa en cuatro capas lógicas. Se inicia con la
detección de un hecho, su representación técnica en la forma de un evento y termina con
un conjunto no vacío de reacciones a ese evento.

Generador de evento

La primera capa lógica es el generador de eventos, que detecta un hecho y representa el

hecho de en un evento. Dado que un hecho puede ser casi cualquier cosa que se puede
detectar, por lo que puede un generador de eventos también serlo. 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. La conversión de los diferentes datos recogidos por los
sensores de una forma estandarizada que se pueda evaluar es un problema importante
en el diseño e implementación de esta capa. [4] Sin embargo, teniendo en cuenta que un
evento es un marco muy declarativo, las operaciones de transformación pueden ser
aplicadas fácilmente, eliminando así la necesidad de un alto nivel de estandarización.

Canal de evento

Un canal de evento es un mecanismo mediante el cual la información a partir de un

generador de eventos se transfiere al motor de eventos [4] o en el fregadero. Esto podría
ser una conexión TCP / IP o cualquier tipo de archivo de entrada (text plano, formato
XML, correo electrónico, etc.) Varios canales de eventos se pueden abrir al mismo tiempo.
Por lo general, debido a que el motor de procesamiento de eventos tiene que procesar en
tiempo casi 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 del evento

El motor de procesamiento de eventos es donde se identifica el evento, y la reacción

adecuada se selecciona y se ejecuta. Esto también puede dar lugar a una serie de
afirmaciones que se producen. Es decir, si el evento que entra en el motor de
procesamiento de eventos es un "identificador de producto bajo en la acción", esto puede
desencadenar reacciones tales como, "ID de pedido del producto" y "Notificar al personal".
Actividad de descarga dirigida por evento

Aquí es donde se muestran las consecuencias del suceso. Esto se puede hacer de
muchas maneras y formas diferentes, Por ejemplo, un correo electrónico se envía a
alguien y una aplicación puede mostrar algún tipo de advertencia en la pantalla [4]
Dependiendo del nivel de automatización proporcionada por el receptor (el motor de
procesamiento de eventos) la actividad aguas abajo puede no ser necesaria.

Estilos de procesamiento de evento

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

Procesamiento simple de evento

El procesamiento de eventos simples se refiere a los acontecimientos que están

directamente relacionados con los cambios, específicos y medibles de la condición. En el
procesamiento de evento simple, un evento notable sucede que inicia una acción de
aguas abajo (s).Se utiliza comúnmente para conducir el flujo en tiempo real de trabajo,
reduciendo así el tiempo de retardo y el costo.

Por ejemplo, los eventos simples pueden ser creados por un sensor que detecta los
cambios en la presión de los neumáticos o la temperatura ambiente.

Procesamiento por flujo de evento

En el procesamiento de flujos de eventos (PFE), ambos acontecimientos ordinarios y

notables ocurren. Los acontecimientos ordinarios (pedidos, las transmisiones de RFID)
son examinados para detectar la notabilidad y transmiten a los suscriptores información.
La secuencia de procesamiento de eventos se utiliza comúnmente 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.

Procesamiento complejo de evento

El procesamiento de eventos complejos (PEC) permite a los patrones de eventos simples

y ordinarios que se deben considerar 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 (notable o ordinario) pueden cruzar los tipos de eventos y se
producen durante un largo período de tiempo. La correlación de eventos puede ser
causal, temporal o espacial. PEC requiere el empleo de sofisticadas intérpretes de
eventos, la definición del modelo de eventos y correspondencia, y las técnicas de
correlación. PEC se utiliza comúnmente para detectar y responder a las anomalías de
negocio, amenazas y oportunidades.

Acoplamientos débiles extremos y bien distribuidos

Una arquitectura orientada a eventos está débilmente acoplados y bien distribuida. Existe
una gran distribución de esta arquitectura, ya que un evento puede ser casi cualquier cosa
y existen en casi cualquier lugar. La arquitectura se acopla muy vagamente porque 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
puerta en sí no sabe que el sistema de alarma se sumará la información cuando se abre
la puerta, sólo que la puerta se ha abierto.

Arquitecturas basadas en eventos se suelta del acoplamiento en el espacio, el tiempo y la

sincronización, proporcionando una infraestructura escalable para el intercambio de
información y flujos de trabajo distribuidos. Sin embargo, el eventos-arquitecturas están
estrechamente unidas, a través de suscripciones de eventos y patrones, a la semántica
del esquema de eventos y valores 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 hace que sea difícil de desarrollar y mantener sistemas
basados en eventos. A fin de abordar la semántica acoplamiento dentro de los sistemas
basados en eventos el uso de coincidencia semántica aproximada de eventos es un área
activa de investigación.
2.4. Implementaciones: Jini

Jini
Jini es una API desarrollada por Sun Microsystems. El objetivo es convertir la red en un
sistema flexible y fácil de administrar en el cual se puedan encontrar rápidamente los
recursos disponibles tanto por clientes humanos como computacionales. Un sistema Jini
consiste en un sistema distribuido basado en la idea de grupos federativo de usuarios y
de recursos requeridos por otros usarios. Los recursos pueden ser implementados tanto
por dispositivos hardware y software.
Las partes de un sistema Jini son:
Un conjunto de componentes que proporcionan una infraestructura de servicios
federativos en un sistema distribuido.
Un modelo de programación que soporta y estimula la producción fiable de servicios
distribuidos.
Los servicios que pueden ser parte de un sistema federativo Jini y los cuales ofrecen
funcionalidad a cualquiera de los miembros de la federación.
Jini supone que la infraestructura de red sobre la que se monta tiene el ancho de banda y
es lo suficientemente fiable para funcionar, por lo que no aporta mecanismo para mejorar
estos dos puntos. También se asume que los dispositivos Jini tienen capacidad de
procesamiento y memoria suficientes.
Servicios
El concepto de servicio es el más importante dentro de la arquitectura Jini. Un servicio es
una entidad que puede ser usada por una persona, un programa u otro dispositivo. Un
servicio puede ser de computación, de almacenamiento, un canal de comunicación con
otro usuario, un filtro software, un dispositivo hardware, o cualquier usuario. La naturaleza
dinámica de Jini permite que los servicios sean añadidos o eliminados en cualquier
instante de una federación, de acuerdo con las necesidades, demandas o cambios en los
requisitos del grupo de trabajo que utiliza la federación. Los servicios se comunican entre
sí utilizando el protocolo de servicio, el cual consiste en un conjunto de interfaces escritas
en Java, que reposan sobre la tecnología de RMI.

Para saber los servicios disponibles se utiliza el servicio de búsqueda (lookup service).
Este mapea las interfaces que indican la funcionalidad de un servicio con el conjunto de
objetos que implementan dicho servicio. El servicio de búsqueda se organiza de forma
jerárquica. Cuando se quiere añadir un servicio a la tabla se utiliza el protocolo discovery
y el protocolo join. El primero se encarga de buscar el lookup service y el segundo de
añadir el servicio.
Cuando se quiere utilizar el servicio se busca en la tabla de servicios (lookup service) si
existe. En caso de encontrarlo el cliente se descarga el código de control de ese servicio,
que puede ir desde una interfaz hasta la implementación completa del servicio.
Se incorporan también un mecanismo de transacciones, para agrupar varias operaciones
en una sola y un mecanismo de eventos.
Leasing
El acceso a muchos de los servicios en un entorno Jini se basa en un sistema de leasing.
Cada lease es una concesión que garantiza el acceso durante un periodo de tiempo
determinado. Este se negocia entre el proveedor del servicio y el cliente como parte del
protocolo de negociación. La concesión puede ser exclusiva o no exclusiva.
Resumen del funcionamiento de Jini

Descubrimiento Join (Unir)

Tanenbaum, A. S. (1996). Sistemas Operativos distribuidos. Ed Prentice Hall. 1ª Ed.

Roger S. Presuman. Ingeniería de Software. Quinta Edición. McGraw-Hill Interamericana.

Madrid. 2002.
George Coulouris. Sistemas Distribuidos. Tercera Edición. Addison Wesley. Madrid. 2001.