Estilos arquitect´ onicos empleados

Fastest fue desarrollado siguiendo una arquitectura Cliente/Servidor [27]. En este tipo de sistemas, un servidor representa un proceso que provee servicios a otros procesos llamados clientes. Es usual que los servidores no conozcan, en principio, la identidad de los clientes que tendr´an acceso a ellos en tiempo de ejecuci´on. Por otro lado, son los clientes quienes conocen la identidad de un servidor. En el caso de Fastest, habr´a un servidor particular, el servidor de datos, donde entre otra informaci´on se encontrar´a el registro de todos los dem´as servidores, los servidores de c´omputo.

La raz´on principal por la cual se eligi´o el mencionado estilo arquitect´onico fue la de aprovechar efi- cientemente los recursos que provee una red de computadoras. Principalmente, se ha buscado obtener mayor desempe˜no ejecutando varias tareas en paralelo, pero adem´as, tener la posibilidad de correr m´as de un cliente de Fastest en distintas terminales. Todos los clientes deben consultar a un ´unico reposi- torio de datos, ubicado en el llamado servidor de datos. Por otra parte, estos solicitan a los servidores de c´alculo la generaci´on de casos de prueba abstractos y la comprobaci´on de correspondencia entre casos de prueba abstractos, especificaci´on y salida abstracta resultante de la ejecuci´on de tales casos. Para que todos los componentes de una arquitectura Cliente/Servidor cooperen entre s´ı, se deben emplear ciertas t´ecnicas de comunicaci´on intercomponentes. En teor´ıa, hay tres tipos b´asicos de t´ecni- cas de comunicaci´on de procesamiento cooperativo que una arquitectura Cliente/Servidor puede usar:

Tubos

Llamadas a procedimiento remotos Interacciones Cliente/Servidor SQL

CAP´ITULO 5. DESCRIPCI ´ON DE FASTEST 42

Los tubos son mecanismos orientados a la conexi´on que pasan datos de un proceso a otro. En principio, los procesos pueden estar en diferentes m´aquinas, incluso corriendo sobre distintos sistemas operativos. Los detalles de los mecanismos de transporte soportados est´an ocultos a los usuarios de un tubo y los tubos imponen restricciones m´ınimas de protocolo y formato a los usuarios.

Unallamada a procedimiento remoto es un mecanismo por el cual un proceso puede ejecutar otro proceso (subrutina) que reside en un sistema diferente, y usualmente remoto, posiblemente corriendo en un sistema operativo diferente. Cualquier par´ametro necesario para la subrutina es pasado entre el proceso original y el de la subrutina. Al igual que con los tubos, los detalles del mecanismo de transporte se ocultan al usuario de la llamada a procedimiento.

Una interacci´on Cliente/Servidor SQL es un mecanismo que permite pasar consultas Structured Query Language (SQL) y los datos asociados a ellas de un proceso (usualmente un cliente) a otro pro- ceso (servidor). Esta es un caso especial de interacci´on Cliente/Servidor, que se utiliza en el contexto de aplicaciones de base de datos relacionales distribuidas. En este caso, el servidor es el servidor de la base de datos relacional. Este puede residir en un sistema diferente y posiblemente corriendo en un sistema operativo distinto. Mientras los detalles de los mecanismos de transporte est´an ocultos por los desarrolladores de aplicaciones, las interacciones Cliente/Servidor de SQL imponen restricciones severas de protocolos y formato a los usuarios.

En el caso de Fastest, para realizar las interacciones entre clientes y servidores de c´omputo se utilizaron unos tubos particulares llamadossockets. Los sockets establecen una abstracci´on a trav´es de la cual dos programas (posiblemente situados en computadoras distintas) pueden intercambiar flujos de datos, generalmente de manera fiable y ordenada. Un socket queda definido por una direcci´on IP, un protocolo y un n´umero de puerto.

