Para poder obtener una soluci´on al problema de la interoperabilidad entre los gestores de colas y las herramientas de monitorizaci´on y que cubra todos los puntos mencionados anteriormente, se puede optar principalmente por dos dise˜nos:
a) Integrar la soluci´on en sus respectivos c´odigos ejecutables:
Este dise˜no de la soluci´on (figura 3.2) se basa en desarrollar las estructuras de datos y operativas (funciones, objetos, etc) que solucionan el problema de interoperabilidad entre los gestores de colas y herramientas de monitorizaci´on para ser integradas dentro de sus respectivos c´odigos ejecutables. Una buena opci´on para implementar este dise˜no, pensando en la modularizaci´on y reutilizaci´on del c´odigo, es encapsular estas
46 3. Problema de Interoperabilidad
estructuras de datos y operativas en una librer´ıa o conjunto de librer´ıas especiales, las cuales se incorporaran (est´atica o din´amicamente) en los c´odigos ejecutables de los gestores de colas y las herramientas de monitorizaci´on. De esta forma, cada acci´on o intercambio de informaci´on que deban realizar sus componentes, se traducir´a en un conjunto de llamadas a las funciones definidas en estas librer´ıas especiales. Esta opci´on implica disponer de los c´odigos fuentes (mayoritariamente escritos C,C++ o java) de los gestores de colas y de las herramientas de monitorizaci´on, para poder situar en ellos las llamadas a las funciones de estas librer´ıas especiales y generar sus nuevos c´odigos ejecutables. Estos c´odigos tambi´en contendr´an el c´odigo ejecutable de las librer´ıas, en caso que estas sean est´aticas o la informaci´on para el enlazador din´amico del sistema operativo (ld en Linux) en caso de que sean din´amicas y se deban enlazar en tiempo de ejecuci´on. Respecto al formato de estas librer´ıas especiales, el recomendado es el din´amico por dos motivos, el primero es que permiten que m´ultiples programas puedan usar una copia de esta librer´ıa al mismo tiempo, permitiendo generar ficheros ejecutables m´as peque˜nos y el segundo es que al enlazarse din´amicamente en tiempo de ejecuci´on, estas librer´ıas permiten modificar su c´odigo sin tener que recompilar los programas fuente para incluir su c´odigo en ellos (como las est´aticas).
Sin contar con el esfuerzo en generar la parte de la soluci´on encapsulada en la librer´ıa, este dise˜no tiene diversos inconvenientes importantes:
La complicaci´on o incluso la imposibilidad de obtener el c´odigo fuente de ciertas herramientas de monitorizaci´on y gestores de colas. Esto es debido a que algunos de ellos son productos comerciales bajo licencia (por ejemplo Totalview) o ´
unicamente se distribuyen sus c´odigos binarios (como Condor).
La necesidad de poseer conocimientos avanzados de ingenier´ıa del software y de lenguajes de programaci´on, debido a que la mayor´ıa de los c´odigos fuente de los gestores de colas y herramientas de programaci´on est´an escritos en lenguajes de alto nivel como C, C++ o Java. Adem´as, para controlar y gestionar la ejecuci´on de los procesos con los que trabajan, estos gestores de colas y herramientas de monitorizaci´on utilizan llamadas al sistema operativo (en sistemas UNIX/Linux: signals, ptrace o kill) o a funciones de librer´ıas especiales (Paradyn utiliza la librer´ıa Dyninst para insertar c´odigo en los procesos que monitoriza), lo cual obliga al dise˜nador de este tipo de soluci´on a poseer tambi´en amplios
3.2. Estudio de las posibles soluciones al problema de interoperabilidad 47
Figura 3.2: Esquema dise˜no de la soluci´on integrada en el c´odigo fuente de los gestores de colas y herramientas de monitorizaci´on.
conocimientos sobre ellos.
El c´odigo fuente de los gestores de colas y las herramientas de monitorizaci´on, como la mayor´ıa de grandes aplicaciones inform´aticas, suele estar distribuido entre diversos programas fuente (.h, .cpp o .java), cuyo tama˜no puede oscilar entre unas decenas o centenares de miles (o incluso millones) de l´ıneas de c´odigo. A parte de estas caracter´ısticas, estos c´odigos fuente no suelen incluir demasiada (o incluso ninguna) informaci´on sobre la codificaci´on realizada en ellos, ya sea utilizando comentarios en el mismo c´odigo o en manuales externos creados por los propios programadores. Todo ello implica dedicar una considerable cantidad de tiempo a comprender la codificaci´on realizada en estos c´odigos fuente, tanto para poder averiguar en que puntos se puede obtener la informaci´on necesaria, como donde se deben modificar para incluir el nuevo c´odigo de la soluci´on al problema.
48 3. Problema de Interoperabilidad
Figura 3.3: Esquema del dise˜no de la soluci´on formada por un entorno intermedio de trabajo.
El dise˜no de esta segunda soluci´on para problema de interoperabilidad entre gestores de colas y herramientas de monitorizaci´on (como se puede ver en figura 3.3) consiste en desarrollar un entorno de trabajo intermedio. Este entorno estar´a formado por un conjunto de componentes, los cuales podr´an ser procesos, ficheros especiales o shell- scripts, que se encargar´an de interactuar con los gestores de colas y herramientas de monitorizaci´on, para poner en ejecuci´on, de una forma sincronizada, los componentes locales (en la m´aquina local del usuario) y remotos (en las m´aquinas del cluster) de estas ´ultimas. Debido a que esta soluci´on no est´a integrada en el c´odigo ejecutable de estos gestores de colas y las herramientas de monitorizaci´on, no ser´a necesario dedicar una importante cantidad de tiempo a comprender sus c´odigos fuentes, permitiendo centrar el tiempo en el dise˜no de la soluci´on al problema.
Los componentes del entorno de trabajo intermedio deber´an realizar las siguientes funciones importantes:
3.2. Estudio de las posibles soluciones al problema de interoperabilidad 49
descripci´on de trabajos, del entorno de ejecuci´on remoto que han de crear, el cual les informa de las acciones a realizar para que se puedan ejecutar correctamente, en las m´aquinas de su cluster, los posibles componentes remotos que intervienen en el proceso de monitorizaci´on. Estos componentes pueden ser: Los procesos de la aplicaci´on, los componentes remotos de la herramienta y si es necesario, algunos componentes de este entorno intermedio que realicen ciertas acciones en las m´aquinas del cluster.
Un ejemplo de las acciones que realizan estos entornos de ejecuci´on remotos, creados por los gestores de colas, podr´ıa ser la creaci´on de la variable de entorno que necesita uno de los componentes del entorno intermedio, la cual le informa de la direcci´on del ejecutable del componente remoto de la herramienta que este ha de ejecutar.
2) En caso de su existencia, aprovechar los mecanismos que ofrecen las herramientas de monitorizaci´on, para obtener la informaci´on necesaria de como ejecutar sus componentes remotos. En el caso de Paradyn, se puede solicitar a su componente local que devuelva, en un fichero, la informaci´on de los argumentos que se le han de pasar a sus componentes remotos. La idea de esta manera de proceder es que estos componentes se puedan ejecutar manualmente, normalmente utilizando terminales remotos abiertos en las m´aquinas del cluster. Por lo tanto, procesando la informaci´on situada en este fichero por el componente local de Paradyn, los componentes de la soluci´on intermedia pueden obtener los argumentos que necesitan los componentes remotos de esta herramienta de monitorizaci´on para su correcta ejecuci´on.
3) Los componentes del entorno de trabajo intermedio deben poseer mecanismos comunicaci´on con los componentes de los gestores de colas y de las herramientas, as´ı como entre ellos, que les permitan enviar y recibir, en el momento temporal adecuado, la informaci´on que necesita cada componente de las herramientas de monitorizaci´on para su correcta ejecuci´on sincronizada. Por ejemplo, la herramienta Gdb necesita conocer el puerto de comunicaci´on de su componente remoto (gdbserver), al cual se le pasa como argumento. Por lo tanto, los componentes de la soluci´on intermedia que se encargan de la ejecuci´on de la parte remota de esta herramienta, deben primero obtener un puerto de
50 3. Problema de Interoperabilidad
comunicaciones libre (usando funciones del sistema operativo o de librer´ıas dedicadas), despu´es ejecutar el componente remoto de Gdb (pas´andole el puerto de comunicaciones como argumento) y finalmente, pasar la informaci´on de este puerto de comunicaciones a los componentes de la soluci´on intermedia que se encargan de la parte local de la herramienta. Una vez tienen esta informaci´on, ya pueden ejecutar el componente local de la herramienta GDB, inform´andole del puerto de comunicaciones donde escucha su componente remoto.
A parte de estos dos dise˜nos, se pod´ıa pensar en un tercer dise˜no h´ıbrido de los dos anteriores para la soluci´on del problema de la falta de inteoperabilidad entre los gestores de colas y las herramientas de monitorizaci´on. Este dise˜no consistir´ıa en dise˜nar una parte de la soluci´on integrada en los c´odigos ejecutables y el resto de la soluci´on mediante un entorno de trabajo intermedio. Al tener una parte de la soluci´on integrada, este tipo de soluci´on puede tener los mismos problemas que aparecen en la soluci´on integrada pura, los cuales son, la necesidad de estudiar los c´odigos fuentes del las herramientas de monitorizaci´on y los gestores de colas y la imposibilidad de conseguir algunos de estos c´odigos fuentes.
Debido a que el dise˜no de la soluci´on integrada en el c´odigo ofrece importantes inconvenientes (estudio de c´odigos fuentes y posible imposibilidad de obtenerlos), el dise˜no del entorno TDP-Shell se ha basado en el tipo de soluci´on de entorno de trabajo intermedio