Jini: nueva tecnología para un mundo en red

Anterior 1 2 Página 2 Página 2 de 2

Jini en contexto

Tradicionalmente, los sistemas operativos se han diseñado asumiendo que una computadora tendrá un procesador, algo de memoria y un disco. Cuando arranca una computadora, lo primero que hace es buscar un disco. Si no encuentra un disco, no puede funcionar como una computadora. Sin embargo, cada vez más, las computadoras aparecen con una apariencia diferente: como dispositivos integrados que tienen un procesador, algo de memoria y una conexión de red, pero sin disco. Lo primero que hace un teléfono móvil cuando lo arranca, por ejemplo, es buscar la red telefónica. Si no encuentra la red, no puede funcionar como un teléfono celular. Esta tendencia en el entorno de hardware, de centrado en disco a centrado en red, afectará la forma en que organizamos nuestro software, y ahí es donde entra Jini.

Jini es un intento de repensar la arquitectura de la computadora, dada la creciente importancia de la red y la proliferación de procesadores en dispositivos que no tienen unidad de disco. Estos dispositivos, que provendrán de muchos proveedores diferentes, deberán interactuar a través de una red. La red en sí será muy dinámica: los dispositivos y servicios se agregarán y eliminarán con regularidad. Jini proporciona mecanismos para permitir la adición, eliminación y búsqueda sin problemas de dispositivos y servicios en la red. Además, Jini proporciona un modelo de programación que facilita a los programadores hacer que sus dispositivos se comuniquen entre sí.

Sobre la base de Java, la serialización de objetos y RMI, que permiten que los objetos se muevan por la red de una máquina virtual a otra, Jini intenta extender los beneficios de la programación orientada a objetos a la red. En lugar de requerir que los proveedores de dispositivos acuerden los protocolos de red a través de los cuales sus dispositivos pueden interactuar, Jini permite que los dispositivos se comuniquen entre sí a través de interfaces con objetos.

¿Qué es Jini?

Jini es un conjunto de API y protocolos de red que pueden ayudarlo a construir e implementar sistemas distribuidos que están organizados como federaciones de servicios. Un servicio puede ser cualquier cosa que se encuentre en la red y esté listo para realizar una función útil. Los dispositivos de hardware, el software, los canales de comunicación, incluso los propios usuarios humanos, pueden ser servicios. Una unidad de disco habilitada para Jini, por ejemplo, podría ofrecer un servicio de "almacenamiento". Una impresora habilitada para Jini podría ofrecer un servicio de "impresión". Una federación de servicios, entonces, es un conjunto de servicios, actualmente disponibles en la red, que un cliente (es decir, un programa, servicio o usuario) puede reunir para ayudarlo a lograr algún objetivo.

Para realizar una tarea, un cliente solicita la ayuda de los servicios. Por ejemplo, un programa cliente puede cargar imágenes del servicio de almacenamiento de imágenes en una cámara digital, descargar las imágenes a un servicio de almacenamiento persistente ofrecido por una unidad de disco y enviar una página con versiones en miniatura de las imágenes al servicio de impresión de una impresora a color. En este ejemplo, el programa cliente crea un sistema distribuido que consta de él mismo, el servicio de almacenamiento de imágenes, el servicio de almacenamiento persistente y el servicio de impresión en color. El cliente y los servicios de este sistema distribuido trabajan juntos para realizar la tarea: descargar y almacenar imágenes de una cámara digital e imprimir una página de miniaturas.

La idea detrás de la palabra federaciónse basa en la visión de Jini de la red: no hay una autoridad central de control. Debido a que ningún servicio está a cargo, el conjunto de todos los servicios disponibles en la red forma una federación, un grupo compuesto por pares iguales. En lugar de una autoridad central, la infraestructura de ejecución de Jini simplemente proporciona una forma para que los clientes y los servicios se encuentren entre sí (a través de un servicio de búsqueda, que almacena un directorio de servicios actualmente disponibles). Una vez que los servicios se ubican entre sí, están solos. El cliente y sus servicios alistados realizan su tarea independientemente de la infraestructura de tiempo de ejecución de Jini. Si el servicio de búsqueda de Jini falla, cualquier sistema distribuido reunido a través del servicio de búsqueda antes de que fallara puede continuar su trabajo.Jini incluso incluye un protocolo de red que los clientes pueden usar para encontrar servicios en ausencia de un servicio de búsqueda.

