DISEÑO ARQUITECTONICO DE SISTEMAS DISTRIBUIDOS EN RAPIDE 1

Transcripción

1 DISEÑO ARQUITECTONICO DE SISTEMAS DISTRIBUIDOS EN RAPIDE 1 Francisca Losavio flosav@cantv.net Centro ISYS, Escuela de Computación, Facultad de Ciencias, Universidad Central de Venezuela Ap , Los Chaguaramos, 1041-A Caracas, Venezuela Christian Guillén Drija cdguillen@telcel.net.ve Universidad Pedagógica Experimental Libertador Instituto Pedagógico de Miranda "J. M. `Siso Martínez" La Urbina, El Marqués, Muncipio Sucre, Estado Miranda Caracas, Venezuela RESUMEN El objetivo de este artículo es presentar la especificación de algunos patrones basicos utilizados para el diseño arquitectónico que permiten modelar los mecanismos de comunicación en sistemas distribuidos utilizando un Lenguaje de Descripción Arquitectónica (ADL) denominado RAPIDE. Las descripciones obtenidas poseen un alto nivel de abstracción y formalismo, por tener los ADLs una semántica bien definida, siendo posible la producción de simulaciones de la arquitectura a partir de ellas. Tales simulaciones pueden ser utilizadas por un especialista para analizar, en etapas tempranas del desarrollo, el comportamiento de la arquitectura propuesta para el sistema, respecto a la especificación inicial de requisitos. Las simulaciones ponen en evidencia caraterístics no funcionales presentes en la arquitectura, como son características de calidad tales como flexibilidad respecto a cambios, eficiencia, confiabilidad, portabilidad y seguridad. De esta manera se facilita la toma de decisiones en cuanto a la aplicabilidad de los patrones. Palabras Clave: Arquitectura del Software, Sistemas Distribuidos, ADL, RAPIDE, Patrones, Mediator, Publisher-Subscriber, Client-Dispatcher-Server, Broker, calidad Introducción Son muchos los logros obtenidos como consecuencia del esfuerzo investigativo realizado en el área de la Ingeniería del Software; entre ellos se puede citar la identificación, descripción y propuestas de clasificación de los estilos 26, patrones arquitectónicos y patrones de diseño 4 para describir la arquitectura del software. Por otra parte, han sido igualmente notables los esfuerzos de la comunidad científica hacia recopilación y registro de la información obtenida en este ámbito, organizándola luego de manera coherente, para así facilitar a los diseñadores tanto su estudio como su aplicación en el diseño de los sistemas de software. 11 Sin embargo, la selección de una arquitectura de software es aún un problema de investigación abierto. 13 La información que los catálogos existentes 4,11 ofrecen sobre un determinado patrón, está constituida por una descripción informal del contexto de la problemática que se pretende atacar y una descripción de la solución (donde la solución viene dada por el patrón a describir), la cual a su vez puede contener gráficos, diagramas y texto que en conjunto identifican la estructura, los participantes y las colaboraciones que se deben producir con el fin de hacer efectiva tal solución. El objetivo de este trabajo es proponer especificaciones más formales de los patrones: MEDIATOR, PUBLISHER SUBSCRIBER, CLIENT DISPATCHER SERVER y BROKER (utilizados para modelar la comunicación en el modelo cliente-servidor), utilizando un Lenguaje de Descripción Arquitectónica (Architecture Description Language o ADL) llamado RAPIDE. 19 De esta forma se intenta aumentar el nivel de formalización de las descripciones propuestas en los catálogos ampliamente conocidos 4, 11, con el fin de facilitar la selección de una arquitectura que responda a características de calidad precisas. El presente artículo también pretende ser un aporte a la discusión sobre la problemática planteada por Shaw y Clements 25 alrededor de la siguiente interrogante: Qué tipo de información, de la contenida en un patrón, puede ser capturada por los ADLs? 12 Los ADLs surgen como una respuesta a la necesidad de representar los sistemas de software desde el punto de vista arquitectónico a un alto nivel de abstracción, de manera que tales descripciones puedan ser utilizadas en las primeras etapas de desarrollo como una herramienta para conocer y evaluar el comportamiento global de la arquitectura 1, 26 propuesta para un sistema, en función de los requisitos iniciales. Este artículo está estructurado de la siguiente forma, a parte de esta introducción y las conclusiones: la segunda sección, trata el tema de los patrones. La tercera sección hace referencia al ADL RAPIDE, colocando especial énfasis en los patrones de eventos que este ADL propone como un medio para describir los comportamientos esperados de cada uno de los componentes participantes de una arquitectura. La cuarta sección propone las descripciones en RAPIDE de los patrones MEDIATOR y PUBLISHER SUBSCRIBER. Para CLIENT DISPATCHER SERVER se enfatiza la descripción de tratamiento de errores y su comportamiento dinámico y para BROKER se discute un resultado de la simulación. Por último, se presentan las conclusiones en las que se discute el aporte de RAPIDE a la descripción de patrones y el trabajo futuro. 1 This work is a result of the CEE INCO SQUAD project EP and the CDCH ARCAS project of the Universidad Central de Venezuela 1

