Desarrollo de aplicaciones distribuidas utilizando Mico CORBA

Transcripción

1 Desarrollo de aplicaciones distribuidas utilizando Mico CORBA Omar Delgadillo, Arnoldo Díaz-Ramírez, Juan Francisco Ibáñez y Heber S. Hernández Departamento de Sistemas y Computación Instituto Tecnológico de Mexicali {odelgadillo, adiaz}@itmexicali.edu.mx, pacois20@gmail.com, heberhdz@hotmail.com Resumen Los sistemas inmersos, debido a la limitación de recursos con los que cuentan, pueden beneficiarse en gran medida de la capacidad de invocar métodos que residen en computadoras remotas. Sin embargo, debido a las diferencias en arquitecturas y plataformas que componen un sistema distribuido que incluya sistemas inmersos, es importante que la comunicación entre las aplicaciones se lleve a cabo de manera consistente. CORBA se ha consolidado como uno de los estándares más importantes para la invocación de métodos remotos. De entre las implementaciones existentes, Mico CORBA destaca por su versatilidad y total cumplimiento del estándar. Desafortunadamente, existe muy poca documentación acerca de la manera de instalar y utilizar esta herramienta. En este artículo se muestra un ejemplo completo de integración de aplicaciones heterogéneas utilizando Mico CORBA. 1. Introducción Un sistema inmerso (embedded system) es un sistema computacional diseñado para desempeñar tan solo una o unas cuantas funciones. Debido a esta especialización, los sistemas inmersos son generalmente dispositivos pequeños y de bajo costo, y por lo tanto, con recursos limitados. La proliferación de sistemas inmersos con capacidad para comunicarse a través de la red, como por ejemplo Internet, ha permitido la implementación de sistemas distribuidos compuestos por aplicaciones y dispositivos heterogéneos. En este tipo de sistemas los recursos pueden compartirse, lo que permite una especialización de las funciones y la posibilidad de que los componentes que cuentan con recursos limitados puedan beneficiarse de servicios que proporcionan otros componentes del mismo sistema [1]. Por ejemplo, a través de un dispositivo móvil (e.g. teléfono celular), puede llevarse a cabo alguna transacción comercial, como por ejemplo, una orden de compra. Sin embargo, para que los sistemas heterogéneos puedan comunicarse de manera eficiente, es necesaria la utilización de algún mecanismo previamente definido y conocido por todos los elementos que interactúan entre sí. Uno de los mecanismos más utilizados en este tipo de sistemas son los Llamados a Procedimientos Remotos o RPC, por sus siglas en inglés (Remote Procedure Call). A través de un RPC, una aplicación puede invocar a un procedimiento que reside y se ejecuta en una computadora remota, de una manera similar en la que se invocaría un procedimiento local [2]. A la fecha, varios estándares relacionados con RPC han sido propuestos, como los son ONC RPC [3], DCE RPC [4], DCOM [5], XML RPC [6] y Java RMI [7], por mencionar algunos. Es importante destacar que en la medida en que el desarrollo de software cambió del paradigma estructurado al paradigma orientado a objetos, los RPC evolucionaron hacia la Invocación a Métodos Remotos. De entre todas las propuestas existentes para los llamados a procedimientos remotos o para la invocación a métodos remotos, la Arquitectura Común de Intermediarios en Peticiones de Objetos o CORBA, por sus siglas en inglés (Common Object Request Broker Architecture) se ha consolidado como uno de los estándares más importantes [8]. Y de entre las implementaciones existentes de CORBA destaca Mico CORBA debido a su versatilidad y al total cumplimiento del estándar. Desafortunadamente existe muy poca documentación relacionada con la manera de instalar y utilizar Mico CORBA. Por esta razón, en este artículo se presenta un ejemplo completo de integración de sistemas heterogéneos utilizando esta herramienta. El resto de este documento está organizado de la siguiente manera. En la sección 2 se explica brevemente lo que son los llamados a procedimientos remotos. En la sección 3 se presenta CORBA, así como sus principales características. Posteriormente, en la sección 4 se presenta Mico CORBA, y se muestra un ejemplo de su instalación. En la sección cinco se presenta el ejemplo en el cuál se integran dos aplicaciones heterogéneas, y el artículo finaliza con las conclusiones y el trabajo futuro. 1

