3.- DESCRIPCIÓN DE LA J2ME

Transcripción

1 3.- DESCRIPCIÓN DE LA J2ME Introducción Con el fin de solucionar la creciente demanda de aplicaciones en pequeños dispositivos, Sun ha extendido el ámbito de la tecnología Java con la introducción de la Java 2 Platform Micro Edition (J2ME).Esta nueva plataforma está enfocada hacia el mercado de los dispositivos electrónicos integrados: teléfonos móviles, Agendas Digitales Personales (PDA s), paginadores y dispositivos similares, que disponen de capacidades de memoria limitadas, pantallas reducidas y limitaciones en la capacidad de cálculo. Sun ha agrupado su tecnología Java en tres ediciones, cada una destinada a un área tecnológica diferente: Java 2 Enterprise Edition (J2EE), orientada a empresas que necesitan proporcionar servicios a clientes y proveedores a través de soluciones e-commerce y e-business. Java 2 Standard Edition (J2SE), para el ya bien establecido mercado familiar del ordenador de sobremesa (aplicaciones de usuario, applets, etc.) Java 2 Micro Edition (J2ME), que combina las necesidades de los fabricantes de dispositivos integrados, los proveedores de servicios que desean distribuir información a sus clientes a través de estos dispositivos y en tercer lugar, a los creadores de contenidos para que estén disponibles así mismo estos dispositivos. Figura 3-1: Arquitectura de la Plataforma Java

2 Cada una de estas ediciones difieren respecto a las demás en la máquina virtual que poseen y en las APIs que utilizan, pero siempre tienen en común el lenguaje de programación que emplean, Java. Desde el lanzamiento de la J2ME cientos de compañías han realizado un gran esfuerzo para el desarrollo de aplicaciones sobre esta tecnología, incluyendo grandes corporaciones, como Motorola, Nokia, Ericsson, Palm, Samsung, WindRiver, Sharp, Siemens, Sympian y RIM. Este voto de confianza no es sorprendente; J2ME proporciona un conjunto de soluciones para crear aplicaciones basadas en red para pequeños dispositivos. Una atracción añadida es el hecho de que la dirección en que se mueve el futuro de J2ME no está sumida bajo ningún tipo de secreto corporativo; su desarrollo es manejado abiertamente, por el Java Community Process (JCP), encontrándose al alcance de cualquier desarrollador Arquitectura de J2ME Con el fin de conseguir una mayor flexibilidad y adaptación a diversos tipos de dispositivos, J2ME se estructura en tres niveles: Máquina virtual Adaptada a dispositivos con capacidades limitadas, ésta máquina está ligada a una configuración. En la actualidad existen dos tipos de máquinas virtuales en J2ME: la CVM (C Virtual Machine) y la KVM (Kilo Virtual Machine). La CVM está orientada a dispositivos integrados y electrónica de consumo (dispositivos como TV digital, electrodomésticos, set-top box, etc.), ligada a la configuración CDC, requiere mayores recursos que su hermana pequeña, la KVM. La KVM tiene sus orígenes en Spotless (máquina virtual para el sistema operativo PalmOS). Diseñada desde cero para dispositivos con poca memoria, capacidad de proceso limitada, limitaciones de batería y conexiones a red intermitentes (como el caso de los teléfonos móviles), esta máquina va unida a la configuración CLDC.

3 Configuración Una configuración es el conjunto mínimo de clases disponible en una categoría de dispositivos. Las categorías se establecen según requisitos similares de memoria y procesamiento. Cabe mencionar que cada configuración está íntimamente relacionada a una máquina virtual, como se mencionó anteriormente. En la actualidad existen dos configuraciones en J2ME: o CDC (Connected Device Configuration), orientada a dispositivos con 512 KB de ROM, 256 KB de RAM, conexión a red fija, soporte completo de la especificación de la JVM e interfaz de usuario relativamente limitado. Iniciativas anteriores a esta configuración son: Personal Java, JavaTV y JavaPhone. o CLDC (Connected Limited Device Configuration), con unos requisitos sensiblemente inferiores a la CDC: la memoria requerida varía de 160 KB a 512 KB y los procesadores necesarios son de 16 o 32 bits. Otro requerimiento es la conectividad intermitente y ancho de banda limitado. Perfil El perfil es un conjunto de clases Java que complementan una configuración para un conjunto específico de dispositivos. Define el modelo de ciclo de vida de las aplicaciones, la interfaz de usuario y el acceso a los servicios proporcionados por una categoría de dispositivos. Un perfil normalmente es un subconjunto de otro perfil. Los perfiles permiten la portabilidad de aplicaciones J2ME entre dispositivos diferentes. Actualmente encontramos el perfil MIDP para la CLDC y los perfiles Foundation Profile, Personal Basis Profile y Personal Profile para la CDC. Por último, pueden usarse paquetes opcionales que proporcionan acceso a servicios que resultan útiles en mas de una clase de dispositivo, pero no en todas. En la siguiente figura puede observarse la arquitectura de J2ME en un modelo por capas:

