Implantación de un Servicio Basado en JINI para un Desarrollo Interno de WEB Edición Única

Texto completo

(1)

(2) IMPLANTACIÓN DE UN SERVICIO BASADO EN JIM PARA UN DESARROLLO INTERNO DE WEB. Tec. de M on te rr e y. TESIS MAESTRÍA EN CIENCIAS CON ESPECIALIDAD EN TECNOLOGÍA INFORMÁTICA. INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY CAMPUS MONTERREY. DIVISIÓN DE GRADUADOS EN ELECTRÓNICA COMPUTACIÓN, INFORMACIÓN Y COMUNICACIONES. POR ANA LAURA PAEZ GARCÍA. DICIEMBRE 2001.

(3) INSTITUTO TECNOLÓGICO Y DE ESTUDIOS SUPERIORES DE MONTERREY CAMPUS MONTERREY División de Graduados en Electrónica, Computación, Información y Comunicaciones Programa de Graduados en Electrónica, Computación, Información y Comunicaciones. Los miembros del comité recomendamos que la presente tesis de la Ing. Ana Laura Páez García sea aceptada como requisito parcial para obtener el grado académico de Maestra en Ciencias con especialidad en:. Tecnología Informática. Comité de tesis. Aprobada. Director del Programa de Graduados en Computación, Información y Comunicaciones. DICIEMBRE 2001.

(4) Dedico esta tesis a mi familia, que me da la fuerza para enfrentar cada reto que se me presenta.. Muchas Gracias.

(5) Reconocimientos A mi profesor Pablo Daniel Díaz López, quien asesoró el presente trabajo. A los sinodales, M.C. Pablo Tejeda Zerón y M.C. Luis Ricardo Salgado Garza. A Rafael Borbolla, por su apoyo constante..

(6) Resumen El crear un servicio de bitácora que posea mayor flexibilidad de uso en comparación con el servicio existente es importante para aprovechar al máximo la información que se almacena en la base de datos de la bitácora electrónica del site. Sobre todo, se mostrará que es importante que se notifique al usuario del sistema cuando se agrega un nuevo evento a la bitácora. La solución que se propone se desarrolló basándose en la tecnología Jini. Se mostrarán los conceptos básicos de su funcionamiento los cuales serán aplicados en un ejemplo de servicio de impresión. Después se mostrará el desarrollo de la solución propuesta. Del servicio de bitácora actual y del servicio de bitácora propuesto se hará un análisis comparativo, se mostrará de que forma el servicio de bitácora propuesto soluciona restricciones innecesarias presentes en el servicio de bitácora actual, logrando así un servicio más flexible de utilizar que el actual..

(7) Contenido Lista de Figuras. III. Capítulo 1. Introducción [1]. 1. 1.1. Objetivo. 2. 1.2. Organización. 2. Análisis de Tecnologías [13,14,15,16,17]. 3. CORBA[13]. 3. 2.1.1 Funcionamiento de CORBA [14]. 4. Jini [15,17]. 4. 2.2.1 Funcionamiento de RMI. 5. Comparación de CORBA y RMI [16]. 5. Conceptos Básicos de Jini [2,3,4,6,10]. 8. 3.1. Funcionamiento de Jini [4]. 8. 3.2. Componentes de Jini [2]. 9. 3.2.1. 10. Capítulo 2 2.1. 2.2 2.3 Capítulo 3. 3.3. 3.4. 3.5. 3.6. Servicio. 3.2.2 Cliente. 10. 3.2.3. 11. Servicio de localización. Protocolo de Descubrimiento [10]. 12. 3.3.1. Protocolo de Descubrimiento Multicast. 13. 3.3.2. Protocolo de Descubrimiento Unicast. 13. Protocolo de Unión [3]. 14. 3.4.1 Requerimientos. 14. 3.4.2. 14. Cumplimiento del Protocolo de Unión. Arquitecturas de Servicios [10]. 15. 3.5.1. El Proxy como Servicio. 15. 3.5.2. El Proxy basado en RMI. 15. 3.5.3. El Proxy no basado en RMI. 15. Eventos Remotos [3]. 16. 3.6.1. 16. Manejo de Eventos Remotos. I.

(8) 3.7. Capítulo 4. 3.6.2. Consumidor de Eventos. 16. 3.6.3. Productor de Eventos. 17. Servicio de Impresión [2,6,10]. 19. 3.7.1. Servicio. 19. 3.7.2. Cliente. 20. Bitácora Electrónica [5,6,8,9,11]. 21. 4.1. Verificación de los equipos computacionales del site. 21. 4.2. Uso de la bitácora electrónica. 21. 4.3. Herramientas utilizadas en el desarrollo de la bitácora electrónica. 24. 4.4. Seguridad de la bitácora electrónica. 24. 4.5. Servicio de bitácora electrónica basado en Jini. 25. 4.6. Seguridad del servicio de bitácora electrónica basado en Jini. 27. 4.7. Servicio de bitácora electrónica basado en Jini [5,6,8,9,11]. 27. 4.7.1. 27. Capítulo 5 5.1. Servicio. 4.7.2 Cliente. 28. Análisis de Resultados [3,5,7]. 29. Requerimientos de los servicios de bitácora. 29. 5.1.1. 29. Requerimientos de la bitácora actual. 5.1.2 Requerimientos del servicio de bitácora [3,5,7]. 29. Comparación entre el servicio actual y el servicio basado en Jini. 30. Conclusiones y Trabajos Futuros. 32. 6.1. Conclusiones. 32. 6.2. Trabajos Futuros. 32. Apéndice A. Servicio de Impresión [2,6,10]. 33. Apéndice B. Servicio de Bitácora Electrónica [5,6,7,8,9,11]. 47. 5.2 Capítulo 6. Apéndice C Funcionamiento de RMI [5,7,12]. 65. Referencias. 67. II.

(9) Lista de Figuras 1-1 Uso de la bitácora electrónica. 1. 3-1 Acciones para hacer uso de un servicio. 9. 3-2 Componentes de Jini. 9. 3-3 Interacciones del servicio de localización con los clientes y servicios. 12. 3-4 Funcionamiento del Protocolo de Descubrimiento Unicast. 13. 3-5 Manejo de Eventos. 16. 3-6 Uso del Servicio de Impresión. 19. 4-1 Esquema de la base de datos de la bitácora electrónica. 23. 4-2 Servicio de notificación de la bitácora. 26. A-l Cliente del servicio de Impresión. 46. III.

(10) Capítulo 1 Introducción [1] En el site del ITESM existen muchos equipos, los cuales constantemente son examinados por los operadores del site para comprobar su estado. Por lo tanto, es necesario llevar un control de las fallas o problemas relacionadas con los equipos. Así, como también saber en qué fecha ocurrió una falla en un equipo y además cómo se solucionó. Por lo anterior, en el site existe una bitácora electrónica, cuya función es almacenar los datos de los eventos ocurridos en el mismo. Los usuarios de la bitácora electrónica son los operadores del site y los administradores de los equipos, los cuales pueden ser servidores, impresoras, etc. De los usuarios de la bitácora, los únicos que tienen privilegios para agregar eventos a la bitácora electrónica son los operadores. Por lo que, los administradores sólo pueden consultar eventos previamente almacenados por los operadores.. Sistema de Bitácorz Electrónica. Administrador. Operador. Fig. 1-1 Uso de la bitácora electrónica El acceso a la bitácora es mediante el uso de una cuenta y una contraseña. La sesión expira después de un cierto tiempo de inactividad. Con esto se busca que un operador no agregue un evento utilizando la sesión de otro operador, así, se tiene mayor confianza sobre el dato de quien agrega cada evento. A su vez, esto presenta una desventaja para los administradores, porque si desean estar informados de los nuevos eventos de los equipos, necesitan autenticarse varias veces al día.. 1.

(11) 1.1. Objetivo. Con la utilización de la tecnología Jini se puede extender el uso de aplicaciones propietarias a otras plataformas. La aplicación que se analizará para probar la hipótesis es la bitácora electrónica del site del ITESM y se utilizará Jini principalmente porque se desea explorar esa nueva tecnología.. 1.2. Organización. En el capítulo 2, se mencionarán conceptos básicos de cómputo de objetos distribuidos, además de la comparación de tecnologías importantes en el área. En el capítulo 3 se expondrán los conceptos básicos de Jini, la manera en que se crean los servicios, cómo los clientes pueden hacer uso de ellos, etc. En el capítulo 4 se hablará del funcionamiento actual de la bitácora electrónica y después se mostrará la forma en que se puede extender un sistema propietario en un servicio Jini. En el capítulo 5 se explicará cómo utilizar el servicio de bitácora basado en Jini, así como también se enunciarán las ventajas y desventajas de utilizar un cliente Jini para hacer uso del servico creado con respecto al cliente de la bitácora actual. Por último, en el capítulo 6 se enunciarán las conclusiones obtenidas a lo largo de la tesis. Además se mencionarán posibles usos futuros del servicio..