2 Patrones Un patrón es una abstracción de una entidad concreta que es recurrente dentro de un contexto específico 3,11, por ejemplo, dentro de una arquitectura. La arquitectura de software describe los sistemas de software en función de los subsistemas y componentes que lo integran, incluyendo las relaciones y el comportamiento. Son mecanismos cuyo objetivo es capturar la solución de problemas que ocurren repetidamente dentro de un contexto muy bien definido. Su objetivo es la reutilización. Algunas propuestas para la descripción de patrones involucran estructuras de información que permiten contemplar los requisitos no funcionales 14,17, los cuales son requeridos para la evaluación de la arquitectura. Los patrones proporcionan un esqueleto sobre el cual se implementan las funcionalidades deseadas en un sistema. Además de capturar la experticia del diseñador, permiten dar una respuesta a requisitos no funcionales tales como confiabilidad, extensibilidad, reutilización, facilidad de uso; en el sentido de proporcionar criterios o elementos para la selección. 16 No importa cual sea la forma en la cual se presenten los patrones, tales descripciones deben poseer los siguientes elementos esenciales: 3,4,14,17 nombre, descripción del problema, descripción de la soluci'on, ejemplos de utilización, descripción del contexto resultante después de aplicar el patrón, justificación, relación con otros patrones, aplicaciones en funcionamiento que utilizan el patrón La tabla 1 a continuación muestra un ejemplo de esta descripción, como una adaptación de la estructura ABAS (Attribute Based Architectural Styles) 14,17 : Estructura Descripción 1. Descripción del problema Descripción informal de problemas de análisis y diseño que el ABAS pretende resolver, incluyendo los atributos de calidad de interés o cuya presencia es deseable en el estilo arquitectónico, el contexto de uso, las restricciones y los requisitos relevantes, específicos para el atributo. 2. Medidas del estímulo/respuesta del atributo Una caracterización del estímulo (o servicio) al cual el ABAS debe responder y las medidas de la respuesta (valor de calidad para el servicio, también conocido como Calidad del Servicio (Quality of Service, QoS). Para la especificación de los QoS se propone construir un Modelo de Calidad que incluye el atributo. 3. Estilo rqitectónico Descripción del estilo o patrón arquitectónico en términos de sus componentes y conectores, patrones de datos e interacciones de control (topología) y restricciones sobre el estillo. Incluye la descripción de las decisiones arquitectónicas. 4. Análsis Descripción de como el modelo ded calidad relacionado con el atributo está formalmente relacionado con el estilo y conclusiones sobre el comportamiento arquitectónico. Determinación de los enlaces o puntos de tradeoff entre las características de calidad requeridas y las medidas (valores) de las propiedades que los afectan. Se formulan justificaciones y heurísticas de diseño. Tabla 1. Descripción de los estilos arquitectónicos considerando los atributos de calidad 17. Lo anterior evidencia la importancia del estudio de alternativas que permitan especificar de una forma poco ambigua toda la información contenida en los patrones de diseño,co el fin de proporcionar a los diseñadores herramientas de simulación que permitan en un momento dado realizar evaluaciones sobre éstos. Aunque los ADLs están dirigidos a la representación arquitectónica de sistemas completos, pueden ser utilizados para producir especificaciones más formales de los patrones, que las utilizadas en la práctica común. Uno de los objetivos de este trabajo es mostrar estas especificaciones en el contexto de las arquitecturas distribuidas y discutir su aplicabilidad práctica. El ADL RAPIDE El lenguaje RAPIDE fue propuesto por la ARPA (Advanced Research Projects Agency) en 1990 como el diseño de un lenguaje para la producción de prototipos de sistemas, con herramientas de soporte para la simulación y el análisis 23. Las razones que condujeron a la escogencia de este ADL para este estudio fueron las siguientes: - La disponibilidad de herramientas de soporte. Junto con la documentación, se encuentran también disponibles en forma gratuita, las herramientas que dan soporte a RAPIDE. Hasta la fecha, todas estas herramientas de análisis corren bajo UNIX y LINUX. El hecho de disponer de tales herramientas facilita el aprendizaje de RAPIDE, y permite la realización de análisis sobre el código producido, así como su verificación y validación. 2

