Introduccrión a J2ME
miércoles, mayo 1, 2002 at 2:00AM
INTRODUCCIÓN A J2ME
El programador Java que tiene algo de experiencia ha utilizado J2SE, Java 2 Standard Edition. J2SE es el conjunto básico de herramientas usadas para desarrollar Java Applets y aplicaciones Java standalone. Sun Microsystems no se planteó hacer un conjunto de herramientas estándar hasta la llegada de Java 2, pues coincidió con los planes de expansión de Java para software empresarial.
El sofware empresarial tiene unas características propias marcadas: está pensado no para ser ejecutado en un equipo sino para ejecutarse sobre una red de ordenadores de manera distribuida de manera remota. De hecho, el sistema se monta sobre varias unidades o aplicaciones. En muchos casos, además, el software empresarial requiere que sea capaz de integrar datos provenientes de entornos heterogéneos. Para este entorno, para sus exigencias y características, Sun ha diseñado J2EE, Java 2 Enterprise Edition.
Sun separó J2SE de J2EE porque este último exigía una caracteríticas muy pesadas o especializadas de I/O, trabajo en red , etc. Por tanto, por razones de eficiencia separó ambos productos. Hoy J2EE es un superconjunto de J2SE pues contiene toda la funcionalidad de este y más características.
Sun ha separado J2ME, Java 2 Micro Edition por las mismas razones. Los dispositivos inalambricos tienen menos potencia y mucha menor capacidad gráfica que los PC de escritorio. Por ello, J2ME representa una versión simplificada de J2SE pensada para dispositivos con estas limitaciones.
El conjunto de J2ME, J2SE y J2EE le llamamos tecnología Java 2.
Dicho esto, es importante señalar que J2ME tiene la característica de tener una parte de su API fija, es decir, aplicable a todos los dispositivos inalámbricos y una parte que es específica para ciertos dispositivos; como ejemplo claro se me ocurre la API especifica de Palm y la de moviles, que evidentemente son distintas.
TECNOLOGIAS MOVILES
J2ME y WAP
Wap es Wireless Application Protocol o protocolo de aplicación inalámbrico. Wap permite a dispositivos inalámbricos soportar un navegador web simplificado. Para comunicaciones WAP debe estar adaptado a esta tecnología el cliente, el servidor y un gateway intermedio debe existir. El gateway WAP es el responsable de convertir las petición WAP y peticiones web habituales y viceversa. Las páginas que se transmiten a través de WAP no son archivos HTML sino que son WML. Si la web habitual soporta javascript, WML cuenta con un lenguaje de script simplificado a partir de javascript que se llama WMLscript.
Wap es una tecnología que está funcionando para moviles adaptados. Mucha gente habla de la competencia que supone J2ME para WAP, cuando esta aseveración no tiene ningún sentido. WAP es competencia a J2ME como lo es HTML a Java en el entorno web con cable. Es decir: son cosas distintas y no pueden competir entre sí. J2ME es una tecnología que permite la creación de aplicaciones que reciban y envíen datos a través de redes inalámbricas. WAP es sencillamente un protocolo para navegar la web en dispositivos móviles. Por tanto ambas tecnologías coexistirán sin problemas.
J2ME y SMS
SMS es la tecnología que permite hacer algo que vemos todos los días: mandar mensajes cortos entre dispositivos móviles, así cómo recibir otro tipo de mensajes. Por tanto, J2ME y SMS son cosas lo suficientemente diferentes como para no tener que competir. Salvo casos de aplicaciones de chat o de mensajería con J2ME, es muy lateral la competencia de J2ME sobre SMS.
J2ME y Bluetooth
La filosofía de Bluetooth es habilitar la comunicación en rangos relativamente cortos entre dispositivos. En la práctica sirve para quitarnos de encima los cables que conectan los ordenadores sustituyendo estos por una conexión de radio. Esto da más comodidad y libertad en el uso del ordenador. Bluetooth no representa por tanto ninguna relación directa con J2ME.
Configuración y CLDC
A la vez que J2ME supone un novedoso nuevo campo por desarrollar, de la misma manera introduce términos que debemos entender para asumir la arquitectura del sistema.
El primer termino que debemos asumir es el de Configuración. Una configuración es un conjunto mínimo de APIs que son útiles para desarrollar aplicaciones para un conjunto definido de dispositivos. Son muy importante porque describen las funcionalidades más importantes requeridas para unos dispositivos determinados.
Hay una configuración estándar para dispositivos inalámbricos que se conoce como Connected Limited Device Configuration o CLDC. Este estándar describe el conjunto de funcionalidades mínimas de los dispositivos inalámbricos, acorde a su potencia y a sus características. CLDC es resumen el conjunto de APIs básicas para construir aplicaciones para dispositivos móviles.
CLDC es un estándar que SUN ha especificado. Según vaya J2ME aplicándose a nuevas familias de dispositivos, SUN especificará nuevos estándares adecuados a cada familia.
Extendiendo un poco el concepto de CLDC, este estándar especifica los siguientes aspectos de la programación wireless:
- El subconjunto del lenguaje java que puede ser usado.
- El subconjunto de funciones de la Máquina Virtual Java.
- Las APIs fundamentales para este tipo de desarrollo.
- Los requerimientos de hardware de los dispositivos móviles enfocados a CLDC.
Algunas características de Java han sido desabilitadas y la razón es sencilla: los dispositivos móviles tienen capacidad limitada. Esto limita algunos aspectos de Java y de la Máquina Virtual por igual.
La función más importante que cumple CLDC es indicar un conjunto de APIs que debe incorporar cualquier dispositivo.
Finalmente, CLDC establece los mínimos de hardware requeridos para J2ME. Estos son los siguientes:
- 160kb de memoria disponible para Java
- Procesador de 16-bit
- Bajo consumo energético
- conexión a una red ( a menudo de 96000 bps pero puede ser menor el ancho de banda )
Los dispositivos aptos para CLDC son teléfonos móviles, PDAs, ciertos electrodomésticos, etc. Muchos otros se irán incorporando al estándar CLDC siempre y cuando cumplan los mínimos marcados por el estándar e incorporen la máquina virtual.
Examinando estos requerimientos más a fondo, es conveniente saber qué significa el requerimiento de 160kb de memoria disponible para java. CLDC explicita que esta cantidad está compuesta de 128kb de memoria no volatil para la Máquina Virtual Java y las APIs de CLDC y otros 32kb de memoria volatil para el sistema Java runtime.
CLDC y Java
Véamos que restricciones le impone el CLDC al lenguaje de programación java. La primera limitación es la falta de soporte para los números de punto flotante, de manera que no ofrece soporte para este tipo de operaciones matemáticas. La limitación se impone porque los dispósitivos carecen de hardware para estas operaciones y hacerlo vía software sería cargarlos por encima de sus posibilidades.
La siguiente restricción es la eliminación del método Object.finalize(). Este método es llamado para que un óbjeto sea borrado de memoria y CLDC no lo soporta ni lo requiere.
Una restricción a tener en cuenta es la limitada capacidad de CLDC para el manejo de excepciones. Esto es debido a que gran parte del manejo de excepciones depende exclusivamente de las APIs de cada dispositivo en concreto, pues las excepciones dependen de las características de cada aparato. Por ello CLDC maneja un número limitado de excepciones y delega el resto del manejo de excepciones en las APIs específicas de cada familia de dispositivos.
CLDC y seguridad
Al igual que la version estándar de Java, J2ME tiene su propio modelo de seguridad. Si estás habituado a desarrollar applets estarás familiarizado con el modelo sandbox de seguridad. Este modelo establece que un applet sólo puedo ejecutar ciertas operaciones que se consideran seguras. Hay otra serie de operaciones que estan fuera del sandbox y que no pueden ser ejecutadas por el applet.
¿Dónde está el límite? La filosofía de este modelo de seguridad es dotar a los desarrolladores de grandes posibilidades para hacer aplicaciones potentes, pero por otra parte minimizar los riesgos que supone un dispositivo que ejecuta aplicaciones descargadas de la red. Esto define las líneas maestras del modelo sandbox de seguridad:
- Los ficheros de clases Java deben ser verificados como aplicaciones Java válidas.
- Sólo se permite el uso de APIs autorizadas por CLDC.
- No esta permitido cargar clases definidas por el usuario.
- Sólo características nativas que entren dentro del CLDC pueden ser accedidas.
Por lo general, las restricciones impuestas por CLDC son restricciones de bajo nivel y esto es así porque CLDC trabaja a este nivel. Se supone que una capa adicional, que está definida en una configuración, impondrá nuevas restricciones.
Veámos que es exactamente una configuración o profile.
MID Profile (MIDP)
Ahora ya estamos preparados para entender el papel de las configuraciones dentro de la arquitectura J2ME. Sabemos que son un conjunto de APIs pensadas para un tipo concreto de dispositivos. De hecho, son una descripción de una familia de dispositivos que añade un conjunto de APIs adicionales al CLDC que se corresponden con las funcionalidades especificas de estos dispositivos.
CLDC es la configuración básica de J2ME. MIDP lleva CLDC más allá y añade nuevos requerimientos y APIs obligatorios para dispositivos MIDP. Los requerimientos de memoria de MIDP son:
- 128kb de memoria no volatil para las librerias MIDP API.
- 32kb de memoria volatil para el sistema Java runtime.
- 8kb de memoria no volatil para datos de aplicación persistente.
Respecto a CLDC, MIDP sólo incremente los 8kb destinados a datos persistentes.
Los requerimientos de entrada para MIDP exigen la existencia de un teclado o una pantalla tactil o ambos. No se exige ratón (raro en un teléfono movil).
Los requerimiento de salida para MIDP son algo más importantes, porque la pantalla es una de las restricciones mayores de los dispositivos móviles. MIDP exige al menos una pantalla de 97 x 54 pixels (anchura, altura) con 1-bit de profundidad de color (blanco y negro). El ratio de salida debe ser 1:1.
MIDP tiene también requerimientos de red. El mínimo soporte de red exigido es disponer de una conexión inalámbrica de 2 sentidos. Se supone que estos dispositivos pueden tener un ancho de bando limitado (9600bps).
MIDP no establece ninguna obligación respecto a qué sistema operativo debe tener el dispositivo. Esto es posible gracias a que Java es multiplataforma. Sin embargo sí que se esperan ciertos mínimos:
- un kernel mínimo que maneje el hardware a bajo nivel.
- un mecanismo que lea y escriba en memoria persistente o no volatil.
- un mecanismo de temporización para establecer mediciones temporales y dotar de información de tiempo a datos persistentes.
- acceso de lectura y escritura hacia la conexión inalambrica.
- acceso a la entrada por teclado o pantalla.
- soporte mínimo para mapas de bits.
- un mecanismo que controle el ciclo de vida de una aplicación.
Este artículo es original de Infolibo. El original se encuentr en http://infolibo.com/bci/java/j2me-1.php
|
Reader Comments