2 2. Llamados a procedimientos remotos En [2], Birrell y Nelson propusieron los llamados a procedimientos remotos, cuya idea consiste en llamar a un procedimiento que se encuentra en otra computadora, de una manera similar a la que se invocan los procedimientos de manera local. Cuando una aplicación que se ejecuta en una computadora A invoca a un procedimiento que se ejecuta en una computadora B, el proceso que hace la invocación desde A se suspende, y la ejecución del procedimiento invocado se lleva a cabo en la computadora B. Una vez que la respuesta es recibida por A, la aplicación puede continuar con su ejecución. La solicitud de ejecución del RPC puede acompañarse con los parámetros requeridos por el procedimiento remoto, y el mensaje de respuesta contendrá el valor retornado por el RPC. Como puede observarse, los RPC utilizan el paradigma cliente-servidor. Por otra parte, los RPC deben funcionar de manera correcta independientemente de que las aplicaciones y las plataformas en que éstas se ejecutan sean diferentes. Este problema no es trivial ya que la información puede tener un sentido diferente en cada plataforma. Por ejemplo, en una de ellas puede utilizarse el formato de almacenamiento de datos littleendian, mientras que en la otra puede utilizarse el formato big-endian. Por esta razón, Birrel y Nelson definieron un mecanismo en el cuál tanto la aplicación que invoca el procedimiento (cliente) como la aplicación que lo ejecuta (servidor) deben contener un apoderado o stub, que es un módulo de software que se encarga de los aspectos relacionados con la conversión de datos de una plataforma a otra, así como de los aspectos relacionados con la comunicación, como puede observarse en la Fig. 1. Generalmente, el código de los stubs del cliente y servidor es generado automáticamente. facilitando la invocación de métodos remotos bajo un paradigma orientado a objetos. CORBA fue definido y es administrado por el Object Management Group (OMG), que define las Interfaces de Programas de Aplicación (APIs), el protocolo de comunicaciones y los mecanismos necesarios para permitir la interoperabilidad entre aplicaciones desarrolladas en diversos lenguajes y ejecutadas en diferentes plataformas, lo que es fundamental en computación distribuida. En un sentido general, CORBA envuelve el código escrito en otro lenguaje, en un paquete que contiene información adicional sobre las capacidades del código que contiene y sobre cómo llamar a sus métodos. Los objetos que resultan, pueden entonces ser invocados desde otro programa desde la red. En este sentido CORBA se puede considerar como un formato de documentación legible por la máquina, similar a un archivo de cabeceras, pero con más información. CORBA utiliza un lenguaje de definición de interfaces (IDL) para especificar las interfaces con los servicios que los objetos ofrecerán. CORBA puede especificar a partir de este IDL, la interfaz a un lenguaje determinado, describiendo cómo los tipos de dato CORBA deben ser utilizados en las implementaciones del cliente y del servidor. En otras palabras, la interfaz es la parte en la que se definen los objetos que el servidor ofrece a los clientes. Al compilar una interfaz en IDL se genera código para el cliente y el servidor. El código del cliente sirve para poder realizar las llamadas a métodos remotos. Este código es el stub que utilizará el cliente. Las interfaces de los objetos de un sistema son el resultado del proceso de diseño modular de la aplicación. En una arquitectura como CORBA es posiblemente la parte más importante, ya que es la que especifica el flujo de los datos y la interacción entre los distintos módulos del sistema. La definición de la interfaz IDL es independiente del lenguaje de programación, pero los mapas de todos los lenguajes de programación a través de estándares OMG ha dado asignaciones estándar de IDL para C, C + +, Java, COBOL, Smalltalk, Ada, Lisp, Python, y IDLscript. [9]. 4. MICO CORBA Figura 1.- Modelo de los RPC 3. CORBA CORBA [8] es un estándar que establece una plataforma de desarrollo de sistemas distribuidos, Mico es una implementación completa de CORBA bajo la licencia de código abierto [10]. Es una de las implementaciones más interesantes de CORBA debido a su versatilidad. En esta sección se explicará brevemente cómo instalar Mico CORBA bajo la 2