3 - La descripción progresiva de una arquitectura. Esto permite iniciar la descripción de un sistema en forma muy simple, y luego mejorar incrementalmente tales descripciones, según las necesidades de especificación del especialista. - La modelación de los mecanismos de comunicación entre los componentes de un sistema distribuido, lo cual puede ser aprovechado en la especificación de patrones de diseño que modelan la comunicación clienteservidor, con un alto nivel de formalidad. - La simulación de sistemas en los que las conexiones entre los componentes pueden establecerse en forma dinámica, o sea, pueden variar en tiempo de ejecución, lo que permite producir simulaciones que muestren el comportamiento de la arquitectura y realizar análisis sobre estas. 2, 6 - La modificabilidad de las arquitecturas especificadas, lo que permite la producción de versiones distintas partiendo de una arquitectura base. De la misma manera, soporta bastante bien la escalabilidad de una arquitectura, permitiendo representar sistemas complejos. - La herramienta POV permite al investigador la exploración interactiva de la traza de eventos producidos por la simulación, lo que facilita el análisis tanto del sistema global como de cada uno de los componentes. 5, 9 Por otra parte, este lenguaje permite la definición y ejecución de modelos de sistemas desde el punto de vista arquitectónico; siendo el resultado de la ejecución de un modelo basado en RAPIDE, un conjunto de eventos entre los cuales existen tanto relaciones de causalidad como relaciones cronológicas. A estos conjuntos de eventos con historiales de causalidad se les denomina posets (partcially ordered events sets), y son propuestos como herramientas de simulación para facilitar el análisis sobre modelos arquitectónicos de sistemas distribuidos. 19 Este manejo de eventos permite la simulación. Los componentes que constituyen un sistema son representados en RAPIDE por medio de sus interfaces 20 ; así, una arquitectura se especifica mediante la declaración de un conjunto de interfaces de componentes junto con las conexiones que se establecen entre ellas. También comprende la declaración de condiciones de comportamiento de los componentes constituyentes, y esto por medio de la producción de eventos parcialmente ordenados (posets). Las conexiones en RAPIDE modelan patrones de comunicación considerados válidos para las condiciones que en ellos se declaren. Como resultado de una conexión, se tiene: a) los eventos generados en un componente causan eventos que la arquitectura global comunica a otros componentes que los detectan; b) las funciones invocadas por un componente son ejecutadas en otros componentes, modelándose de esta forma el flujo de datos y la sincronización entre los componentes de una arquitectura. Una arquitectura puede estar constituida por componentes simples o complejos. Los componentes pueden poseer una arquitectura interna propia. De esta forma, RAPIDE permite el desarrollo de arquitecturas jerárquicamente constituidas. Un componente puede ser implementado por un módulo o puede estar representado en una arquitectura, únicamente por su interfaz que en el caso de no estar asociada a un módulo, puede hacer las veces de este 21. Las declaraciones de conexiones en una arquitectura contienen las reglas de conexión 22 (básica, tubería (pipe), agente) entre los componentes y las reglas de creación. Las reglas de conexión son las que permitirán el flujo de información entre los componentes y las reglas de creación definen las condiciones que conducen a la creación de nuevos componentes. Resumiendo, la semántica de RAPIDE se basa en los conceptos de interfaz, posets y patrones de conexión. Dicha semántica es apoyada por un conjunto de herramientas, las cuales son: - Rpdc: que es el compilador de código fuente RAPIDE, el cual reporta errores de sintaxis y semánticos. Genera un ejecutable que al correr produce un archivo.log que es un registro de los eventos producidos durante la ejecución. - Pov ( Partial Order Viewer): que permite observar en forma gráfica la traza de eventos producidos por los ejecutables. - Raptor: la cual es una herramienta para la animación de arquitecturas. Tales animaciones ayudan a los especialistas a comprender la arquitectura de un sistema, pues muestran el funcionamiento de cada uno de los componentes, siempre desde la óptica de los posets. Especificación en RAPIDE de algunos patrones para sistemas distribuidos. A continuación se describen los patrones que intervienen con más frecuencia en las arquitecturas de aplicaciones distribuidas, poniendo en evidencia las características de calidad por ellos promuevidas y que condicionan su comportamiento. Presentamas solo algunos ejemplos de las especificaciones y simulaciones, para abreviar esta presentación. Ella pueden verse completas en 12. Patrón Mediator Su objetivo es encapsular la forma mediante la cual un conjunto de componentes interactúan manteniéndolos desacoplados. Este patrón es aplicado cuando un conjunto de componentes necesitan comunicarse con el fin de 3

