JiniTM se puede definir como el "contrato" o conjunto de requisitos que deben cumplir las entidades de una comunidad para poder conectar servicios ...

JiniTM se puede definir como el "contrato" o conjunto de requisitos que deben cumplir las entidades de una comunidad para poder conectar servicios y clientes entre si, sin importar su funcion especifica. En esta definicion se mencionan tres palabras que se usaran constantemente a lo largo de este articulo: Comunidad, Servicio y Cliente. El conjunto de servicios que forman un grupo de entidades con alguna similitud define una comunidad JiniTM o djinn. Servicio queda definido como una entidad que tiene la capacidad de efectuar una tarea, y estar disponible para ser utilizada por otras entidades de la comunidad, ya sea otro Servicio o un Cliente; donde Cliente es la entidad que se encuentra usando un servicio [8], [9]. JiniTM maneja 6 conceptos fundamentales: Discovery (Descubrimiento). Tarea realizada por 10s Servicios y Clientes, en la cual, ambas entidades tratan de localizar el o 10s djinns, en especifico a 10s servicios de busqueda o de lookup. Lookup (Busqueda). Accion llevada a cab0 por todos 10s Clientes quienes buscan el servicio que necesitan basandose en la interfaz o en atributos. Join (Union). Proceso en el cual el servidor se registra en el servicio de Lookup. Este registro implica dejar el objeto proxy y 10s atributos que lo definen. Leasing (Arrendamiento). Caracteristica de todas las entidades del djinn. Es una "prueba de interes" en cualquier servicio incluyendo al lookup. Este proceso le da a JiniTM su capacidad de autorregeneracion y configuracion dinamica. Eventos Remotos. Al igual que JavaTM que soporta eventos o mensajes asincronos, JiniTM 10s toma de imagenes (iluminacion y camaras) son implementa de una manera remota en donde se respectivamente las funciones de posicionamiento y ejecucion. Transacciones. Una transaccion es la operacion que no puede quedar en estado indefinido (se complementa con exito o se fracasa). Utilizada normalmente en accesos y escrituras a bases de datos, JiniTM, en cambio, la utiliza en manera remota. Estas caracteristicas permiten la creacion de una red distribuida con cero administracion central, auto reparable y dinamica, esto es, respectivamente, una red en donde la administracion de 10s servicios recae en 10s laboratorios fisicos que 10s contienen, detecta fallas de conexion y muestra unicamente 10s dispositivos disponibles, su configuracion cambia constantemente al permitir una frecuente conexion y desconexion de 10s servicios sin que por esto sufra alteraciones la estructura de la red como un todo; siendo estas propiedades ideales para satisfacer las necesidades del Laboratorio Virtual. C. Requerimientos y principios de funcionamiento del Laboratorio Virtual con hiTM En la elaboracion de un Laboratorio Virtual con JiniTM es necesario crear primer0 una abstraccion de 10s dispositivos que seran conectados al Los Servicios disponibles son ofrecidos a cualquier cliente que se conecte al laboratorio virtual. El Laboratorio Virtual puede ser utilizado por el cliente de dos maneras distintas: mediante una interfaz grafica de usuario (GUI) o de manera automatica por un agente-cliente de software. Este agente puede ser creado por el investigador o estar disponible en el laboratorio. En el primer caso, la interfaz grafica de usuario, GUI, representa para el usuario el Laboratorio Virtual, por medio de la cual se conecta con la comunidad JiniTM correspondiente y haciendo uso de 10s Servicios de Lookup que descubra, buscara la interfaz que identifica a 10s dispositivos del laboratorio. Este Servicio de Lookup le informa sobre la disponibilidad 10s Servicios encontrados y sus caracteristicas. El usuario elige entonces cuales desea utilizar y solicita el objeto proxy del Servicio para descargarlo en su maquina junto con la interfaz grafica que provee el servicio para su operacion. Por otra parte, si se utiliza un Cliente de Software (agente), este sera ejecutado y automaticamente se encargara de localizar 10s Servicios requeridos, descargara el objeto proxy para utilizarlo y al terminar entregara un reporte al cliente con 10s resultados obtenidos. Gracias al uso de JavaTM, con sus capacidades de trasmision de codigo vivo y serializacion, y con un disefio e le puede agregar mayor funcionalidad dependiendo de la irnplernentacion del Servicio). init( ). Con este cornando se envia al dispositivo a su posicion inicial. stop( ). Reestablece la posicion inicial del dispositivo y lo declara disponible a 10s usuarios. interfaz es una subclase de la interfaz java.rmi.Remote, que en el lenguaje de programacion JavaTM, indica que la clase que la implernente sera usada de rnanera rernota a traves de RMI. Cualquier dispositivo que se pretenda colocar en el laboratorio virtual debe irnplernentar la interfaz JMVL. B. Clases desarrolladas para la creacion del cliente. En el paquete jmvl.client se encuentran la clase JMVLApp, y el subpaquete jmvl.client.ui, el cual a su vez contiene las clases relacionadas a la interfaz grafica (fig 3). % s e w ~ c e ~ s c o r e ~ ~ ~ ~ r Ser
ceDaco~ryManager %lookup~scoveryMgr LookupDlscweryManager + l e a s e ~ g r LeaseRenewa lbnager &lookupcache Lookupcache Figura 3. Subpaquete jrnvl.client. JMVLApp es el nucleo para la creacion de 10s tipos de clientes que pueden acceder al laboratorio virtual de rnanufactura. La clase JMVLApp es el nucleo de la aplicacion cliente. Esta clase se encarga del descubrimiento (discovery) de 10s servicios de Lookup en la red de area local, y en la lista de laboratorios federados en el laboratorio virtual. Sin necesidad de una configuracion adicional la clase JMVLApp se encarga de la localizacion (lookup) de todos 10s servicios del laboratorio virtual, permitiendole al cliente una busqueda por nombre, localizacion o estatus. Ademas, en su busqueda puede escuchar por eventos remotos generados en 10s servicios de Lookup encontrados, 10s cuales indican carnbio en el estatus de 10s servicios: desconexion, union o rnodificiacion. %dasklup . JDaskiupP..irw Figura 4. Subpaquete jrnvl.client.ui. Vista general de la interfaz grafica propuesta para JMVLApp Las clases JMVLFrame y ServiceUlMenultem son las clases graficas localizadas en el subpaquete jmvl.client.ui (fig 4). JMVLFrame es una ventana del tip0 MDI, (Multiple Document Interface) donde el usuario descarga las interfaces graficas que provee cada dispositivo para su control. Si un usuario desea utilizar la interfaz grafica del laboratorio JMVL debe ejecutar esta clase para que las GUI de 10s Servicios sean recuperadas y puestas a disposition del usuario (fig. 5 y 6), esto permite que el laboratorio remoto tenga information actualizada de las GUI y del funcionamiento de 10s dispositivos. Figura 5. Aplicacion cliente ejecutada desde una de las paginas web del laboratorio virtual de rnanufactura basado en hiTM. Esta ejecucion tarnbien usa Java Web Start ver. 1.0.1 La clase ServiceUIMenultem, es el escuchador de eventos remotos que sirve al JMVLFrame para detectar 10s nuevos Servicios y agrega 10s laboratorios federados y 10s dispositivos que contienen, mostrandolos en el menu de la ventana "Padre" del MDI. Ademas, esta clase se encarga de descargar la interfaz grafica del servicio y desplegarla en la ventana JMVLFrame. Las caracteristicas de busqueda pueden ser modificadas por medio del escuchador. Aunque JMVLFrame utiliza la clase JMVLApp, no utiliza su escuchador de eventos remotos, en su lugar utiliza como este a ServiceUIMenultem. Figura 6. Aplicacion cliente ejecutada localrnente con Java Web Start ver 1.0.1 C. Clase del Servidor General Los Servicios del JMVL, que representan dispositivos distribuidos espacialrnente a lo largo del rnundo, necesitan descubrir y unirse a 10s Servicios del Lookup para poder federarse en el Laboratorio Virtual, esto es, necesitan colocar sus objetos proxy en 10s Servicios de Lookup y esperar ser requeridos, ademas necesitan conservar su numero de identification universal de servicio para ser localizables siernpre a pesar de fallas, modificaciones o actualizaciones del Labor