3 plataforma de Linux. La distribución utilizada de Linux es Ubuntu En primera instancia, es necesario descargar el paquete mico-x.y.z.tar.gz [11], donde x, y y z representan al número de versión de Mico. Para este ejemplo se utilizó el archivo mico tar. Una vez descargado el archivo, debe copiarse a la carpeta en la que se hará la instalación. Por ejemplo, si la carpeta será /usr/src, en una terminal o intérprete de comandos se escribe lo siguiente: % sudo cp mico tar.gz /usr/src/ Posteriormente, será necesario descomprimir el archivo: % cd /usr/src/ % sudo tar xvf mico tar Una vez que se ha descomprimido se tendrán los archivos para la instalación en la carpeta /usr/src/mico. Para continuar el proceso de instalación, será necesario cambiarse a esa carpeta: % cd mico/ Posteriormente, debe definirse la ruta con las bibliotecas necesarias por Mico: % export LD_LIBRARY_PATH = /usr/src/mico/ orb:$ld_library_path y ejecutarse el proceso de configuración previa a la instalación: % sudo./configure --with-qt=/usr/local/ qt Antes de ejecutar el proceso que compilará y concluirá con la instalación de Mico CORBA, se tuvo que agregar una línea al archivo orb/fast_array.cc. Utilizando cualquier editor ASCII, se agrega al inicio del archivo la línea #include <limits.h>. Una vez hecho esto se invoca al comande make: % sudo make y posteriormente: % sudo make install Con esto se habrá concluido con la instalación de Mico CORBA. 5. Ejemplo Con la finalidad de ejemplificar el uso de Mico CORBA para integrar aplicaciones heterogéneas, se definió una base de datos simple que contiene los siguientes datos de estudiantes: número de matrícula, nombre y carrera. Para administrar la base de datos se utilizó MySQL [12]. Además, se desarrolló una aplicación en C++ que proporcionará un método para consultar la información de los estudiantes. Este método puede ser invocado de manera remota por procesos clientes. La aplicación servidor, así como la base de datos, se ejecutarán en una computadora que utiliza el sistema operativo Linux. Cómo se comentó anteriormente, con CORBA es necesario definir los métodos que podrán invocarse de manera remota, así como los tipos de datos de los parámetros que se utilizarán, por medio del lenguaje de definición de interfaces o IDL. Para el ejemplo, se creó el archivo database.idl, en el que se definió una estructura que contendrá los datos de los estudiantes, a la que se le nombró DBData. struct DBData { long matricula; string nombre; long calif; }; En el mismo archivo se definió el prototipo del método que podrá invocarse de manera remota, que se nombró getalldata. interface DataBase { DBData getalldata(in long matricula); }; Una vez que se ha definido el prototipo del método remoto junto con sus parámetros, a continuación se genera de manera automática el stub del servidor, que será desarrollado en C++. Y el stub del cliente en el lenguaje java. Para esto, se ejecuta las siguientes líneas: % idl database.idl % idlj -fall database.idl El comando idl generará, a partir de las definiciones del archivo database.idl, el código necesario para la construcción del servidor que proporcionará el método remoto. En el ejemplo, los archivos generados automáticamente y que se utilizarán para construir el servidor son database.h y server.cc, como puede observarse en la Fig. 2. 3