4 trabajar en forma cooperativa; las vías de interacción, aunque bien definidas se caracterizan por ser muy complejas; o bien se quieren utilizar componentes que tienen formas muy distintas de comunicación. Este patrón se caracteriza por 4 : Componentes - Un mediador (Mediator): que define la interfaz de comunicación entre los colegas, permitiendo la cooperación entre ellos para la realización de tareas. Este componente conoce y mantiene a todos los colegas. - Colegas (Colega): siendo que cada uno de estos conoce tan solo a su mediador. Estos pueden hacer requerimientos únicamente a través del mediador. Comportamiento Un colega (que actúa en este caso como cliente) hace un requerimiento al mediador correspondiente. Luego, el mediador busca en sus registros a aquellos colegas que pueden hacer frente a tal requerimiento, enviándoles entonces la información necesaria. El colega que acepta el requerimiento (actuando en este caso como servidor) no conoce al colega cliente, tan solo produce una respuesta apropiada y la envía al mediador, que toma la respuesta y la comunica al cliente que originalmente ha realizado la demanda del servicio. Es necesario apuntar que mediador debe conocer a todos sus colegas en tiempo de compilación, por lo que se mantiene una estructura estática. Como ninguno de los colegas conoce la existencia de otros colegas, se logra de esta manera un bajo acoplamiento 15, para efectuar cambios sin afectar los otros componentes. En la figura 1 se muestra la especificación en RAPIDE correspondiente al componente mediator. Obsérvese que mediator conoce a los colegas en tiempo de compilación y no en tiempo de ejecución, lo que evidencia la naturaleza no dinámica y por lo tanto poco flexible (se entiende por flexibilidad la capacidad de realizar cambios eficientemente). Mediator recibe mensajes de sus colegas, lo que se traduce en la invocación de la acción recibir_mensaje (y por lo tanto en la generación de eventos del mismo nombre) y luego envía los mensajes a los Colegas, provocando eventos enviar_mensaje_a_colega.. Junto con la descripción de los componentes, se debe indicar la arquitectura global del patrón, para lo cual se deben declarar los componentes constituyentes, así como las reglas de conexión arquitectónicas, entre estos (véase la figura 2). type mediator is interface action in recibir_mensaje(d:data;s:tipo_mensaje); out enviar_mensaje_a_colega:data:c:colega end interface; module newmediator(col1:colega;col2:colega) return mediator is primer_colega: colega is col1; segundo_colega is col2; mensaje_a_recibir_primer_colega: tipo_mensaje is primer_colega.tipo_mensaje_a_recibir; mensaje_a_recibir_segundo_colega: tipo_mensaje is col2.tipo_mensaje_a_recibir; parallel when (?dat:data?t:tipo_mensaje) recibir_mensaje(?dat,?t) where?t=mensaje_a_recibir_primer_colega do enviar_mensaje_a_colega(?dat.primer_colega); when (?dat:data;?t:tipo_mensaje) recibir_mensaje(?dat.?t) where?t=mensaje_a_recibir_segundo_colega do enviar mensaje_a_colega(?dat.segundo_colega); Figura 1. Especificación del componente Mediator architecture modelo_patron_mediator is colega1:colega is newcolega(leer_entero("tipo de mensaje a enviar:"), leer_entero("tipo de mensaje a recibir:"), leer_entero("cantidad de mensajes a enviar:")); colega2:colega is newcolega(leer_entero("tipo de mensaje a enviar:"), leer_entero("tipo de mensaje a recibir:"), leer_entero("cantidad de mensajes a enviar:")); M:mediator is newmediator(colega1,colega2); connect (?D:data:?C:colega) M.enviar_mensaje_a_colega(?D,?C) => (?C:recibir_mensaje_de_mediator(?D); (?C:colega;?D:data;?T:tipo_mensaje)?C.enviar_mensaje(?T,?D) => M.recibir_mensaje(?D,?T); Figura 2. Arquitectura global del patrón Mediator Si tales conexiones formasen parte de un patrón de eventos dentro de un componente, entonces actuarían como enlaces entre el llamado cuerpo del evento y su gatillo. En realidad, las reglas de conexión son también patrones de eventos que en este caso gobiernan la comunicación entre los eventos que ocurren en distintos componentes. La especificación propuesta (figuras 1 y 2) logra evidenciar en forma clara la naturaleza poco flexible del patrón, puesto que no toma en cuenta la adición de componentes tanto clientes como servidores en tiempo de ejecución. Igualmente, evidencia la función de intermediario del componente Mediador en la interacción que se produce entre los componentes Colegas. Por último, se produjo una especificación del comportamiento de cada uno de los componentes que intervienen en el patrón, acorde a la descripción contenida en los catálogos consultados 4 ; y esto a través de la aplicación de posets, lo que permite afirmar que tales mecanismos RAPIDE son eficientes para 4

5 describir comportamientos de componentes a un alto nivel de abstracción, y al mismo tiempo con un grado de formalidad notable. Patrón Publisher-Subscriber Este patrón facilita la cooperación entre componentes sincronizados. Esto se logra mediante la propagación de los cambios en una dirección, es decir, el Publisher notifica a un número determinado de Subscribers acerca de los cambios de su estado 1. También es conocido como Observer 11 y está compuesto por 4 : Componentes - Un Publisher: el cual conoce a sus Subscribers. Muchos Subscribers pueden estar unidos a un Publisher. Este puede aceptar nuevos Subscribers durante la ejecución del sistema, y también los puede eliminar, por lo que el número de Subscribers no es fijo. Además, este componente debe guardar el estado de la información que es importante para los Subscribers y enviarles notificaciones de estos cambios. - Subscribers: los cuales son notificados de los cambios que se realizan en el Publisher, manteniéndose de esta forma consistencia entre la información contenida en el Subscriber y la información contenida en el Publisher. Comportamiento En la descripción que se propone de este patrón los subscriptores, una vez que se han registrado con el Publisher, pueden recibir la información que para ellos es importante. En este caso, la descripción que se propone atiende a las características del tipo push, es decir que: el componente Publisher recibe información que luego es enviada a todos los Subscriber registrados a manera de difusión ( Broadcasting ) Por otra parte, a diferencia del patrón Mediator, los componentes Subscribers llegan a ser conocidos por el Publisher en tiempo de ejecución, permitiendo la adición de nuevos suscriptores en forma dinámica favoreciendo así la flexibilidad para la reconfiguración en tiempo de ejecución de la arquitectura (adición o remoción de componentes, por ejemplo). En la figura 3 se muestra la descripción del tipo de componente Subscriber. En ella se especifica que estos componentes deben comportarse de la siguiente forma: antes de comenzar a recibir información, cada Subscriber debe registrarse con el Publisher, lo cual significa que es agregado a la estructura arquitectónica del patrón, evidenciándose su naturaleza dinámica. Un componente Publisher se comporta de la siguiente forma: - Registra a cada Subscriber, o sea, guarda la información referente a la identidad de cada Subscriber en forma dinámica. - Recibe información del ambiente y la comunica a los componentes Subscribers. Obsérvese además que mientras la descripción del componente Subscriber consiste de una interfaz y de un módulo generador, la descripción del componente Publisher solo viene dada por su interfaz, en la cual se especifica el comportamiento del mismo dentro de la arquitectura global. Cuando se genera una simulación de esta descripción, la instancia del componente Publisher se produce a partir de dicha interfaz, puesto que RAPIDE generará un módulo generador por defecto. Esto permite observar que en RAPIDE, una arquitectura puede ser representada tan solo a través de la especificación de las interfaces de los componentes constituyentes. De esta forma, la aplicación de RAPIDE permitió producir simulaciones de este patrón (ver figura 4) en las cuales se evidenció la naturaleza dinámica del mismo. Con lo anterior se quiere significar el hecho de que la descripción propuesta genera simulaciones que evidencian la flexibilidad, permitiendo la adición o remoción de nuevos componentes Subscribers a la arquitectura. Por otra parte, para lograr producir una simulación efectiva y real, fue necesario agregar a la descripción el elemento Ambiente, cuya función es representar el medio ambiente externo al patrón del cual llega información que luego es distribuida entre los Subscribers, generando además nuevos componentes Subscriber que son agregados a la arquitectura. Tal elemento es sin embargo extraño al patrón Publisher, de manera que su inclusión en la descripción propuesta debió ser manejada de manera tal que no se produjese la alteración de la estructura arquitectónica original del patrón. Gracias a que las herramientas que dan soporte a RAPIDE permiten generar vistas distintas de una simulación, fue posible aislar aquellos componentes que realmente conforman al patrón Publisher, así como las trazas de eventos por estos producidos durante las simulaciones realizadas. Patrón Client-Dispatcher-Server Este patrón introduce una capa intermedia entre los clientes y servidores proporcionando de esta forma localizaciones transparentes que encapsulen los detalles de comunicación entre clientes y servidores 4. Es aplicable a sistemas en los que existan componentes servidores distribuidos, bien sea localmente o a través de una red. Cuando un sistema tiene estas características, debe contar con mecanismos para establecer canales de comunicación entre los servidores y los clientes, que en muchos casos, deben ser establecidos antes de que la interacción entre los componentes se lleve a cabo, puesto que ésta depende de la confiabilidad de tales canales. 5

6 type subscriber is interface action out eliminarse_de_registros(s:subscriber); out registrarse(s:subscriber); in recibir_mensaje_de_publisher(i;información); in aceotado(); end interface module newsubscriber() return subscriber is tipo_mensaje_a_recibir: tipo_mensaje is leer_entero("tipo de mensaje a recibir:"); n_mensaje_a_recibir: integer is leer_entero("canitdad de mensajes a recibir:"); mensajes_recibidos:var integer = 0; action mensaje_recibido(i:informacion); parallel when (?informacion) recibir_mensaje_de_publisher(? ) where? =tipo_mensaje_a_recibir do if ($mensajes_recibidos < n_mensajes_a_recibir) then mensajes_recibidos(?i); mensajes_recibidos:=$mensajes_recibidos+1; else eliminarse_de_registro(self); end if; when aceptado() do registrarse (self)) Figura 3. Especificación parcial del componente Subscriber type modelo_patron_publisher is interface action in agregar_nuevo_subscriber (); in recibir_informacion_de_ambiente(i:informacion); behavior end interface module patron_publisher() return modelo_patron_publisher is action agregado(s:subscriber); connect (?S:subscriber)?S.eliminarse_deregistro(?S) >P:eliminar_registro(?S); (?I:informacion) recibir_informacion_de_ambiente(?i) => P.recibir_infromacion(?I); (?S:subscriber)agregado(?S) >?S.aceptado); architecture simulacion () is A: ambiente; X:modelo_patron_publisher is patron_publisher(); connect A:nuevo() > X.agregar_nuevo subscriber(); (?Informacion)A:enviar_informaci(?I) > X.recibir_informacion_de_ambiente(?I); end simulación Figura 4. Arquitectura global del patrón Publisher-Subscriber con simulac La estructura del patrón Client-Dispatcher-Server es como sigue: Componentes - Clientes: los cuales llevan a cabo tareas de dominio específico, accediendo a operaciones ofrecidas por los servidores cada vez que sea necesario. Antes de realizar un requerimiento a un servidor, el cliente pregunta al Dispatcher por un canal de comunicación. Si dicho canal está disponible, entonces lo utiliza para comunicarse con el servidor. - Servidores: los cuales proveen una serie de servicios a los clientes, registrándose previamente con el componente Dispatcher. Un componente servidor puede estar localizado en la misma computadora en la que se encuentra el cliente, o puede estar localizado en algún lugar de la red. - Dispatcher: que ofrece las funcionalidades necesarias para el establecimiento de los canales de comunicación entre los clientes y los servidores. El Dispatcher establece un vínculo entre el nombre del servidor y su dirección física en la red, de forma que un cliente sólo tiene que preguntar por ese nombre siendo el Dispatcher el encargado de localizar al servidor correspondiente. Una vez que el Dispatcher consigue al servidor, establece un enlace de comunicación con el servidor y lo entrega al cliente, produciéndose de esta forma un enlace directo entre el cliente y el servidor. Si el Dispatcher no puede establecer el canal de comunicación entonces retorna al cliente un mensaje de error. Comportamiento En dicha descripción se puede observar que todo componente Cliente que se genere durante una simulación, se debe comportar de la siguiente manera: - Una vez agregado dinámicamente a la arquitectura del patrón, ejecuta una tarea. - Solicita al componente Dispatcher la dirección de un Servidor que ofrezca los servicios por él requeridos. Después de lo cual queda en espera de tal dirección (comunicación síncrona). - Al recibir la dirección del Servidor correspondiente, establece un canal de comunicación con él, tras lo cual le solicita una serie de servicios. Un Cliente puede solicitar al Dispatcher la ubicación de un servicio que no está registrado en él, por lo que recibiría en consecuencia un mensaje de error. Un componente Servidor se comporta de la siguiente forma: - Una vez que se ha agregado a la arquitectura del patrón, se registra con el componente Dispatcher. - Recibe los posibles requerimientos que a él pueda realizar algún Cliente y les envía los resultados después de ejecutar los servicios solicitados. 6