4 Figura 3-2: Arquitectura de J2ME A partir de ahora desarrollaremos sólo lo referente a la configuración CDC, que será la usada para desarrollar el programa correspondiente al proyecto que nos ocupa Configuración CDC y sus perfiles CDC es una de las tecnologías desarrolladas por el Java Community Process (recogido en la JSR 36) para el desarrollo de aplicaciones para dispositivos móviles integrados. Proporciona una serie de librerías básicas y una máquina virtual de Java apropiada para ser usada con los perfiles adecuados. CDC está pensada para dispositivos potentes, que están conectados de forma intermitente a la red, incluyendo set-top boxes, TV interactiva, electrodomésticos y sistemas de navegación de vehículos. CDC soporta completamente las especificaciones de la máquina virtual de Java 2, incluyendo soporte para operaciones en punto flotante y características de librerías como carga dinámica total de clases, soporte para hilos y seguridad. En cuanto a las librerías, CDC usa las clases de J2SE cuyas implementaciones han sido optimizadas para entornos con poca memoria. Además, algunas de las librerías basadas en J2SE han modificado sus interfaces, mientras que otras han sido eliminadas por completo. El resultado es un entorno de aplicaciones Java flexible, fácilmente introducible en un sistema con 2 MB de RAM y 2 MB de ROM.

5 Un dispositivo, para cumplir los requerimientos que J2ME especifica para CDC, debe tener: Un procesador de 32 bits. Debe tener disponible para el entorno Java al menos 2 MB de memoria, incluyendo tanto RAM y memoria flash como memoria ROM. Completa funcionalidad con la especificación de la máquina virtual de Java. Conectividad con algún tipo de red, normalmente inalámbrica. Interfaz de usuario con algún grado de sofisticación. Cabe destacar que las aplicaciones desarrolladas usando APIs de CLDC son compatibles hacia arriba con CDC La librería de clases de CDC La librería de clases de J2SE incluye un número de clases de apoyo de aplicación que los desarrolladores de software han estado usando durante años para desarrollar incontables aplicaciones. CDC fue diseñado para trasladar esta amplia experiencia con las APIs de la J2SE estándar al espacio de los dispositivos personales móviles. Mientras que muchas APIs de CDC son idénticas a sus correspondientes en J2SE, la implementación subyacente ha sido dirigida hacia las necesidades de los dispositivos móviles con mayores limitaciones de memoria y de CPU. El resultado es una librería de clases de Java que permite a los desarrolladores una rápida migración de su código desde J2SE hacia CDC. Las principales APIs que incluye CDC son las siguientes: java.lang: clases del sistema de la máquina virtual. java.io: clases de entrada y salida de ficheros. java.net: datagramas UDP. java.util: clases de utilidades Java. java.text: soporte mínimo para internacionalización.

6 java.security: soporte para mínima seguridad y encriptación para serialización de objetos C Virtual Machine La configuración CDC define su propio subconjuto de características de Java Virtual Machine. Su máquina virtual se llama CVM. Como anécdota, comentar que CVM era en un principio el acrónimo de Compact Virtual Machine. Los ingenieros de Sun Microsystem creyeron que la gente podría confundir el Compact en CVM con la K en la KVM, por lo que la C no significa nada realmente en la actualidad. La máquina virtual es conocida simplemente como C Virtual Machine. CVM está designada para los dispositivos integrados y móviles para los que está pensado CDC. La implementación de referencia proporcionada actualmente por Sun Microsystem corre bajo Linux y VxWorks. Está implementada casi por completo en C, con unas 100 líneas de código ensamblado Perfiles de CDC Para que sea posible definir las plataformas Java para diferentes mercados de productos, J2ME introduce los perfiles. A nivel de implementación, un perfil es un conjunto de APIs que residen sobre una configuración y proporcionan a distintas aplicaciones el acceso a las posibilidades de una categoría de dispositivos. Los perfiles definidos sobre CDC son tres: Foundation Profile, Personal Profile y Personal Basis Profile. Foundation Profile: Como su nombre sugiere, el Foundation Profile está pensado para servir como fundación o base para otros perfiles, como el Personal y el Personal Basis. Este perfil amplía las APIs existentes en CDC para proporcionar aquellos servicios que todas las aplicaciones basadas en CDC necesiten. Debido a que no necesita una interfaz de usuario, este perfil no proporciona ninguna API de UI. El Foundation Profile contiene todos los paquetes básicos de la J2SE 1.3 excepto aquellos necesarios para soportar las clases de GUI de java.awt. Contiene los paquetes incluidos en CDC y algunos añadidos y mejoras necesarios para dar un completo servicio a las aplicaciones:

7 o java.lang: el paquete java.lang completo. o java.io: todos los paquetes de entrada y salida. o java.net: soporte para sockets TCP y HTTP. o java.util: completo soporte para ficheros ZIP y otras clases de utilidades. o java.text: soporte total para internacionalización. o java.security: soporte para firmas codificadas y certificados. Comentar también que al heredar paquetes desde la J2SE, CDC Y Foundation Profile eliminan todas las APIs que han quedado obsoletas y que tienen nuevas sustitutas. Se intentó empezar con un conjunto limpio y correcto de APIs, y no necesitar soportar y mantener APIs que resultaran inútiles. Las únicas APIs desaprobadas incluidas son aquellas que aún no tienen su equivalente. Personal Profile: Para soportar applets basadas en web, el Personal Profile extiende el Foundation Profile con paquetes que proporcionan una interfaz de usuario gráfica (GUI). El Perfil Personal es una redefinición de PersonalJava, y por lo tanto es compatible con aplicaciones basadas en PersonalJava 1.1 y 1.2. En otras palabras, proporciona la funcionalidad del entorno de PersonalJava en un perfil de la próxima generación de Java, la J2ME. Lo más interesante de este perfil es que puede soportar muchas librerías de especificaciones gráficas, como Home Audio- Video interoperability (HAVi) y la API de Java TV. Las aplicaciones basadas en el Personal Profile pueden ser gráficas o no. EL perfil proporciona APIs gráficas basadas en el Abstract Windowing Toolkit, incluyendo tanto los componentes ligeros del AWT como los pesados. Las aplicaciones con unos requerimientos de GUI modestos, pueden usar el Personal Basis Profile, que proporciona soporte básico de AWT, excluyendo los componentes pesados del mismo. El Personal Profile es un superconjunto del Personal Basis Profile, y aplicaciones basadas en el segundo son compatibles con el primero. Por ejemplo, una Xlet escrita para el Personal Basis Profile puede correr sobre el Personal Profile. Además, como curiosidad comentar que la mayoría de las aplicaciones y applets desarrolladas para el Personal Profile pueden correr en un

8 entorno J2SE, excepto las Xlets, que usan el paquete javax.microedition, exclusivo de la J2ME. El Personal Profile puede ser usado para crear una amplia variedad de aplicaciones para PDAs, televisión interactiva, terminales de lotería, dispositivos médicos, guías electrónicas de televisión, y aplicaciones del hogar, como aplicaciones para controlar electrodomésticos o servicios caseros, como calefacción, luz, entretenimiento o seguridad. Algunas de las características del Personal Profile son: o Incluye todos los componentes del AWT. o Soporte para BigDecimal y BigInteger. o Soporte para JavaBeans. o Soporte para applets y Xlets, incluyendo comunicación entre Xlets. Personal Basis Profile: es un subconjunto del Personal Profile, por lo que las aplicaciones escritas para el Personal Basis son compatibles con el Personal. Este perfil soporta Xlets tan bien como las típicas aplicaciones que contienen un main. Es más pequeño que el Personal Profile ya que excluye los componentes pesados de AWT y no proporciona soporte para applets. El Personal Basis Profile esta encaminado hacia el mercado de la televisión interactiva, ya que contiene todas las APIs necesarias para la plataforma Java para el soporte de la Multimedia Home Platform (MHP), actualmente en desarrollo. La MHP es un estándar para la difusión mejorada de servicios interactivos; define una interfaz entre las aplicaciones interactivas y los dispositivos en los que se ejecutan. El Personal Basis Profile es también compatible con otras especificaciones para aparatos electrónicos de uso doméstico, como Home Audio-Video interoperability (HAVi), el OpenCable Application Profile, especificación para servicios de TV interactiva y aplicaciones basadas en MHP, y el DTV Applications Software Environment (DASE), un estándar para televisión mejorada que define un middleware que permite a aplicaciones mejoradas e interactivas funcionar en un receptor común.