Por otro lado, cada cliente de la arquitectura Cliente/Servidor es organizado de acuerdo a una arquitectura de Invocaci´on Impl´ıcita. La idea detr´as de la Invocaci´on Impl´ıcita, la cual se ilustra en la Figura5.2, es que los componentes invoquen los servicios provistos por otros componentes a trav´es de un mecanismo indirecto. En efecto, un componente puede anunciar uno o m´as eventos. Los compo- nentes del sistema pueden registrar inter´es en un evento, asociando a ´el un procedimiento. Cuando el evento es anunciado por alg´un componente, el propio sistema (a trav´es de un administrador de even- tos) invoca a todos los procedimientos que anteriormente registraron inter´es en tal evento. Entonces, el anuncio de un evento “impl´ıcitamente” causa la invocaci´on de procedimientos en otros m´odulos. En t´erminos arquitect´onicos, los componentes en un estilo de Invocaci´on Impl´ıcita son m´odulos cuyas interfaces pueden proveer tanto una colecci´on de procedimientos como un conjunto de eventos. Los procedimientos pueden ser invocados de la forma usual, pero un componente puede tambi´en registrar algunos de sus procedimientos con eventos del sistema. Esto causar´a que tales procedimientos sean invocados cuando los eventos de inter´es sean anunciados en tiempo de ejecuci´on [26].

El principal invariante del estilo es que los anunciantes de eventos no conocen qu´e componentes ser´an afectados por los eventos que pueden lanzar. Por esta raz´on, los componentes no tienen la posi- bilidad de hacer suposiciones acerca del orden de procesamiento, ni sobre si el procesamiento ocurrir´a o no como resultado del anuncio de determinado evento [28]. El beneficio m´as importante de este as-

CAP´ITULO 5. DESCRIPCI ´ON DE FASTEST 43

Figura 5.2: El estilo arquitect´onico de Invocaci´on Impl´ıcita.

pecto, y el principal motivo que llev´o a elegir este estilo para organizar los clientes de Fastest, es que facilita enormemente la evoluci´on del sistema: los componentes pueden ser reemplazados por otros componentes o pueden agregarse otros nuevos sin afectar las interfaces de los ya existentes.

En este sistema, la capacidad din´amica de poder agregar y quitar componentes del sistema se con- trola a trav´es de un archivo de configuraci´on donde se indica qu´e procedimientos de qu´e componentes est´an interesados en qu´e eventos. Simplemente lo que se hace es leer este archivo de configuraci´on al momento de iniciar el cliente del sistema, almacenando en una tabla dentro del administrador de eventos las relaciones entre eventos, componentes y procedimientos de componentes. Por esto, aunque la declaraci´on de eventos es est´atica (dado que el conjunto posible de eventos queda fijado en tiempo de compilaci´on), el binding entre eventos y procedimientos es din´amico: los componentes registran su inter´es en eventos en tiempo de ejecuci´on. La declaraci´on de eventos es centralizada: nos pareci´o su- ficiente contar con un ´unico administrador de eventos. En cuanto a la estructura de los eventos, se decidi´o que los mismos tengan una lista de par´ametros por tipo de evento, es decir, cada evento tiene una lista fija de par´ametros pero la cantidad y tipo puede ser diferente para cada evento.

Si bien en t´erminos de arquitectura se habla de Invocaci´on Impl´ıcita, la implementaci´on de este mecanismo se realiz´o a trav´es de llamadas a procedimientos tradicionales. Esto es, el anuncio de un evento se lleva a cabo realizando la invocaci´on expl´ıcita de una subrutina particular del administrador de eventos (m´odulo llamado EventAdmin), pasando como par´ametro la instancia del m´odulo que representa al evento. El administrador simplemente consulta su tabla de eventos en busca de el o los procedimiento/s interesado/s en el evento, para luego realizar cada una de las invocaciones en un hilo de proceso diferente. Luego, es responsabilidad del componente ”invocado” (esto es, del cual se invoc´o un procedimiento) obtener los par´ametros relevantes del evento para llevar a cabo la tarea que le corresponde.

CAP´ITULO 5. DESCRIPCI ´ON DE FASTEST 44