7 Junto a los dos componentes anteriormente mencionados, y sirviendo de intermediario, se encuentra el componente Dispatcher, el cual cumple las siguientes tareas, según la descripción propuesta: - Registra a Servidores y los servicios que estos ofrezcan. - Retorna a los Clientes las direcciones de los Servidores que pueden hacer frente a sus requerimientos, tras lo cual queda como responsabilidad de los Clientes la administración de las conexiones establecidas. De esta manera, el papel de intermediario que lleva a cabo este componente es distinto al de los componentes Mediator y Publisher de los patrones anteriormente tratados, puesto que mientras estos dos últimos controlan totalmente la interacción, obligando a que todas las interacciones tengan que pasar a través de ellos, el Dispatcher solo se limita a dispensar a los Clientes la dirección de los Servidores. Además, es también flexible en tiempo de ejecución, como el Publisher. Los detalles de la especificación y del compartamiento en la simulación pueden verse en 12. Se concluye entonces que RAPIDE permite representar interacciones tanto síncronas como asíncronas. Por otra parte, merece especial mención el hecho de haber podido, no solo agregar componentes a la arquitectura en forma dinámica, sino también simular el establecimiento de conexiones entre componentes también en forma dinámica. Recuérdese que un componente Cliente no conoce a priori la ubicación del Servidor del cual va a requerir un servicio; más bien debe solicitar el Dispatcher la dirección de tal servidor si es que está disponible, luego de lo cual busca establecer con este una conexión que le permita finalmente solicitar el servicio. La figura 5 muestra una especificación parcial del componente cliente, para un caso de error: when ejecutar_tarea do solicitar_dirección_servvidor(tipo_servicio_a_solicitar,self); await (?D:direccion)recibir_direccion(?D) => direccion_servidor:=?d; hacer_requerimiento ($direccion_servidor,nueva_data()); or recibir_error() => sin_servidor(); Figura 5: Un tratamiento de error en el componente Cliente Patrón Broker Es un patrón arquitectónico aplicado a la estructuración de sistemas distribuidos, en los cuales es necesaria la interacción remota de componentes altamente desacoplados 4. Lo anterior se logra al introducir un componente Broker cuya función principal es lograr el desacoplamiento de los clientes y de los servidores. También registra a los servidores, logrando de esta forma que los servicios que estos ofrecen estén disponibles a los posibles clientes. Además de los componentes Broker, servidores y clientes, este patrón está también constituido por los componentes de tipo Proxy y por los componentes de tipo Bridges. Los Proxies, pueden ser de dos tipos: client-side-proxy y server-side-proxy. Los proxies del primer tipo pueden ser considerados como una capa entre los clientes y el Broker, la cual proporciona transparencia puesto que gracias a ella un servidor remoto aparece ante un componente cliente como local. Los proxies del segundo tipo son análogos a los del primer tipo, sin embargo difieren en que son responsables de recibir peticiones y desempaquetarlas con el fin de llamar al servicio correcto. Además se encargan de recibir resultados y excepciones del servidor, empaquetarlos y enviarlos al Broker. Por otra parte, los componentes Bridges tienen como principal función ocultar los detalles de implementación de los mecanismos de interoperatividad entre dos Brokers; así, si estos corren en redes distintas, pueden, no obstante, comunicarse entre si independientemente de los sistemas operativos sobre los cuales ellos corren. Ahora bien, una de las características deseables en un ADL, es la capacidad de ofrecer distintas vistas de una misma arquitectura compleja, de manera que se facilite su estudio. En el caso de la arquitectura del patrón Broker, esta característica tiene gran importancia para su representación en RAPIDE debido a su complejidad; la cual específicamente se reflejó en el hecho de que las simulaciones realizadas mediante la utilización de la herramienta POV produjeron una gran cantidad de eventos. Por ejemplo, una prueba realizada en la cual intervenían dos componentes de tipo Broker, cada uno con dos componentes Clientes y dos componentes Servidores, produjo una traza que contenía cerca de 1800 eventos) haciendo verdaderamente complejo el estudio y la verificación de la descripción propuesta. Sin embargo, la herramienta POV permitió producir varias vistas por medio del filtrado de eventos, lográndose así aislar varios casos de interacción, facilitándose de esta manera el estudio del patrón. Las vistas escogidas para la verificación de la descripción RAPIDE propuesta fueron: interacción entre Clientes y Servidores locales, e interacción entre Clientes y Servidores en forma remota. De la simulación producida mediante la herramienta POV, para clientes y servidores locales, se logró definir una vista que mostró la interacción entre clientes y servidores registrados con un mismo Broker, por lo que la interacción entre ellos puede ser considerada en forma local. La figura 6 muestra una traza de eventos en la que se evidencia este tipo de interacción. En ella se puede observar que una vez que un componente Cliente es agregado a la arquitectura, se genera un componente Proxy del lado del Cliente, el cual se encargará de enviar los requerimientos al componente Broker y enviar luego los resultados a su Cliente. El componente Cliente, una vez integrado a la arquitectura global, realiza requerimientos al componente Broker a través de su Proxy; 7

