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

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

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.

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

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.

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:

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:

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)

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.

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

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.

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)

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.

“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.

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 java.net

Inclusión de sockets para TCP/IP y conexiones vía HTTP.

Soporte para zip y otras funcionalidades (Timer). Inclusión de sockets para TCP/IP y conexiones vía HTTP.

java.text Soporte para Internacionalización. java.security Manejo de códigos y certificados.

Soporte para Internacionalización. Manejo de códigos y certificados.

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.xlet

Interfaces de comunicación del 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.

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.

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.

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

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.

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

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.

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