BRAULIO MALAVE U.P.T.P.

LUIS MARIANO RIVERA BAUDILIO MALAVE En los inicios de la informtica, la programacin se consideraba un arte y se desarrollaba como tal, debido a la dificultad que entraaba para la mayora de las personas, pero con el tiempo se han ido descubriendo y desarrollando formas y guas generales, con base a las cuales se puedan resolver los problemas. A estas, se les ha denominado Arquitectura de Software, porque, a semejanza de los planos de un edificio o construccin, estas indican la estructura, funcionamiento e interaccin entre las partes del software. En el libro "An introduction to Software Architecture", David Garlan y Mary Shaw definen que la Arquitectura es un nivel de diseo que hace foco en aspectos "ms all de los algoritmos y estructuras de datos de la computacin; el diseo y especificacin de la estructura global del sistema es un nuevo tipo de problema". Los Estilos arquitectnicos indican los componentes y conectores as como tambin los patrones y restricciones que estn asociados a ciertos estilos los cuales cada uno de los estilos posee sus ventajas y desventajas caractersticas de ellos. Los estilos arquitectnicos son sistemas organizados de manera estructural, que cada estilo tiene su propio vocabulario de componente. Generalmente, no es necesario inventar una nueva arquitectura de software para cada sistema de informacin. Lo habitual es adoptar una arquitectura conocida en funcin de sus ventajas e inconvenientes para cada caso en concreto. As, las arquitecturas ms comunes son: Estilo basado en Eventos e Invocacin Implcita Estilo basado en capas Estilo basado en repositorios Estilo cliente-servidor Estilo para sistemas distribuidos Estilo de arquitecturas heterogneas

La Arquitectura dirigida por eventos, Event-driven architecture o EDA, es un patrn de arquitectura software que promueve la produccin, deteccin, consumo de, y reaccin a eventos. 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 (tpicamente asncriono) llamado notificacin del evento, y no el evento en s mismo, el cul es el cambio de estado que dispar la emisin del evento. Los eventos no viajan, solamente ocurren. Por otro lado, el trmino evento es frecuentemente usado para denotar el mensaje de notificacin en s mismo, lo cual puede llevar a algn tipo de confusin. Este patrn arquitectnico puede ser aplicado por el diseo e implementacin de aplicaciones y sistemas que transmitan eventos entre componentes software que estn emparejados libremente y servicios. Un sistema dirigido por eventos est compuesto tpicamente de emisores de eventos (o agentes) y consumidores de eventos (o "sink" en ingls). Los consumidores tienen la responsabilidad de llevar a cabo una reaccin tan pronto como el evento est presente. La reaccin puede o no puede ser completamente proporcionada por el consumidor en s mismo. Por ejemplo, el consumidor debe tener slamente la responsabilidad de filtrar, transformar y reenviar el evento a otro componente o debe proporcionar una reaccin propia a algn 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 reaccin, debido a que los sistemas dirigidos por eventos estn, por el diseo, ms normalizados para entornos no predecibles y asncronos.

ESTILOS BASADOS EN EVENTOS E INVOCACIN IMPLCITA Este patrn, tambin conocido como orientado a eventos, funciona de forma diferente a los patrones comunes en el sentido de que las acciones de los usuarios generan eventos no acciones, y luego tienes a "listeners" que se interesan por ciertos eventos y realizan sus acciones dependiendo del evento. Es un estilo bastante comn en desarrollo de aplicaciones stand-alone. Los componentes son mdulos cuyas interfaces proveen una coleccin de procedimientos y un conjunto de eventos. Los procedimientos se llaman de la manera usual pero el componente tambin puede activar algunos de sus procedimientos con los eventos del sistema. Esto har que estos

procedimientos sean invocados cuando los eventos ocurren en tiempo de ejecucin.

Las arquitecturas basadas en eventos se han llamado tambin de invocacin implcita. Otros nombres propuestos para el mismo estilo han sido integracin reactiva o difusin (broadcast) selectiva. Por supuesto que existen estrategias de programacin basada en eventos, sobre todo referida a interfaces de usuario, y hay adems eventos en los modelos de objetos y componentes, pero no es a eso a lo que se refiere primariamente el estilo, aunque esa variedad no est del todo excluida. En trminos de patrones de diseo, el patrn que corresponde ms estrechamente a este estilo es el que se conoce como Observer, un trmino que se hizo popular en Smalltalk a principios de los ochenta; en el mundo de Java se le conoce como modelo de delegacin de eventos

