1. ARQUITECTURA J2ME
Este artículo fue extraído del trabajo presentado por Andrés Arley Pacheco a la
Universidad de Pamplona para optar por el título de Ingeniero de Sistemas, en
Septiembre de 2008 y cuyo título es:
“IMPLEMENTACIÓN DE UN SISTEMA PARA LA ADMINISTRACIÓN DE SERVICIOS
WEB EN TELEFONÍA MÓVIL A TRAVÉS DE LA PLATAFORMA J2ME”
El texto completo de este trabajo lo pueden encontrar en:
http://www.slideshare.net/arpa1986/aplicaciones-moviles-empresariales-con-servicios-
web-y-j2me
Los textos que aparecen en color verde no están en el documento original, han sido
agregados con el fin de aclarar algún tópico. Los textos que aparecen en azul son
hipervínculos que puede utilizar haciendo clic sobre ellos; estos vínculos no se encuentran
en el texto original.
Este artículo es una exposición muy detallada y completa de la plataforma J2me; su
lectura y comprensión es muy importante dada su popularidad en el mundo del desarrollo
de aplicaciones para dispositivos móviles.
INTRODUCCIÓN
El advenimiento de nuevas tecnologías que permiten la portabilidad de aplicaciones
en diversos tipos de dispositivos móviles como los teléfonos celulares, ha provocado
el surgimiento de plataformas de programación que permitan el desarrollo y ejecución
de este tipo de aplicaciones. Entre las plataformas actualmente reconocidas está Java
con su Edición Micro (J2ME) cuyo objetivo es el desarrollo de aplicaciones para
cualquier tipo de dispositivo móvil, portátil, etc.
J2ME cumple con los requisitos necesarios para la implementación de diversas
aplicaciones en telefonía móvil debido a la flexibilidad y capacidad con la que
administra los pocos recursos con los que cuentan estos dispositivos móviles. Su
interoperabilidad en diversos sistemas operativos móviles y otras características
convierten a la plataforma J2ME en una de las más atractivas. J2ME hace uso de
unas características disminuidas en cuanto a procesamiento y ejecución con respecto
a otras plataformas Java tales como J2EE y J2SE. Esto ocurre debido a que las
características de los tipos de dispositivos mencionados anteriormente manejan
recursos limitados en cuanto a interfaz gráfica y poder de procesamiento de las
aplicaciones.
Los servicios Web son componentes software interoperables estructurados sobre la
Arquitectura Orientada a Servicios (SOA) (vea nota al final para una descripción de
esta arquitectura), que permiten la búsqueda de determinados productos, servicios,
etc., a los usuarios, que de manera interactiva y amigable pueden tener acceso a ellos
desde cualquier dispositivo móvil. El corazón del funcionamiento de este tipo de
aplicaciones está basado en el modo de operación de los archivos XML, que son los

2. que realizan el transporte de información, entre el servicio Web y/o aplicaciones o
usuarios que hagan uso del mismo, a través de diversos protocolos de Internet como
HTTP.
XML se considera el corazón de los servicios Web, ya que es la tecnología que
permite el manejo de datos estructurados, a través de mensajes SOAP en la
interacción entre el servicio Web y el usuario por medio de peticiones y resultados
devueltos por el servicio Web. WSDL es el Lenguaje de Descripción de Servicios Web
basado en XML que describe las características y operaciones que ofrece el servicio
Web.
La Extensibilidad de este lenguaje permite ser utilizado en cualquier plataforma que
maneje el intercambio de datos sobre cualquier protocolo de red, entre ellos J2ME.
La implementación de servicios Web en telefonía móvil a través de la plataforma
J2ME permite a los usuarios de telefonía móvil la interacción con servicios ubicados
en la red accediendo desde su teléfono celular, PDA, etc., y tener acceso de forma
rápida a una gran diversidad de contenido interactivo. Dicha implementación se
llevará a cabo manejando metodologías de programación soportadas por J2ME que
conlleven al desarrollo de aplicaciones empresariales como lo son los Servicios Web,
a través del estudio de las generalidades, características de la plataforma y APIs de la
Referencia de Implementación de Servicios Web en J2ME.
Se pretende utilizar el patrón de desarrollo MVC (Modelo Vista Controlador) en la
ingeniería del software, usando múltiples capas que aseguren la integridad de la
aplicación final. Este patrón permite dividir el desarrollo, es decir, separa la lógica de
la aplicación del manejo de datos y de la interfaz gráfica de la aplicación. Para esto es
necesario adaptar el modelo inicialmente soportado sobre J2EE a la plataforma J2ME,
de tal forma que el patrón de desarrollo sea manejado por las APIs de J2ME y pueda
ser implementado en la implementación de la aplicación que accederá servicios Web
sobre telefonía celular.
JUSTIFICACIÓN
El auge que está teniendo la telefonía móvil actualmente repercute en la creciente
necesidad de que los usuarios y clientes de telefonía móvil tengan acceso a diferentes
tipos de servicios a través de la red. Con el fin de manejar la búsqueda de servicios en
estos dispositivos móviles, los Web Services (Servicios Web) son la solución más
conveniente para orientar e integrar aplicaciones que permitan realizar y estandarizar
las metodologías de búsqueda de una forma segura al igual que se hace con una
computadora personal.
Es de destacar que el estudio de las capacidades de los teléfonos móviles es de vital
importancia en el establecimiento de criterios que agilicen el desarrollo de
aplicaciones para el manejo de Servicios Web debido a las restricciones que estos
tienen.
J2ME (Java 2 Micro Edition) como plataforma Java debido a su robustez se ajusta de
la mejor manera a la solución de Servicios Web en cuanto al manejo y estructuración