4 Una vez que se ha generado automáticamente el código stub, es necesario desarrollar el código para el proceso servidor y los procesos clientes. Es importante mencionar que el código del stub debe integrarse al código de los clientes y del servidor, pues contiene el módulo Marshaller, que es el encargado del control de los tipos de datos, transformando al formato adecuado del destinatario, así como también contiene el código que se encargará de los aspectos relacionados con la comunicación entre clientes y el servidor. Por ejemplo, para construir el código del servidor, crearemos un archivo llamados server.cc. En nuestro ejemplo este programa está desarrollado utilizando el lenguaje de programación C++. Este archivo debe contener las cabeceras necesarias para la correcta ejecución del programa, como por ejemplo la cabecera mysql.h, que en nuestro caso están relacionadas con el administrador de bases de datos utilizado. También es necesario agregar la cabecera database.h, ya que como se menciono con anterioridad, en ese archivo se encuentran definiciones importantes para CORBA, tales como los prototipos de los métodos que podrán ser invocados de manera remota: #include "/usr/include/mysql/mysql.h" #include "database.h" Debido a que el servidor proporcionará a los clientes el servicio de ejecución del método de consulta de la base de datos llamado getalldata, debe definirse en el servidor. Es importante destacar que el método debe cumplir con el prototipo generado automáticamente por el programa idl. El método recibe como parámetro la matrícula de un estudiante, que es de tipo CORBA::Double, y retornará un puntero a una estructura de tipo ::DBData, que contendrá la información relacionada con el estudiante. ::DBData* DataBase_impl::getAllData(CORBA::Double matricula) Dentro de la implementación del método es necesario realizar la conexión a la base de datos para consultar la información. Una vez que se ha logrado la conexión, se lleva a cabo una consulta para verificar existe algún estudiante con el número de matrícula enviado por el cliente. En caso de ser así, se obtiene la información del estudiante, misma que es retornada por el método. CORBA::Double mat = (CORBA::Double)::atof(row[0]); if (mat == matricula) { strdata -> matricula = mat; } strdata -> nombre = row[1]; strdata -> calif = (CORBA::Double)::atof(row[2]); Una vez que se ha definido el código del método remoto, hay que desarrollar el código del servidor CORBA. Para esto, en primer lugar dentro del método main se inicializa el objeto ORB, para poder recibir los datos del cliente y reenviarle el resultado. Posteriormente se obtiene una referencia al Root POA (Portable Object Adapter), y su administrador. CORBA::ORB_var orb = CORBA::ORB_init (argc, argv); CORBA::Object_var poaobj = orb->resolve_initial_references ("RootPOA"); PortableServer::POA_var poa = PortableServer::POA::_narrow (poaobj); PortableServer::POAManager_var mgr = poa->the_poamanager(); Se crea un objeto DataBase (de tipo DataBase_impl y definido por el idl). Se activa el objeto Servant, que contiene los métodos para el manejo de los (RMI). El Servant puede reenviar las llamadas a otro servidor. DataBase_impl * micodatabase = new DataBase_impl; PortableServer::ObjectId_var oid = poa->activate_object (micodatabase); CORBA::Object_var ref = poa->id_to_reference (oid.in()); nc->rebind (name, ref); Finalmente se activa el POA para recibir peticiones. mgr->activate (); orb->run(); poa->destroy (TRUE, TRUE); delete micodatabase; Una vez que el servidor ha sido puesto en ejecución, se mantendrá en ese estado indefinidamente. Con la finalidad de mostrar la facilidad con la que CORBA permite la integración de aplicaciones heterogéneas, se construyó un cliente utilizando el lenguaje de programación Java y el sistema operativo Windows 7. En el código del cliente, es necesario crear e inicializar un objeto de tipo ORB, para poder enviar los datos a el servidor y recibir el resultado. org.omg.corba.orb orb = org.omg.corba.orb.init( args, props ); Una vez que se obtiene el contexto raíz de nombres, (root naming context) es necesario resolver (localizar) 4

5 la referencia al objeto DataBase, que como se mencionó anteriormente, es el nombre que se le dio al objeto que se ejecuta en el servidor y que ofrece el servicio de ejecución del método remoto getalldata.. String name = "DataBase"; org.omg.corba.object object = ncref.resolve_str( name ); Una vez hecho esto es posible invocar remoto. el método DataBase sf = DataBaseHelper.narrow( object ); DBData param = new DBData(); param = sf.getalldata(matricula); String nombre = param.nombre; double calif = param.calif; Como puede observarse en el ejemplo, la invocación del método remoto es bastante sencilla, con la ventaja de que el desarrollador del programa cliente no debe preocuparse por detalles relacionados con la conexión o el manejo consistente de los tipos de datos. mostrado en este artículo el servidor se ejecuta en una computadora con sistema operativo Linux. % nsd ORBNoResolve -ORBIIOPAddr inet:localhost:12456 & Posteriormente se inicia la ejecución del servidor. %./server ORBNoResolve -ORBInitRef NameService=corbaloc::localhost:12456/Nam eservice & Después de que el servidor está en ejecución, es posible ejecutar al cliente. % java client -ORBInitRef NameService=corbaloc::localhost:12456/Nam eservice En la Fig. 2 se muestra la relación entre los diversos archivos del ejemplo mostrado en esta sección. Como se comentó previamente, es necesario incluir el código del stub a los programas servidor y cliente. Esto se hace de manera sencilla una vez compilados los programas. En el caso de C++, puede resultar conveniente compilar por separado el código del stub. % mico-c++ -I. -c database.cc -o database.o Posteriormente se debe compilar el programa servidor y enlazar el código del stub. Figura 2: Relación de archivos en el ejemplo % mico-c++ -I. -c server.cc -o server.o % mico-ld -I. -o server server.o database.o -lmico lmicocoss L/usr/include/mysql -lmysqlclient -I/usr/include/mysql Para el caso del cliente el proceso es más sencillo, ya que tan solo deben compilarse todos los programas fuente. % javac *java Para ejecutar el ejemplo, en primer lugar es necesario iniciar la ejecución del demonio de servidor de nombres. Es importante recordar que en el ejemplo 6. Conclusiones y Trabajo Futuro La capacidad de interactuar con sistemas heterogéneos es una característica importante de los sistemas informáticos modernos. Esta capacidad es aún más relevante para los sistemas inmersos debido a su limitación de recursos. Sin embargo, la heterogeneidad presente en un sistema representa nuevos retos de desarrollo de software. Una de las propuestas más interesantes para la integración de sistemas distribuidos es CORBA. Y de entre las diversas implementaciones de CORBA 5