Cómo funciona Jini

Jini define una infraestructura de tiempo de ejecución que reside en la red y proporciona mecanismos que le permiten agregar, eliminar, ubicar y acceder a servicios. La infraestructura de tiempo de ejecución reside en la red en tres lugares: en los servicios de búsqueda que se encuentran en la red; en los proveedores de servicios (como dispositivos habilitados para Jini); y en clientes. Los servicios de búsqueda son el mecanismo de organización central para los sistemas basados ​​en Jini. Cuando hay nuevos servicios disponibles en la red, se registran en un servicio de búsqueda. Cuando los clientes desean localizar un servicio para ayudar con alguna tarea, consultan un servicio de búsqueda.

La infraestructura de tiempo de ejecución usa un protocolo a nivel de red, llamado descubrimiento , y dos protocolos a nivel de objeto, llamados unión y búsqueda. Discovery permite a los clientes y servicios localizar servicios de búsqueda. Unirse permite que un servicio se registre en un servicio de búsqueda. La búsqueda permite a un cliente consultar un servicio de búsqueda de servicios que pueden ayudar al cliente a lograr sus objetivos.

El proceso de descubrimiento

El descubrimiento funciona así: imagina que tienes una unidad de disco habilitada para Jini que ofrece un servicio de almacenamiento persistente. Tan pronto como conecta la unidad a la red, transmite un anuncio de presencia al colocar un paquete de multidifusión en un puerto conocido. En el anuncio de presencia se incluye una dirección IP y un número de puerto donde un servicio de búsqueda puede comunicarse con la unidad de disco.

Los servicios de búsqueda monitorean el puerto conocido en busca de paquetes de anuncios de presencia. Cuando un servicio de búsqueda recibe un anuncio de presencia, se abre e inspecciona el paquete. El paquete contiene información que permite al servicio de búsqueda determinar si debe comunicarse o no con el remitente del paquete. Si es así, se pone en contacto con el remitente directamente mediante una conexión TCP a la dirección IP y el número de puerto extraídos del paquete. Usando RMI, el servicio de búsqueda envía un objeto, llamado registrador de servicios,a través de la red al originador del paquete. El objeto del registrador de servicios es facilitar una mayor comunicación con el servicio de búsqueda. Al invocar métodos en este objeto, el remitente del paquete de anuncios puede realizar una unión y una búsqueda en el servicio de búsqueda. En el caso de la unidad de disco, el servicio de búsqueda haría una conexión TCP a la unidad de disco y le enviaría un objeto de registro de servicios, a través del cual la unidad de disco registraría su servicio de almacenamiento persistente a través del proceso de unión.

El proceso de unión

Una vez que un proveedor de servicios tiene un objeto de registro de servicios, el producto final del descubrimiento, está listo para unirse, para formar parte de la federación de servicios que están registrados en el servicio de búsqueda. Para hacer una unión, el proveedor de servicios invoca el register()método en el objeto del registrador de servicios, pasando como parámetro un objeto llamado elemento de servicio, un paquete de objetos que describen el servicio. El register()método envía una copia del elemento de servicio al servicio de búsqueda, donde se almacena el elemento de servicio. Una vez que esto se ha completado, el proveedor de servicios ha finalizado el proceso de unión: su servicio se ha registrado en el servicio de búsqueda.

El elemento de servicio es un contenedor para varios objetos, incluido un objeto llamado objeto de servicio, que los clientes pueden utilizar para interactuar con el servicio. El artículo de servicio también puede incluir cualquier número de atributos, que pueden ser cualquier objeto. Algunos atributos potenciales son iconos, clases que proporcionan GUI para el servicio y objetos que brindan más información sobre el servicio.

Los objetos de servicio generalmente implementan una o más interfaces a través de las cuales los clientes interactúan con el servicio. Por ejemplo, un servicio de búsqueda es un servicio Jini y su objeto de servicio es el registrador de servicios. El register()método invocado por los proveedores de servicios durante la unión se declara en la ServiceRegistrarinterfaz, que implementan todos los objetos de registro de servicios. Los clientes y proveedores de servicios se comunican con el servicio de búsqueda a través del objeto registrador de servicios invocando métodos declarados en la ServiceRegistrarinterfaz. Asimismo, una unidad de disco proporcionaría un objeto de servicio que implementara alguna interfaz de servicio de almacenamiento conocida. Los clientes buscarían e interactuarían con la unidad de disco mediante esta interfaz de servicio de almacenamiento.