Las arquitecturas basadas en eventos se vinculan histricamente con sistemas basados en actores, daemons y redes de conmutacin de paquetes publicacin-suscripcin). Los conectores de estos sistemas incluyen

procedimientos de llamada tradicionales y vnculos entre anuncios de eventos e invocacin de procedimientos. La idea dominante en la invocacin implcita es que, en lugar de invocar un procedimiento en forma directa (como se hara en un estilo orientado a objetos) un componente puede anunciar mediante difusin uno o ms eventos. Un componente de un sistema puede anunciar su inters

en un evento determinado asociando un procedimiento con la manifestacin de dicho evento.

Ejemplo: Cuando un modelo est salvando datos sobre la base de datos tendremos eventos antes y despus de realizar la operacin.

MARIA PANTOJA

ETAPAS DE LA ARQUITECTURA (capas de flujo de eventos)

Un evento que desencadena la arquitectura se basa en cuatro capas de lgica. Se inicia con la deteccin de un hecho, la representacin tcnica en forma de un evento y termina con un conjunto no vaco de las reacciones a ese evento. Generador y escuchador de eventos: Se mantiene a la escucha del evento. Enva el evento al motor de eventos. La primera capa de lgica es la generadora de eventos, que detecta un hecho, y representa el hecho en un evento. Dado que un hecho puede ser casi cualquier cosa que se puede percibir, por lo que puede hacer un generador de eventos.

Como un ejemplo, un generador de eventos podra ser un cliente de correo electrnico, un sistema de comercio electrnico o algn tipo de sensor. La conversin de los diferentes datos recogidos de los sensores a un formulario estandarizado de datos que puede ser evaluado es un problema importante en el diseo y la aplicacin de esta capa. Sin embargo, considerando que un evento es un marco muy declarativo, las operaciones de transformacin pueden ser de fcil aplicacin, eliminando as la necesidad de un alto nivel de estandarizacin.

Motor de eventos (Canal de eventos): Recibe un evento. Gestiona el evento. Enva al cliente de evento indicado para procesarlo.

Un canal de eventos es un mecanismo mediante el cual la informacin de un generador de eventos es transferida al motor de eventos o hundirse. Esta podra ser una conexin TCP / IP o cualquier tipo de archivo de entrada (plano, el formato XML, e-mail, etc.). Varios canales de eventos se pueden abrir al mismo tiempo. Por lo general, porque el motor de procesamiento de eventos

tiene que procesar en tiempo casi real y los canales de evento se puede leer de forma asincrnica. Los eventos se almacenan en una cola, esperando para ser procesado posteriormente por el motor de procesamiento de eventos.

Motor de procesamiento de sucesos y El cliente: El motor de procesamiento de eventos es donde se identifica el evento, y

la reaccin apropiada es seleccionada y ejecutada. Esto tambin puede dar lugar a una serie de afirmaciones que se producen. Es decir, si el evento que entra en el motor de procesamiento de evento es un "identificador de producto en stock", esto puede provocar reacciones como la "Orden de identificacin de producto" y "Notificacin personal".

El cliente Procesa el evento. Ejecuta la funcin indicada. Realiza las operaciones indicadas

Downstream o la actividad impulsada por el evento:

Aqu es donde se muestran las consecuencias del evento. Esto se puede hacer de muchas maneras y formas diversas, por ejemplo, un correo se enva a una persona y una aplicacin puede mostrar una especie de alerta en la pantalla.

DESCRIPCIN GENERAL DEL ESTILO:

En lugar de invocaciones de procedimientos explicitas o directas, un componente anuncia uno o ms eventos y otros componentes registran el inters en un evento asociando un procedimiento a dicho evento.

La ocurrencia de un evento causa la invocacin implcita de procedimientos en otros mdulos.

Los componentes son los mdulos cuyas interfaces ofrecen un conjunto de procedimientos y de eventos.

Los conectores incluyen llamadas a procedimientos tradicionales as como el ligado de eventos con llamadas a procedimientos.

RESTRICCIONES:

Quien anuncia el evento no conoce a que componentes afecta el evento. No se pueden hacer asunciones acerca del orden de procesamiento.

En este estilo, la interfaz de los componentes (objetos) cuentan con una coleccin de procedimientos y funciones, y la integracin entre ellos se logra a travs de la invocacin explcita de stos. En este estilo, se considera una tcnica de integracin conocida como invocacin implcita.