(12) Capítulo 2 Análisis de Tecnologías [13,14,15,16,17] El cómputo distribuido de objetos extiende los sistemas programados utilizando el paradigma orientado a objetos permitiendo que los objetos sean distribuidos a través de una red heterogénea, así cada uno de los objetos distribuidos interoperan formando un todo. Dos de los paradigmas de objetos distribuidos más conocidos son Common Object Request Broker Architecture (COREA) de OMG y Java/Remóte Method Invocation (Java/RMI) de JavaSoft. A continuación se hablará de la historia y características de ambos paradigmas.. 2.1. CORBA [13]. En 1989 se formó la OMG (Object Management Group) para definir una arquitectura de software que fuera abierta. Los fundadores de la OMG deseaban definir una manera abierta de escribir aplicaciones basadas en red (aplicaciones cliente - servidor entre otras), donde el mismo código de la aplicación se pudiera utilizar en diferentes sistemas operativos. El resultado de ese trabajo fue la especificación de CORBA 2.0 en 1994 la cual logró los objetivos de ser una arquitectura abierta orientada a objetos e independiente de la plataforma. Después aparecieron 3 tendencias que influyeron en el crecimiento de CORBA. - La importancia que adquirieron las técnicas de programación orientada a objetos en el desarrollo de sistemas. -. IBM, Microsoft y Apple, desarrollaron modelos de aplicaciones basados en pequeños componentes. Tales componentes se caracterizaban por ser fáciles de escribir y actualizar. Las principales ventajas de estos modelos consistían en que los desarrolladores sólo actualizarían pequeñas partes de su software y los clientes no tendrían que comprar nuevas versiones completas de un paquete entero. Y los pequeños componentes pudieran ser distribuidos por la red más fácilmente.. -. Después de la versión CORBA 2.0, a principios de 1995, surgió el lenguaje de programación Java, con la visión de una arquitectura orientada a objetos y de componentes de software capaces de correr sobre cualquier sistema operativo que cuente con una máquina virtual de Java. Además tales componentes contaban con la habilidad de utilizarse através de Internet.. Tales tendencias hicieron que CORBA se adecuara al enfoque basado en componentes e Internet para la construcción y uso del software. Se definió una manera de dividir la lógica de aplicación en objetos que pudieran estar distribuidos por Internet, algunos en el lado del cliente y otros en una variedad de servidores. También se definió la forma en que los objetos se pudieran comunicar.. 3.

(13) 2.1.1. Funcionamiento de COREA [14]. El funcionamiento de cualquier objeto COREA depende de un ORB (Object Request Broker). El ORB actúa como un bus central de objetos sobre el cual todo objeto CORSA interactúa transparentemente con otros objetos CORBA localizados local o remotamente. Cada objeto servidor CORBA tiene una interfaz la cual expone un conjunto de métodos. Para hacer uso de un servicio, un cliente CORBA adquiere una referencia al objeto servidor y sobre tal referencia llama a los métodos del objeto servidor.. 2.2. Jini [15,17]. Bill Joy co-fundador y vice-presidente de Sun tuvo la idea de crear una red de servicios ubicuos haciendo uso de características de cómputo distribuido de Java, especialmente la habilidad de mover código y datos de una máquina a otra. Joy y un pequeño grupo de ingenieros trabajaron en secreto en un laboratorio ubicado en Aspen, Colorado en 1994. Durante 4 años trabajaron en el nuevo paradigma de red, el cual tenía como requerimientos: utilizar un enfoque orientado a objetos y una interacción simple con el usuario. Con ello se esperaba facilitar el uso del poder de cómputo de los diversos dispositivos conectados a la red, al mismo tiempo cada dispositivo podría compartir sus recursos con los demás. El equipo de desarrollo con el que trabajo Joy lo conformaron principalmente los siguientes ingenieros: Ann Wollrath: Ingeniera de Sun Microsystems, diseñadora del sistema de invocación de métodos remotos (RMI). Durante su estancia en los laboratorios de Sun Microsystems realizó investigaciones en el campo de cómputo paralelo y distribuido a gran escala. Ken Arnold: Líder en el diseño de la tecnología de Java Spaces. Experto en el diseño orientado a objetos, C, C++ y cómputo distribuido. -. Jim Waldo: Ingeniero de Sun Microsystems, líder en la arquitectura del proyecto de Jini desde su inicio. Anterior al trabajo en Jini, Jim trabajó haciendo investigaciones en las áreas de programación orientada a objetos y en cómputo distribuido. Jim Waldo ha impartido clases de cómputo distribuido en la Universidad de Harvard .. -. Robert W. Scheifler. Ingeniero de Sun Microsystems, ha tenido la responsibilidad del diseño e implementación del servicio de localización y del protocolo de descubrimiento asociado.. Jini especifica lo que se necesita para crear una red funcional de objetos que dinámicamente se unen para realizar un trabajo en conjunto. Jini, por otro lado, no especifica el mecanismo de comunicación entre la referencia que tiene el cliente del servicio y el servicio mismo. Es. 4.

(14) por ello que en esa parte Jini se ayuda de la funcionalidad de RMI. Por ello, a continuación se hablará brevemente del funcionamiento de RMI.. 2.2.1. Funcionamiento de RMI. Los objetos servidor RMI definen una interfaz la cual es utilizada para acceder al objeto servidor desde otra máquina virtual de Java. La interfaz expone un conjunto de métodos los cuales indican los servicios ofrecidos por el objeto servidor. Para hacer uso de un servicio, el cliente RMI debe interactuar con el RMIRegistry el cual mantiene información acerca de los objetos servidores. Los objetos servidor RMI son nombrados con formato URL. Si se desea utilizar RMI para la interacción entre el cliente y servidor será necesario codificar ambos utilizando Java. COREA y RMI proveen los mecanismos para un acceso e invocación transparente de objetos remotos distribuidos. Para notar similitudes y diferencias de COREA y RMI se presenta una tabla comparativa de ambas tecnologías.. 2.3. Comparación de CORBA y RMI [16]. RMI Soporta múltiple herencia a nivel de interfaz. Los objetos remotos del servidor se identifican con el ObjID, el cual sirve como un manejador del objeto en tiempo de ejecución. Además es posible convertirlo a String llamando al método toStringQ. Identifica a una interfaz utilizando su nombre e identifica una implementación del objeto servidor haciendo un mapeo un URL en el Registry E constructor del objeto del servidor remoto llama al método UnicastRemoteObject(this) el cual instancia el skeleton. Utiliza el protocolo JRMP (Java Remote Method Protocol) como el protocolo para el manejo de peticiones del cliente hacia el servicio. Cuando un objeto del cliente necesita activar Cuando un objeto del cliente necesita una un objeto del servidor, lo hace a través de un referencia a un objeto del servidor, debe servicio de nombres. llamar al método lookupQ sobre el nombre del URL del objeto remoto del servidor.. CORBA Soporta múltiple herencia a nivel de interfaz. Los objetos remotos del servidor se identifican por referencias únicas a objetos, las cuales sirven como un manejador del objeto en tiempo de ejecución. Tales referencias pueden convertirse en strings. Identifica una interfaz utilizando su nombre e identifica una implementación del objeto del servidor haciendo un mapeo a un nombre en el Implementation Repository El constructor implícitamente ejecuta tareas comunes como el registro del objeto del servidor remoto y la instalación del skeleton. Utiliza el protocolo IIOP (Inter-ORB Protocol) como protocolo para el manejo de peticiones del cliente hacia el servicio.. 5.