El proceso de búsqueda

Una vez que un servicio se ha registrado con un servicio de búsqueda a través del proceso de unión, ese servicio está disponible para que lo utilicen los clientes que consultan ese servicio de búsqueda. Para construir un sistema distribuido de servicios que trabajarán juntos para realizar alguna tarea, un cliente debe ubicar y solicitar la ayuda de los servicios individuales. Para encontrar un servicio, los clientes consultan los servicios de búsqueda a través de un proceso llamado búsqueda.

Para realizar una búsqueda, un cliente invoca el lookup()método en un objeto de registro de servicios. (Un cliente, como un proveedor de servicios, obtiene un registrador de servicios mediante el proceso de descubrimiento, como se describió anteriormente en este artículo). El cliente pasa como argumento a lookup()una plantilla de servicio, un objeto que sirve como criterio de búsqueda para la consulta. La plantilla de servicio puede incluir una referencia a una matriz de Classobjetos. Estos Classobjetos indican al servicio de búsqueda el tipo (o tipos) de Java del objeto de servicio deseado por el cliente. La plantilla de servicio también puede incluir un ID de servicio, que identifica de forma única un servicio, y atributos, que deben coincidir exactamente con los atributos cargados por el proveedor de servicios en el elemento de servicio. La plantilla de servicio también puede contener comodines para cualquiera de estos campos. Un comodín en el campo de ID de servicio, por ejemplo, coincidirá con cualquier ID de servicio. El lookup()método envía la plantilla de servicio al servicio de búsqueda, que realiza la consulta y devuelve cero a muchos objetos de servicio coincidentes. El cliente obtiene una referencia a los objetos de servicio coincidentes como valor de retorno del lookup()método.

En el caso general, un cliente busca un servicio por tipo de Java, generalmente una interfaz. Por ejemplo, si un cliente necesitara usar una impresora, compondría una plantilla de servicio que incluyera un Classobjeto para una interfaz conocida para los servicios de la impresora. Todos los servicios de impresión implementarían esta conocida interfaz. El servicio de búsqueda devolvería un objeto de servicio (u objetos) que implementaron esta interfaz. Los atributos se pueden incluir en la plantilla de servicio para limitar el número de coincidencias para dicha búsqueda basada en tipo. El cliente utilizaría el servicio de impresora invocando los métodos del objeto de servicio declarados en la conocida interfaz de servicio de impresora.

Separación de interfaz e implementación

La arquitectura de Jini lleva la programación orientada a objetos a la red al permitir que los servicios de red aprovechen uno de los fundamentos de la programación orientada a objetos: la separación de interfaz e implementación. Por ejemplo, un objeto de servicio puede otorgar a los clientes acceso al servicio de muchas formas. El objeto realmente puede representar el servicio completo, que se descarga al cliente durante la búsqueda y luego se ejecuta localmente. Alternativamente, el objeto de servicio puede servir simplemente como un proxy para un servidor remoto. Cuando el cliente invoca métodos en el objeto de servicio, envía las solicitudes a través de la red al servidor, que hace el trabajo real. El objeto de servicio local y un servidor remoto también pueden hacer parte del trabajo.

Una consecuencia importante de la arquitectura de Jini es que el protocolo de red utilizado para comunicarse entre un objeto de servicio proxy y un servidor remoto no necesita ser conocido por el cliente. Como se ilustra en la figura siguiente, el protocolo de red es parte de la implementación del servicio. Este protocolo es un asunto privado decidido por el desarrollador del servicio. El cliente puede comunicarse con el servicio a través de este protocolo privado porque el servicio inyecta parte de su propio código (el objeto de servicio) en el espacio de direcciones del cliente. El objeto de servicio inyectado podría comunicarse con el servicio a través de RMI, CORBA, DCOM, algún protocolo casero construido sobre sockets y streams, o cualquier otra cosa. El cliente simplemente no necesita preocuparse por los protocolos de red,porque puede comunicarse con la interfaz conocida que implementa el objeto de servicio. El objeto de servicio se encarga de cualquier comunicación necesaria en la red.