6 destaca Mico CORBA. Sin embargo, existe muy poca documentación acerca de esta herramienta. En este artículo se presentó la manera de instalar Mico CORBA, así como un ejemplo de su uso. En particular, el ejemplo muestra la manera de construir un método que puede ser invocado de manera remota. El método se construyó utilizando C++ en Linux. Para mostrar la facilidad con que las aplicaciones heterogéneas pueden interactuar, se desarrolló una aplicación cliente utilizando Java en Windows 7. Como puede observarse en el ejemplo, utilizando Mico Corba pueden construirse aplicaciones con capacidades de interactuar ente sí, independientemente de las plataformas y lenguajes utilizados. Por otra parte, si bien es verdad que las aplicaciones CORBA son altamente acopladas, presentan un alto grado de eficiencia, una característica deseable en los sistemas inmersos. [7] D. Hou and H. Xia, Design of Distributed Architecture Based on Java Remote Method Invocation Technology, In Proceedings of the International Conference on Environmental Science and Information Application Technology, pp , July [8] Object Management Group (OMG), CORBA, Kendrick Street, Building A Suite 300 Needham, MA 02494, USA, [9] George Coulouris, Jean Dollimore and Tim Kindbero, Sistemas Distribuidos Conceptos y Diseño, Madrid, España: Addison wesley, vol. 3, pp , [10] Arno Puder, MICO: An Open Source CORBA Implementation, Los Vaqueros Circle Los Alamitos, San Francisco CA USA, July/August 2004 IEEE SOFTWARE [11] Sitio Web de Mico Corba: [12] P. Dubois, MySQL, 4th Edition, Addison-Wesley Professional, Sep Como trabajo futuro se tiene la evaluación y desarrollo de aplicaciones utilizando CORBA en sistemas operativos diseñados para dispositivos móviles, y compararlo con las prestaciones que proporcionan otras alternativas, como Web Services, REST y Enterprise Service Bus. 7. Referencias [1] A.S. Tanenbaum and M. Van Steen, Distributed Systems: Principles and Paradigms, Pearson Prentice Hall, [2] A. D. Birrell and B. J. Nelson, Implementing Remote Procedure Call, Palo Alto, CA USA, ACM Transactions on Computer Systems, Vol. 2, No. I,, pp 39 59, February [3] R. Srinivasan, RPC: Remote Procedure Call Protocol Specification Version 2, RFC 1831, Internet Engineering Task Force, Aug [4] A. Vogel, B. Gray and K. Duddy, Understanding Any IDL Lesson One: DCE and CORBA, In Proceeding of the 3 rd International Workshop on Services in Distributed and Networked Environments, pp , Jun [5] Y-I. Ming, O.P. Damani and W-J. Lee, Reliability and Availability Issues In Distributed Component Object Model (DCOM), In Proceedings of the 4 th International Workshop on Community Networking, pp , Sep [6] S. Laurent, J. Johnston, E. Dumbill, Programming web services with XML RPC, O Reilly