3. de los datos en teléfonos móviles, debido a la flexibilidad con que soluciona los
problemas de limitación de éstos permitiendo la adecuación de operaciones complejas
que se pueden realizar en un PC. No obstante, cabe aclarar que no se pueden
solucionar del todo esas limitaciones debido a la naturaleza intrínseca de estos
dispositivos.
Con J2ME y APIs (Interfaz de Programación de Aplicaciones) auxiliares se llevará a
cabo la realización de módulos que permitan gestionar la administración de Servicios
Web en un celular o cualquier tipo de teléfono móvil que sea capaz de soportar la
plataforma J2ME.
NECESIDADES Y PROBLEMAS
No existe un conocimiento claro y conciso sobre la plataforma J2ME que permita el
establecimiento de técnicas de programación de este tipo en Colombia. El desarrollo
de aplicaciones para dispositivos móviles se está convirtiendo en una prioridad a nivel
mundial con el fin de dar más comodidad a los usuarios de estos dispositivos en
cuanto al acceso y manejo de contenido interactivo, gestores de búsqueda en la Web,
aplicaciones, etc.
En el mercado de la telefonía móvil se pueden encontrar los siguientes inconvenientes
en cuanto al desarrollo se refiere:
La poca aceptación de Sistemas Operativos Móviles que no establezcan
una estructura jerárquica en el manejo de archivos en estos dispositivos.
La escasa información encontrada sobre la generación de software que
permita manejar de forma integral la seguridad e interoperabilidad de los
Servicios Web en dispositivos móviles.
El hecho de que no existan metodologías aceptadas de forma veraz que
ayuden a la ejecución y prueba de técnicas para la construcción de
aplicaciones que cumplan con los requerimientos esperados.
La falta de robustez de las plataformas de desarrollo y ejecución de tales
aplicaciones.
Es necesario el conocimiento de una plataforma abierta, robusta y flexible como lo es
J2ME con el fin de establecer criterios que ayuden a procesar aplicaciones integrales
que permitan al usuario final interactuar a través de los dispositivos móviles en la
búsqueda de servicios.
MARCO TEÓRICO
1. GENERALIDADES DE J2ME
1.1. INTRODUCCIÓN.

4. El lenguaje de programación JAVA fue lanzado a mediados de los años 90 con el
único fin de ser usado en el desarrollo de aplicaciones para el control de
electrodomésticos por su robustez e interoperabilidad, ya que no importa la plataforma
sobre la que se ejecute la aplicación. Este tipo de aplicaciones fue denominado
applets. El grado de avance de este lenguaje es tal que actualmente es considerado
uno de los lenguajes y plataforma de diseño más famoso del mundo. Cuenta con
soporte para diferentes protocolos de Internet para el manejo de aplicaciones Web y
controladores para diversos manejadores de bases de datos como JDBC, entre otros.
Actualmente está orientado a soluciones personales y empresariales en varios
ámbitos tecnológicos. Estos ámbitos se han agrupado en ediciones distintas del
lenguaje Java. Estas versiones son:
Java 2 Platform, Standard Edition (J2SE): Maneja el núcleo de toda la
funcionalidad del lenguaje Java. Satisface requerimientos específicos para
aplicaciones particulares como applets, incluyendo paquetes opcionales para
extensión de seguridad en sockets usado en comercio electrónico.
Java 2 Platform, Enterprise Edition (J2EE): Usado para el desarrollo a
nivel empresarial y en entornos de aplicaciones servidor, incorporando nuevas
tecnologías tales como los servlets, Enterprise JavaBeans (EJBs), XML y Java
Server Pages.
Java 2 Platform, Micro Edition (J2ME): Subconjunto de J2SE usado para
programación de aplicaciones y necesidades combinadas tales como:
Consumidores y fabricantes de dispositivos móviles con recursos limitados,
Proveedores de servicio que desarrollan contenido personal sobre estos
dispositivos, y
Creadores de contenido que ajustan el contenido para dispositivos con
recursos limitados.
Estas ediciones de la Plataforma Java estandarizan un conjunto de tecnologías que
pueden ser usadas con un producto particular:
Máquinas virtuales Java que se ajustan dentro de un amplio rango de
dispositivos,
Librerías y APIs especializadas para cada tipo de dispositivo, y
Herramientas para el desarrollo y configuración de dispositivos.

La edición J2ME lanzada en 1999 por la Sun MicroSystems tiene una aparición tardía
debido a que las necesidades de los usuarios de dispositivos móviles cambió de
manera drástica en los últimos años. J2ME se orienta al desarrollo de aplicaciones
para pequeños dispositivos con limitaciones gráficas, de procesamiento y memoria
(teléfonos móviles, PDAs, Beepers, etc.). J2ME consta de un conjunto de

5. especificaciones para definir una colección de plataformas, apropiadas para un
subconjunto del amplio rango de dispositivos para usuarios existentes en el mercado.
1.2. ANÁLISIS COMPARATIVO.
Las siguientes son las características referidas en cada una de las distintas ediciones
de Java:

Java 2 Platform, Standard Edition (J2SE): Constituye el núcleo de Java y
tiene las siguientes características:
Desarrollado al principio sobre C++. A diferencia de C++, este maneja
soporte nativo de cadenas de caracteres y recolector de basura.
Su código es interoperable, es decir independiente de la plataforma sobre
la cual se ejecute. Se ejecuta en el lado del cliente por una JVM (Maquina
Virtual Java).
Su modelo de seguridad sandbox (caja de arena) permite el control de
acceso a un programa y sus recursos, es proporcionado por la JVM.
Permite un ajuste al sistema operativo en donde se ejecuta a través de un
conjunto de APIs.
Esta edición de Java permite el desarrollo de aplicaciones personalizadas a través
de applets, interfaz gráfica de usuario, multimedia, etc.