(15) El tipo de información para los métodos es almacenada en el Interface Repository La responsabilidad de localizar la implementación de un objeto cae directamente sobre el ORB (Object Request Broker) utilizado. El stub del lado del cliente es llamado proxy o stub. El stub del lado del servidor es llamado stub. No intenta realizar general-purpose distributed garbage collection.. Cualquier tipo de información es almacenada en el objeto mismo. La responsabilidad de activar una implementación de un objeto cae sobre la máquina virtual de Java. El stub del lado del cliente es llamado proxy o stub. El stub del lado del servidor es llamado skeleton. Intenta realizar distributed garbage collection de objetos del servidor remoto utilizando mecanismos de la JVM. Podrá ejecutarse sobre cualquier plataforma que cuente con una implementación de una máquina virtual de Java para dicha plataforma. Como depende mucho sobre Java Object Serualization, esos objetos pueden solamente ser codificados en el lenguaje Java.. Podrá ejecutarse sobre cualquier plataforma que cuente con una implementación de un ORB de CORB A para dicha plataforma. Como es sólo una especificación, diferentes lenguajes de programación pueden utilizarse para codificar los objetos siempre y cuando existan librerías de ORB que puedan utilizarse en el lenguaje de programación deseado.. En la siguiente tabla aparece la comparación de utilizar Jini y RMI contra CORBA. Funcionalidad Búsqueda de un servicio por nombre. Jini y RMI Tiene un sevidor de registro que permite realizar búsqueda de un objeto remoto por su nombre y obtener una referencia remota hacia él.. CORBA Tiene un servicio de nombres que permite hacer la búsqueda de un objeto remoto por nombre y así obtener una referencia a él.. Uso de la referencia de servicio. Se utiliza la referencia a un servicio a través de la invocación de métodos a un stub. Un cliente puede dinámicamente cargar el código para un objeto stub por lo que los desarrolladores del cliente no necesitan conocer tal código para hacer el cliente.. Se utiliza la referencia a un servicio a través de la invocación de métodos a un stub local. Se requiere que el cliente tenga la definición del stub localmente, es decir, se requiere que el código para el objeto stub sea conocido a los desarrolladores del cliente.. 6.

(16) Parámetros en la invocación a un método. Permite pasar objetos por valor, también como por referencia al momento de invocar un método remoto.. Con la versión CORBA/IIOP 2.2 specification liberada en 1998, CORBA solamente permitía pasar objetos por referencia. La especificación 2.2 agregó el soporte para objetos por valor, pero tal funcionalidad aún no es soportada en todas las implementaciones de CORBA.. Servicio de localizador!. El servicio encargado de realizar la búsqueda de un objeto por su tipo es el servicio de localización. Como resultado de la búsqueda regresa un objeto proxy por valor.. Incluye un servicio llamado trader service, con el cual, en lugar de utilizar un nombre al cual está asociado un objeto remoto, se puede describir el tipo del objeto remoto que se está buscando. Como resultado de la búsqueda devuelve una referencia remota hacia el objeto remoto.. Cuando apareció RMI no era una solución para el desarrollo de sistemas distribuidos masivos y entonces se elegía CORBA. Actualmente RMI soporta la administración de transacciones por lo que ahora la utilización de RMI ya es una opción viable y robusta. La elección de uso de CORBA o de RMI dependerá de los requerimientos que se tengan. El requerimiento básico a considerar es: si se necesita homogeneidad o heterogeneidad, es decir, en sistemas desarrollados en lenguajes diferentes a Java el uso de CORBA es el más conveniente; en cambio, sistemas en los cuales se utiliza parcialmente Java, podría usarse RMI. Cabe señalar que las propiedades de ambas tecnologías pueden complementarse en diferentes situaciones. También es importante antes de elegir la tecnología a utilizar: la experiencia de los desarrolladores y responsables de realizar el diseño, implementación y mantenimiento del sistema distribuido. En el presente trabajo se decidió hacer uso de RMI con Jini principalmente para explorar las características que nos ofrecen actualmente.. 7.

(17) Capítulo 3 Conceptos Básicos de Jini [2,3,4,6,10] Desde hace algunos años surgió la inquietud de poder reutüizar recursos en el área de desarrollo de software. Por ejemplo, se desarrollaron técnicas para la generación de software utilizando código ya hecho. Por otro lado, los lenguajes orientados a objetos nos brindan la facilidad de realizar nuevos sistemas ayudándonos de clases ya codificadas y verificadas. Además de facilitar el desarrollo, nos ayuda a disminuir el tiempo invertido en realizar la verificación al sistema, porque sólo se aplicarán pruebas a las nuevas clases. Así como se reutiliza código ya hecho para el desarrollo de un sistema, Sun creó el lenguaje de programación Java, para codificar programas que pudieran ejecutarse en múltiples plataformas. El concepto de reutilización surgido del ambiente de desarrollo se extendió al campo distribuido, porque en la actualidad se busca reutüizar los recursos de hardware o de software conectados a la red. En enero de 1999 Sun presentó la tecnología Jini basada en Java, cuya finalidad era hacer realidad la visión del cómputo distribuido de crear una red ubicua, la cual pueda estar presente en todos los lugares. Donde cualquier dispositivo o aplicación de software habilitado con la tecnología Jini puede funcionar como un servicio en la red, de esa forma se facilita el desarrollo de sistemas distribuidos.. 3.1. Funcionamiento de Jini [4]. La idea que sigue Jini para compartir recursos, consiste básicamente en crear un objeto Java que represente el recurso a compartir, después tal objeto debe registrarse como público en algún servicio de localización (lookup service) para que este lo exponga, adquiriendo así el estado de servicio Jini. Con la tecnología Jini se pueden crear tantos servicios como recursos se deseen compartir y con ello la creación de redes dinámicas de servicios. Una gran ventaja de utilizar Jini consiste en que después de registrar un servicio, cualquier cliente que lo necesite, lo podrá utilizar. Por ejemplo, si un cliente desea imprimir, entonces el procedimiento que debe seguir es lanzar una búsqueda especificando que desea un servicio de impresión al servicio de localización, y de los servicios que cumplan con los requisitos de la búsqueda, el cliente escogerá uno, al cual enviará sus datos para que los imprima. Los servicios en Jini se unen en grupos cooperativos. Estos grupos de servicios son llamados comunidades o federaciones, donde los servicios en la comunidad saben de la existencia de otros servicios pertenecientes a su comunidad y así poder utilizar los servicios de los demás.. 8.