8 en forma seguida, el Broker recibe el requerimiento y busca un servidor disponible que pueda hacer frente a este. Si la búsqueda tiene éxito, el Broker procede a enviar al Servidor el requerimiento a través de su Proxy. Una vez que el Servidor recibe el requerimiento, genera una respuesta y la envía de retorno al Broker que será el encargado de devolver a su vez la respuesta al Cliente que originalmente hizo el requerimiento. Con respecto a la interacción entre clientes y servidores en forma remota, se utlizó el componente Bridge. En la descripción propuesta, dos componentes de tipo Arquitectura Broker interactúan, siendo que en realidad tales componentes tienen una arquitectura interna compuesta por un componente Broker, un componente Bridge, varios componentes Servidores y varios componentes Clientes. Un componente Broker puede interactuar con otro Broker, pero siempre a través de los componentes de tipo Bridge, el cual tiene como tarea establecer mecanismos que permitan la comunicación entre componentes de tipo Broker con diferentes mecanismos de comunicación que corran además en distintos sistemas operativos o en distintos ambientes, favoreciendo así la portabilidad. Cabe destacar que las características de calidad más importantes que se pusiern en evidencia para el patrón Broker fueron: la interoperabilidad, la transparencia de ubicación, la capacidad de manejar los cambios con eficiencia (flexibilidad) y la adaptabilidad (portabilidad). En la tabla 2 18, se resume la información de los cuatro patrones tratados en la presente sección, atendiendo a las características de calidad relacionadas con estos. Obsérvese que la modificabilidad es común a los cuatro patrones; sin embargo es necesario mencionar que mientras el Mediator permite conseguir modificabilidad en tiempo de compilación, los restantes están dirigidos lograr la modificabilidad en tiempo de ejecución, lo que evidencia un comportamiento dinámico. Patrón Componentes Comportamiento Características de calidad Mediator mediador, colegas estático Cambios a nivel estático Publisher/-Subscriber publisher, subscribers dinámico Cambios a nivel dinámico, eficiencia, Client-dispatcher-server Broker clientes, dispatcher, servidores Broker, proxies, servidores, clientes, bridges dinámico dinámico seguridad Cambios a nivel dinámico, transparencia respecto a la ubicación. portabilidad (configurabilidad), confiabilidad (tolerancia a fallas) Cambios a nivel dinámico, extensibilidad, reutilización, portabilidad (adaptabilidad), transparencia respecto a la ubicación Tabla 2. Patrones utilizados para modelar las comunicaciones en sistemas distribuidos y sus características de calidad 18. Conclusión La aplicación del ADL RAPIDE, produjo un alto nivel de formalidad en las descripciones de los patrones tratados en este trabajo. Las simulaciones producidas a partir de esta especificación, se proponen como una forma de auxiliar la comprensión del comportamiento y de la estructura de tales patrones a un alto nivel de abstracción 12. El análisis de las simulaciones puede ayudar en el proceso de selección de arquitecturas durante las primeras fases del desarrollo. Una característica arquitectónica que es necesario mencionar es el comportamiento dinámico o estático de las estructuras de los patrones estudiados (véase tabla 2). En este sentido, se tiene que el patrón Mediator es el único que muestra un comportamiento esencialmente estático, mientras que los otros tres patrones poseen una estructura de naturaleza esencialmente dinámica, lo que significa que presentan una mayor flexibilidad, es decir que los cambios se pueden efectuar eficientemente, es decir en un tiempo y espacio aceptables. Debido a esta característica pueden ser utilizados en sistemas reconfigurables, como por ejemplo aplicaciones Web. Sin embargo, debemos señalar que recientemente se han identificado nuevos patrones que intervinene en componentes intermediarios para la integración ó middleware, que facilitan la reconfiguración dinámica, en le sentido de permitir la observabilidad y así favorecer la adición y remoción de componentes en tiempo de ejecución. En un futuro cercano pensamos especificar en RAPIDE estos patrones y así poder evaluarlos. Para su evaluación pensamos utilizar las características de calidad identificadas, estableciendo métricas adecuadas para la arquitectura 16. Las especificaciones propuestas en este trabajo, permitieron explorar las capacidades expresivas de RAPIDE en relación a los siguientes aspectos: especificación de los componentes constituyentes de cada patrón, especificación de los conectores, y caracterización global de las arquitecturas. En relación a este aspecto, RAPIDE, permitió definir distintas vistas, correspondientes a distintos niveles de detalle. Tales vistas consisten en trazas de eventos que pueden ser filtradas según se requiera. De esta forma, la herramienta POV permitió filtrar eventos correspondientes a distintos casos de interacción entre los componentes, 8