Los componentes son mdulos cuyas interfaces proveen una coleccin de procedimientos y un conjunto de eventos. Los procedimientos se llaman de la manera usual pero el componente tambin puede activar algunos de sus procedimientos con los eventos del sistema. Esto har que estos procedimientos sean invocados cuando los eventos ocurren en tiempo de ejecucin.

Los generadores de eventos no saben cules componentes se afectarn por el evento. Ejemplos de este estilo son los sistemas de gestin de bases de datos cuando aseguran la consistencia de los datos, las aplicaciones con interfaces de usuarios al separar la representacin de los datos de las aplicaciones que las gerencian.

VENTAJAS DEL ESTILO BASADO EN EVENTOS E INVOCACION IMPLICITA: Provee un robusto soporte de reusabilidad. Facilita la evolucin del sistema. Se optimiza el mantenimiento haciendo que procesos de negocios que no estn relacionados sean independientes.

Se alienta el desarrollo en paralelo, lo que puede resultar en mejoras de performance.

Es fcil de empaquetar en una transaccin atmica. Es agnstica en lo que respecta a si las implementaciones corren sincrnica o asincrnicamente porque no se espera una respuesta.

Se puede agregar un componente registrndolo para los eventos del sistema; se pueden reemplazar componentes.

DESVENTAJAS DEL ESTILO BASADO EN EVENTOS E INVOCACION IMPLICITA: Prdida de control en el comportamiento del sistema. Problemas en el intercambio de datos. Es difcil asegurar la correccin global del sistema. El estilo no permite construir respuestas complejas a funciones de negocios. Un componente no puede utilizar los datos o el estado de otro componente para efectuar su tarea. Cuando un componente anuncia un evento, no tiene idea sobre qu otros componentes estn interesados en l, ni el orden en que sern invocados, ni el momento en que finalizan lo que tienen que hacer. Pueden surgir problemas de performance global y de manejo de recursos cuando se comparte un repositorio comn para coordinar la interaccin. En esta estrategia juega un rol importante el Servicio de Eventos, el cual a su vez proporciona un buen punto de partida para la implementacin del estilo o patrn, segn se est concibiendo la arquitectura o

implementndola.

BRAULIO MALAVE INVOCACIONES: Explicita: Cuando un objeto desea que otro objeto ejecute una funcin, necesita mandar un mensaje indicando cual operacin es la indicada y los argumentos que esta necesita, esto significa que un objeto A debe tener algn tipo de visibilidad hacia el objeto B.

Implcita La invocacin Implcita podra ser utilizada para obtener mayor

independencia entre clases o mdulos, y de la misma forma tambin tener un menor acoplamiento, y a la vez proveer un gran soporte para la reutilizacin de cdigo. En otras palabras, Invocacin Implcita pretende que un Objeto A puede ser comunicado con un objeto B sin tener la necesidad de ninguna manera de conocer B, esto significa que A no necesita tener una instancia de B para mandarle mensajes. Y el hecho de que A no necesite conocer a B implica que A no tenga dependencia con B. Cuando una clase est demasiado conectada o dependiente de otras clases es considerada como una clase que tiene un Alto Acoplamiento, lo cual significa que no tiene muchas posibilidades de ser reutilizada porque depende de campos que puedan tomar efecto en otras clases, siento esto poco recomendable cuando se pretende la futura reutilizacin de cdigo en su componente o clase.

Para que esto sea posible se debe implementar un mecanismo que actu como un intermediario entre clases, de esta manera la comunicacin directa entre objetos puede ser minimizada o eliminada y la comunicacin entre objetos ser reemplazada por notificaciones de eventos. DIVERSOS TIPOS DE EVENTOS QUE SE USAN EN EL ESTILO Desde este punto de vista un evento es cuando el usuario del mecanismo necesita que una accin sea ejecutada. Entre los eventos tenemos: Evento Externo:

Proviene del exterior del sistema y requiere de una accin dentro del sistema. Eventos Generados:

Son producidos dentro del sistema en respuesta a un evento generado por la interface de usuario o por otro sistema. Estos eventos pueden ser: Sincrnicos: Un evento sincrnico est esperando por una respuesta despus de que la ejecucin de una operacin es solicitada para continuar su proceso. Cuando el gestor de eventos recibe una notificacin, este consulta su lista de eventos registrados y obtiene de ella el objeto interesado en el evento notificado, para invocar la operacin necesaria. Asncrona:

