PROYECTO FIN DE CARRERA
Implementación de los protocolos JXTA
sobre la plataforma J2ME (JXME)
UNIVERSIDAD DE SEVILLA
ESCUELA SUPERIOR DE INGENIEROS
INGENIERÍA DE TELECOMUNICACIÓN
DEPARTAMENTO DE INGENIERÍA DE
SISTEMAS Y AUTOMÁTICA
ÁREA DE INGENIERÍA TELEMÁTICA
Alumno: José Pablo Soriano Canela Tutor: Antonio J. Sierra Collado
AGRADECIMIENTOS
En primer lugar, agradecer a mi familia que me ha ofrecido el apoyo necesario y ha tenido la suficiente paciencia a lo largo de los años
ÍNDICE
0. OBJETIVOS………...4 1. INTRODUCCIÓN………..5 2. JXTA………..8 2.1. INTRODUCCIÓN………...8 2.2. ARQUITECTURA JXTA………...9 2.2.1. COMPONENTES DE JXTA………..10 2.3. ARQUITECTURA DE RED……….17 2.3.1. ORGANIZACIÓN DE LA RED………172.3.2. ÍNDICE DISTRIBUIDO DE RECURSOS COMPARTIDOS…………...18
2.3.3. FIREWALLS Y NAT………...19
2.4. PROTOCOLOS JXTA………..19
2.4.1. PEER DISCOVERY PROTOCOL (PDP)…………...20
2.4.2. PEER INFORMATION PROTOCOL (PIP)...21
2.4.3. PEER RESOLVER PROTOCOL (PRP)...21
2.4.4. PIPE BINDING PROTOCOL (PBP)...22
2.4.5. ENDPOINT ROUTING PROTOCOL (ERP)………..22
2.4.6. RENDEZVOUS PROTOCOL (RVP)………..23
3. J2ME……….24
3.1. INTRODUCCIÓN……….24
3.2. CARACTERÍSTICAS………...24
3.3. COMPONENTES………..26
3.3.2. CONFIGURACIONES………...29
3.3.3. PERFILES………...31
3.4. MIDLETS………..34
3.4.1. GESTOR DE APLICACIONES (AMS)………35
3.4.2. EL PAQUETE JAVAX.MICROEDITION.MIDLET………38
3.4.3. ESTRUCTURA DE UN MIDLET……….39
3.4.4 DESCARGAS VÍA OTA (OVER THE AIR)………...40
3.5. INTERFACES GRÁFICAS DE USUARIO……….43
3.5.1. INTERFAZ GRÁFICA DE USUARIO DE ALTO NIVEL………...45
3.5.2. INTERFAZ GRÁFICA DE USUARIO DE BAJO NIVEL………...47
3.6. RECORD MANAGEMENT SYSTEM………50
3.6.1. RECORD STORES………50
3.6.2. REGISTROS………...51
3.7. CONECTIVIDAD DE UN DISPOSITIVO MID……….51
3.7.1. CLASES Y CONEXIONES DEL GENERIC CONNECTION FRAMEWORK………52
3.7.2. COMUNICACIONES HTTP……….53
3.7.3. OTRAS CONEXIONES……….54
4. JXME (JXTA PARA J2ME)……….………...56
4.1. INTRODUCCIÓN……….56
4.2. VERSIÓN CON PROXY………...………...56
4.3. VERSIÓN SIN PROXY………58
5. APLICACIÓN DESARROLLADA………..………...60
5.1.1. CLASE MICHAT………...61 5.1.2. CLASE OPERACIONES………...68 5.1.3. CLASE BUDDY……….76 5.1.4. CLASE CONF………81 5.1.5. CLASE POLLTHREAD……….86 5.1.6. CLASE STATUSUPDATE………88 5.2. DESCRIPCIÓN DE LA APLICACIÓN………...89
6. INSTALACIÓN Y PRUEBAS DE LA APLICACIÓN………..93
6.1. INTRODUCCIÓN……….93
6.2. INSTALACIÓN DE LA APLICACIÓN………...93
6.2.1. INSTALACIÓN EN LÍNEA DE COMANDOS……...……….94
6.2.2. INSTALACIÓN USANDO CVS Y ANT………..………95
6.2.3. DESCARGA VÍA OTA………..99
6.3. PRUEBAS DE LA APLICACIÓN……….101
7. PLANIFICACIÓN TEMPORAL………...102
8. CONCLUSIONES………..…103
9. BIBLIOGRAFÍA………104
0. OBJETIVOS
El objetivo del presente proyecto consiste en la implementación de los protocolos JXTA sobre la plataforma J2ME, lo que se conoce como proyecto JXME, y que implica la unión de dos tecnologías de bastante actualidad con un amplio abanico de posibles aplicaciones.
El mundo de las redes P2P, en contraposición al modelo cliente/servidor, supone el acceso directo a las redes de comunicación de cualquier dispositivo con conectividad, eliminando la figura del servidor que hacía de intermediario en el anterior modelo. De esta forma, podemos salvar algunos problemas típicos de dicho modelo, tales como la saturación en el acceso a los servidores debido al incremento de usuarios de Internet. El proyecto JXTA es un ejemplo de red P2P que tiene como principal característica su independencia frente al lenguaje y plataforma en que se implementen los protocolos que lo conforman.
Por otra parte, la telefonía móvil puede ser uno de los campos en que se ha producido un mayor crecimiento en número de usuarios en los últimos años, implicando una demanda de servicios y prestaciones de grandes dimensiones. Para proporcionar estas prestaciones, se está imponiendo el uso como plataforma de desarrollo del entorno J2ME, la edición de Java dedicada a dispositivos con restricciones de capacidad, memoria, etc.
Partiendo de estos dos puntos, surge la posibilidad de llevar las tecnologías P2P a los terminales móviles, en particular los protocolos JXTA y utilizando la J2ME, permitiendo al móvil comunicarse con otros nodos de la red JXTA, compartiendo datos y recursos.
Para lograr el objetivo comentado, con el presente proyecto se ha desarrollado una aplicación que implementa los protocolos JXTA sobre la plataforma J2ME. Dicha aplicación consiste en un programa de mensajería instantánea en que se utiliza una versión del proyecto JXME (JXTA para J2ME) donde se requiere la presencia de un relay, que sirve al móvil de intermediario con la red JXTA, debido a las limitaciones características de los dispositivos móviles.
Para comprobar el buen funcionamiento de la aplicación mencionada se ha utilizado el emulador de dispositivos móviles proporcionado por Sun Microsystems, habiéndose realizado una serie de pruebas que se han saldado con resultados satisfactorios.
CAPÍTULO 1º: INTRODUCCIÓN
En los últimos años, se ha producido un incremento espectacular en el número de usuarios de dispositivos de pequeña capacidad dotados de conectividad, ya sean PDAs, teléfonos móviles, etc. Este aumento ha conllevado la aparición de un gran mercado que ha demandado una amplia gama de servicios y prestaciones.
Entre las prestaciones que se han desarrollado para dichos dispositivos se encuentran las tecnologías punto-a-punto (P2P), siendo uno de sus exponentes el proyecto JXTA. En dichas tecnologías se elimina la utilización de nodos centralizados o servidores a los que conectarse para realizar cualquier actividad, como intercambio de archivos o participación en tareas comunes, permitiendo la conexión directa entre los distintos nodos participantes.
Para aplicar el proyecto JXTA a los dispositivos móviles se ha utilizado un subconjunto del entorno Java conocido como J2ME, en el que se tienen en cuenta las limitaciones propias de tales terminales.
De la aplicación de los protocolos JXTA sobre la plataforma J2ME es de lo que trata el presente proyecto, incluyendo una aplicación en la que se va a desarrollar un programa de mensajería instantánea o chat.
La tecnología JXTA es un conjunto de protocolos abiertos P2P que permite que cualquier dispositivo conectado a una red pueda actuar como nodo comunicándose con el resto de nodos que componen la red. Estos protocolos son independientes del lenguaje de programación, existiendo implementaciones para múltiples entornos. Los nodos JXTA crean una red virtual donde cualquier nodo puede interactuar con otros nodos y recursos directamente, incluso cuando se encuentren tras firewalls o NATs.
El proyecto JXTA comenzó como un proyecto de investigación incubado en Sun Microsystem bajo la tutela de Bill Joy y Mike Clary, para proporcionar un espacio peer-to-peer a cualquier dispositivo capaz de conectarse a una red de comunicación.
Todo surgió a comienzos de 2001 como tema en una conferencia, siendo creada la página principal del proyecto www.jxta.org en abril de dicho año. Desde el principio, la filosofía del proyecto ha sido la participación de todo aquél interesado en colaborar, pudiéndose unir a los distintos subproyectos que han ido surgiendo con aplicaciones basadas en los protocolos JXTA.
En la actualidad, se pueden encontrar una gran variedad de proyectos, que abarcan desde la investigación en las propias APIs de JXTA, servicios P2P o aplicaciones que implementan los distintos protocolos.
En resumen, el mundo JXTA es aún algo bastante nuevo, en constante fase de estudio y de cambio, no estando sus aplicaciones optimizadas debido a esta permanente actualización.
Por otra parte, la edición Java 2 Micro Edition fue presentada en 1999 por Sun Microsystems con el propósito de habilitar aplicaciones Java para pequeños dispositivos. Podemos decir que Java Micro Edition es la versión del lenguaje Java que está orientada al desarrollo de aplicaciones para dispositivos pequeños con capacidades restringidas tanto en pantalla gráfica, como de procesamiento y memoria (teléfonos móviles, PDA`s, Handhelds, Pagers, etc).
Esta tecnología ha aparecido relativamente tarde (a finales de los 90 frente a la tecnología Java que nació a mediados), pudiéndose deberse esto a que las necesidades de los usuarios de telefonía móvil han cambiado mucho en estos últimos años y cada vez demandan más servicios y prestaciones por parte tanto de los terminales como de las compañías.
Además, el uso de esta tecnología depende del asentamiento en el mercado de otras, como GPRS, íntimamente asociada a J2ME y que no ha estado a nuestro alcance hasta hace poco. J2ME es la tecnología del futuro para la industria de los dispositivos móviles, estando implantada en la actualidad en la práctica totalidad de móviles que van apareciendo en el mercado.
A continuación vamos a pasar a describir la distribución que se ha seguido a la hora de redactar la presente documentación.
En primer lugar, tras el índice, se realizará una breve descripción de los objetivos que se han pretendido alcanzar con la ejecución del presente proyecto y a continuación, se hará una pequeña introducción a los temas que vamos a tocar después, adjuntándose la descripción de la estructura de la memoria que nos ocupa actualmente.
En el capítulo segundo, pasaremos a describir el proyecto JXTA, desarrollando su estructura, protocolos, etc.
El capítulo tercero está dedicado a la plataforma J2ME , enumerando sus componentes, clases, interfaz gráfica, etc.
En el capítulo cuarto se definirá qué es JXME ( JXTA para J2ME), así como las dos versiones disponibles(con y sin proxy).
En el capítulo quinto, se explicará el funcionamiento de la aplicación desarrollada para el presente proyecto, consistente en un programa de mensajería instantánea que implementa los protocolos JXTA en un emulador de teléfono móvil.
En el capítulo sexto se enumerarán los pasos seguidos para su instalación y las pruebas realizadas.
En el capítulo septimo, describiremos la planificación temporal con la que se ha ejecutado el proyecto.
En el octavo capítulo, se especificarán las conclusiones obtenidas con la realización del presente proyecto así como se referirán las posibles líneas futuras de trabajo.
En el capítulo noveno incluimos una bibliografía con los documentos consultados tanto para la ejecución del proyecto como para la redacción de la memoria.
Por último, y a modo de anexo, se incluye el código Java de la aplicación desarrollada, dividido en las clases que lo componen.
CAPÍTULO 2º: JXTA
2.1. INTRODUCCIÓN
JXTA es un conjunto de protocolos abiertos peer-to-peer (P2P: punto a punto) que permite que cualquier dispositivo conectado a una red (ya sea un PC, una PDA, un móvil, etc.), pueda actuar como nodo comunicándose con el resto de nodos que conforman la red. Estos protocolos son independientes del lenguaje de programación, existiendo implementaciones para múltiples entornos.
El término JXTA procede de la palabra inglesa juxtapose (yuxtaposición), con lo que se quiere recalcar que se trata de un modelo computacional yuxtapuesto (no está diseñado para sustituir sino para ampliar y satisfacer un nuevo conjunto de necesidades) al actual modelo predominante conocido como cliente-servidor, en el que una serie de equipos centralizados llamados servidores, atienden y resuelven las peticiones realizadas por los distintos clientes autorizados que utilizan un determinado servicio.
Pero, ya sea en el caso en el que el recurso que se solicita no se encuentra en un servidor sino en un equipo determinado, o el caso en el que no podemos acceder al servidor que contiene la información que requerimos, surge la necesidad de otro modelo en el que los equipos finales sean capaces de comunicarse entre sí, sin la necesidad de realizarlo a través de un nodo central.
Aquí es donde aparecen la computación distribuida y las tecnologías peer-to-peer por las que se proporciona acceso directo a los recursos de un dispositivo (nodo) a otro, sin utilizar un control central. Ejemplos de servicios P2P distribuidos son los programas para intercambios de archivos tipo Emule, Kazaa, etc.
JXTA se basa en la tecnología punto a punto, proporcionando un mecanismo que permitirá crear una nueva gama de servicios y aplicaciones a la vez que amplía los servicios Web desde ubicaciones fijas o centralizadas hasta cualquier punto de la red. Ejemplos de dichos servicios y aplicaciones son:
• Realizar búsquedas en toda la Web y en todos los dispositivos conectados (no sólo en los servidores) para encontrar la información que se necesita.
• Compartir servicios de computación, tales como procesadores o sistemas de almacenamiento, independientemente del lugar en el que estén ubicados físicamente los usuarios.
• Colaborar en proyectos desde cualquier lugar, utilizando un dispositivo conectado. • Participar en subastas entre grupos de usuarios seleccionados.
• Conectar sistemas de juegos para que varios usuarios ubicados en distintos lugares puedan disfrutar del mismo juego de forma interactiva.
Las características principales que debe cumplir la tecnología JXTA son:
• Interoperabilidad: para permitir la localización y comunicación de los nodos entre sí por medio de servicios P2P.
• Independencia: debe ser independiente de los lenguajes de programación (Java, C/C++, Perl, etc), protocolos de transporte (TCP/IP, HTTP, Bluetooth, HomePNA, etc.) y plataformas de desarrollo donde se ejecute.
• Accesibilidad: está diseñada para ser accesible por cualquier dispositivo, no sólo por PCs, en cualquier plataforma de desarrollo.
Los protocolos que conforman la tecnología JXTA estandarizan la forma en que los nodos: • Se descubren unos a otros.
• Se auto-organizan dentro de grupos de nodos. • Anuncian y descubren servicios.
• Se comunican con otros nodos. • Monitorizan al resto.
2.2. ARQUITECTURA JXTA
La arquitectura JXTA está dividida en tres capas como vemos en la siguiente figura:
Figura 2.1: Arquitectura JXTA
•
Núcleo JXTA (JXTA Core): pertenecen a esta capa las primitivas esenciales que soncomunes en una red P2P, tales como la creación de nodos y grupos, primitivas de seguridad, mecanismos de búsqueda y transporte (incluido manejo de firewalls), etc.
•
Capa de servicios (JXTA Services): incluye servicios de red que no son estrictamentenecesarios en una red P2P, aunque si puedan resultar deseables. Ejemplos de tales servicios son mecanismos de búsqueda e indexado, tratamiento de directorios, sistemas de almacenamiento, compartimiento de ficheros, cesión de recursos, sistemas de ficheros distribuidos, autenticación, servicios PKI (Public Key Infrastructure), etc.
•
Capa de aplicaciones (JXTA Applications): incluye implementaciones de aplicaciones,tales como mensajería instantánea P2P, compartimiento de ficheros y recursos, sistemas de correo P2P, sistemas de subasta P2P, etc.
2.2.1. COMPONENTES DE JXTA
La red JXTA está formada por una serie de nodos interconectados (peers) que se pueden agrupar dentro de grupos (peer groups), que proporcionan una conjunto de servicios comunes (tales como compartimiento de documentos o aplicaciones de chat).
Los nodos JXTA anuncian sus servicios por medio de documentos XML llamados
advertisements, permitiendo que el resto de nodos de la red sepan como conectarse e interactuar
con dichos servicios. Los nodos usan tuberías (pipes) para enviar mensajes a otros nodos. Vamos a pasar a describir los componentes de una red JXTA uno a uno.
2.2.1.1. Nodos (Peers)
Un nodo es cualquier dispositivo que implementa uno o más protocolos JXTA. Pueden ser PCs, PDAs, móviles, servidores, etc. Cada nodo actúa asíncrona e independientemente del resto de nodos y es unívocamente identificado por un identificador llamado Peer ID.
Los nodos publican uno o más interfaces de red para usar con los protocolos JXTA. Cada interfaz publicada es anunciada como un punto final de nodo (peer endpoint), que identifica unívocamente la interfaz de red. Estos puntos finales son usados por los nodos para establecer conexiones directas punto a punto entre dos nodos.
No todas las conexiones entre nodos deben ser directas, sino que puede haber nodos intermedios en aquellos casos en que los nodos origen y destino estén separados debido a conexiones de redes físicas y a distintas configuraciones de red (NATS, firewalls, proxies, etc.). 2.2.1.2. Grupos de Nodos (Peer Groups)
Un grupo es una colección de nodos que han acordado ofrecer una serie de servicios comunes. Cada grupo cuenta con un único identificador llamado peer group ID y establece su propia política de admisión de miembros, desde admitir a cualquiera hasta requerir una serie de credenciales determinadas.
Los nodos pueden pertenecer a más de un grupo simultáneamente. Por defecto, el primer grupo que es inicializado es el Net Peer Group. Todos los nodos pertenecen al Net Peer Group y pueden elegir si unirse a grupos adicionales.
Los protocolos JXTA describen como los nodos pueden anunciar, descubrir, unirse y monitorizar grupos de nodos.
Algunas de las razones para crear grupos se describen a continuación:
• Para crear entornos seguros: los grupos crean un dominio local de control con una determinada política de seguridad (como un nombre de usuario y una contraseña). Esto permite a los miembros limitar el acceso a los recursos del grupo.
• Para crear entornos de especialización: los grupos establecen un dominio local formado por nodos con los mismos intereses (por ejemplo una red de compartimiento de CPUs). • Para crear un entorno de monitorización: con ello se puede monitorizar un conjunto de
nodos con diversos motivos (por ejemplo para efectos de facturación).
Los grupos forman una estructura jerárquica, en la que cada grupo tiene un grupo padre. El
advertisement del grupo es publicado en el grupo padre.
Un grupo de nodos proporciona una serie de servicios (peer group services). Para que dos nodos puedan interactuar por medio de un servicio, esos dos nodos deben pertenecer al mismo grupo. JXTA define un núcleo de servicios aunque es posible desarrollar servicios adicionales para cada actividad específica. El núcleo de servicios está formado por:
• Discovery Service: es usado por los nodos miembros para buscar recursos de grupo, tales como nodos, grupos de nodos, tuberías y servicios.
• Membership Service: es usado por los miembros para aceptar o rechazar una solicitud de inclusión en el grupo. Los nodos que deseen unirse a un grupo deben buscar primero a un nodo miembro y solicitarle la inclusión. La solicitud es estudiada por el colectivo de nodos miembros que, ya sea por medio de votación o eligiendo a un subgrupo encargado de la admisión de nuevos miembros, determina si es aceptada o rechazada.
• Access Service: es usado para validar las solicitudes de un nodo a otro. El nodo receptor proporciona las credenciales del nodo transmisor e información sobre la solicitud para determinar si es permitida. No todas las acciones dentro de un grupo necesitan ser comprobadas por el servicio, solo aquéllas que están limitadas para algunos nodos. • Pipe Service: es usado para crear y controlar las tuberías entre los nodos miembros del
grupo.
• Resolver Service: es usado para enviar solicitudes genéricas de información a otros nodos (por ejemplo comprobar el estado de un determinado servicio).
• Monitoring Service: es usado para permitir a un nodo monitorizar a otros miembros del mismo grupo.
No todos los grupos deben implementar todos los servicios vistos, sino aquéllos que encuentre útiles para su funcionamiento normal, obteniendo del grupo Net Peer Group implementaciones genéricas del resto de servicios.
2.2.1.3. Servicios de Red
Los nodos cooperan para publicar, descubrir (por medio del Peer Discovery Protocol) e invocar servicios de red.
Se establecen dos niveles de servicios de red:
• Peer Services: los servicios de nodo son sólo accesibles en el nodo que publica dicho servicio. Si falla ese nodo, el servicio también falla. Se pueden ejecutar múltiples instancias de un servicio en diferentes nodos, pero cada instancia publicará su propio
advertisement.
• Peer Group Services: los servicios de grupo están compuestos por una colección de instancias (que pueden colaborar potencialmente entre ellas) de un servicio que está ejecutándose en múltiples miembros del grupo. Si un nodo falla, el servicio no se ve afectado. Los servicios de grupo son publicados como parte del advertisement del grupo. Los servicios pueden ser preinstalados en un nodo o cargados desde la red.
2.2.1.4. Módulos
Los módulos JXTA son abstracciones usadas para representar cualquier trozo de código que implemente un comportamiento en JXTA. Los servicios de red son el ejemplo más común de comportamiento que se puede dar en un nodo. La abstracción no especifica cuál es el código, ni en el lenguaje ni la plataforma en la que va a ser implementado.
Cuando un nodo se une a un nuevo grupo, puede darse el caso de que encuentre nuevos comportamientos que debe inicializar para poder formar parte de dicho grupo (por ejemplo un nuevo servicio de búsqueda que sólo es usado en ese grupo).
El uso de módulos permite la representación de comportamientos independientes de la plataforma que se use y ayuda a los nodos a especificar cualquier tipo de implementación de dichos comportamientos.
La habilidad para describir y publicar comportamientos independientes es esencial a la hora de soportar grupos compuestos por nodos heterogéneos (uno de los objetivos fundamentales de JXTA).
Las abstracciones de módulo incluyen una clase, una especificación y una implementación: • Module Class: es usada principalmente para anunciar la existencia de un
comportamiento. La definición de la clase representa un comportamiento y una relación esperados para soportar el módulo. Cada clase es identificada por un único ModuleClass
ID.
• Module Specification: es usada principalmente para acceder al módulo. Contiene toda la información necesaria para acceder e invocar al módulo. En el caso de un servicio, la especificación podría contener el advertisement de una tubería con la que comunicarse
con el servicio. La especificación proporciona un acercamiento a la funcionalidad que una clase implica. Puede haber múltiples especificaciones para una clase dada. Cada especificación es identificada por un único ModuleSpecID. Éste contiene el ModuleClass
ID de la clase asociada. Una especificación implica compatibilidad de red. Todas las
implementaciones de una especificación dada deben usar los mismos protocolos y ser compatibles, aunque estén escritas en lenguajes diferentes.
• Module Implementation: es la implementación de una especificación dada. Puede haber múltiples implementaciones para cada especificación de módulo, cada una conteniendo el
ModuleSpecID de dicha especificación.
Los módulos pueden ser usados tanto por los servicios de grupo como por los servicios individuales. Tanto las clases, como las especificaciones, como las implementaciones, tienen asociados un advertisement que puede ser publicado y descubierto por otros nodos JXTA. 2.2.1.5. Tuberías (Pipes)
Los nodos usan las tuberías para enviarse mensajes entre ellos. Las tuberías son mecanismos de transferencia de mensajes asíncronos y unidireccionales.
Los extremos de una tubería (pipe endpoints) son conocidos como input pipe (el lado receptor) y output pipe (el lado transmisor). Los extremos de las tuberías son dinámicamente asignados a los puntos finales de los nodos (peer endpoints) en tiempo de ejecución. Los puntos finales de un nodo se corresponden con una interfaz de red disponible (por ejemplo un puerto TCP y una dirección IP asociada) que puede ser usada para enviar y recibir mensajes.
Las tuberías son canales de comunicación virtual y pueden permitir conectar nodos que no tienen una comunicación directa. En este caso, se requiere la presencia de uno o más nodos intermedios que retransmitan los mensajes.
Las tuberías ofrecen dos modos de comunicación, punto a punto (unicast) y propagación (propagate) como vemos en la Figura 2.2. El núcleo de JXTA también contiene un tipo especial de tubería llamada secure unicast, que es una variante segura de la tubería punto a punto.
• Point-to-point Pipes: conectan dos extremos de tubería: un input pipe en un nodo que recibe mensajes enviados desde el output pipe de otro nodo.
• Propagate Pipes: conectan un output pipe a varios input pipes. La propagación se da siempre dentro de un mismo grupo.
• Secure Unicast Pipes: es un tipo de tubería punto a punto que proporciona un canal seguro de comunicación.
Se pueden construir tipos adicionales a partir de las tuberías básicas (por ejemplo tuberías bidireccionales y tuberías bidireccionales/seguras).
Figura 2.2: Tuberías punto a punto y de propagación 2.2.1.6. Mensajes (Messages)
Los nodos JXTA se intercambian mensajes para comunicarse entre sí. El mensaje es la unidad básica de intercambio de datos. Los mensajes son enviados y recibidos por los servicios
Pipe Service y Endpoint Service. Normalmente las aplicaciones usan el servicio de tuberías
(Pipe Service) para crear, enviar y recibir mensajes. El Endpoint Service sólo lo usan las aplicaciones que necesitan entender y controlar la topología de la red JXTA.
Un mensaje es una secuencia ordenada de componentes llamados elementos del mensaje (message elements). Cada mensaje es un conjunto de parejas nombre/valor de un determinado tipo.
Los protocolos JXTA son especificados como un conjunto de mensajes intercambiados entre los nodos. Cada plataforma de desarrollo describe de una forma distinta como un mensaje es convertido desde y a la estructura de datos original.
Existen dos representaciones para los mensajes: XML y en forma binaria. Los servicios pueden usar la forma más apropiada para su transporte (si un servicio requiere una representación compacta para un mensaje usaría la representación binaria, por ejemplo JXTA J2SE usa formato binario). Los datos binarios pueden ser codificados en Base64 en el cuerpo de un mensaje XML.
El uso de mensajes XML para definir protocolos permite que muchos tipos distintos de nodos puedan usar ese protocolo. Cada nodo lo implementa de la mejor forma que sus características se lo permiten. Si un nodo sólo necesita un subconjunto del mensaje, puede identificar dentro de él las partes que le son útiles e ignorar el resto.
2.2.1.7. Advertisements
Todos los recursos de una red JXTA (nodos, grupos, tuberías, y servicios) están representados por un advertisement. Los advertisements son estructuras de datos representadas como documentos XML. Los nodos descubren los distintos recursos buscando su correspondiente advertisement y pueden almacenar localmente los ya descubiertos.
Cada advertisement es publicado con un tiempo de vida que especifica la disponibilidad del recurso asociado. Este tiempo de vida permite la eliminación de recursos obsoletos sin que sea
requerida la presencia de un control central. Para extender el tiempo de vida, el advertisement puede ser re-publicado.
Los protocolos JXTA definen los siguientes tipos de advertisement:
• Peer Advertisement: describe los recursos de un nodo. Mantiene información sobre un nodo, tal como su nombre, su identificador, los puntos finales disponibles y cualquier atributo que un servicio de grupo de ese nodo quiera publicar (por ejemplo si ese nodo es un nodo de encuentro (rendezvous peer) para el grupo).
• Peer Group Advertisement: describe los recursos específicos de un grupo, tales como su nombre, su identificador, una descripción, especificaciones y parámetros de servicio. • Pipe Advertisement: describe un canal de comunicación y es usado por el servicio de
tuberías para crear los extremos asociados. Cada advertisement de una tubería contiene un identificador opcional, el tipo de tubería (punto a punto, propagación, segura, etc) y un identificador de tubería único.
• Module Class Advertisement: describe una clase de un módulo. Su principal objetivo es formalizar la existencia de una clase. Incluye un nombre, una descripción, y un identificador (ModuleClassID).
• Module Spec Advertisement: define una especificación de un módulo. Su objetivo primario es proporcionar la información necesaria para crear implementaciones conforme a la especificación. También facilita el uso remoto de la especificación al proporcionar información tal como el advertisement de la tubería con la que comunicarnos con el servicio. Incluye un nombre, una descripción, un identificador unívoco (ModuleSpecID), un advertisement de tubería y un campo con parámetros para ser interpretados por cada implementación.
• Module Impl Advertisement: define una implementación de una determinada especificación. Incluye un nombre, el ModuleSpecID asociado, así como código, parámetros, etc. que un nodo pueda necesitar para ejecutar la implementación.
• Rendezvous Advertisement: describe un nodo que actúa de nodo de encuentro
(rendezvous peer) para un determinado grupo.
• Peer Info Advertisement: publica información sobre el estado actual de un nodo, tal como la cuenta de mensajes enviados y recibidos, el tiempo en que se recibió y en que se envió el último mensaje, etc.
Cada advertisement es representado por un documento XML, en el que se dan una serie de elementos ordenados jerárquicamente. Cada elemento puede tener atributos formados por una pareja nombre/valor.
En la siguiente figura vemos un ejemplo del advertisement de una tubería, pudiendo apreciar los distintos campos tales como el tipo de componente al que pertenece el advertisement, el identificador de la tubería, el tipo de tubería de que se trata y el nombre de la tubería.
<?xml version="1.0"?> <!DOCTYPE jxta:PipeAdvertisement> <jxta:PipeAdvertisement xmlns:jxta="http://jxta.org"> <Id> urn:jxta:uuid59616261646162614E504720503250338E3E786229EA460DADC 1A176B69B731504 </Id> <Type> JxtaUnicast </Type> <Name> TestPipe.end1 </Name> </jxta:PipeAdvertisement>
Tabla 2.1: Ejemplo de advertisement de una tubería 2.2.1.8. Seguridad
Los nodos JXTA operan bajo un modelo basado en la confianza garantizada por otro nodo para realizar una determinada tarea. Se deben proporcionar cinco elementos básicos de seguridad:
• Confidencialidad: garantiza que el contenido de un mensaje no será revelado a individuos no autorizados.
• Autenticación: garantiza que el emisor es quien dice ser.
• Autorización: garantiza que el emisor está autorizado para enviar el mensaje.
• Integridad en los datos: garantiza que el mensaje no ha sido modificado accidental o deliberadamente en el camino.
• Refutabilidad: garantiza que el mensaje fue transmitido por un emisor apropiadamente identificado y no es una copia de un mensaje previamente enviado.
Los mensajes XML proporcionan la capacidad de añadir credenciales, certificados y claves a los mensajes JXTA. Los mensajes pueden ser encriptados (con claves públicas) y firmados (con certificados) para dar confidencialidad y refutabilidad. Las credenciales pueden usarse para proporcionar autenticación y autorización.
En las comunicaciones con varios saltos, debe existir confianza entre cada nodo intermedio ya que la seguridad está comprometida si alguno de los enlaces no es seguro.
2.2.1.9. Identificadores
Cualquier recurso JXTA debe estar unívocamente identificado y proporciona una referencia única a dicha entidad. Existen seis tipos de recursos JXTA que cuentan con un tipo de identificador definido: nodos, grupos, tuberías, contenidos, clases y especificaciones.
Para representar un identificador se usa URN (Uniform Resource Name), un tipo especial de URI (Uniform Resource Identifier) que proporciona identificadores para recursos persistentes e independientes de la localización.
Existen dos identificadores reservados en JXTA: NULL ID y Net Peer Group ID. En JXTA J2SE, los identificadores unívocos son generados aleatoriamente.
2.3. ARQUITECTURA DE RED
2.3.1. ORGANIZACIÓN DE LA RED
La red JXTA es una red ad hoc, multisalto y adaptable, compuesta de nodos interconectados, en donde el rutado de mensajes no está determinado previamente. Los nodos pueden unirse o dejar la red en el momento en que deseen y las rutas suelen cambiar frecuentemente.
Los nodos pueden ser cualquier equipo capaz de usar los protocolos JXTA. Se suelen dividir en cuatro tipos:
• Minimal edge peer: estos nodos pueden enviar y recibir mensajes pero no almacenan los
advertisements ni redireccionan mensajes para otros nodos. Suelen ser dispositivos con
recursos limitados (PDAs y teléfonos móviles).
• Full-featured edge peer: pueden enviar y recibir mensajes y almacenar advertisements. Pueden contestar a las solicitudes de búsqueda con la información guardada en los
advertisements almacenados pero no las transmiten más allá. La mayoría de los nodos son
de este tipo.
• Rendezvous Peer: es como cualquier otro nodo, almacenando los advertisements, pero puede transmitir las solicitudes de búsqueda de otros equipos, ayudándolos a descubrir recursos. Cuando un nodo se une a un grupo, automáticamente busca un nodo de encuentro (rendezvous peer). Si no lo encuentra, se convierte dinámicamente en nodo de encuentro de ese grupo. Cada nodo de encuentro mantiene una lista de otros nodos de encuentro conocidos y también de los nodos que lo están utilizando como nodo de encuentro.
Cada grupo puede tener tantos nodos de encuentro como necesite. Sólo los nodos de encuentro de un determinado grupo verán las solicitudes de búsqueda específicas de grupo.
Los nodos finales envían solicitudes a los nodos de encuentro y las que éstos no pueden contestar, las envían a otros nodos de encuentro conocidos. Este proceso continúa hasta que se da una respuesta a la solicitud o hasta que la solicitud muere. Los mensajes tienen un tiempo de vida por defecto (TTL: time to live) de siete saltos. Los bucles son prevenidos manteniendo la lista de nodos a través de los que ha pasado el mensaje.
• Relay Peer: un nodo de retransmisión almacena información sobre las rutas hacia otros nodos, enviándoles los mensajes hacia ellos dirigidos. Un nodo, primero busca en su caché local si tiene almacenada la ruta. Si no la encuentra, envía una consulta (query) a los nodos de retransmisión pidiendo información para direccionar el mensaje. Los nodos de retransmisión también transmiten mensajes en nombre de nodos que no pueden directamente alcanzar otro nodo ( Ej; entornos NAT), puenteando redes físicas y lógicas. Cualquier nodo puede actuar como nodo de encuentro y de retransmisión, pudiéndose dar en un mismo nodo a la vez los dos comportamientos.
2.3.2. ÍNDICE DISTRIBUIDO DE RECURSOS COMPARTIDOS
La plataforma JXTA 2.0 J2SE proporciona un servicio de índice distribuido de recursos compartidos (SRDI: Shared Resource Distributed Index) que permite un mecanismo más eficiente para propagar las solicitudes de consulta (query) dentro de la red JXTA. Los nodos de reunión mantienen un índice con los advertisements publicados por los nodos finales. Cuando un nodo final publica un nuevo advertisement, usan el SRDI para que su nodo de encuentro lo almacene. Luego, gracias a este servicio, limitamos a que los queries se propaguen sólo entre los nodos de encuentro, reduciendo el número de nodos involucrados en las búsquedas de
advertisements.
Cada nodo de encuentro mantiene su propia lista de nodos de encuentro conocidos dentro del grupo, y periódicamente, selecciona un número aleatorio de ellos, y les envía una lista aleatoria de sus nodos de encuentro conocidos. Periódicamente también, eliminan los nodos de encuentro que no responden.
Cuando un nodo publica un nuevo advertisement, éste es indexado por el SRDI usando como índice su nombre o su identificador. Sólo los índices son almacenados por el nodo de encuentro, minimizando la cantidad de información a ser almacenada. Los nodos de encuentro también promueven el índice a nodos de encuentro adicionales (seleccionados por el cálculo de una función de comprobación aleatoria del índice del advertisement).
2.3.2.1. Consultas
Cuando un nodo final inicia una petición de búsqueda, se envía inicialmente a su nodo de encuentro y también por difusión a los otros nodos de la misma subred.
En una búsqueda local, los nodos receptores de la consulta responden directamente al par emisor, si contienen la información en su memoria caché local.
Las consultas fuera de la vecindad local se envían al nodo de encuentro al que está conectado. Éste trata de satisfacer la consulta buscando en su memoria caché. Si contiene la información demandada, entonces contesta directamente al nodo que hizo la petición y no sigue propagando la petición. Si contiene el índice para el recurso en su SRDI, entonces contactará con el nodo que publicó el recurso y ese nodo responderá directamente al nodo que hizo la petición (los nodos de encuentro almacenan sólo el índice del advertisement y no el
advertisement en sí).
Si el nodo de encuentro no contiene la información demandada, entonces se usa un algoritmo predeterminado que recorre el conjunto de nodos de encuentro conocidos, buscando el que contenga el índice. Se usa una cuenta de saltos para determinar el número máximo de veces que la petición puede ser reenviada. Una vez que la consulta alcanza al nodo destinatario, éste contesta directamente al que originó de la consulta.
2.3.3. FIREWALLS Y NAT
Un nodo detrás de un firewall puede enviar un mensaje directamente a un nodo fuera de él. Pero un nodo fuera del firewall no puede establecer una conexión directamente con otro que se encuentre detrás del firewall.
Para que los nodos JXTA se comuniquen entre sí a través un firewall, se deben dar las siguientes condiciones:
• Al menos un nodo en el grupo que está dentro del firewall debe conocer a al menos un nodo de fuera del firewall.
• El nodo interior y el nodo exterior del firewall deben conocer al otro y deben soportar HTTP.
• El firewall tiene que permitir transferencias de datos HTTP.
Estas transferencias HTTP a través del firewall no necesitan estar restringidas al puerto 80, aunque ese es el puerto usado por defecto por la mayoría de navegadores de Internet y por el actual JXTA J2SE.
Cuando dos nodos quieren pasarse un mensaje pero el firewall les impide comunicarse directamente, el nodo emisor primero hace una conexión a un nodo retransmisor usando un protocolo como HTTP que puede penetrar el firewall. Luego el nodo retransmisor hace una conexión al nodo receptor, usando un protocolo como TCP/IP. Se establece una conexión virtual entre los dos nodos finales.
2.4. PROTOCOLOS JXTA
JXTA define una serie de formatos de mensaje XML, o protocolos, para la comunicación entre nodos. Los nodos usan estos protocolos para descubrirse unos a otros, anunciar y descubrir recursos de la red, y comunicar y encaminar los mensajes.
Hay seis protocolos JXTA:
• Peer Discovery Protocol (PDP): usado por los nodos para anunciar sus recursos (por ejemplo nodos, grupos de nodos, tuberías o servicios) y descubrir recursos de otros nodos. Cada recurso del nodo se describe y publica usando un advertisement.
• Peer Information Protocol (PIP): usado por los nodos para obtener información acerca del estado (el tiempo activo, el estado, el tráfico reciente, etc.) de otros nodos.
• Peer Resolver Protocol (PRP): permite a los nodos enviar una consulta genérica a uno o más nodos y recibir una respuesta (o respuestas múltiples) para la consulta. Las consultas pueden ser dirigidas a todos los nodos de un grupo de nodos o a nodos específicos dentro del grupo. A diferencia de PDP y PIP, los cuáles se usan para consultar información específica predefinida, este protocolo permite a los servicios de nodo definir e intercambiar cualquier información arbitraria que necesiten.
• Pipe Binding Protocol (PBP): usado por los nodos para establecer un canal de comunicación virtual, tubería o pipe, entre varios nodos. El PBP es usado por un nodo para unir dos o más finales de la conexión (los extremos de una tubería).
• Endpoint Routing Protocol (ERP): usado por los nodos para encontrar rutas (caminos) a los puertos de destino en otros nodos. La información de la ruta incluye una secuencia ordenada de identificadores de nodos de retransmisión que pueden usarse para enviar un mensaje al destino.
• Rendezvous Protocol (RVP): el mecanismo por el cuál los nodos pueden subscribirse o pueden ser un suscriptor de un servicio de propagación. Dentro de un grupo, los nodos pueden ser nodos de encuentro o nodos que están escuchando a nodos de encuentro. El RVP permite a un nodo enviar mensajes a todas las instancias del servicio que estén escuchando. El RVP es usado por el Peer Resolver Protocol y el Pipe Binding Protocol para propagar mensajes.
Todos los protocolos JXTA son asíncronos, y se basan en un modelo de consulta/respuesta. Los nodos JXTA usan los protocolos para enviar una consulta a uno o más nodos en su grupo.
Los nodos JXTA no están obligados a implementar los seis protocolos, sólo los que vayan a usar.
2.4.1. PEER DISCOVERY PROTOCOL (PDP)
El Protocolo de Descubrimiento de Nodos (PDP) se usa para descubrir cualquier recurso de nodo publicado. Los recursos son representados como advertisements. Un recurso puede ser un nodo, grupo de nodos, tubería, servicio, o cualquier otro recurso que tenga advertisement.
PDP permite a un nodo encontrar advertisements en otros nodos. El PDP es el protocolo predeterminado de descubrimiento para todo usuario que cree un grupo o use el Net Peer Group predeterminado. Servicios personalizados de descubrimiento pueden escogerse para ampliar el PDP. Si un grupo de nodos no tiene su propio servicio de descubrimiento, entonces el PDP se usa para sondear los nodos en busca de advertisements.
Hay múltiples formas para descubrir información distribuida. La plataforma JXTA J2SE actual usa una combinación de IP multicast para la subred local y el uso de nodos de encuentro, una técnica basada en “serpentear por la red” (network crawling). Los nodos de encuentro proporcionan el mecanismo para enviar peticiones de un nodo conocido al siguiente para descubrir información dinámicamente.
Un nodo puede ser preconfigurado con un conjunto predefinido de nodos de encuentro. Un nodo también puede escoger inicializarse dinámicamente localizando a nodos de encuentro o recursos de la red en su entorno cercano. También pueden agregarse otras técnicas, tales como redes de contenido direccionable (CAN's) para realizar descubrimiento de recursos.
Los nodos generan peticiones de mensajes de consulta de descubrimiento para descubrir
advertisements dentro de un grupo de nodos. Este mensaje contiene la credencial del grupo del
cualquier nodo dentro de un grupo o a un nodo de encuentro. El mensaje de respuesta devuelve uno o más advertisements.
2.4.2. PEER INFORMATION PROTOCOL (PIP)
Una vez que un nodo está ubicado, sus capacidades y estado pueden ser consultados. El Protocolo de Información de Nodo (PIP) provee un conjunto de mensajes para obtener información de estado del nodo. Esta información puede usarse para la implementación comercial o interna de aplicaciones JXTA. Por ejemplo, en las implementaciones comerciales la información puede usarse para determinar el uso de un servicio de nodo y facturar a los consumidores del servicio por su uso. En una implementación interna, la información puede ser usada para supervisar el comportamiento de un nodo y cambiar el itinerario del tráfico de la red para mejorar el funcionamiento global.
El mensaje ping de PIP se envía a un nodo para comprobar si el nodo está vivo y obtener información sobre él. El mensaje ping especifica si se debe devolver una respuesta total (advertisement del nodo) o un reconocimiento simple (si está encendido y el tiempo activo).
El mensaje de información de nodo se usa para enviar un mensaje en respuesta a un mensaje ping. Contiene la credencial del emisor, el identificador del nodo emisor y el del nodo objetivo, el tiempo activo, y el advertisement de nodo.
2.4.3. PEER RESOLVER PROTOCOL (PRP)
El Protocolo de Resolución de Nodo (PRP) permite a los nodos enviar peticiones genéricas de consulta a otros nodos e identifica las respuestas encontradas. Las peticiones de consulta pueden enviarse a un nodo específico, o pueden ser propagadas por el Servicio Rendezvous (usando nodos de encuentro) dentro del alcance de un grupo de nodos. El PRP usa el Servicio Rendezvous para propagar una consulta a múltiples nodos y usa mensajes unicast para enviar consultas a nodos determinados.
PRP es un protocolo fundamental que da soporte a peticiones genéricas de consulta. Tanto PIP como PDP se construyen usando PRP, y proporcionan consultas/peticiones específicas. PIP se usa para consultar información específica de estado y PDP se usa para descubrir recursos de nodo. PRP puede servir para cualquier consulta genérica que pueda necesitar una aplicación. Por ejemplo, el PRP permite a los nodos definir e intercambiar consultas para encontrar o buscar información de servicio como el estado del servicio, el estado de un extremo de una tubería, etc.
El mensaje de consulta de resolución se usa para enviar una petición de consulta de resolución a un servicio en otro miembro de un grupo de nodos. Contiene la credencial del emisor, un identificador único de consulta, un manipulador de servicio específico y la consulta en sí. Cada servicio puede registrar un manipulador en el servicio de resolución del grupo de nodos para procesar las peticiones de consulta de resolución y generar respuestas.
El mensaje de respuesta de resolución se usa para enviar un mensaje en respuesta a un mensaje de consulta de resolución. Contiene la credencial del emisor, un identificador único de búsqueda, un manipulador de servicio específico y la respuesta. Se pueden enviar múltiples
mensajes de consulta de resolución, pudiéndose recibir ninguna, una o más respuestas para una petición de consulta.
Los nodos también pueden participar en el índice distribuido de recursos compartidos (SRDI). SRDI proporciona un mecanismo genérico donde los servicios JXTA pueden utilizar índices distribuidos de recursos compartidos con otros nodos. Estos índices se usan para dirigir consultas en la dirección donde la consulta es más probable que sea contestada, y repropagar mensajes a los nodos interesados en ésta propagación de mensajes. PRP envía a un mensaje SRDI de resolución al manipulador nombrado en uno o más nodos en el grupo de nodos. El mensaje SRDI de resolución se envía a un manipulador específico, y contiene una cadena que se interpretará por el manipulador apuntado.
2.4.4. PIPE BINDING PROTOCOL (PBP)
El Protocolo de Asociación de Tuberías (PBP) es usado por los miembros del grupo de nodos para vincular un advertisement de una tubería al extremo de una tubería.
Una tubería puede ser vista como una cola mensajes que soporta las operaciones de crear, abrir/resolver (asociar), cerrar (desligar), suprimir, enviar y recibir. Las implementaciones efectivas de una tubería pueden diferir, pero todas usan PBP para asociar la tubería a un punto final. Durante la operación abstracta de creación, un nodo local asocia un extremo de tubería a una tubería de transporte.
El mensaje de consulta PBP se envía por un extremo de una tubería para encontrar otro extremo de tubería ligado al mismo advertisement de tubería. El mensaje de consulta puede pedir información que no ha sido obtenida de la memoria caché. Con esto actualizamos la información sobre los nodos. El mensaje de consulta también puede contener a un identificador de nodo optativo, que si está presente indica que sólo el nodo especificado debe responder a la consulta.
Un mensaje de respuesta PBP se devuelve al nodo que hizo la petición por cada nodo ligado a la tubería. El mensaje contiene el identificador de tubería, el nodo donde la entrada de tubería correspondiente haya sido creada, y un valor booleano indicando si la entrada de tubería existe en el nodo especificado.
2.4.5. ENDPOINT ROUTING PROTOCOL (ERP)
El Protocolo de Encaminamiento de Puntos finales (ERP) define un conjunto de mensajes de petición/consulta que se usan para encontrar información de encaminamiento. Esta información de la ruta es necesaria para enviar a un mensaje de un nodo (la fuente) a otro (el destino).
Cuando un nodo recibe instrucciones para enviar un mensaje a una dirección de un punto final de nodo dado, primero mira en su memoria caché local para determinar si tiene una ruta para este nodo. Si no encuentra una ruta, entonces envía una petición de consulta de resolución de ruta a los nodos de retransmisión disponibles pidiendo información de la ruta. Cuando un nodo de retransmisión recibe una consulta de ruta, éste comprueba si conoce la ruta. Si esto ocurre, entonces devuelve la información de ruta como una enumeración de saltos.
Cualquier nodo puede consultar a un nodo de retransmisión para obtener la información de la ruta, y cualquier nodo en un grupo de nodos puede convertirse en uno de retransmisión.
La información de la ruta incluye el identificador de nodo de la fuente, el identificador de nodo del destino, un tiempo de vida (TTL) para la ruta, y una secuencia ordenada de identificadores de nodo de las puertas de enlace (gateways). La secuencia de los identificadores de nodo podría no estar completa, pero debería contener al menos al primer nodo intermedio.
Las peticiones de consulta de la ruta son enviadas por un nodo a un nodo de retransmisión para solicitar información de la ruta. La búsqueda puede indicar una preferencia para buscar dinámicamente una ruta nueva.
Los mensajes de respuesta de ruta se envían por un nodo de retransmisión en respuesta a peticiones de información de ruta. Este mensaje contiene el identificador de nodo del destino, el identificador de nodo y el advertisement de nodo del encaminador que conoce una ruta para el destino y una secuencia ordenada de uno o más nodos de retransmisión.
2.4.6. RENDEZVOUS PROTOCOL (RVP)
El Protocolo de Rendezvous (RVP) es el responsable de propagar los mensajes dentro de un grupo de nodos. Mientras que grupos de nodos diferentes pueden tener diferentes métodos para propagar los mensajes, el Protocolo Rendezvous define un protocolo simple que permite:
• A los nodos conectarse al servicio (puede propagar mensajes y recibir mensajes propagados).
• Controlar la propagación del mensaje (el tiempo de vida, la detección de bucles, etc.). RVP es usado por el Protocolo de Resolución de Nodo y por el Protocolo de Asociación de Tuberías para propagar los mensajes.
CAPÍTULO 3º: J2ME
3.1. INTRODUCCIÓN
Es de sobra conocido por todos el éxito que ha alcanzado el lenguaje de programación Java, llegando a ser el lenguaje más popular en Internet. Fue creado por Sun Microsystems a principios de los 90, procediendo su nombre de como se conoce popularmente al café de alta calidad en EE.UU., de ahí que su logotipo sea un taza de dicha bebida.
Los constructores de Java optaron en su momento por dotar al lenguaje de un conjunto rico de capacidades orientadas a objetos que permitiese añadir librerías de apoyo a medida que fuera necesario y en función de las necesidades tecnológicas del momento. Es por ello que Java supone un núcleo en torno al cuál giran una multitud de bibliotecas con las más diversas orientaciones: desde bibliotecas dedicadas a la gestión de interfaces de usuario hasta aquéllas que se dedican al tratamiento de imágenes bidimensionales, pasando por las que se centran en difundir información multimedia, envío y recepción de correo electrónico, distribución de componentes software en Internet, etc.
Por otra parte, en los últimos años, es notorio el espectacular incremento en el uso de dispositivos de pequeña capacidad con acceso a redes de información, principalmente teléfonos móviles. Este gran número de usuarios ha conllevado la necesidad de crear software específico para dicho tipo de terminales, incluidos programas desarrollados en Java.
Las características concretas de este tipo de dispositivos han obligado a los desarrolladores de Java a construir un subconjunto del lenguaje y a reconfigurar sus principales bibliotecas para permitir su adaptación a un entorno con poca capacidad de memoria, poca velocidad de proceso, y pantallas de reducidas dimensiones. Todo esto hace que necesitemos una nueva plataforma de desarrollo y ejecución: la Java 2 Micro Edition, o de forma abreviada J2ME.
La edición Java 2 Micro Edition fue presentada en 1999 por Sun Microsystems con el propósito de habilitar aplicaciones Java para pequeños dispositivos. En esta presentación, lo que realmente se enseñó fue una primera versión de una nueva Java Virtual Machine (JVM) que podía ejecutarse en dispositivos Palm. Posteriormente se ha ido desarrollando hasta el punto de que, actualmente, la totalidad de compañías telefónicas y fabricantes de móviles están implantando los protocolos y dispositivos necesarios para soportarla.
3.2. CARACTERÍSTICAS
Sun, dispuesto a proporcionar las herramientas necesarias para cubrir las necesidades de todos los usuarios, creó distintas versiones de Java de acuerdo a las necesidades de cada uno. Según esto nos encontramos con que el paquete Java 2 lo podemos dividir en tres ediciones distintas: J2SE (Java Standard Edition) orientada al desarrollo de aplicaciones independientes de la plataforma, J2EE (Java Enterprise Edition) orientada al entorno empresarial y J2ME (Java
Micro Edition) orientada a dispositivos con capacidades restringidas. Estas tres ediciones las vemos representadas en la siguiente figura:
Figura 3.1: Arquitectura de la plataforma Java 2 de Sun
La versión J2ME está enfocada a la aplicación de la tecnología Java en dispositivos electrónicos con capacidades computacionales y gráficas muy reducidas, tales como teléfonos móviles, PDAs o electrodomésticos inteligentes. Esta edición tiene unos componentes básicos que la diferencian de las otras versiones, como el uso de una máquina virtual denominada KVM (Kilo Virtual Machine, debido a que requiere sólo unos pocos Kilobytes de memoria para funcionar) en vez del uso de la JVM clásica y la inclusión de un pequeño y rápido recolector de basura.
Asimismo, J2ME contiene una mínima parte de las APIs de Java. Esto es debido a que la edición estándar de APIs de Java ocupa 20 Mb, y los dispositivos pequeños disponen de una cantidad de memoria mucho más reducida. En concreto, J2ME usa 37 clases de la plataforma J2SE provenientes de los paquetes java.lang, java.io, java.util. Esta parte de la API que se mantiene fija forma parte de lo que se denomina “configuración”, concepto que pasaremos a explicar más adelante.
Como vemos, J2ME representa una versión simplificada de J2SE. Sun separó estas dos versiones ya que J2ME estaba pensada para dispositivos con limitaciones de proceso y capacidad gráfica. También separó J2SE de J2EE porque este último exigía unas características muy pesadas o especializadas de E/S, trabajo en red, etc. Por tanto, separó ambos productos por razones de eficiencia. Hoy, J2EE es un superconjunto de J2SE pues contiene toda la funcionalidad de éste y más características, así como J2ME es un subconjunto de J2SE (excepto por el paquete javax.microedition) ya que, como se ha mencionado, contiene varias limitaciones con respecto a J2SE.
Figura 3.2: Relación entre las APIs de la plataforma Java
3.3. COMPONENTES
A continuación vamos a ver cuáles son los componentes que forman parte de esta tecnología:
• Por un lado tenemos una serie de máquinas virtuales Java con diferentes requisitos, cada una para diferentes tipos de pequeños dispositivos.
• Configuraciones, que son un conjunto de clases básicas orientadas a conformar el corazón de las implementaciones para dispositivos de características específicas. Existen 2 configuraciones definidas en J2ME: Connected Limited Device Configuration (CLDC) enfocada a dispositivos con restricciones de procesamiento y memoria, y Connected Device Configuration (CDC) enfocada a dispositivos con más recursos.
• Perfiles, que son unas bibliotecas Java de clases específicas orientadas a implementar funcionalidades de más alto nivel para familias específicas de dispositivos.
• Una serie de paquetes opcionales.
La arquitectura de un entorno de ejecución la podemos ver en la Figura 3.3:
3.3.1. MÁQUINAS VITUALES J2ME
Una máquina virtual de Java (JVM) es un programa encargado de interpretar el código intermedio (bytecode) de los programas Java precompilados, pasándolo a código máquina ejecutable por la plataforma, efectuar las llamadas pertinentes al sistema operativo subyacente y observar las reglas de seguridad y corrección de código definidas para el lenguaje Java. De esta forma, la JVM proporciona al programa Java independencia de la plataforma con respecto al hardware y al sistema operativo.
Las implementaciones tradicionales de JVM son, en general, muy pesadas en cuanto a memoria ocupada y requerimientos computacionales. J2ME define varias JVMs adecuadas al ámbito de los dispositivos electrónicos que, en algunos casos, suprimen algunas características con el fin de obtener una implementación menos exigente.
Ya hemos visto que existen dos configuraciones CLDC y CDC, cada una con unas características propias que veremos más adelante. Como consecuencia, cada una requiere su propia máquina virtual. La VM (Virtual Machine) de la configuración CLDC se denomina KVM y la de la configuración CDC se denomina CVM. Veremos a continuación las características principales de cada una de ellas.
• KVM: se corresponde con la Máquina Virtual más pequeña desarrollada por Sun. Su nombre KVM proviene de Kilobyte (haciendo referencia a la baja ocupación de memoria, entre 40Kb y 80Kb). Se trata de una implementación de Máquina Virtual reducida y especialmente orientada a dispositivos con bajas capacidades computacionales y de memoria. La KVM está escrita en lenguaje C, aproximadamente unas 24000 líneas de código, y fue diseñada para ser:
o Pequeña, con una carga de memoria entre los 40Kb y los 80 Kb, dependiendo de la plataforma y las opciones de compilación.
o Alta portabilidad. o Modulable.
o Lo más completa y rápida posible y sin sacrificar características para las que fue diseñada.
Sin embargo, esta baja ocupación de memoria hace que posea algunas limitaciones con respecto a la clásica Java Virtual Machine (JVM):
1) No hay soporte para tipos en coma flotante. No existen por tanto los tipos double ni float. Esta limitación está presente porque los dispositivos carecen del hardware necesario para estas operaciones.
2) No existe soporte para JNI (Java Native Interface) debido a los recursos limitados de memoria.
3) No existen cargadores de clases (class loaders) definidos por el usuario. Sólo existen los predefinidos.
4) No se permiten los grupos de hilos o hilos daemon. Cuándo queramos utilizar grupos de hilos utilizaremos los objetos Colección para almacenar cada hilo en el ámbito de la aplicación.
5) No existe la finalización de instancias de clases. No existe el método Object.finalize().
6) No hay referencias débiles para la eliminación del objeto por el recolector de basuras.
7) Limitada capacidad para el manejo de excepciones debido a que el manejo de éstas depende en gran parte de las APIs de cada dispositivo por lo que son éstos los que controlan la mayoría de las excepciones.
8) No soporta reflexión, es decir, el mecanismo por el que los objetos pueden obtener información sobre otros objetos en tiempo de ejecución.
Aparte de la no inclusión de estas características, el verificador de clases estándar de Java es demasiado grande para la KVM. De hecho es más grande que la propia KVM y el consumo de memoria es excesivo, más de 100Kb para las aplicaciones típicas. Este verificador de clases es el encargado de rechazar las clases no válidas en tiempo de ejecución. Por esta razón los dispositivos que usen la configuración CLDC y KVM introducen un algoritmo de verificación de clases en dos pasos. Este proceso podemos verlo en la Figura 3.4:
Figura 3.4: Preverificación de clases en CDLC/KVM
La KVM puede ser compilada y probada en tres plataformas distintas: 1) Solaris Operating Environment.
2) Windows. 3) PalmOs.
• CVM: la CVM (Compact Virtual Machine) ha sido tomada como Máquina Virtual Java de referencia para la configuración CDC y soporta las mismas características que la Máquina Virtual de J2SE. Está orientada a dispositivos electrónicos con procesadores de 32 bits de gama alta y en torno a 2Mb o más de memoria RAM. Las características que presenta esta Máquina Virtual son:
1) Sistema de memoria avanzado.
2) Tiempo de espera bajo para el recolector de basura. 3) Separación completa de la VM del sistema de memoria.
4) Recolector de basura modularizado. 5) Portabilidad.
6) Rápida sincronización.
7) Ejecución de las clases Java fuera de la memoria de sólo lectura (ROM). 8) Soporte nativo de hilos.
9) Baja ocupación en memoria de las clases.
10) Proporciona soporte e interfaces para servicios en Sistemas Operativos de Tiempo Real.
11) Conversión de hilos Java a hilos nativos.
12) Soporte para todas las características de Java2 v1.3 y librerías de seguridad, referencias débiles, Interfaz Nativa de Java (JNI), invocación remota de métodos (RMI), Interfaz de depuración de la Máquina Virtual (JVMDI).
3.3.2. CONFIGURACIONES
Una configuración es el conjunto mínimo de APIs Java que permiten desarrollar aplicaciones para un grupo de dispositivos. Estas APIs describen las características básicas, comunes a todos los dispositivos:
• Características soportadas del lenguaje de programación Java. • Características soportadas por la Máquina Virtual Java. • Bibliotecas básicas de Java y APIs soportadas.
Como ya hemos visto con anterioridad, existen dos configuraciones en J2ME: CLDC, orientada a dispositivos con limitaciones computacionales y de memoria y CDC, orientada a dispositivos con no tantas limitaciones. Ahora veremos un poco más en profundidad cada una de estas configuraciones.
3.3.2.1. Configuración de dispositivos con conexión,CDC (Connected Device Configuration) La CDC está orientada a dispositivos con cierta capacidad computacional y de memoria. Por ejemplo, decodificadores de televisión digital, televisores con Internet, algunos electrodomésticos y sistemas de navegación en automóviles. CDC usa una Máquina Virtual Java similar en sus características a una de J2SE, pero con limitaciones en el apartado gráfico y de memoria del dispositivo. Ésta Máquina Virtual es la que hemos visto como CVM (Compact Virtual Machine). La CDC está enfocada a dispositivos con las siguientes capacidades:
• Procesador de 32 bits.
• Disponer de 2 Mb o más de memoria total, incluyendo memoria RAM y ROM. • Poseer la funcionalidad completa de la Máquina Virtual Java2.
• Conectividad a algún tipo de red.
La CDC está basada en J2SE v1.3 e incluye varios paquetes Java de la edición estándar. Las peculiaridades de la CDC están contenidas principalmente en el paquete javax.microedition.io,
que incluye soporte para comunicaciones HTTP y basadas en datagramas. La Tabla 3.1 nos muestra las librerías incluidas en CDC:
Tabla 3.1: Librerías de configuración CDC
3.3.2.2. Configuración de dispositivos limitados con conexión, CLDC (Connected
Limited Device Configuration)
La CLDC está orientada a dispositivos dotados de conexión y con limitaciones en cuanto a capacidad gráfica, cómputo y memoria. Un ejemplo de estos dispositivos son: teléfonos móviles, buscapersonas (pagers), PDAs, organizadores personales, etc.
Algunas de estas restricciones vienen dadas por el uso de la KVM, necesaria al trabajar con la CLDC debido a su pequeño tamaño. Los dispositivos que usan CLDC deben cumplir los siguientes requisitos:
• Disponer entre 160 Kb y 512 Kb de memoria total disponible. Como mínimo se debe disponer de 128 Kb de memoria no volátil para la Máquina Virtual Java y las bibliotecas CLDC, y 32 Kb de memoria volátil para la Máquina Virtual en tiempo de ejecución. • Procesador de 16 o 32 bits con al menos 25 Mhz de velocidad.
• Ofrecer bajo consumo, debido a que estos dispositivos trabajan con suministro de energía limitado, normalmente baterías.
• Tener conexión a algún tipo de red, normalmente sin cable, con conexión intermitente y ancho de banda limitado (unos 9600 bps).
La CLDC aporta las siguientes funcionalidades a los dispositivos:
• Un subconjunto del lenguaje Java y todas las restricciones de su Máquina Virtual (KVM). • Un subconjunto de las bibliotecas Java del núcleo.
• Soporte para E/S básica. • Soporte para acceso a redes. • Seguridad.
La Tabla 3.2 nos muestra las librerías incluidas en la CLDC:
Tabla 3.2: Librerías de configuración CLDC
En cualquier caso, una determinada Configuración no se encarga del mantenimiento del ciclo de vida de la aplicación, interfaces de usuario o manejo de eventos, sino que estas responsabilidades caen en manos de los perfiles.
3.3.3. PERFILES
Como acabamos de comentar, el perfil es el que define las APIs que controlan el ciclo de vida de la aplicación, interfaz de usuario, etc. Más concretamente, un perfil es un conjunto de APIs orientado a un ámbito de aplicación determinado. Los perfiles identifican un grupo de dispositivos por la funcionalidad que proporcionan (electrodomésticos, teléfonos móviles, etc.) y el tipo de aplicaciones que se ejecutarán en ellos. Las librerías de la interfaz gráfica son un componente muy importante en la definición de un perfil. Aquí nos podemos encontrar grandes diferencias entre interfaces, desde el menú textual de los teléfonos móviles hasta los táctiles de los PDAs.
El perfil establece unas APIs que definen las características de un dispositivo, mientras que la configuración hace lo propio con una familia de ellos. Esto hace que a la hora de construir una aplicación se cuente tanto con las APIs del perfil como de la configuración. Tenemos que tener en cuenta que un perfil siempre se construye sobre una configuración determinada. De este modo, podemos pensar en un perfil como un conjunto de APIs que dotan a una configuración de funcionalidad específica.
Existen unos perfiles que construiremos sobre la configuración CDC y otros que construiremos sobre la CLDC. Para la configuración CDC tenemos los siguientes perfiles:
• Foundation Profile. • Personal Profile. • RMI Profile.
Para la configuración CLDC tenemos los siguientes: • PDA Profile.
• Mobile Information Device Profile (MIDP).
En la Figura 3.5 se puede ver como quedaría el esquema del entorno de ejecución al completo. Un perfil puede ser construido sobre cualquier otro. Sin embargo, una plataforma J2ME sólo puede contener una configuración.