Java 2 Platform, Enterprise Edition (J2EE): Orientada al desarrollo de
aplicaciones de entorno empresarial, como los servicios Web, servicios de
nombres, persistencia de objetos, XML, etc. Debido al manejo distribuido de
información en estos tipos de entornos, J2EE proporciona las herramientas
necesarias para cumplir con tal objetivo a través de los EJBs. También permite la
manipulación de datos provenientes de entornos heterogéneos. El objetivo de esta
edición es ampliar las capacidades de J2SE dando soporte a requisitos
empresariales.
Java 2 Platform, Micro Edition (J2ME): Enfocada en la aplicación de la
tecnología Java en dispositivos electrónicos con capacidades restringidas en
cuanto a memoria, tales como teléfonos móviles, PDAs, etc. A diferencia de las
otras dos ediciones esta hace uso de una maquina virtual denominada KVM
(Maquina Virtual Kilo), ya que solo requiere de unos cuantos Kilobytes de memoria
para poder funcionar de manera correcta, incluyendo además un recolector de
basura pequeño.
J2ME está dividido en dos categorías que se enfocan en consumidores
sofisticados y consumidores de bajo nivel. J2ME usa 37 clases de la plataforma
J2SE, conformando lo que se denomina configuración. Los perfiles definen el
subconjunto del entorno de programación completo de Java para un dispositivo
particular. La configuración y/o perfiles depende en gran medida de de la
naturaleza de su hardware y el mercado objetivo.

6. La figura siguiente muestra los componentes de la tecnología Java ME y su relación
con las otras tecnologías Java.
Figura 1 Arquitectura de la plataforma JME
Esta gráfica ha sido tomada de http://www.oracle.com/technetwork/java/javame/tech/technology-139316.html#cdc
1.2. CARACTERÍSTICAS DE J2ME.
J2ME especifica el rápido y extenso espacio de consumidor, el cual abarca un amplio
rango de dispositivos con pequeñas comodidades, tales como beepers, consolas de
TV, etc. J2ME permite el mantenimiento de las cualidades que la tecnología Java ha
conocido para la inclusión de consistencia a través de productos, portabilidad de
código, transmisión segura de red, y escalabilidad.
El concepto de sofisticación en J2ME permite a las plataformas de desarrollo
proporcionar aplicaciones detalladas con extensibilidad dinámica, dispositivos de red y
aplicaciones para el consumidor y el mercado incorporado. Además, permite a los
fabricantes de dispositivos, proveedores de servicio y creadores de contenido a
capitalizar en una nueva oportunidad del mercado para el desarrollo y despliegue de
nuevas aplicaciones y servicios portentosos para sus clientes a nivel mundial. Esto
conlleva a que estos fabricantes abran sus dispositivos para extender el desarrollo de
aplicaciones de terceras partes sin la pérdida en el manejo del control de la seguridad
en la plataforma subyacente específica del fabricante.
J2ME es encontrado en dos extensas categorías de productos:

7. Dispositivos para consumidores “Sofisticados o de Alto Nivel”, cuya
categoría se representa en la Figura 1 por el grupo etiquetado con la palabra
CDC (Configuración de Dispositivos Conectados). Entre estos tipos de
dispositivos se incluyen, las consolas de Televisión, Televisores son Internet,
teléfonos con pantalla habilitados para Internet, comunicadores inalámbricos
de alto nivel, y sistemas de navegación y entretenimiento para automóviles.
Este tipo de dispositivos ofrece unas grandes capacidades en la interfaz de
usuario, el total de memoria establecida de entre dos hasta cerca de cuatro
megabytes, persistencia, conexiones de red con alto ancho de banda, a
menudo usando TCP/IP.

Dispositivos para consumidores de “Bajo Nivel”, representada en la
Figura 1.1 por el grupo etiquetado con la palabra CLDC (Configuración de
Dispositivos con Conexión Limitada). Son ejemplo de este tipo de dispositivos
los teléfonos celulares, beepers y organizadores personales. Estos dispositivos
tienen una interfaz de usuario simple, con recursos de memoria desde 128
hasta 256 kilobytes, bajo ancho de banda y conexión de red intermitente. La
comunicación de red a menudo no está basada en el protocolo TCP/IP y la
gran mayoría de estos dispositivos son operados a través de baterías.
J2ME está conformado por los siguientes componentes:
Múltiples máquinas virtuales específicas para cualquier tipo de dispositivo
pequeño.
Configuraciones, clases básicas orientadas para implementaciones en
dispositivos con características específicas. Las dos configuraciones
manejadas en J2ME son: Configuración de Dispositivos con Conexión
Limitada, CLDC usada en dispositivos con restricciones de procesamiento y
memoria, y CDC, Configuración de Dispositivos Conectados para dispositivos
con más recursos.
Los Perfiles, librerías Java para familias de dispositivos específicas, con
clases para la implementación de funcionalidades de más alto nivel.
1.3. ARQUITECTURA DE J2ME.
La arquitectura J2ME está proyectada para ser modular y escalable, además puede
soportar los tipos de desarrollo demandados por el consumidor e incorporados en los
mercados. El entorno de J2ME proporciona un conjunto de Maquinas Virtuales Java,
optimizadas para diferentes tipos de procesamiento.
Al igual que los fabricantes desarrollan nuevas características en sus dispositivos, los
proveedores de servicio desarrollan nuevas aplicaciones, estas configuraciones
mínimas pueden ser expandidas con librerías adicionales que administran las
necesidades de un segmento del mercado en particular. Existen cuatro conceptos
esenciales, que conforman el corazón de la arquitectura de J2ME:

8.  Máquina Virtual.
 Configuración.
 Perfil.
 Paquetes Opcionales.

La estructura de la arquitectura de J2ME se puede observar en la Figura 2.
1.4.1. Máquinas Virtuales.
La Máquina Virtual Java tiene como función principal interpretar código intermedio
(bytecode) procedentes de la pre-compilación a código ejecutable por la plataforma,
permitiendo así efectuar llamadas al sistema operativo subyacente para que éste
evalúe el código y establezca reglas de seguridad para que el lenguaje Java se
ejecute. Esto proporciona al programa independencia a la plataforma con respecto al
hardware y el sistema operativo del dispositivo, lo cual la convierte en interoperable.
A diferencia de las ediciones de Java J2SE y J2EE, J2ME utiliza una máquina virtual
con capacidades reducidas debido a las características intrínsecas de los teléfonos
celulares con el fin de realizar una implementación menos exigente, suprimiendo el
soporte a algunas características del lenguaje Java pertenecientes a J2SE yJ2EE. De
acuerdo al tipo de configuración se utiliza una maquina virtual distinta. La Maquina
Virtual de la configuración CLDC se denomina KVM y la de la configuración CDC
CVM.
KVM (Kilobyte Virtual Machine)