9 START AGREGADO CLIENTE START AGREGADO PROXY_CLIENT ACEPTADO ACEPTADO ENVIAR REQUERIMIENTO EJECUTAR TAREA EMPAQUETAR DATOS LLAMAR SERVIDOR RECIBIR REQUERIMIENTO START RECIBIR START REQUERIMIENTO RECIBIDO BUSCAR SERVIDOR REGISTRARSE REGISTRAR SERVIDOR ENVIAR REQUERIMIENTO SERVER SERVIDOR ENCONTRADO SOLICITAR SERVICIO REQUERIMIENTO ENVIADO SERVER DESEMPAQUETAR DATOS GENERAR RESPUESTA LLAMAR SERVICIO CORRER SERVICIO RECIBIR REQUERIMIENTO ENVIAR RESPUESTA RESPUESTA RECIBIDA RECIBIR RESPUESTA RECIBIR RESPUESTA EMPAQUETAR DATOS ENVIAR RESPUESTA ENVIAR RESPUESTA RECIBIR DESEMPAQUETAR DATOS RECIBIR RESPUESTA ENVIAR RESPUESTA New Client New Clent Side Proxy Arquitectura Broker New Server NewBroker New Server Side Proxy Figura 6. Traza de eventos para la simulación del patrón Broker para la interacción local entre clientes y servidotres 9