De la misma manera que los eventos sincrnicos, esta es hecha por un objeto y es enviada al gestor de eventos informando la ocurrencia de un evento, la diferencia es que este tipo de notificacin no esperara ningn tipo de respuesta para continuar su proceso. EJEMPLO DE LA ARQUITECTURA BASADA EN EVENTOS: Arquitecturas basadas en eventos para sistemas distribuidos Evento: ha ocurrido un cambio

Sistemas distribuidos basados en eventos: comunican a objetos remotos eventos generados por cualquier objeto.

Paradigma: publish-subscribe

- un objeto que genera eventos, los publica - los objetos interesados, se subscriben - A veces, anuncian los tipos de eventos que publicarn

O tro ejemplo notable sera el de la Universidad De Murcia. Facultad de Informtica, cuyo proyecto llevo por nombre arquitectura dirigida por eventos para un sistema de deteccin de intrusiones basado en patrones. Realizado por Jess Joaqun Martnez Molina en el 2008, donde el objetivo de este trabajo es sentar las bases de un Sistema de Deteccin de Intrusiones que sea capaz de detectar ataques complejos. Para ello se parte de lo que actualmente existe en

la literatura y se propone una arquitectura con la que desarrollar el sistema. Como ataque complejo vamos a entender aquel ataque formado por una secuencia de eventos que pueden llegar en cualquier momento, en cualquier orden y desde cualquier direccin a la red que se est monitorizando con el sistema.

Y por ltimo un ejemplo de arquitecturas basadas en eventos para la ayuda a la decisin en sistemas de trfico rodado Los sistemas de ayuda a la decisin para la gestin de sistemas de trfico deben trabajar con un gran volumen de eventos generados por sensores. Las arquitecturas software convencionales no estn enfocadas al proceso continuo de flujos de eventos. Las arquitecturas basadas en eventos (Event-Driven Architecturas, EDA) proponen un nuevo paradigma basado en eventos para desarrollar aplicaciones. El objetivo de este proyecto es la implementacin de una arquitectura basada en eventos para sistemas de trfico, encargada del anlisis y procesada de flujos de eventos en tiempo real provenientes de los distintos sensores de trfico. En concreto se redisear un prototipo para las redes de carreteras de alta velocidad de Bilbao, en l se

analizarn los datos provenientes de los sensores colocados en la calzada y se tomarn decisiones para mejorar la circulacin de los vehculos (informacin en paneles luminosos, avisos a servicios de emergencia, etc.) El estilo basado en Eventos e Invocacin Implcita se fundamenta en los sistemas basados en actores, satisfaccin de restricciones. La idea principal de invocacin implcita, es que en vez de invocar directamente un procedimiento, un componente puede anunciar uno o ms eventos. Otros componentes en el sistema pueden registrar un inters en el evento por la asociacin de un procedimiento con el evento. Provee fuerte soporte al reuso, es un sistema de fcil evolucin. Cuando los componentes anuncian un evento, ellos no tienen idea de que si los dems componentes respondern o no y las correcciones son problemticas. La mayor dificultad que se tiene que enfrentar es que con la Invocacin Implcita, una clase no necesita tener visibilidad hacia otra para ejecutar una operacin, as que de esa manera se minimiza el acoplamiento o dependencia entre clases. En la actualidad el desarrollo de un sistema, independiente de su propsito, resulta un reto para los profesionales de la informtica y tecnologas en general. El conocimiento de la arquitectura del software resulta indispensable por ser el diseo de ms alto nivel que tiene un sistema. Por la variedad de arquitecturas que existen algunas son ms recomendables de implementar con ciertas tecnologas mientras que otras tecnologas no so actas para implementar con ciertas arquitecturas. Por ejemplo, no es viable emplear una arquitectura de software de tres capas para implementar en sistemas de tiempo real. En este caso la arquitectura a estudiar ser la arquitectura orientada a eventos. Esta misma es un patrn que promueve la produccin, detencin, consumo de, y reaccin a eventos. Donde los eventos pueden ser cualquier cambio ocurrido en algn modulo del sistema, que desencadene alguna reaccin o produzca otro evento. El estudio de esta arquitectura resulta interesante ya que est estrechamente relacionada con la arquitectura dirigida a servicios.