9 Modelos de aplicación del Personal Profile El Personal Profile de la configuración CDC soporta tres tipos de aplicaciones diferentes: Aplicaciones típicas: contienen un método main que es el que controla la ejecución del resto de clases de las aplicaciones. Cuando el método main termina, se finaliza la aplicación. Están escritas como las que se desarrollan para la plataforma J2SE, excepto aquellas que usan las clases específicas del Personal Profile. Dichas aplicaciones pueden tener una GUI (una aplicación de monitorización médica, por ejemplo) o no (un servidor casero). Interaccionan con el entorno Java para manejar su propio ciclo de vida y los recursos del sistema que se necesiten. Figura 3-3: Modelo de aplicación con método main Applets: son las típicas mini-aplicaciones que corren y son manejadas por el Applet Viewer o por un navegador web. Las Applets para el Personal Profile se codifican como las de J2SE, excepto las que usan clases propias del PP. Figura 3-4: Modelo de aplicación para Applets

10 En el ejemplo de la figura anterior, el entorno de Java está integrado en un navegador web. Cuando el navegador carga una página web, recibe un flujo HTTP que incluye tanto el contenido HTML para la página web, como las clases del applet, que se entregan al entorno Java; éste carga la clase principal del applet, que incluye métodos para cada uno de los eventos que conforman el ciclo de vida de una applet: inicialización, comienzo, parada y destrucción. Esta abstracción permite a los desarrolladores evitar mucho código relacionado con el sistema, normalmente relacionado con las típicas aplicaciones con método main, ya que ahora se deja en manos del navegador web. Xlets: son aplicaciones que pueden ser descargadas dinámicamente al sistema donde está ejecutándose el Personal Profile. El usuario puede ejecutar una aplicación del proveedor bajo demanda. Al igual que las applets, las Xlets son ejecutadas bajo unas restricciones de seguridad más estrictas que las de las aplicaciones locales. El mecanismo de seguridad evita que Xlets problemáticas accedan a los recursos del sistema. Una aplicación Xlet consiste en una o más Xlets y un manejador de Xlets, que ejecuta las Xlets y maneja sus estados. Figura 3-5: Modelo de aplicación para Xlets Los Applets son idóneos para ser usados con navegadores de Internet. Por otra parte, los Xlets están pensados para aplicaciones como difusión de televisión; de hecho el modelo de aplicación Xlet fue originalmente diseñado para aplicaciones de TV interactiva. Los Applets normalmente tienen una GUI, pero no siempre necesitan una. Una aplicación que no requiere una GUI puede ejecutarse como una Xlet. Algunas aplicaciones muestran algunos gráficos en la pantalla y proporcionan una cierta interacción con el usuario.

11 3.4.- Seguridad La seguridad es una característica principal del lenguaje de programación Java y ha dirigido la evolución de la plataforma Java desde el principio. CDC incluye seis niveles de seguridad que dan a los usuarios, desarrolladores, proveedores de servicio y empresas un marco de aplicación con una potente arquitectura de seguridad. Dichos niveles son: Seguridad de máquina virtual: es el primer nivel de seguridad. Incluye verificación de clases y características del lenguaje, como la omisión de punteros. Estos rasgos de seguridad han eliminado una clase completa de amenazas de seguridad llamadas de desbordamiento del buffer de cola. Las primeras versiones de la tecnología Java, como JDK 1.1 usaron estas características para construir un modelo de seguridad de cajón de arena, simple pero potente, que permite a navegadores web descargar applets de Java sin exponer el sistema del usuario a riesgos innecesarios. Clases firmadas: extienden el modelo de seguridad de caja de arena y verifican la integridad y la fuente de las clases Java a la máquina virtual que intenta cargarlas. Seguridad basada en permisos: fue introducida en la plataforma Java 2. Este marco de seguridad proporciona a los desarrolladores de aplicaciones un control de fina granularidad sobre quiénes pueden acceder a los datos e interfaces de una aplicación. Incluye un conjunto de permisos y pólizas que son definidos por el programador de la aplicación en archivos de permisos que pueden ser modificados por los administradores de sistemas. Criptografía: proporciona una forma de codificación estándar para software y datos para una transferencia o almacenamiento seguro. El marco de seguridad de Java incluye la Arquitectura de Criptografía Java (JCA), que es un marco basado en estándares para acceder y desarrollar la funcionalidad criptográfica. Control de certificados: proporciona un mecanismo basado en estándares para aumentar la confianza en el titular de un certificado durante un proceso de autentificación. Identidad de red federada: proporciona control de identidad de una forma abierta, interoperable y descentralizada.