9. Es la máquina virtual más pequeña desarrollada por la Sun, compacta y
portable diseñada específicamente para un grupo de dispositivos pequeños
con recursos restringidos. Su nombre hace referencia a la baja ocupación de
memoria que utiliza. KVM es apropiado para microprocesadores de 16/32 bits
RISC/CISC y con un total de memoria asignada de no más de unos cientos de
kilobytes (algunas veces menos de 128 kilobytes). KVM fue diseñada para ser:
Pequeña, con una carga de memoria entre los 40Kb y los 80 Kb,
dependiendo de la plataforma y las opciones de compilación.
Alta portabilidad.
Modulable.
Lo más completa y rápida posible y sin sacrificar características para las
que fue diseñada.
“Alrededor de 128 kB es el mínimo total de memoria requerido para una
implementación de la KVM, incluyendo la maquina virtual, librerías Java y una gran
cantidad de espacio para ejecutar aplicaciones Java. Una implementación más típica
requiere un total de memoria de 256 kB, del cual la mitad es usado como espacio para
aplicaciones, de 40 a 80 kB es necesario para la maquina virtual, y el resto es reservado
para librerías.
El rol de la KVM en los dispositivos objetivos puede variar significativamente. En
algunas implementaciones, la KVM es usada en la parte superior de un software
existente dando al dispositivo la capacidad de descargar y ejecutar contenido Java
dinámico, interactivo y seguro en el dispositivo. En otras implementaciones, la KVM es
usada en un nivel más bajo para implementar el software y aplicaciones de los
dispositivos en el lenguaje de programación Java. “[1].
El hecho de no contar con todas las capacidades de memoria, origina algunas
limitaciones con respecto a la clásica Maquina Virtual Java (JVM):
1. No hay soporte para la JNI (Interfaz Nativa de Java) debido a los
recursos limitados de memoria.
2. No existen cargadores de clases (class loaders) definidos por el
usuario. Existen únicamente los predefinidos.
3. No se realiza la implementación del método Object.finalize(), el cual
permite la finalización de instancias de clases.
4. Es necesario el uso de objetos de tipo Colección que permitan
agrupar varios hilos y almacenar cada uno en el ámbito de la aplicación.
5. La capacidad en el manejo de excepciones es limitada, ya que este
tipo de eventos son manejados de forma independiente por las APIs
propias del dispositivo.

10. 6. No se manejan las referencias débiles, no se apunta a objetos que
puedan ser adquiridos por el recolector de basura.
Debido a que el verificador de clases de J2SE es muy pesado para la
verificación de clases en J2ME, la implementación del verificador de clases en
KVM requiere de al menos 10 kB de código binario y menos de 100 bytes de
RAM dinámica en tiempo de ejecución para clases típicas. El verificador realiza
solamente un escaneo lineal del código intermedio, sin la necesidad de un
algoritmo de flujo de datos iterativo costoso. Así el nuevo verificador de clases
opera en dos fases como se ilustra en la Figura 3.
En la fase número 1, las clases tienen que ser ejecutadas a través de una
herramienta de pre-verificación para poder remover ciertos códigos intermedios
y aumente las clases con atributos adicionales llamados StackMap
aumentando la velocidad de verificación en tiempo de ejecución. La fase de
preverificación es realizada típicamente en una estación de trabajo que el
desarrollador usa para escribir y compilar aplicaciones.
Figura 3. Pre-verificación de clases en J2ME.
En la fase número 2, el componente verificador en tiempo de ejecución de la
máquina virtual usa los atributos adicionales StackMap generados por el

11. preverificador para realizar la preverificación de la clase actual de forma
eficiente.
A través de estas fases se realizan las siguientes comprobaciones:
Observar que el código no sobrepase los límites de la pila de la
Máquina Virtual.
Comprobar que no se utilizan variables locales antes de ser
inicializadas.
Comprobar que se respetan los campos, métodos y los modificadores
de control de acceso a clases.
CVM (Compact Virtual Machine)
Máquina Virtual para la configuración CDC. Orientado a dispositivos
electrónicos con procesadores de 32 bits de gama alta y alrededor de 2 Mb ó
más de memoria RAM, con conexiones de red de forma intermitente o
permanente a través de TCP/IP. Sus principales características son:
1. Sistema de memoria avanzado
2. Tiempo de espera bajo para el recolector de basura
3. Separación de la funcionalidad de la Máquina Virtual del sistema de
memoria.
4. Consta de un Recolector de Basura modularizado.
5. Portabilidad.
6. Sincronización rápida.
7. Ejecución de clases a través de la implementación de la memoria de
solo lectura ROM.
8. Soporte nativo de hilos.
9. Las clases tienen baja ocupación de la memoria.
10. Tiene soporte para interfaces y servicios en Sistemas Operativos de
Tiempo Real.
11. Conversión de hilos Java a hilos nativos.
12. Soporte para JNI, referencias débiles, RMI (Invocación de Métodos
Remotos), Interfaz de Depuración de la Máquina Virtual (JVMDI).
13. Serialización de Objetos.
14. Cargadores de clases definidos por el usuario.
1.4.2. Configuraciones.