(18) En la Fig. 3-1 se muestra el funcionamiento de Jini. Antes de que el cliente pueda hacer uso del servicio, este debe almacenar suproxy en el servicio de localización.. Servicio. Cliente. ( Proxy ^. sNv.. ^/; Almacenar. Buscar. \. \. / Almacenamiento de Proxies. Fig. 3-1 Acciones para hacer uso de un servicio. 3.2. Componentes de Jini [2]. Del funcionamiento previamente descrito se aprecia que los componentes básicos en una red Jini son: un servicio, un cliente y un servicio de localización. Estos componentes tienen funciones muy particulares, necesarias para llevar a cabo la acción de compartir recursos. A continuación se mencionará la definición y las funciones de cada componente.. Cliente. Servicio de Localización. TCP/IP Fig. 3-2 Componentes de Jini. 9. Sercicio.

(19) 3.2.1. Servicio. El papel del servicio lo puede realizar un dispositivo de hardware o una aplicación. Cuando el servicio se publica en la red Jini espera que un cliente le solicite realizar una tarea para la cual fue publicado en la red. Un servicio se compone de un servidor y un objeto proxy, donde el proxy será quien represente el servicio ante el cliente, es decir, cualquier petición del cliente hacia el servicio la realizará a través del proxy. Las funciones del servicio son: 1.- Buscar servicios de localización ya sea por multicast o por unicast.- Un servicio podrá encontrar por multicast sólo los servicios de localización ubicados en su misma subred. Por otro lado, para encontrar un servicio de localización por unicast, es necesario conocer su dirección de red. El mecanismo de búsqueda unicast es poco flexible, debido a que es necesario saber de antemano la dirección del localizador. Pero, a su vez provee la ventaja de poder contactar servicios de localización en subredes diferentes a la del servicio. 2.- Registrar el proxy con los servicios de localización.- Para que el servicio este disponible y puedan los clientes utilizarlo, el servidor necesita enviar un objeto conocido como proxy a los servicios de localización, así los clientes obtendrán dicho proxy para interactuar con el servicio. Más adelante se hablará de los diferentes tipos de proxy que se manejan en Jini. 3.- Cumplir con el protocolo de unión.- El protocolo de unión se desarrolló para guiar a los servicios en la manera en que deben comportarse mientras pertenezcan a una red Jini, al mismo tiempo puedan cooperar a que la red mantenga un estado consistente. Para que un servicio pueda seguir el protocolo de unión se requiere que guarde cierta información de si mismo. Así, si por alguna razón falla el servicio, entonces se pueda reiniciar con los mismos parámetros que tenía cuando se registró por primera vez para pertenecer a la red Jini. Más adelante se detallará qué información necesita conservar el servicio. 4.- Renovar el registro del proxy.- El proxy que registra un servicio, no permanece indefinidamente en el servicio de localización, es necesario que el servicio lo renueve continuamente durante el tiempo en que este disponible. De lo contrario, si se perdiera el proxy del servicio de localización, los clientes no podrían tener acceder al servicio. 3.2.2. Cliente. Un cliente es aquel que busca un servicio para solicitarle una tarea necesaria para la operación del cliente. Las funciones del cliente son:. 10.

(20) 1.- Buscar servicios de localización ya sea por multicast o por nnicast.- La búsqueda de localizadores por parte de un cliente se realiza de la misma forma en que lo hace un servicio cuando busca localizadores. 2.- Enviar búsquedas al servicio de localización.- Cuando un cliente desea utilizar un servicio, lanza una búsqueda al servicio de localización, solicitando un servicio que cumpla con ciertos requisitos. Por ejemplo, si un cliente desea imprimir un archivo, entonces enviará una búsqueda al servicio de localización, indicándole que desea imprimir, y además podrá agregar en la búsqueda que la impresora se encuentre en su mismo piso. 3.- Enviar peticiones de notificación al servicio de localización.- El uso de notificaciones es útil para que el cliente se entere de algún cambio que ocurra con el servicio que está utilizando o que desea utilizar. Es decir, cuando el cliente desea saber cuando está disponible un servicio en particular, tiene que solicitarle al servicio de localización que le avise que el servicio está activo. 4.- Renovar las peticiones de notificación. Siguiendo con el tema de las notificaciones, estas no permanecen indefinidamente en el servicio de localización, la razón consiste en que de esa forma se trata de evitar la reservación de recursos cuando estos no son utilizados. Es decir, si un cliente ya no está interesado en que se le notifique un cambio, entonces no renovará el tiempo de vida de la notificación y el servicio de localización la borrará de la lista de peticiones de notificación. 3.2.3. Servicio de localización. El servicio de localización se utiliza como mediador entre el servicio y el cliente. Su función principal es compartir la información que tiene de los servicios que adminsitra con los clientes. 1.- Enviar referencias de él a los clientes o servicios.- La referencia de un servicio de localización se conoce como registrar. El registrar funciona como proxy hacia el servicio de localización. Para que un cliente o un servicio puedan comunicarse con un servicio de localización necesita hacerlo a través de su registrar. 2.- Asignar identificadores a los servicios.- Un servicio necesita un identificador porque es así como se puede diferenciar de otros servicios, el servicio de localización es quien se encarga de asignarle un identificador a cada servicio.Cuando un servicio se registra por primera vez, no tiene todavía un identificador, entonces el servicio de localización se encarga de generarle uno y enviárselo. 3.- Almacenar los proxies de los servicios.- El servicio de localización tiene una base de datos en la cual almacena los objetos proxies y sus respectivos atributos. 4.- Almacenar las peticiones de notificación de los clientes.- El servicio de localización almacena las peticiones de notificación y avisa al cliente cuando ocurre el evento por el cual está en espera.. 11.

(21) Soporte del Protocolo de Descubrimiento. Soporte del Protocolo de Descubrimiento y de Unión. Envía búsqueda de servicio vía un témplate Devolver un proxy de servicio i Cliente. Registrar y almacenar el proxy Servicio de Localización. Enviar peticiones de notificación. Asignar identificadores de servicio. Servicio. Mantener separación de recursos para el registro del proxy. Enviar notificaciones Mantener separación de recursos para peticione! de notificación. Fig. 3-3 Interacciones del servicio de localización con los clientes y servicios.. 3.3. Protocolo de Descubrimiento [10]. Un protocolo de descubrimiento es útil para encontrar servicios en una red. Existen dos tipos de protocolos de descubrimiento y su uso dependerá de donde se localice el servicio que se desea. Uno de los protocolos de descubrimiento se basa en multicast y el otro en unicast. Si el servicio que se desea se encuentra en la misma subred, desde donde se solicita, su descubrimiento será de forma transparente y se utilizará el protocolo de descubrimiento multicast para contactarlo. De lo contrario, será necesario conocer la dirección de red del servicio y se utilizará el protocolo de descubrimiento unicast para contactarlo. Ambos protocolos tienen ventajas y desventajas de uso, donde el cliente decidirá cuál utilizar dependiendo de sus necesidades.. 12.

(22) 3.3.1. Protocolo de Descubrimiento Multicast. El protocolo basado en multicast es flexible, porque no es necesario conocer la dirección de red del servicio para poder utilizarlo. Un cliente puede ocupar este protocolo para contactar servicios dentro de su misma subred. Una red de servicios Jini se puede dividir en grupos de servicios, con el propósito de diferenciar el uso o restricciones inherentes de los servicios. Por lo tanto, sería conveniente que los servicios de un mismo departamento formarán un grupo y los interesados en utilizar las capacidades de dicho departamento, solo necesitarían buscar servicios del grupo específico del departamento.Para utilizar el protocolo de descubrimiento multicast se utiliza la clase: LookupDiscovery(java.lang.String[] groups). Donde el valor del parámetro groups indica lo siguiente: nuil, si se desea encontrar un servicio de localización sin importar el grupo o grupos que administra. - LookupDiscovery.NO_GROUPS, implica que se crea el objeto, pero no inicia la búsqueda. Un arreglo de strings no vacío. Cuando se desea encontrar localizadores que pertenezcan a ciertos grupos.. 3.3.2. Protocolo de Descubrimiento Unicast. El protocolo basado en unicast, no es tan flexible como el de multicast, porque solo es útil cuando sabes la dirección de red del servicio que deseas contactar. La principal ventaja es que mediante este protocolo el cliente puede contactar servicios en cualquier subred. Así, en la Fig. 3-4 se puede ver un servicio de la federación A registrándose con un servicio de localización de la federación B, logrando con ello estar disponible tanto para los clientes de la federación A como para los de la federación B. Federación B Servicio de locali Federación A. Descubrimiento Unica^.. £<. Fig. 3-4 Funcionamiento del Protocolo de Descubrimiento Unicast. 13.

(23) Para utilizar el protocolo de descubrimiento unicast se utiliza la clase LookupLocator cuyos constructores son: LookupLocator(java.lang.String url) LookupLocator(java.lang.String host, int port);. En el primer constructor, en el parámetro url se utiliza la sintaxis estándar de URL de "protocolo://servidor" o "protocolo://servidor:puerto", en donde "protocolo" es jini, y si no se especifica un puerto se tomará el puerto 4160.. 3.4. Protocolo de Unión [3]. Jini se ayuda del protocolo de unión para mantener un control y orden en cuanto a la forma en que se unen o salen de la red los servicios. El protocolo de unión es una serie de requerimientos que deben seguir y cumplir los servicios durante su tiempo de vida dentro de una red Jini 3.4.1. Requerimientos. Para seguir el protocolo de unión, cada servicio deberá guardar información de si mismo, de forma permanente. Así, si existe la necesidad de remiciar el servicio, se hará con los mismos parámetros con los que trabajaba antes de fallar o salir de la red. Un servicio debe guardar la siguiente información si desea seguir el protocolo de unión: 1.- El identificador de servicio que le asignó el servicio de localización cuando se registró por primera vez. 2.- Atributos que describan el servicio. Este caso se da sólo si el servicio se registro con atributos. El agregar atributos a un servicio facilita que los cliente puedan encontrarlo. 3.- El conjunto de grupos al que desea unirse o pertenecer el servicio. Esto sucede cuando el servicio está configurado para servir a ciertos grupos. Será necesario guardar tal información para que la próxima vez que se inicie, ofrezca sus servicios sólo a los grupos con los que estaba configurado. 4.- Direcciones de red de servicios de localización. Si el servicio necesita registrarse con ciertos servicios de localización utilizando el protocolo de descubrimiento unicast. 3.4.2. Cumplimiento del Protocolo de Unión. Cuando un servicio se inicia por primera vez, no tiene toda la información necesaria para el protocolo de unión. Sin embargo, después de su primer registro podrá obtenerla. El servicio una vez registrado deberá guardar la información requerida para el protocolo de unión, y de. 14.

(24) esta manera podrá utilizarla para registrarse con otros servicios de localización, logrando así que haya consistencia en la red, porque un mismo servicio, sin importar donde este registrado, debe tener la misma y única identidad. También, es importante guardar cualquier cambio que se realice sobre las características de un servicio, ya sea en sus atributos, la lista de servicios de localización que debe contactar, etc. Así, cuando se requiera registrar de nuevo el servicio se hará con la información actualizada.. 3.5. Arquitecturas de Servicios [10]. Una arquitectura de servicio se refiere a la manera en la que se realiza el servicio, sobre todo, como se reparte el procesamiento entre el servicio y el cliente. Dependiendo del tipo de proxy se determina la arquitectura de servicio. 3.5.1. El Proxy como el servicio.. Este tipo de arquitectura se da cuando el procesamiento se realiza enteramente en el lado del cliente y el proxy no necesita comunicarse con el servicio para realizar la tarea solicitada por el cliente. En este tipo de arquitectura, el servicio sólo se encargará de registrar el proxy con los servicios de localización y de renovar el registro del proxy cuando sea necesario. Así, el registro del proxy permanecerá mientras el servicio este activo. 3.5.2. El Proxy basado en RMI.. Cuando el proxy se basa en RMI para realizar el servicio, el procesamiento se lleva a cabo en el lado del servidor. Si el cliente desea utilizar una funcionalidad del servicio lo hace invocando métodos sobre el proxy, el cual redirigirá las llamadas al verdadero servicio. La forma en que se hará la redirección será a través de RMI. El proxy conoce la forma de comunicarse con el servidor. En el apéndice C se describe el funcionamiento de RMI. 3.5.3. El Proxy no basado en RMI.. Cuando se utiliza este tipo de proxy el procesamiento se realiza también del lado del servicio, como en el caso anterior. La diferencia consiste en la manera en que se comunica el proxy con el servidor, la cual se realiza a través de sockets y llevando una comunicación al estilo de paso de mensajes.. 605667. 15.

(25) 3.6. Eventos Remotos [3]. Tanto en Java como en Jini, se utilizan eventos para poder reportar cuando ocurre algún cambio de estado. Así, el envío de un evento es para notificar al receptor de que ha ocurrido el evento por el cual estaba interesado. Por ejemplo, un cliente Jini pudiera estar interesado, en saber cuándo el servicio que necesita está disponible en la red. La ventaja de utilizar eventos remotos es que el receptor del evento no tiene que hacer consultas frecuentemente para ver cuando ocurre el suceso en el que está interesado, deja que el productor le envíe el aviso. 3.6.1 Manejo de Eventos Remotos Para que se de una notificación es necesario que existan un productor y un consumidor de eventos. Cada uno tiene ciertas funciones que realizar para que haya una exitosa entrega de notificaciones. En la Fig. 3-5 se muestra las actividades del consumidor y productor de eventos. Consumidor de Eventos. Productor de Eventos. 1. Registra su interés por un cambio de estado específico. 2. Monitoreo del cambio de estado registrado. 3. Ocurrió el cambio de estado, notificarlo. Fig. 3-5 Manejo de Eventos. 3.6.2. Consumidor de eventos. Un consumidor de eventos, es aquel que está interesado en que ocurra un suceso o cambio de estado. Para poder estar informado de cuando ocurre, lo que hace es registrarse con el productor de eventos necesario, posteriormente recibirá una notificación en el momento en que ocurre el suceso.. 16.

(26) 3.6.3 Productor de eventos El productor de eventos, por su parte debe darle seguimiento a los registros de notificaciones de los consumidores. Cuando ocurra un cambio de estado de interés para algún consumidor deberá reportarlo, enviando una notificación al consumidor en cuestión. Jini utiliza eventos de un solo tipo llamado RemoteEvent. La clase que repesenta a este tipo de eventos se encuentra en el paquete net.jini.core.event. La definición de la clase es: public class public public public. RemoteEvent implements java. io. Serializable { long getID(); long getSequenceNumber (); java. rmi.MarshalledObject getRegistrationObject ( ) ;. Una forma de crear un productor de eventos sería creando un método como el siguiente para recibir los registros que mandan los consumidores de eventos: public EventRegistration addRemoteListener (RemoteEventListener listener) { return new EventRegistration (O, this, nuil, 0) ;. donde la clase EventRegistration (que se encuentra en el paquete net.jini.core.event ) se especifica como: import net . jini .core. léase. Léase; public class public long seqNum) public public public public. EventRegistration implements java . io. Serializable { EventRegistration (long eventID, Object source, Léase léase, ; long getID(); Object getSource ( ) ; Léase getLease(); long getSequenceNumber ( ) ;. Cuando un consumidor se registra con un productor de eventos, este le debe regresar un objeto del tipo EventRegistration, dicho objeto le proporcionará información valiosa acerca del registro de la notificación que le mando al productor. Por ejemplo, podrá saber cuanto tiempo más el productor conservará el registro de la notificación, y así estar al pendiente para renovarlo mientras tenga interés sobre un cambio de estado deseado. Cada consumidor de eventos deberá implementar la clase RemoteEventListener cuya definición es la siguiente:. 17.

(27) public interface RemoteEventListener extends java. rmi .Remote, java. útil . EventListener { public void notif y (RemoteEvent evt) throws UnknownEventException, j ava . rmi . RemoteException;. Mediante la implementación de la interface RemoteEventListener el cliente podrá crear un objeto conocido como listener el cual registrará con el productor de eventos. Por el lado del productor este le notificará al consumidor cuando ocurra el cambio en el que está interesado ejecutando el método notify del objeto listener. Un método útil para notificar a un consumidor es el siguiente. void sendNotify (long eventID, long seqNum) { if ( listener == nuil) { return;. remoteEvent remoteEvent = new RemoteEvent (this, eventID, seqNum, nuil) ; listener .notify (remoteEvent) ;. 18.

(28) 3.7 Servicio de Impresión [2], [6] y [10]. Cliente Servicio de Localización. Fig. 3-6 Uso del Servicio de Impresión. Después de haber visto los conceptos y algunas de las clases de Jini, lo que sigue es implementar un servicio sencillo y así demostrar la aplicación de los conceptos de Jini. El código completo del servicio de impresión se encuentra en el Apéndice A Se puede ver los pasos necesarios para compilar y hacer uso del servicio de impresión en http://appdev.mty.itesm.mx/Jini/impresion/README.htnil. 3.7.1. Servicio. Lo primero que sedebe hacer al implementar un servicio es crear una interfaz con la cual los clientes podrán comunicarse con el servicio, es decir, cuando requieran hacer uso del servicio enviarán a los localizadores que desean un servicio que implemente la interfaz. La implementación de la interfaz es responsabilidad del servidor. La interfaz que se utilizará en el servicio de impresión se especifica de la siguiente forma: public interface Printer { public void print(int format, int copies, Object data) throws RemoteException;. A continuación sigue la definición del proxy, quien se encargará de recibir las peticiones de impresión del cliente y dirigirlas al servicio remoto para que realice el trabajo.. 19.

(29) public class PrintProxy implements Serializable, Printer {. 3.7.2. Cliente. Cuando se inicializa el cliente, crea un objeto de tipo ServiceTemplate con este objeto se especifica el tipo de servicio que se necesita. En el caso del servicio de impresión, el cliente necesita encontrar servicios que soporten la interface Printer. Class [] types = { Printer.class }; témplate = new ServiceTemplate(nuil, types, nuil);. Después, el cliente se inicia en el entorno de Jini, esto lo hace a través del proceso de descubrimiento de localizadores de servicios. En este ejemplo se desea encontrar todos los localizadores dentro de la misma subred sin importar los grupos que administren dichos localizadores. LookupDiscovery disco = new LookupDiscovery(LookupDiscovery.ALL_GROUPS); disco.addDiscoveryListener(new Discoverer());. La clase Discoverer implementa la interface DiscoveryListener, con el listener el cliente podrá recibir las respuestas de los servicios de localización que pueden atenderlo.. 20.

(30) Capítulo 4 Bitácora Electrónica [5,6,8,9,11] Para mantener de forma permanente y organizada la información de lo que ocurre en el site del Tecnológico de Monterrey surgió el proyecto de desarrollo de una bitácora electrónica. 4.1. Verificación de equipos computacionales del site. Los operadores verifican manualmente el estado de los equipos, vía comandos. Si detectan una falla en el estado de los mismos, la registran en la bitácora electrónica, después le avisan al administrador del equipo con problemas. Un aviso a un administrador puede darse: - Vía radiolocalizador - Vía teléfono No todos los administradores tienen radiolocalizadores, los radiolocalizadores se turnan entre los administradores y se les avisas a los operadores de quién tiene radiolocalizador y quién no, así puedan enviar adecuadamente el aviso de un problema. El administrador al recibir el aviso de que falla uno de sus equipos puede ir y arreglar el problema personalmente, o puede dar indicaciones por teléfono a los operadores para que ellos resuelvan el problema, dependerá de la complejidad del problema si lo resuelve personalmente o no. Además de verificar el estado de los equipos, los operadores se encargan de realizar los respaldos de los mismos y los registran también en la bitácora electrónica. Registran tanto el inicio como el estado en que termina cada respaldo. De esa forma, los administradores puedan enterarse de si se ejecutó o no el respaldo de sus equipos, y si fue exitoso. Los eventos relacionados a respaldos no son motivo de aviso a los administradores.. 4.2. Uso de la bitácora electrónica. La bitácora electrónica permite almacenar eventos relacionados con servidores, impresoras, ruteadores y switches que se encuentran en el site. Los anteriores dispositivos son administrados por el Departamento de Tecnología Computacional (TC), el Departamento de Telecomunicaciones y Redes (TyR) y por la Rectoría Zona Norte (RZN). La bitácora mantiene la información acerca de cada dispositivo, como su número de serie, modelo, nombre lógico con el que se conoce, etc.. 21.

(31) De acuerdo a lo anterior, los usuarios de la bitácora electrónica son: los operadores del site y los administradores de los equipos de hardware( servidores, impresoras, switches, ruteadores, etc.) que se encuentran adentro del site. Las actividades que pueden realizar los usuarios dentro de la bitácora varían dependiendo de ciertas políticas. Es por eso, que de los usuarios de la bitácora, los únicos que tienen privilegios para agregar eventos a la bitácora electrónica son los operadores. En cuanto a los administradores, la única interacción con la bitácora es la de consultar eventos previamente almacenados. De la sección de verificación de equipos computacionales, se puede ver que los eventos que registran los operadores pueden ser causa de aviso a los administradores sólo cuando el evento se relaciona con fallas en un equipo, de lo contrario, si el evento es sólo informativo como el caso de inicio y terminación exitosa de un respaldo, entonces el operador registrará el evento y no avisará al administardor. Ejemplos de eventos que se manejan en la bitácora electrónica: Entrada y salida de personal. Información de los respaldos realizados. Fallas en los equipos computacionales. - Falla en el clima del site, etc. En cuanto a la consulta de eventos previamente almacenados en la bitácora, se realiza de acuerdo a ciertas políticas: 1.- Los operadores pueden consultar todos los eventos. 2.- Los administradores de TC pueden ver todos los eventos de TyR y de RZN. En cuanto a los eventos de su propio departamento sólo pueden consultar eventos de los servidores o impresoras que administren. 3.- Los administradores de TyR y RZN tienen acceso a ver todos los eventos de ambos departamentos.. 22.

(32) El esquema de la base de datos que se maneja en la bitácora electrónica es el siguiente:. Administrador. Equipo. Operador iIIi. rS O^. Impresora. Evento ». •. 'Vlm. Aviso. Origen Fig. 4-1 Esquema de la base de datos de la bitácora electrónica Del esquema anterior se tienen las siguientes reglas al agregar un evento a la bitácora: -. Un evento de la bitácora puede tener sólo un origen, donde el origen representa el departamento o rectoría del cual proviene el evento. Un evento es agregado por un sólo operador. Si el evento que se agrega es originado por una falla, entonces además de registrar el evento, se registra un aviso al administrador del equipo con problemas. Un evento puede crearse a causa de un suceso ocurrido en uno de los equipos o impresoras del site, o simplemente puede ser un evento relacionado únicamente con el estado del site, como lo es la falla del clima del mismo.. -. Un administrador puede atender equipos y/o impresoras.. 23.

(33) 4.3. Herramientas utilizadas en el desarrollo de la bitácora electrónica. Gracias a la bitácora electrónica se mantiene la información de cada evento de forma permanente, en una base de datos de mSQL. Los programas desarrollados para agregar y consultar la información de la bitácora se realizaron mediante el uso de CGI's, los cuales se programaron utilizando el lenguaje de programación Perl. Perl permite crear fácilmente reportes en html de las consultas hechas a la base de datos. Para realizar algunas validaciones y además facilitar la navegación y uso de las pantallas se empleo JavaScript.. 4.4. Seguridad de la bitácora electrónica. El acceso a la bitácora se regula a través de un mecanismo de autenticación basado en cuenta y contraseña. Se necesita de tal mecanismo, porque se requiere confidencialidad de la información almacenada en la bitácora, ya que cualquier usuario del mundo puede intentar acceder a alguna de las páginas de la bitácora a través de su navegador, por eso, con el mecanismo de autenticación se intenta verificar que el usuario que accede a la bitácora es un usuario válido de la misma. Al autenticarse el usuario, se abre una sesión, útil para consultar los eventos que le corresponde ver de la bitácora. Una sesión de la bitácora, tiene como característica el expirar después de 7 minutos de inactividad, los operadores fijaron ese tiempo de acuerdo a las actividades que realizan, si después de 7 minutos no utilizan la bitácora significa que están ocupados en alguna otra actividad. La característica de expiración de una sesión, se tiene para evitar que un operador agregue un evento utilizando la sesión e identidad de otro operador. Así, cuando se consulta el detalle de un evento en particular, se puede tener una mayor confianza en cuanto a quién lo agrego. De acuerdo a la forma en que se desarrollo la bitácora, el navegador no tiene conocimiento del tipo de usuario que observa las páginas de la bitácora, sólo se sabe la identidad del usuario cuando lanza una consulta o una alta a la base de datos. Por lo anterior, la expiración de una sesión se aplica a todos los usuarios, tanto operadores como administradores. A su vez, la restricción en el tiempo de expiración de una sesión, presenta una desventaja para los administradores. Es decir, si un administrador desea estar informado de los eventos de sus equipos, entonces necesitará autenticarse varias veces al día, o autenticarse una sola vez, pero no dejar de utilizar la bitácora más de 7 minutos y así su sesión siempre estará activa, lo cual es improbable y molesto.. 24.

(34) 4.5. Servicio de bitácora electrónica basado en Jini. Tomando en cuenta las características de la bitácora electrónica, se puede observar que al no exisitir un acceso a la bitácora de una forma flexible para los administradores provoca la falla de uso de la información de la bitácora; Con lo cual, la bitácora pierde la utilidad para la que fue creada, informar a los operadores con un medio electrónico y de almacenamiento permanente. Además si los administradores checan los errores o eventos registrados en la bitácora, libera a los operadores de la tarea de avisar y así pueden dedicarse a hacer una verificación a fondo de cada uno de los servidores. Por este motivo, se necesita de una solución que provea un cliente para los administradores que no tenga las mismas restricciones que el cliente del browser, el cual maneja tiempo de expiración. En el desarrollo de la solución se utilizó Jini, lo cual nos brinda la facilidad de crear servicios y clientes más enterados de su entorno. Los clientes Jini son capaces de saber cuando está o no disponible algún servicio requerido, ayudados por el uso de eventos remotos. En este caso, el uso de los eventos remotos será de gran utilidad para saber cuando se agregó un nuevo evento a la bitácora. La principal ventaja que posee un cliente Jini es la de ser capaz de ejecutarse en múltiples plataformas. Al igual que el cliente que ya se tiene basado en web browser el cliente de Jini seguirá las mismas políticas de mostrar todos los eventos de otros departamentos y del departamento de Tecnología Informática, pero sólo mostrará eventos que se relacionen con los servidores que sean administrados por el usuario; Es decir, un administrador sólo podrá ver eventos relacionados con sus servidores. Para llevar a cabo el desarrollo de la solución se creo un servidor Jini capaz de recibir por sockets la notificación de que se agrego un nuevo evento. Esto se hizo así para no modificar la bitácora completa. A la bitácora ya existente, se le agregaron las líneas de código que se conectan por sockets al servicio de bitácora basado en Jini. Fue la manera de envolver un servicio de software y exponerlo a la red utilizando Jini. Además se desarrolló un cliente que es capaz de comunicarse con el servicio de la bitácora, el cual es notificado cuando se agregan eventos que puedan mostrarse al administrador.. 25.

(35) A continuación se muestra el esquema utilizado en el servicio de bitácora implementado.. Consulta Cventos Bitácora Electrónica. Base de. Servicio. Envía aviso de nuevo Evento Registra su Interés por Eventos. Búsqueda de Servicio de Bitácora Servicio de Locali/ación. Fig. 4-2 Servicio de Notificación de la bitácora. 26. Cliente.

(36) 4.6. Seguridad del servicio de bitácora electrónica basado en Jini.. El cliente que se propone es útil sólo para los administradores, porque lo que se pretende es crear un cliente que solvente la desventaja del cliente actual basado en web browsers (cierre de la sesión al tiempo de expiración).. 4.7. Servicio de bitácora basado en Jini [5,6,8,9,11]. 4.7.1. Servicio. El primero paso en la definición de un nuevo servicio, consiste en la creación de una interface de Java, la cual representa los métodos o funciones que pueden utilizar los clientes del servicio. La interface que se hizo para el servicio de bitácora es la siguiente: public interface Auth extends Remote { public EventoBitacora getEvento (long ID) throws java . rmi . RemoteException; public EventRegistration addRemoteListener (RemoteEventListener listener, String cuenta, String password) throws java. rmi. RemoteException; public void removeRemoteListener (RemoteEventListener listener) throws j ava . rmi . RemoteException;. El método getEvento() regresa como resultado un objeto de tipo EventoBitacora. Este método se utiliza sabe el número de evento que desea consultar. Más adelante, se verá que cuando se le notifica al cliente de un nuevo evento, el mensaje de notificación lleva consigo el número de evento por el cual se le está notificando al cliente. El método addRemoteListener •() lo utilizan los clientes para avisarle al servicio que desean recibir notificaciones cuando se agregue un evento que pueda ver el cliente en particular. Este método se encargará de autenticar el usuario y sí resulta exitosa la autenticación almacenará el registro de que el cliente desea ser notificado. Por último, el método removeRemoteListener() es utilizado por los clientes cuando ya no desean ser notificados cuando se agregue un evento. Es útil para cuando los usuarios desean cerrar la aplicación, así el servicio no mantiene innecesariamente el registro de clientes que ya no están dispuestos a recibir notificaciones por parte del servicio. Cabe señalar que la interface extiende de la interface Remote, lo cual implica que el proxy se comunicará con el servicio utilizando RMI.. 27.

(37) 4.7.2. Cliente. El cliente al igual que el servicio debe ser capaz de exportar una referencia a él como lo es un proxy. Tal proxy será útil para que el servicio pueda contactar al cliente y notificarle cuando se agregue un evento a la bitácora. El proxy del cliente se creará como un stub de la clase cliente. Es por eso que la clase del cliente extiende de UnicastRemoteObject. También cabe señalar, que el cliente iniplementa la interface RemoteEventListener lo cual implica que este es el objeto por parte del cliente que recibirá las notificaciones de que se agregó un nuevo evento. public class TestUnicastAuth extends UnicastRemoteObject implements ActionListener,ItemListener,RemoteEventListener {. 28.

(38) Capítulo 5 Análisis de Resultados [3,5,7] 5.1. Requerimientos de los servicios de bitácora. En este apartado se mencionan los requerimientos necesarios para hacer uso tanto de la bitácora actual como del servicio de bitácora basado en Jini. 5.1.1. Requerimientos de la bitácora actual. Por el lado del cliente, se necesita un web browser, el cual debe estar habilitado para usar Java Script y también debe permitir guardar una cookie, necesaria para guardar la identidad del usuario que accede a la bitácora. En el lado del servidor, es necesario que este funcionando el proceso de la base de datos y el servidor de web encargado de publicar las páginas de la bitácora electrónica.. 5.1.2. Requerimientos del servicio de bitácora [3,5,7]. Para el cliente se necesita: Instalar Jini Technology Starter Kit de http://www.sun.com/jini -. Instalar Java 2 SDK de http://java.sun.com/j2se Variable de ambiente CLASSPATH, apuntando a los archivos para usar la tecnología Jini. Un ejemplo para Windows: CLASSPATH=%JINIJlOMEDIR%\lib\jini-core.jar;%JINI_HOMEDIR%\lib\jiniext.jar; %JINI_HOMEDIR%\sun-util.jar. -. Iniciar un servidor de web con las clases que necesita exportar el cliente para que pueda ser notificado cuando se agregue un evento a la bitácora. El cual puede iniciarse desde Windows como: startjava -jar %JINI_HOMEDIR%\lib\tools.jar -port 8098 -dir %CLIENT-DL% trees -verbose - Iniciar la aplicación que representa el cliente. Ejemplo para Windows: java -Djava.security.policy=policy.all -Djava.rmi.server.codebase = http://131.178.2.61:8098/ TestUnicastAuth. 29.

(39) Para iniciar el servicio de bitácora basado en Jini: Levantar un servidor de web para que tanto los clientes como los servicios puedan hacer uso de las funciones de los servicios de localización. -. Iniciar el proceso de rmi.. -. Iniciar el servicio de localización, especificamente reggie, el cual es implementado por Sun. Servidor de web para exportar las clases del servicio. Un ejemplo para Windows sería: startjava -jar %JINI_HOMEDIR\lib\tools.jar -port 8095 -dir %SERVER-DL% -trees -verbose. -. Ejecutar el servicio para que se registre con el localizador. Un ejemplo para Windows sería: java -Djava.security.policy=policy.all -Djava.rmi.server.codebase = http://l31.178.2.61:8095/ AuthServerRMI. Con lo anterior, se aprecia que una desventaja de utilizar Jini, es que es mayor el número de requerimientos para poder hacer uso un servicio. La forma de utilizar el cliente se hace mediante el uso de una cuenta y una contraseña. Se utilizará la misma contraseña que maneja el cliente del web browser, ya que ambos se autentican directamente con la base de datos. Así, el administrador podrá abrir su cliente Jini y autenticarse sólo una vez y estará listo para recibir los eventos relacionados con sus equipos en el momento en que se agregan en la bitácora electrónica, con la ventaja de que no se cerrará su sesión, porque no hay tiempo de expiración.. 5.2 Comparación entre el servicio actual y el servicio basado en Jini Ambos servicios le permiten a los usuarios consultar información acerca de los eventos de la bitácora electrónica, pero existen algunas diferencias. En el servicio actual de la bitácora, el cliente puede agregar y consultar eventos, pero tiene algunas desventajas en su uso, las cuales se podrían eliminar con programación, lo cual resultaría complejo, debido a la estructura utilizada para el manejo de usuarios que tiene la bitácora actual. Una de tales desventajas es que utiliza un tiempo de expiración en las sesiones que abren los clientes, en donde, se determinó que el tiempo de inactividad es el mínimo necesario para que los operadores puedan realizar sus actividades, específicamente agregar eventos, con tal restricción de tiempo se impacta en el uso de los demás usuarios. Por lo que, los administradores tienen que volver a autenticarse cada vez que se cumple el tiempo de inactividad. Otra desventaja de la bitácora actual es que los administradores. 30.

(40) necesitan periódicamente realizar consultas a la bitácora para enterarse si se agregó un nuevo evento relacionado a sus equipos. Con el servicio y el cliente basados en Jini, se corrigieron las desventajas de la bitácora actual, aclarando que tales desventajas pueden solucionarse directamente en la bitácora actual, pero, con Jini pueden solucionarse de una manera más fácil, ya que la manera en que trabaja Jini se acopla perfectamente a las necesidades que se tienen. Con el uso del cliente Jini, los administradores sólo necesitarán autenticarse una vez y con ello podrán recibir notificaciones del servicio de bitácora justo en el momento en que se agregue un nuevo evento relacionado a sus equipos, y así se disminuye la cantidad de veces en que un administrador consulta la bitácora en busca de nuevos eventos.. 31.

(41) Capítulo 6 Conclusiones y trabajos futuros 6.1 Conclusiones Jini se define como una infraestructura capaz de permitir a los dispositivos o servicios conectarse entre sí para crear comunidades o federaciones de servicios instantáneas. De esa forma, los usuarios pueden crear sus propias redes o comunidades sin importar donde se encuentren. Jini permite que los servicios puedan fluir entre redes, sin requerir una configuración o administración estática. Es por eso, que se dice de Jini que soporta la creación de redes espontáneas Algunas de las ventajas claves de Jini son las siguientes: Ayuda extender el dominio de sistemas propietarios ya que puede exportarlo a diferentes plataformas. - Un servicio puede exportar su funcionalidad de manera transparente, sin necesidad de replicar los programas o datos que necesita, para ejecutarse en otras computadoras. - El uso de tiempos de expiración en la separación de recursos, evita acapar los recursos innecesariamente. - El uso de notificaciones asincronas ayuda a mantener informado a los clientes de su entorno y del estado de los servicios que requieren.. 6.2 Trabajos Futuros Una desventaja que tiene actualmente la tecnología Jini es que no puede utilizarse en dispositivos pequeños, aún y existan máquinas virtuales para dispositivos como PDA's, tales máquinas virtuales no manejan la especificación completa de RMI necesaria para transferir objetos entre máquinas virtuales diferentes. En un futuro, después de que se liberen máquinas virtuales capaces de transferir objetos, se podría utilizar el servicio de bitácora desde PDA's. Otra mejora al cliente, sería agregarle la funcionalidad de poder hacer consultas de eventos creados antes de que el usuario se autenticara.. 32.

(42) Apéndice A Servicio de Impresión [2,6,10] A continuación se presentan los programas que conforman el servicio de impresión así como su uso. Se trabajará en un servicio de impresión sencillo, su única función será recibir de los clientes un enunciado a imprimir. Por el lado del cliente, la interfaz gráfica presentará los servicios de impresión disponibles en la red, el usuario podrá escoger alguno en base a su localización geográfica. La ayuda para la compilación y uso del servicio de impresión se encuentra en: http://appdev/.nity.itesm.mx/Jini/impresión/README.html El análisis del servicio de impresión comprende la creación y uso del mismo.. A.l. Creación del servicio de impresión. La creación del servicio de impresión se divide en codificación del servicio, cliente y termina con la compilación correspondiente. A.1.1 Servicio El presente servicio se utilizará la arquitectura de un servicio basado en un proxy RMI. Para ello, es necesario especificar una interfaz que herede de la interfaz java.rmi.Remote. Dicha interfaz será el medio de publicación de lo que será capaz de realizar el servicio. La especificación de la interfaz es como sigue: import java.rmi.Remote; import java.rmi.RemoteException; public interface Printer extends Remote { public void print(int format, int copies, Object data) throws RemoteException;. La interfaz posee un único método llamado print el cual recibe los parámetros: data: Los datos a imprimir. El objeto que se va a imprimir debe implementar la interface java.awt.Printable o la java.awt.print.Pageable para que pueda imprimirse.. 33.

(43) -. formal: La orientación del papel. El entero representa uno de los formatos especiales definidos en java.awt.print.PageFormat como PORTRAIT, LANDSCAPE o REVERSE_LANDSCAPE.. -. copies: El número deseado de copias a imprimir.. Con la interfaz anterior se muestra que el cliente sólo necesitará invocar el método print al servicio para que este efectúe la impresión. Ahora es necesario especificar la implementación del servicio: import import import import import import import. j ava . awt . print . Printable ; java. awt .print . Pageable; j ava . awt . print . PageFormat ; java . awt .print . PrinterJob; j ava . rmi . server . UnicastRemoteOb j ect ; java . rmi . Remote; j ava . rmi . RemoteException;. public class Printerlmpl extends UnicastRemoteObject implements Printer { public Printerlmpl ( ) throws RemoteException {. public void print (int format, int copies, Object d a t a ) { Object agent = getPrintAgent ( d a t a ) ; PrintRecord record = new PrintRecord ( f o r m a t , copies, data, agent) ; printRecord (record) ;. Object getPrintAgent (Object data) { if (data instanceof Printable) { System. out . println ( "printable" ) ; return data; } if (data instanceof Pageable) { System. out .println ( "pageable" ) ; return data;. System. out .println ( "Error al imprimir"); return nuil;. Exception printRecord (PrintRecord record) { Exception ex = nuil; System. out .println ("Datos : " + record. data) ; PageFormat format = new PageFormat (); format . setOrientation (record. format) ; PrinterJob Job = PrinterJob. getPrinter Job (); job. setCopies (record. copies) ; job.defaultPage (format) ;. 34.

(44) if (record.agent instanceof Pageable) { Job.setPageable((Pageable) record.agent); try { job.print(); } catch (Exception ex2) { ex = ex2; } else if (record.agent instanceof Printable) { job.setPrintable((Printable) record.agent, format); try { job.print() ; } catch (Exception ex2) { ex2.printStackTrace(); ex = ex2; } else { ex = new IllegalArgumentException("Formato invalido"); return ex; } }. Al heredar de UnicastRemoteObject significa que creará y exportará un objeto proxy sin necesidad de que el programador haga algo para ello. En la implementación se utiliza un objeto del tipo PrintRecord para manipular los datos a imprimir. La especificación de la clase es la siguiente: import java. io . Serializable; class PrintRecord implements Serializable { int format; int copies; Object data; Object agent; PrintRecord (int format, int copies, Object data, Object agent) { this. format = format; this. copies = copies; this. data = data; this. agent = agent;. Este objeto además de contener los datos a imprimir también cuenta con un agente el cual conoce como se imprimirá la información. A continuación, para publicar el servicio se definirá un servidor de impresión, cuya función será registrar el proxy RMI con los diferentes servicios de localización, así como de administrar el tiempo de registro.. 35.

(45) import import import import import import import import import import import import import import. net . jini .discovery. LookupDiscovery; net . j ini . discovery. DiscoveryListener; net . jini . discovery. DiscoveryEvent; net . jini. core. lookup. ServiceRegistrar; net . j ini . core . lookup . Serviceltem; net . j ini . core . lookup . ServiceRegistration; net . j ini . core . léase . Léase ; net . j ini . léase . LeaseRenewalManager; net . j ini . léase . LeaseListener; net . j ini . léase . LeaseRenewalEvent ; j ava . rmi . RMISecurityManager ; net . j ini . core . entry . Entry; net . j ini . lookup . entry . Location; net . j ini . core . léase . UnknownLeaseException;. public class PrinterServerRMI implements DiscoveryListener, LeaseListener. protected Printerlmpl impl; static protected String edificio, piso, cuarto; protected LeaseRenewalManager leaseManager = new LeaseRenewalManager ( ) ; public static void main (String [] args) { if (args.length != 3) { System. out .println ( "Uso : PrinterServerRMI <edificio> <piso> <cuarto>") ; } else { edif icio=args [0] ; piso=args [1] ; cuarto=args [2] ; System. out. println ("Ed: "+edificio+" Piso: "+piso+" Cuarto: "+cuarto) ; new PrinterServerRMI () ;. public PrinterServerRMI () { try { impl = new Printerlmpl ( ) ; } catch (Exception e) { System. err .println ( "New impl: " + e . toString (}); System. exit (1) ;. System. setSecurityManager (new RMISecurityManager ( ) ) ; LookupDiscovery discover = nuil; try { discover = new LookupDiscovery (LookupDiscovery. ALL_GROUPS) ; } catch (Exception e) { System. err .println (e. toString () ) ; System. exit (1) ;. 36.

(46) discover . addDiscoveryLis tener (this) ;. public void discovered(DiscoveryEvent evt) { ServiceRegistrar [] registrara = evt . getRegistrars ( ) ; Printer service; for (int n = 0; n < registrars . length; n++) { ServiceRegistrar registrar = registrars [n] ; Serviceltem Ítem = new Serviceltem(null, impl, nuil) ; ServiceRegistration reg = nuil; try { reg = registrar . register (Ítem, Léase . FOREVER) ; Entry[] entries = new Entry[l]; entries[0] = new Location (piso, cuarto, edificio) ; reg. addAt tributes (entries) ; } catch (java. rmi . RemoteException e) { System. err.print ( "Register exception: ") ; e . printStackTrace ( ) ; continué; } catch (UnknownLeaseException lex) { System. err.print ("Error al agregar attributos : "}; lex. printStackTrace ( ) ; continué;. try { System. out .println ( "service registered at " + registrar . getLocator ( ) . getHost ( ) ) ; } catch (Exception e) { } leaseManager . renewUntil (reg. getLease (), Léase. FOREVER, this) ;. public void discarded (DiscoveryEvent evt) {. public void notify (LeaseRenewalEvent evt) { System. out .println ( "Léase expired " + evt . toString ( ) ) ;. 37.