10 así como del comportamiento global de las arquitecturas. En cuanto a la problemática planteada en por Shaw y Clements 25, se puede concluir que RAPIDE mostró una gran capacidad expresiva para la descripción de las soluciones que cada uno de los patrones estudiados plantea. Una consecuencia natural que se deriva esta investigación es aprovechar la capacidad de los lenguajes de modelado 10, como por ejemplo UML 8 y ROOM 24 para capturar información altamente intuitiva combinándola con el alto grado de formalidad que pueden ofrecer los ADLs. 7 El hecho de que las especificaciones RAPIDE sean de naturaleza formal y que al mismo tiempo se puedan generar a partir de ellas simulaciones, sugiere que éstas pueden facilitar el proceso de selección de los patrones tanto de diseño como arquitectónicos. Finalmente, no podemos dejar de mencionar también que RAPIDE puede ser de gran ayuda como un medio didáctico en cursos de Arquitectura e Ingeniería del Software. Referencias 1. Allen R. A Formal Approach to Software Architecture. School of Computer Science. Carnigie Mellon University. CMU-CS pp Allen R., Douence R., Garlan D. Specifying and Analyzing Dynamic Software Architectures. Proceedings of 1998 conference on Fundamental Approaches to Software Engineering Lisbon. Portugal, Marzo pp Appleton B. Patterns and Software: Essential Concepts and Terminology pp Buschmann F., Meunier R., Rhonert H., Sommerland P., Stal M. Patern Oriented Software Architecture. A System of Patterns. Jhon Wiley & Sons, pp , Dabrowski C., Mills K. Analyzing Properties and Behavior of Service Discovery Protocols Using an Architecture-Based Approach. Maryland: National Institute of Standards and Technology pp Dabrowski C., Mills K., Elder J. Understanding Consistency Maintenance in Service Discovery Architectures During Communication Failure. Maryland: National Institute of Standards and Technology pp De La Puente J. Real-time Object-Oriented Design and Formal Methods. Dept. of telematics Engineering. School of Telecommunication. Technical University of Madrid pp Egyed A., Medvidovic N. Extending Architectural Representation in UML With View Integration. 2 nd ICUML. Oct.ober pp Egyed A., Wile D. Statechart Simulator for Modeling Architectural Dynamics. 2 nd WICSA, Amsterdam. Aug. 2001, pp France R. The UML as a Formal Modeling Notation. Department of Computer Science & Engineering. Florida Atlantic University. Florida pp Gamma E., Helm R., Johnson R., Vlissides J. Design Patterns: Abstraction and Reuse of Object Oriented Design. Proceedings of ECOOP 93, pp Guillén C. Descripción de Patrones Arquitectónicos para Sistemas Distribuidos. Tesis de maestría. Universidad Central de Venezuela, Caracas, Venezuela, Mayo Kazman R., Klein M., Barbacci M., Longstaff T., Lipson H., Carriere J. The Architecture Tradeoff Analysis Method. CMU/SEI-98-TR-008, ESC-TR pp Klein M., Kazman R. Attribute-Based Architectural Styles. CMU/SEI-99-TR-022, ESC-TR pp Levy N., Losavio F. Analyzing and Comparing Architectural Styles. Proc. IEEEXIX SCCC 99, Chile Nov 99. pp Losavio F., Chirinos L., Lévy, N., Ramdane-Cherif A.,. Quality Characteristics for Software Architecture, Journal of Object Technology. March/April Vol 2, No. 2, pp Losavio F., Chirinos L., Pérez M. Attribute-Based Techniques to Evaluate Architectural Styles: a Case Study for Interactive Systems. Acta Científica Venezolana, Vol. 53, No. 2, pp Losavio F., Ortega D., Pérez M. Modeling EAI. Proceeding IEEE of XXII International Conference of the Chilean Computer Science Society. Noviembre pp Luckham D., Kenney J., Augustin L., Vera J., Bryan D., Mann W. Specification and Analysis of System Architecture Using RAPIDE pp Luckham D., Vera J. Event-based Concepts and Language for System Architecture pp RAPIDE Design Team. RAPIDE 1.0 Architecture Language Reference Manual. Program Analysis and Verification Group, Computer Systems lab. Stanford University pavg.stanford.edu/rapide/. pp RAPIDE Design Team. RAPIDE 1.0 Language Reference Manual. Program Analysis and Verification Group, Computer Systems lab. Stanford University pavg.stanford.edu/rapide/. pp RAPIDE Design Team. RAPIDE 1.0 Pattern Language Reference Manual. Program Analysis and Verification Group, Computer Systems lab. Stanford University pp Rumpe B., Schoenmakers M., Radermacher A., Schürr A. UML + ROOM as a Standard ADL? Proceedings of ICECCS pp Shaw M., Clements P. How Should Patterns Influence Architectural Description Languages? A Call for Discussion. Computer Science Department and Software Engineering Institute Carnegie Mellon University pp Shaw M., Garlan D. Software Architecture, Perspectives on an Emerging Discipline. Prentice Hall, New Yersey, pp