12. En el entorno J2ME las configuraciones se refieren al conjunto de APIs que permiten
el desarrollo de aplicaciones para un grupo de dispositivos. La configuración maneja
características básicas, comunes a un grupo de dispositivos o mercado objetivo en
cuanto a asignación de memoria y otras capacidades de hardware se refiere. El perfil
hace uso o “hereda” una configuración particular. Las configuraciones no permiten la
definición de características adicionales ya que este tipo de características son
manejadas por los perfiles.
Entre las características soportadas por las configuraciones, se especifica:
Soporte para características del lenguaje de programación Java.
Soporte para características de la Máquina Virtual.
Soporte para las librerías Java y APIs.
Las configuraciones en el momento de definir el entorno software para un conjunto de
dispositivos relacionados entre sí por un conjunto de características, tiene en cuenta
cosas como:
El tipo y cantidad de memoria disponible para ejecución de aplicaciones.
El tipo de procesador y velocidad.
La forma en la que se conecta el dispositivo a la red.
Actualmente están disponibles dos configuraciones en J2ME:
Configuración de Dispositivos con Conexión (CDC)
Esta configuración está diseñada para dispositivos con ciertas capacidades
computacionales y de memoria soportando un entorno más completo para la
Maquina Virtual Java con características similares a las de J2SE, con
limitaciones en el ambiente gráfico y memoria del dispositivo. La Máquina
Virtual adaptada a esta configuración es la CVM.
Esta configuración se enfoca en dispositivos con las siguientes características:
Memoria volátil de al menos 2 Mb ó más, incluyendo RAM Y ROM.
Procesador de 32 bits.
Conexión a algún tipo de red.
Manejo de la funcionalidad completa de la Maquina Virtual de Java 2.
Estos rasgos pueden ser encontrados en dispositivos como decodificadores de
televisión digital, televisores con internet y sistemas de navegación de
automóviles. La configuración cuenta con un subconjunto de clases de la
Edición Estándar de la Plataforma Java 2, J2SE. Incluye soporte para
protocolos como HTTP y el manejo de datagramas. La Tabla 1 muestra las
librerías incorporadas en CDC.
Configuración de Dispositivos Limitados con Conexión (CLDC)

13. 
Esta configuración es apropiada para dispositivos provistos con conexión pero
con limitaciones en cuanto a capacidad gráfica, de cómputo y memoria. Es el
bloque básico en donde se soportan los perfiles de la gran mayoría de
dispositivos que se apoyan en J2ME como plataforma de desarrollo.
La gran mayoría de estas restricciones está dada debido al uso que se hace de
la KVM, necesaria al trabajar con CLDC.
Paquete Descripción
java.io Clases e interfaces de Entrada y Salida.
java.lang Clases básicas del lenguaje.
java.lang.ref Clases para referencias.
java.lang.reflect Clases e interfaces de reflexión.
java.math Paquete para operaciones matemáticas.
java.net Clases e interfaces de red.
java.security Clases e interfaces de seguridad
java.security.cert Clases para el manejo de certificados de
seguridad.
java.text Paquete para texto.
java.util Clases de utilidades estándar.
java.util.jar Clases y utilidades para el manejo de
archivos JAR.
java.util.zip Clases y utilidades para el manejo de
archivos ZIP y comprimidos.
javax.microedition.io Clases e interfaces de conexión genérica
para CDC.
Tabla 1. Librerías de Configuración CDC.
Los dispositivos que hacen uso de esta configuración (en la versión 1.1) deben
cumplir con las siguientes características:
1. Al menos 192 kB de memoria total disponible para la plataforma Java,
2. Un procesador de 16 ó 32 bits,
3. Bajo poder de consumo, a menudo operan con suministro de energía
limitado, a través de baterías,
4. Conectividad a algún tipo de red, por lo general inalámbrica, con
conexión intermitente y con ancho de banda limitado.
Entre los requerimientos de hardware especificados para CLDC se encuentran:
Al menos 160 kilobytes de memoria no volátil disponible para la
maquina virtual y las librerías CLDC.
Al menos 32 kilobytes de memoria volátil disponible para la ejecución de
la maquina virtual.

14. “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“[2].
Entre los dispositivos que soportan esta configuración se encuentran los
teléfonos celulares, Asistentes Digitales Personales (PDAs), organizadores,
decodificadores de televisión digital, y terminales de venta.
A continuación se muestra en la Tabla 2 las librerías utilizadas por la
configuración CLDC.
Paquetes Descripción
java.io Subconjunto de J2SE para manejo de E/S.
java.lang Clases e interfaces de la Máquina Virtual.
java.util Utilidades estándar.
javax.microedition.io Clases de conexión genérica para CLDC.
Tabla 2. Librerías de Configuración CLDC.
De acuerdo a la tabla anterior, la Configuración CLDC cubre las siguientes
áreas:
Lenguaje Java y características de la máquina virtual.
Librerías del Núcleo Java (java.lang.*, java.util.*).
Entrada/Salida (java.io.*).
Seguridad.
Interconexión.
 Internacionalización (tipo de codificación de caracteres).

Las demás características adicionales referentes al manejo del ciclo de vida de
una aplicación en un dispositivo móvil, interfaz de usuario, manejo de eventos,
etc., son administradas por perfiles implementados en la parte superior de
CLDC.
1.4.3. Perfiles.
Los perfiles definen de forma personalizada mediante APIs, el manejo del ciclo de
vida de la aplicación, interfaz de usuario, etc., extendiendo de esta manera la
configuración a través de la adición de clases, para un tipo especifico de dispositivo,
un ámbito de aplicación determinado o un segmento del mercado, permitiendo
identificar un grupo de dispositivos a través de la funcionalidad que ofrecen y el tipo
de aplicaciones que se ejecutan en ellos. Los perfiles surgen debido a la necesidad de
soportar los diferentes requerimientos demandados por los consumidores de
dispositivos.

15. Básicamente se considera importante el uso de librerías de interfaz gráfica para la
definición de un perfil. Por lo tanto el perfil define rasgos propios de un dispositivo
mientras que la configuración hace lo mismo con un conjunto de ellos. Así que a la
hora de construir una aplicación se tenga a disposición tanto las APIs del perfil como
de la configuración. Además un perfil está constituido bajo las bases de una
configuración dotando a esta última de funcionalidades específicas. Se puede
observar entonces las características del entorno de ejecución de J2ME, el cual se
estructura en capas, observada en la Figura 4.
Figura 4. Entorno de ejecución para J2ME.
Los perfiles al igual que la maquina virtual están predeterminados por la configuración
que se pretende usar en el desarrollo de una aplicación J2ME.
Para la configuración CDC se tienen los siguientes perfiles:
Foundation Profile: Orientada a dispositivos móviles que no tienen
interfaz gráfica, como por ejemplo, decodificadores de televisión digital.
Funciona como base para otros perfiles definidos para CDC. Excluye paquetes
que hacen parte de la interfaz gráfica de J2SE, de tal manera que para poder
implementar interfaz de usuario en forma gráfica sería necesaria la
implementación de otro perfil adicional. Las librerías usadas por el Foundation
Profile se muestran en la Tabla 3.

