3.- DESCRIPCIÓN DE LA J2ME

3.- DESCRIPCIÓN DE LA J2ME
3.1.- 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
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.
3.2.- 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.
•
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:
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.
3.3.- 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.
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.
3.3.1.- 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.
•
java.security: soporte para mínima seguridad y encriptación para
serialización de objetos.
3.3.2.- 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.
3.3.3.- 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:
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:
certificados.
soporte
para
firmas
codificadas
y
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 AudioVideo 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
entorno J2SE, excepto las Xlets, que
javax.microedition, exclusivo de la J2ME.
usan
el
paquete
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.
3.3.4.- 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
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.
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.