Diferentes implementaciones de la misma interfaz de servicio pueden utilizar enfoques de implementación completamente diferentes y protocolos de red completamente diferentes. Un servicio puede utilizar hardware especializado para satisfacer las solicitudes de los clientes o puede hacer todo su trabajo en software. De hecho, el enfoque de implementación adoptado por un solo servicio puede evolucionar con el tiempo. El cliente puede estar seguro de que tiene un objeto de servicio que comprende la implementación actual del servicio, porque el cliente recibe el objeto de servicio (a través del servicio de búsqueda) del propio proveedor de servicios. Para el cliente, un servicio se parece a la interfaz conocida, independientemente de cómo se implemente el servicio.

Conclusión

Como hemos visto en esta columna introductoria, Jini intenta elevar el nivel de abstracción para la programación de sistemas distribuidos, desde el nivel de protocolo de red hasta el nivel de interfaz de objeto. En la proliferación emergente de dispositivos integrados conectados a redes, muchas piezas de un sistema distribuido pueden provenir de diferentes proveedores. Jini hace innecesario que los proveedores de dispositivos acuerden protocolos de nivel de red que permiten que sus dispositivos interactúen. En cambio, los proveedores deben acordar las interfaces Java a través de las cuales sus dispositivos pueden interactuar. Los procesos de descubrimiento, unión y búsqueda, proporcionados por la infraestructura de tiempo de ejecución de Jini, permitirán que los dispositivos se ubiquen entre sí en la red. Una vez que se ubiquen entre sí, los dispositivos podrán comunicarse entre sí a través de interfaces Java.

Próximo mes

Aunque esta columna se enfocará principalmente en cómo resolver problemas de programación específicos usando Jini, como agregar una GUI a un servicio o hacer que un servicio sea administrable, el próximo mes discutiré los problemas y perspectivas del mundo real de Jini.

Hablando de Jini

Para discutir el material presentado en este artículo, visite: //www.artima.com/jini/jf/intro/index.html

Bill Venners ha escrito software profesionalmente durante 14 años. Con sede en Silicon Valley, brinda servicios de consultoría y capacitación de software y mantiene un sitio web para desarrolladores de Java y Jini, artima.com. Es autor del libro: Inside the Java Virtual Machine, publicado por McGraw-Hill.

Más información sobre este tema

  • Visite la Comunidad Jini para obtener información sobre el proceso mediante el cual se definirán interfaces conocidas

    //www.jini.org

  • Página de descarga de la versión actual de Jini (en Java Developer Connection)

    //developer.java.sun.com/developer/products/jini

  • Página de descarga de la versión JDK 1.2 FCS, en la que se ejecuta la versión actual de Jini

    //java.sun.com/products/jdk/1.2/

  • Un tutorial de Jini en línea

    //pandonia.canberra.edu.au/java/jini/tutorial/Jini.xml

  • Notas de clase en línea para un curso sobre RMI y Jini

    //www.eli.sdsu.edu/courses/spring99/cs696/notes/index.html

  • "La revolución de las redes", Clyde Higaki y Bill Venners (página de inicio de Sun's Jini Technology, 1999). Los autores Clyde Higaki y Bill Venners ofrecen una serie de escenarios para describir cómo podría usarse Jini en el mundo real

    //java.sun.com/features/1999/01/jini_scenario.html

  • Enlaces a recursos de Jini

    //www.artima.com/jini/resources/index.html

  • La página principal de Jini en Sun

    //java.sun.com/products/jini/

  • La Comunidad Jini, el sitio central para la interacción entre los firmantes de la Licencia de Fuente de la Comunidad Jini Sun

    //www.jini.org

  • Página de descarga para todas las especificaciones de Jini

    //java.sun.com/products/jini/specs/

  • Archivos de listas de correo de JINI-USERS. Para suscribirse a la lista de correo de JINI-USERS, envíe un correo electrónico a [email protected]. En el cuerpo del mensaje, escribasubscribe jini-users

    //archives.java.sun.com/archives/jini-users.html

  • Preguntas frecuentes de Jini para la lista de correo JINI-USERS

    //www.artima.com/jini/faq.html

Esta historia, "Jini: Nueva tecnología para un mundo en red" fue publicada originalmente por JavaWorld.