Paquetes Descripción
java.io Clases de Lectura y Escritura de J2SE.
java.lang Soporte del lenguaje Java.
java.util Soporte para zip y otras
funcionalidades (Timer). Inclusión de sockets para TCP/IP y
java.net Inclusión de sockets para TCP/IP y
conexiones vía HTTP.
conexiones vía HTTP.

16. java.text Soporte para Internacionalización. para Internacionalización.
Soporte
java.security Manejo de códigos y certificados. de códigos y certificados.
Manejo
Tabla 3. Librerías del Foundation Profile.


Personal Profile: Extiende al Foundation Profile proporcionando soporte
completo para gráficos AWT, permitiendo el manejo de applets y con
capacidades web. Este perfil redefine a Personal Java (la tecnología Personal
Java ha sido anunciada como EOL (End Of Live) y ya no está soportada por la
tecnología Java. Así aparece anunciado en http://java.sun.com/products/personaljava/)
como un perfil J2ME.
Las librerías utilizadas por este perfil se muestran en la Tabla 4.

Paquetes Descripción
java.applet Sirve para creación de applets.
java.awt Clase para crear Interfaces de Usuario
con Manejo de Eventos.
java.awt.datatransfer Clases e interfaces que permiten la
transmisión de datos entre
aplicaciones.
java.awt.event Clases e interfaces de manejo de
eventos.
java.beans Soporte de JavaBeans.
javax.microedition.xl Interfaces de comunicación del
et Personal Profile.
Tabla 4. Librerías del Personal Profile.

RMI Profile: Requiere de la implementación del Foundation Profile.
Soporta un subconjunto de las APIs RMI (Invocación de Métodos Remotos) de
J2SE. Ha sido necesaria la eliminación de ciertos rasgos del perfil RMI debido
a las limitaciones propias de los dispositivos manejados bajo la configuración
CDC. Estas características son:
java.rmi.server.disableHTTP.
java.rmi.activation.port.
java.rmi.loader.packagePrefix.
java.rmi.registry.packagePrefix.
java.rmi.server.packagePrefix.
Para la configuración CLDC los perfiles más importantes son:
PDA Profile: construido sobre CLDC y abarca PDAs (Asistentes Digitales
Personales) de baja gama, con pantalla cuya resolución oscile entre los 20000
pixeles y puntero.

17. Mobile Information Device Profile (MIDP Perfil de Información de
Dispositivo Móvil): al igual que el perfil PDA este también está construido
sobre CLDC y es el perfil central de esta configuración. Fue la primera
configuración establecida para la plataforma J2ME. Este perfil maneja las
siguientes características:
Capacidad computacional, gráfica y de memoria reducida.
Ciclo de vida de la aplicación (definición de la semántica de una
aplicación MIDP y como se controla).
Almacenamiento persistente.
Conexión limitada.
Entrada de datos alfanumérica.
Transacciones punto a punto seguras (HTTPS).
Temporizadores.
Entre los requerimientos de hardware se puede encontrar:
Tamaño de pantalla: 96 x 54 pixeles con factor 1:1.
Uno o varios de los siguientes mecanismos de entradas: teclado o pantalla
táctil.
256 kilobytes de memoria no volátil para la implementación de MIDP.

8 kilobytes de memoria no volátil para creación de aplicaciones con datos
persistentes.
128 kilobytes de memoria volátil para el entorno de ejecución de Java.
Dos formas posibles de interconexión: de forma inalámbrica, posiblemente
intermitente ó con ancho de banda limitado.
Capacidad para reproducir tonos, a través de un hardware o software.
Los requerimientos de software son los siguientes:
Un sistema operativo pequeño que administre el hardware de las capas
inferiores (que permita el manejo de excepciones e interrupciones).
Un mecanismo que permita leer y escribir de la memoria no volátil para
soportar los requerimientos de las APIs del Record Management Storage
(RMS Manejo de Almacenamiento de Registros) que manejan
almacenamiento persistente.
Soporte para APIs que manejen Interconexión de redes Inalámbricas.

18. Un mecanismo para la captura de entradas desde el usuario a través de
cualquier componente de entrada referido en los requerimientos de
hardware.
Mecanismo para el manejo del ciclo de vida de la aplicación en el
dispositivo.
Los paquetes que utiliza el perfil MIDP se pueden observar en la Tabla 5.
Paquetes Descripción
javax.microedition.lcdui Clases e Interfaces para Interfaces de
Usuario.
javax.microedition.rms Administración del almacenamiento
persistente en el dispositivo.
javax.microedition.midlet Clases para la definición de la aplicación.
javax.microedition.io Manejo de conexión genérica.
java.io Clases e interfaces de Entrada y Salida.
java.lang Clases e interfaces de la Máquina Virtual.
java.util Clases e interfaces de utilidades estándar.
Tabla 5. Librerías del perfil MIDP.
Las aplicaciones que se realizan utilizando MIDP y la configuración CLDC llevan el
nombre de MIDlets.
1.4.4 Paquetes Opcionales
Además de las características que traen incorporadas los perfiles y configuraciones,
existe la necesidad de adicionar librerías de uso general que no están limitadas a una
categoría o familia de dispositivos. Los paquetes opcionales J2ME son un conjunto de
APIs estándar, que pueden ser usados para extender un perfil y hacer uso tanto de
tecnologías existentes como emergentes.
Estos paquetes opcionales especifican funcionalidad independiente de cualquier perfil,
jugando un papel importante en la evolución de los mismos. El desarrollo de estos
paquetes opcionales permite que las APIs maduren y sean creadas nuevas versiones
a través de la Comunidad de Procesos de Java (JCP), para luego ser incorporadas en
un perfil.
A continuación se muestra en forma detallada algunos de los paquetes opcionales
más usados:
API de Mensajería Inalámbrica (WMA, Wireless Messaging API) JSR
120: Define un conjunto de APIs que proporcionan acceso independiente de la
plataforma a través de recursos de comunicación inalámbricos, como el
Servicio de Mensajería Corta (SMS, Short Message Service). En la versión
WMA 1.1 se incluyen arquitecturas que permiten el manejo de seguridad en la
comunicación a través del perfil MIDP en su versión 2.0. Puede ser
implementado en CLDC y CDC.

19. API de Contenido Multimedia Móvil (MMAPI, Mobile Media API) JSR
135: proporciona control de recursos multimedia (audio y video), archivos y
gran variedad de tipos de datos multimedia basados en tiempo, a dispositivos
con recursos limitados. Al igual que WMA este paquete puede ser incorporado
en aplicaciones desarrolladas para las configuraciones CLDC y CDC.
Especificación de Servicios Web en J2ME (WSA, Web Services API)
JSR 172: extiende el concepto de Servicios Web permitiendo que los
dispositivos J2ME puedan ser consumidores de servicios Web a través de
modelos de programación provenientes de la plataforma estándar de servicios
Web. La infraestructura de esta API permite:
Proporcionar capacidades para el procesamiento de archivos XML,
Reusar (Reutilizar) el concepto de servicios Web en el momento de
diseñar servicios empresariales para clientes J2ME,
Suministrar APIs y convenciones para el desarrollo de clientes J2ME de
servicios empresariales,
Posibilitar la interacción entre los clientes J2ME con los servicios Web
de forma interoperable,
Manejar un modelo de programación para la comunicación entre el
cliente J2ME y los servicios Web.
Implementado exclusivamente en CLDC.
API para Servicios de Seguridad y Certificación en J2ME JSR 177:
Este paquete opcional extiende las características de seguridad para la
plataforma J2ME a través del uso de APIs que proporcionen servicios de
seguridad, con el fin de que sean suministrados mecanismos eficientes que
soporten una amplia variedad de aplicaciones basadas en servicios, entre los
que se encuentra, el acceso a redes corporativas, comercio electrónico, etc.
Estas APIs de seguridad manejaran aspectos como el cifrado, firmas digitales,
y gestión de credenciales de usuario, entre otros.
También permiten definir un modelo de acceso que ayuda a las aplicaciones
existentes en el dispositivo a comunicarse con una tarjeta inteligente insertada
en el dispositivo, definiendo a través de mecanismos flexibles la definición de
operaciones seguras entre los proveedores de servicios y el dispositivo. Usado
para la configuración CLDC.
API de Localización para J2ME JSR 179: …Permite el desarrollo de
aplicaciones basadas en localización para dispositivos J2ME. Su propósito es
proporcionar una API que genere información acerca de la ubicación
geográfica y orientación del dispositivo para las aplicaciones Java. Permite el
acceso a bases de datos con mapas almacenados en el terminal móvil. Define

20. interfaces estándar para trabajar con metodologías de posicionamiento como
GPS. Utilizado por CLDC y CDC.
Protocolo de Iniciación de Sesión para J2ME (SIP, Session Initiation
Protocol) JSR 180: La configuración que lo utiliza es CLDC. Permite el
establecimiento y gestión de sesiones IP multimedia. Este mismo mecanismo
puede ser ampliado para el soporte de mensajería multimedia y servicios de
juego.
API para Gráficas Móviles en 3D para J2ME JSR 184: Usado bajo
CLDC, permite la generación de gráficos tridimensionales a frecuencias de
imagen interactiva en dispositivos con recursos limitados. También se incluye
la gestión de escenas 3D, animaciones, mensajes animados, salvapantallas,
etc.
API para Bluetooth JSR 82: Paquete usado en CLDC y MIDP.
Proporciona mecanismos estándar para la creación de aplicaciones Bluetooth
de modo que puedan ser ejecutadas a través de esta tecnología.
API para Invocación de Métodos Remotos (RMI) JSR 66: puede ser
implementado en dispositivos con la configuración CDC y CLDC. Permite a
dispositivos consumidores interactuar con aplicaciones distribuidas.
Paquete Opcional JDBC para CDC/Foundation Profile JSR 169: se
puede utilizar en CDC y es un subconjunto de JDBC, que sirve para el
procesamiento de datos de repositorio, que por lo general son bases de datos
relacionales a través de SQL. Además permite la manipulación de datos
tabulares como si fueran JavaBeans.
A continuación se listan los pasos necesarios para la construcción de los MIDlets:
1. Desarrollo: En esta fase vamos a escribir el código que conforma nuestro
MIDlet.
2. Compilación: Se compilará nuestra aplicación haciendo uso de un
compilador J2SE.
3. Preverificación: Antes de empaquetar nuestro MIDlet es necesario realizar
un proceso de preverificación de las clases Java. En esta fase se realiza un
examen del código del MIDlet para ver que no viola ninguna restricción de
seguridad de la plataforma J2ME.
4. Empaquetamiento: En esta fase crearemos un archivo JAR que contiene los
recursos que usa nuestra aplicación, y crearemos también un archivo
descriptor JAD.
5. Ejecución: Para esta fase haremos uso de los emuladores que nos
permitirán ejecutar nuestro MIDlet.

21. 6. Depuración: Esta última fase nos permitirá depurar los fallos detectados en
la fase anterior de nuestro MIDlet.
Básicamente cualquier aplicación en Java sigue este proceso de desarrollo excepto
por las etapas de empaquetamiento y preverificación que es exclusivo de las
aplicaciones desarrolladas usando la plataforma J2ME.
Para el desarrollo de aplicaciones en esta plataforma, puede utilizar:
Comandos en consola y un editor de archivos planos
NetBeans
Eclipse
Sun One Studio Mobile Edition
J2me Wireless Toolkit
----------------------------------------------------
En la dirección http://jcp.org/en/jsr/ encuentra amplia información sobre las diferentes
APIs descritas en las solicitudes de especificación Java (Java Specificatios Requests
– JSR) que hace la JCP
Para obtener una especificación detallada de cada una de las APIs, visite la página
http://download.oracle.com/javame/config/cldc/ref-impl/cldc1.1/jsr139/index.html
------------------------------------------------------

Qué es SOA
Tomado de download.microsoft.com/download/c/2/c/c2ce8a3a-b4df-4a12-ba18-
7e050aef3367/070717-Real_World_SOA.pdf
La Arquitectura SOA establece un marco de diseño para la integración de aplicaciones
independientes de manera que desde la red pueda accederse a sus funcionalidades, las cuales se
ofrecen como servicios. La forma más habitual de implementarla es mediante Servicios Web, una
tecnología basada en estándares e independiente de la plataforma, con la que SOA puede
descomponer aplicaciones monolíticas en un conjunto de servicios e implementar esta
funcionalidad en forma modular.
¿Qué es un servicio exactamente? Un servicio es una funcionalidad concreta que puede ser
descubierta en la red y que describe tanto lo que puede hacer como el modo de interactuar con ella.
Desde la perspectiva de la empresa, un servicio realiza una tarea concreta: puede corresponder a un
proceso de negocio tan sencillo como introducir o extraer un dato como “Código del Cliente”. Pero
también los servicios pueden acoplarse dentro de una aplicación completa que proporcione servicios
de alto nivel, con un grado de complejidad muy superior –por ejemplo, “introducir datos de un
pedido”-, un proceso que, desde que comienza hasta que termina, puede involucrar varias
aplicaciones de negocio. (Regresar a “API de Servicios de Seguridad”)
La estrategia de orientación a servicios permite la creación de servicios y aplicaciones compuestas
que pueden existir con independencia de las tecnologías subyacentes. En lugar de exigir que todos
los datos y lógica de negocio residan en un mismo ordenador, el modelo de servicios facilita el

22. acceso y consumo de los recursos de IT a través de la red. Puesto que los servicios están diseñados
para ser independientes, autónomos y para interconectarse adecuadamente, pueden combinarse y
recombinarse con suma facilidad en aplicaciones complejas que respondan a las necesidades de
cada momento en el seno de una organización. Las aplicaciones compuestas (también llamadas
“dinámicas”) son lo que permite a las empresas mejorar y automatizar sus procesos manuales,
disponer de una visión consistente de sus clientes y socios comerciales y orquestar sus procesos de
negocio para que cumplan con las regulaciones legales y políticas internas. El resultado final es que
las organizaciones que adoptan la orientación a servicios pueden crear y reutilizar servicios y
aplicaciones y adaptarlos ante los cambios evolutivos que se producen dentro y fuera de ellas, y con
ello adquirir la agilidad necesaria para ganar ventaja competitiva.
Servicios Web
La adopción de una solución de diseño basada en SOA no exige implantar servicios Web. No
obstante, como ya comentamos anteriormente, los servicios Web son la forma más habitual de
implementar SOA. Los servicios Web son aplicaciones que utilizan estándares para el transporte,
codificación y protocolo de intercambio de información. Los servicios Web permiten la
intercomunicación entre sistemas de cualquier plataforma y se utilizan en una gran variedad de
escenarios de integración, tanto dentro de las organizaciones como con partners de negocios.
Los servicios Web se basan en un conjunto de estándares de comunicación, como son XML para la
representación de datos, SOAP (Simple Object Access Protocol) para el intercambio de datos y el
lenguaje WSDL (Web Services Description Language) para describir las funcionalidades de un
servicio Web. Existen más especificaciones, a las que se denomina genéricamente como la
arquitectura WS-*, que definen distintas funcionalidades para el descubrimiento de servicios Web,
gestión de eventos, archivos adjuntos, seguridad, gestión y fiabilidad en el intercambio de mensajes
y transacciones. (Regresar a SOA)
------------------------------------------
Verificador de clases.
(Extraído de http://bibing.us.es/proyectos/abreproy/11320/fichero/Capitulos%252F17.pdf)
Cualquier máquina virtual Java contiene un verificador de clases que asegura que las clases
cargadas tienen la estructura interna correcta. Si el verificador de clases descubre un
problema dentro de una clase genera una excepción. Debido a que una clase es una
secuencia de bytes, la máquina virtual no puede saber si una clase en particular es
realmente un bytecode correcto o no. Como consecuencia de esto, todas las
implementaciones de la máquina virtual disponen de un verificador de clases que puede ser
invocado sobre clases no seguras, asegurando de esta forma su corrección.
Uno de los objetivos del verificador de clases es ayudar a obtener aplicaciones robustas. Si
un programador malintencionado generara una clase que contuviera un método cuyo código
en bytes incluyera una instrucción de salto al final del método, podría causar que la
máquina virtual no funcionara si el método es invocado.

23. La especificación recomienda que la verificación del bytecode de las aplicaciones se realice
justo después de que la clase haya sido cargada. El verificador de clases lleva a cabo su
tarea de comprobación en dos fases:
1. La primera fase tiene lugar justo después de cargar la clase. En ella el
verificador de clases comprueba la estructura interna de la clase, incluyendo la
comprobación de la integridad de los bytecodes.
2. La segunda fase se lleva a cabo mientras se ejecuta el bytecode de la clase. En
esta el verificador de clases confirma la existencia de las referencias simbólicas
a clases, campos y métodos. (Regresar)

------------------------------------------------
A continuación encontrará direcciones de internet que pueden ser útiles para el
desarrollo de su aplicación en la plataforma j2me.
Para especificación de los Apis en cldc 1.1 vaya a
http://download.oracle.com/javame/config/cldc/ref-impl/cldc1.1/jsr139/index.html
En la dirección http://grasia.fdi.ucm.es/j2me/_Devices/index.html encuentra una tabla con
los dispositivos que a 2004 eran compatibles con j2me. A través de esta página se
pueden obtener algunos SDK