Download Transmisión de imágenes de vídeo mediante Servicios Web XML

UNIVERSIDAD DE SEVILLA
ESCUELA SUPERIOR DE INGENIEROS
INGENIERÍA DE TELECOMUNICACIÓN
Transmisión de imágenes de vídeo
mediante Servicios Web XML sobre J2ME
Francisco Prieto Donate
Tutor: Antonio Jesús Sierra Collado
Departamento de Ingeniería de Sistemas y Automática
Área de Ingeniería Telemática
Sevilla, Febrero de 2007
Francisco Prieto Donate
III
IV
Francisco Prieto Donate
AGRADECIMIENTOS
A mis padres y mi hermana, que tanto han confiado en mí, me han apoyado y han
compartido conmigo las alegrías y tristezas en estos años de carrera.
A mis amigos de la facultad, con los que he compartido cada uno de mis días
universitarios.
A mis amigos de la residencia, que tantos buenos momentos me han hecho pasar.
Al “Carry Team”, por ser el mejor grupo de amigos que haya existido jamás.
A todos ellos, muchísimas gracias.
Francisco Prieto Donate
V
VI
Francisco Prieto Donate
OBJETIVOS
El objetivo de este proyecto consiste en transmitir imágenes de vídeo desde un
servidor de vídeo hasta un teléfono móvil utilizando Servicios Web XML.
Partimos de un servidor de vídeo ya implementado, que permite la captura y
transmisión de una señal de vídeo así como de imágenes estáticas, con el cual debemos
interactuar para realizar una petición y recibir una respuesta.
En primer lugar es necesario estudiar cómo adaptar el servidor de vídeo para que
se comporte como un servidor de aplicaciones, atendiendo peticiones mediante el
protocolo estándar SOAP. Buscamos además que esta adaptación provoque el menor
número de cambios posible en el servidor de vídeo.
Asimismo tendremos que implementar un cliente que se comunique con dicho
servidor. Se utilizará el lenguaje de programación orientado a objetos Java, en su
versión para dispositivos de recursos limitados (J2ME). Para realizar esta
implementación se hace necesario conocer las tecnologías existentes para utilizar
Servicios Web XML en dispositivos inalámbricos.
Para poder ejecutarse, la aplicación será instalada en el teléfono por descarga
OTA, es decir, a través de Internet siguiendo el procedimiento normal de descarga de
aplicaciones para móviles. El teléfono móvil debe disponer de conexión a Internet a
través de GPRS.
La interfaz gráfica de usuario de la aplicación será realizada para que resulte lo
más fácil e intuitiva posible, de forma que su manejo sea lo suficientemente sencillo
como para que la aplicación pueda ser utilizada por cualquier persona con unos
mínimos conocimientos sobre teléfonos móviles.
Por último debemos comparar entre distintos formatos de imagen, codificaciones
y tecnologías de Servicios Web para conseguir la mejor relación entre calidad de
imagen y tiempo de espera.
Francisco Prieto Donate
VII
VIII
Francisco Prieto Donate
ÍNDICE
1 INTRODUCCIÓN ........................................................... 1
1.1
Java en dispositivos inalámbricos..................................................................... 1
1.2
SOAP y XML en dispositivos inalámbricos .................................................... 2
1.3
Organización de la memoria............................................................................. 3
1.3.1
Introducción teórica.......................................................................... 3
1.3.2
Aplicación desarrollada .................................................................... 4
1.3.3
Temporización y presupuesto........................................................... 5
1.3.4
Guía de instalación y planos de código ............................................ 5
2 J2ME .......................................................................... 7
2.1
Introducción...................................................................................................... 7
2.2
Java 2 Platform Micro Edition (J2METM) ........................................................ 7
2.3
Arquitectura J2ME ........................................................................................... 9
2.3.1
Máquina Virtual.............................................................................. 11
2.3.2
Configuraciones.............................................................................. 12
2.3.3
Perfiles ............................................................................................ 13
2.3.4
Capas altas ...................................................................................... 14
2.4
Seguridad ........................................................................................................ 14
2.5
Objetivos, requisitos y alcance de J2ME........................................................ 16
2.6
2.7
2.5.1
Objetivos......................................................................................... 17
2.5.2
Requisitos ....................................................................................... 18
2.5.3
Alcance ........................................................................................... 19
CLDC (Connected Limited Device Configuration) ....................................... 20
2.6.1
CLDC Expert Group....................................................................... 21
2.6.2
Modelo de Aplicación de CLDC .................................................... 21
2.6.3
Compatibilidad con JavaTM Virtual Machine Specification ........... 22
2.6.4
Verificación de ficheros de clase.................................................... 24
2.6.5
Librerías de CLDC ......................................................................... 25
2.6.6
CLDC 1.1 ....................................................................................... 30
MIDP (Mobile Information Device Profile)................................................... 31
Francisco Prieto Donate
IX
2.8
2.7.1
MIDP Expert Group ....................................................................... 32
2.7.2
Modelo de Aplicación de MIDP..................................................... 33
2.7.3
MIDlet Suites.................................................................................. 37
2.7.4
Librerías de MIDP .......................................................................... 38
2.7.5
MIDP 2.0 ........................................................................................ 55
Descarga OTA ................................................................................................ 60
2.8.1
2.9
Usos de la tecnología OTA............................................................. 61
Consideraciones finales .................................................................................. 61
3 GPRS ........................................................................ 63
3.1
Introducción.................................................................................................... 63
3.2
Introducción histórica a GPRS ....................................................................... 63
3.3
Protocolo GPRS.............................................................................................. 67
3.4
3.3.1
Identificador del protocolo GPRS .................................................. 68
3.3.2
Identificador del protocolo de los PDU.......................................... 68
3.3.3
Mensaje GPRS................................................................................ 68
Arquitectura de la red GPRS .......................................................................... 69
3.4.1
Elementos de una red GPRS........................................................... 69
3.4.2
Interfaces de una red GPRS............................................................ 74
3.5
Tipología de servicios..................................................................................... 76
3.6
Terminales GPRS ........................................................................................... 77
3.7
Tercera generación de móviles: UMTS.......................................................... 79
3.8
Consideraciones finales .................................................................................. 80
4 SERVICIOS WEB XML.............................................. 83
4.1
4.2
X
Introducción.................................................................................................... 83
4.1.1
Evolución de los Servicios Web..................................................... 83
4.1.2
Conceptos básicos .......................................................................... 84
XML ............................................................................................................... 85
4.2.1
Introducción.................................................................................... 85
4.2.2
Reglas sintácticas............................................................................ 86
4.2.3
DTD (Definición de Tipos de Documentos) .................................. 87
4.2.4
XML Schema.................................................................................. 89
Francisco Prieto Donate
4.3
4.4
4.5
4.6
4.7
4.2.5
Espacios de nombres XML ............................................................ 91
4.2.6
Analizadores XML ......................................................................... 93
SOAP .............................................................................................................. 94
4.3.1
Concepto de SOAP......................................................................... 95
4.3.2
Objetivos de SOAP......................................................................... 95
4.3.3
Un ejemplo sencillo de mensajes SOAP ........................................ 96
4.3.4
Partes de un mensaje SOAP ........................................................... 97
4.3.5
Enlaces SOAP (bindings) ............................................................. 101
4.3.6
SOAP 1.2 ...................................................................................... 101
WSDL........................................................................................................... 102
4.4.1
Elementos de un documento WSDL ............................................ 103
4.4.2
Estilo y uso de un documento WSDL .......................................... 106
4.4.3
Generación del documento WSDL............................................... 112
4.4.4
Interpretación del documento WSDL........................................... 112
UDDI ............................................................................................................ 113
4.5.1
Concepto de UDDI ....................................................................... 113
4.5.2
Datos almacenados en el registro ................................................. 114
4.5.3
Publicación en UDDI ................................................................... 115
4.5.4
Búsqueda en UDDI....................................................................... 115
Servicios Web XML para dispositivos móviles ........................................... 116
4.6.1
kSOAP .......................................................................................... 116
4.6.2
JSR-172 ........................................................................................ 127
Consideraciones finales ................................................................................ 132
5 PROTOCOLO HTTP................................................ 135
5.1
Características y funcionamiento.................................................................. 135
5.2
Comandos de HTTP ..................................................................................... 139
5.3
Codificación de la información .................................................................... 143
5.4
Consideraciones finales ................................................................................ 145
6 TRANSMISIÓN DE VÍDEO EN INTERNET .................. 147
6.1
Introducción.................................................................................................. 147
6.2
Descarga y visualización del contenido ....................................................... 147
Francisco Prieto Donate
XI
6.3
6.4
6.2.1
Formatos de imagen ..................................................................... 148
6.2.2
Formatos de codificación de vídeo............................................... 159
Tecnología de streaming............................................................................... 167
6.3.1
Funcionamiento ............................................................................ 168
6.3.2
Reproductores de streaming ......................................................... 169
6.3.3
Servidores de streaming................................................................ 170
6.3.4
Protocolos de streaming ............................................................... 170
Consideraciones finales ................................................................................ 171
7 APLICACIÓN DESARROLLADA ................................ 173
7.1
Introducción.................................................................................................. 173
7.2
Desarrollo del servidor ................................................................................. 173
7.3
7.2.1
Transformación del servidor de vídeo en servidor web XML...... 174
7.2.2
Comunicación entre servidor de vídeo y servidor web ................ 174
7.2.3
Protocolo de comunicación entre servidores ................................ 175
Desarrollo del cliente.................................................................................... 176
7.3.1
Servicios web en dispositivos móviles ......................................... 176
7.3.2
Formato de imagen solicitada....................................................... 177
7.4
Comunicación cliente-servidor..................................................................... 177
7.5
Consideraciones finales ................................................................................ 179
8 ESCENARIO DE PRUEBAS ........................................ 181
8.1
Introducción.................................................................................................. 181
8.2
Escenario de pruebas .................................................................................... 181
8.3
Escenario kSOAP ......................................................................................... 182
8.4
XII
8.3.1
Desarrollo del servicio web .......................................................... 182
8.3.2
Despliegue del servicio web ......................................................... 185
8.3.3
Desarrollo del cliente.................................................................... 188
8.3.4
Simulación del cliente .................................................................. 197
Escenario JSR-172........................................................................................ 201
8.4.1
Desarrollo del servicio web .......................................................... 201
8.4.2
Despliegue del servicio web ......................................................... 204
8.4.3
Desarrollo del cliente.................................................................... 208
Francisco Prieto Donate
8.4.4
8.5
Simulación del cliente .................................................................. 217
Consideraciones finales ................................................................................ 222
9 PRUEBAS Y RESULTADOS ........................................ 223
9.1
Introducción a las pruebas ............................................................................ 223
9.2
Escenario kSOAP ......................................................................................... 224
9.3
9.4
9.5
10
9.2.1
Codificación Base64..................................................................... 224
9.2.2
Codificación Array de enteros...................................................... 226
Escenario JSR-172........................................................................................ 228
9.3.1
Codificación Base64..................................................................... 228
9.3.2
Codificación Array de enteros...................................................... 230
Análisis de los resultados ............................................................................. 233
9.4.1
Consumo de memoria................................................................... 233
9.4.2
Tiempo entre imágenes................................................................. 234
9.4.3
Información enviada por el servidor............................................. 235
Consideraciones finales ................................................................................ 236
CONCLUSIONES .................................................... 237
10.1
Conclusiones................................................................................................. 237
10.2
Líneas de desarrollo futuras.......................................................................... 239
11
TEMPORIZACIÓN.................................................. 241
12
PRESUPUESTO ...................................................... 243
12.1
Coste de recursos humanos .......................................................................... 243
12.2
Coste de hardware ........................................................................................ 243
12.3
Coste de software ......................................................................................... 243
12.4
Coste de consumibles ................................................................................... 243
12.5
Resumen de costes........................................................................................ 244
13
13.1
GUÍA DE INSTALACIÓN......................................... 245
Servidor de vídeo.......................................................................................... 245
Francisco Prieto Donate
XIII
13.2
13.3
13.1.1
Instalación..................................................................................... 246
13.1.2
Funcionamiento ............................................................................ 247
13.1.3
Formato de la petición al servidor ................................................ 249
Servidor web Apache Tomcat 4.1 ................................................................ 251
13.2.1
Instalación..................................................................................... 251
13.2.2
Funcionamiento ............................................................................ 252
Apache Axis 1.4 ........................................................................................... 254
13.3.1
Instalación..................................................................................... 254
13.3.2
Despliegue de servicios ................................................................ 257
13.4
J2ME Wireless Toolkit 2.2........................................................................... 263
13.5
NetBeans IDE 5.5 ......................................................................................... 265
14
14.1
14.2
15
PLANOS DE CÓDIGO ............................................. 269
Escenario kSOAP ......................................................................................... 269
14.1.1
Servidor Web................................................................................ 269
14.1.2
Cliente J2ME ................................................................................ 272
Escenario JSR-172........................................................................................ 295
14.2.1
Servidor web................................................................................. 295
14.2.2
Cliente J2ME ................................................................................ 298
14.2.3
Stub del cliente J2ME................................................................... 308
REFERENCIAS BIBLIOGRÁFICAS .......................... 315
15.1
Libros de consulta......................................................................................... 315
15.2
Proyectos fin de carrera ................................................................................ 315
15.3
Páginas web .................................................................................................. 316
15.4
Apuntes de asignaturas ................................................................................. 318
15.5
Artículos ....................................................................................................... 318
XIV
Francisco Prieto Donate
1. Introducción
1
INTRODUCCIÓN
1.1 Java en dispositivos inalámbricos
El lenguaje de programación Java fue concebido inicialmente para el desarrollo de
aplicaciones en dispositivos comerciales controlados digitalmente. El objetivo de los
creadores de Java fue el diseño de un nuevo lenguaje de alto nivel que permitiese
controlar dispositivos hardware de prestaciones más o menos reducidas. Se buscaba un
lenguaje totalmente portable e independiente de la plataforma de ejecución.
Con el tiempo se vio la verdadera potencia que podía proporcionar, y su
inclusión en el navegador Netscape marcó el inicio de su extensión a los ordenadores.
Al disponer de mayor capacidad de procesamiento que en los dispositivos para los que
inicialmente estaba pensado, las sucesivas versiones de Java requieren más recursos y
añaden nuevas características útiles.
En la actualidad, debido al creciente mercado de dispositivos móviles, Java ha
tenido que volver a sus inicios y desarrollar una versión más limitada para que pueda ser
usada en dichos dispositivos. Esta versión es la Java 2 Micro Edition, o J2ME.
Son muchas las características que hacen de Java el lenguaje ideal para este tipo
de dispositivos inalámbricos. De entre todas ellas cabe destacar:
•
Es independiente de la red, por tanto permite descargar cualquier tipo de
aplicaciones y servicios en cualquier tipo de conexión.
•
Tareas como la verificación de ficheros de clase proporcionan una alta seguridad
de que las aplicaciones que se desarrollen con este lenguaje funcionen
adecuadamente.
•
La portabilidad, debida a la independencia de Java respecto de la plataforma
subyacente, hace que sea este lenguaje ideal para aplicaciones que irán dirigidas a
dispositivos diseñados por diferentes fabricantes.
•
J2ME ha sido diseñado de forma que se pueda presentar de forma sencilla al
usuario un conjunto de prestaciones gráficas que hacen muy atractivas las
aplicaciones desarrolladas con este lenguaje.
Francisco Prieto Donate
1
Transmisión de Imágenes de Vídeo mediante Servicios Web XML sobre J2ME
•
Para las aplicaciones diseñadas con J2ME no es necesario la conexión a
permanente a la red, ya que estas aplicaciones residen en el dispositivo
inalámbrico y no tienen por qué ser descargadas cada vez que vayan a ser
ejecutadas.
•
Se puede decir que la comunidad de desarrolladores de aplicaciones Java en la
red es la mayor de todas las existentes, con un número de participantes que
supera los cuatro millones y medio.
1.2 SOAP y
inalámbricos
XML
en
dispositivos
Debido a las características del lenguaje Java es posible la ampliación de la
funcionalidad de una aplicación sin más que añadir nuevas librerías.
Esto hace que las aplicaciones software desarrolladas con Java, y en particular con
J2ME, tengan un potencial muy grande, ya que pueden adaptarse de forma sencilla a las
distintas tecnologías que vayan apareciendo, de modo que nunca se quedarán obsoletas.
La tendencia actual en cuanto a la representación de datos es el uso de la
tecnología XML, la cual permite de forma sencilla contener cualquier tipo de dato
dentro de mensajes de texto plano. Esto hace que la sencillez en la transferencia de
datos mediante XML sea tal que prácticamente todas las aplicaciones Web que corren
sobre Internet usen este lenguaje de marcas.
Comprobada la versatilidad de XML, continuamente se están llevando a cabo
proyectos con el fin de desarrollar las prestaciones que ofrece este lenguaje. De esta
forma son múltiples los campos de la tecnología que hacen uso de XML, no solamente
en la red, sino ya en tareas de configuración de dispositivos físicos.
De entre todos estos proyectos nació uno que recibió el nombre de SOAP, cuyo
objetivo es el utilizar XML en tareas de transferencia de datos en la red. Así, SOAP
encapsula en documentos XML los mensajes intercambiados entre un servidor de
aplicaciones y un cliente.
Puesto que los dispositivos inalámbricos se están introduciendo cada día más en
Internet, es evidente que antes o después sería necesario para éstos el uso de XML y por
tanto de SOAP. Este hecho ha traído consigo que algunos de los componentes de la
comunidad de desarrollo con la que cuenta Java se hayan dedicado a desarrollar las
2
Francisco Prieto Donate
1. Introducción
librerías necesarias para el uso de SOAP o XML en aplicaciones sobre J2ME. En la
actualidad existen las librerías ksoap para SOAP inalámbrico y kxml2, nanoXml, TAM,
X-parse y tinyXml para analizar documentos XML en dispositivos inalámbricos.
1.3 Organización de la memoria
La memoria de este proyecto se estructura en cuatro bloques principales. El
primer bloque contiene una introducción teórica de las tecnologías utilizadas. El
segundo muestra una descripción de la aplicación desarrollada junto con las pruebas
realizadas, resultados obtenidos y conclusiones. En tercer lugar presentamos la
temporización y el presupuesto. Por último se incluye la guía de instalación y el código
fuente utilizado en el desarrollo de la aplicación.
1.3.1 Introducción teórica
Los primeros capítulos de la memoria están dedicados a presentar cada una de las
tecnologías implicadas en la realización de este proyecto. Este bloque está formado por
los siguientes capítulos:
•
Capítulo 2: J2ME. En este capítulo presentamos y analizamos Java 2 Micro
Edition, también conocida como “Java para móviles”. Esta tecnología nos
permite ejecutar programas Java en dispositivos móviles con reducidas
prestaciones de capacidad y memoria.
•
Capítulo 3: GPRS. Estudiamos la tecnología que usará nuestro dispositivo móvil
para conectarse a Internet con el fin de comunicarse con un servidor.
•
Capítulo 4: Servicios Web XML. Este capítulo se dedica a explicar el marco
que utilizarán cliente y servidor para intercambiarse información. Analizaremos
las distintas tecnologías y protocolos asociados a los servicios web, prestando
especial atención al estudio de XML. Por último presentaremos dos escenarios
diferentes de comunicación entre cliente y servidor.
•
Capítulo 5: Protocolo HTTP. Estudiaremos las características y el fundamento
del protocolo de transferencia de datos más utilizado en la red para la descarga de
páginas web e intercambio de información de los Servicios Web.
Francisco Prieto Donate
3
Transmisión de Imágenes de Vídeo mediante Servicios Web XML sobre J2ME
•
Capítulo 6: Transmisión de vídeo en Internet. En este capítulo haremos un
repaso de las principales alternativas utilizadas en la actualidad para la
transmisión de vídeo a través de Internet. Analizaremos distintos formatos de
imágenes y vídeo y comentaremos las tecnologías existentes para transmisión en
tiempo real.
1.3.2 Aplicación desarrollada
Tras la introducción teórica realizamos una aplicación con la que se pretende
recibir imágenes de vídeo en un cliente móvil compatible con J2ME mediante Servicios
Web XML utilizando todas las tecnologías anteriormente explicadas. Este segundo
bloque está formado por los siguientes capítulos:
4
•
Capítulo 7: Aplicación desarrollada. Capítulo dedicado a presentar una
panorámica de la aplicación que se va a desarrollar. En este punto se introducen
los servidores que se van a utilizar y las distintas tecnologías, formatos y
codificaciones de los que haremos uso para realizar la implementación.
•
Capítulo 8: Escenario de pruebas. En este capítulo se detalla la aplicación
desarrollada. Se presentan dos escenarios, donde cada uno utiliza una tecnología
de servicios web diferente. Para cada escenario se explica cómo se ha realizado y
desplegado el servicio web, y cual es el funcionamiento del cliente móvil. Se
adjuntan fragmentos de planos de código fuente con comentarios para mejorar la
comprensión de las implementaciones.
•
Capítulo 9: Pruebas y resultados. Una vez preparado el escenario,
establecemos una batería de pruebas destinada a medir factores como tiempos de
respuesta y consumo de memoria en tiempo de ejecución. Al final del capítulo se
ponen en común y se justifican todos los resultados obtenidos.
•
Capítulo 10: Conclusiones. El último capítulo del bloque está dedicado a
estudiar y comentar los resultados obtenidos en las pruebas para conseguir una
aplicación con altos niveles de rendimiento. Asimismo se hace un repaso de cada
una de las tecnologías implicadas y cómo ha afectado cada una de ellas en la
aplicación desarrollada.
Francisco Prieto Donate
1. Introducción
1.3.3 Temporización y presupuesto
Este bloque está dedicado a mostrar el tiempo utilizado en la realización del
proyecto y redacción de la memoria y el presupuesto necesario para su puesta en
práctica. Dos son los capítulos que conforman este bloque:
•
Capítulo 11: Temporización. En este capítulo exponemos la división que se ha
realizado del proyecto en fases, estableciendo el tiempo dedicado a la realización
de cada una de ellas.
•
Capítulo 12: Presupuesto. Presentamos el coste total necesario para poner en
práctica la aplicación desarrollada en este proyecto.
1.3.4 Guía de instalación y planos de código
El último bloque de la memoria presenta la guía de instalación y los planos de
código fuente utilizados.
•
Capítulo 13: Guía de instalación. El primer capítulo de este bloque expone
todos los pasos necesarios para poner en práctica el escenario de pruebas que se
ha utilizado en este proyecto. Se presenta todo el software utilizado y se explica
detalladamente el proceso de instalación y configuración de cada uno de los
programas.
•
Capítulo 14: Planos de código. Por último mostramos el código fuente utilizado
para crear un servicio web, desplegarlo y acceder a él a través del cliente móvil.
Francisco Prieto Donate
5
Transmisión de Imágenes de Vídeo mediante Servicios Web XML sobre J2ME
6
Francisco Prieto Donate
2. J2ME
2
J2ME
2.1 Introducción
El cliente desarrollado en este proyecto está basado en la tecnología J2ME, una
plataforma que permite la ejecución de programas Java en dispositivos móviles. Esta
tecnología puede encontrarse en teléfonos móviles, PDAs o Palms, o incluso cualquier
otro tipo de dispositivo móvil que pudiese ser diseñado en un futuro próximo.
La aplicación cliente se ejecutará en un teléfono móvil con soporte J2ME y se
conectará, mediante el protocolo de comunicación SOAP, con un servicio Web el cual
le facilitará una serie datos de utilidad para el usuario.
2.2 Java 2
(J2METM)
Platform
Micro
Edition
Actualmente Sun Microsystems ha agrupado la tecnología Java en tres tecnologías
claramente diferenciadas, cada una de ellas adaptada a un área específica de la industria:
•
Java 2 Platform, Enterprise Edition (J2EETM), pensada para cubrir las
necesidades que puedan tener las empresas que quieran ofrecer servicios a sus
clientes, proveedores y empleados.
•
Java 2 Platform, Standard Edition (J2SETM), pensada para satisfacer las
necesidades de usuarios y programadores en sus equipos personales y estaciones
de trabajo.
•
Java 2 Micro Edition (J2METM), enfocada tanto para productores de dispositivos
portátiles de consumo como para quienes proporcionan servicios de información
aplicables a estos dispositivos.
Cada una de estas plataformas define en su interior un conjunto de tecnologías
que pueden ser utilizadas con un producto en particular:
Francisco Prieto Donate
7
Transmisión de Imágenes de Vídeo mediante Servicios Web XML sobre J2ME
•
Java Virtual Machine que encuadra en su interior un amplio rango de equipos de
computación.
•
Librerías y APIs especializadas para cada tipo de dispositivo.
•
Herramientas para desarrollo y configuración de equipos.
J2ME abarca un espacio de consumo en rápido crecimiento, que cubre un amplio
rango de dispositivos, desde pequeños dispositivos de mano hasta incluso televisores.
Todo esto manteniendo siempre las cualidades por las cuales la tecnología Java ha sido
mundialmente reconocida: consistencia entre los distintos productos Java y portabilidad
de código entre equipos, así como gratuidad y escalabilidad.
La idea principal de J2ME es proporcionar aplicaciones sencillas, que permitan al
programador desarrollar aplicaciones de usuario para el consumidor de dispositivos
móviles y portátiles. De esta forma se abre un amplio mercado para todas aquellas
empresas que deseen cubrir las necesidades que los usuarios demandan en sus
dispositivos móviles, tales como teléfonos móviles o agendas personales.
J2ME está orientada a dos categorías muy concretas de productos, como son:
8
•
Dispositivos de información compartida conectados de forma permanente. Esta
categoría se conoce con la denominación CDC (Connected Device
Configuration). Ejemplos típicos de éstos son televisores, teléfonos conectados a
Internet y sistemas de navegación y entretenimiento para el automóvil. Estos
dispositivos se caracterizan por tener un gran número de interfaces de usuario,
conexión permanente a Internet de banda ancha de tipo TCP/IP y unos rangos de
capacidad de memoria entre 2 y 16 MB.
•
Dispositivos de información personales móviles. Categoría conocida como
CLDC (Connected, Limited Device Configuration). De entre todos éstos los más
representativos son los teléfonos móviles y las agendas personales (PDAs). Se
caracterizan por disponer de interfaces simples, conexión no permanente a
Internet, menor ancho de banda y rangos de capacidad de memoria muy
reducidos, entre 128 y 512 KB.
Francisco Prieto Donate
2. J2ME
Figura 2.1: Dispositivos Java y sus ediciones
Con el paso de los años la línea fronteriza que separa ambos grupos es cada vez
más fina, hecho que va potenciándose aún más a medida que la tecnología avanza y van
apareciendo nuevos tipos de dispositivos y evolucionando los ya existentes. De esta
forma hoy ya se “confunden” los ordenadores y los dispositivos de comunicaciones y
cada vez más se va haciendo más uso de conexiones sin cables, lo cual nos lleva a
realizar en la práctica una agrupación de equipos basándonos únicamente en sus
capacidades de memoria, sus consumos de batería y el tamaño de la pantalla.
2.3 Arquitectura J2ME
Aunque los dispositivos mencionados tales como teléfonos móviles, PDAs o
televisores tienen muchos aspectos en común, también son muy diferentes en cuanto a
forma y función. Éstos contarán con diferentes configuraciones hardware, diferentes
modos de uso (uso de teclado, voz, etc.), diferentes aplicaciones y características
software, así como todo un amplio rango de futuras necesidades a cubrir. Para
considerar esta diversidad la arquitectura J2ME está diseñada de forma modular y
extensible de tal forma que se dé cabida a esta extensa variedad de dispositivos así como
a aquellos que sean desarrollados en el futuro.
La arquitectura J2ME tiene en cuenta todas aquellas consideraciones relativas a
los dispositivos sobre los que tendrá que trabajar. De esta forma, son tres los conceptos
básicos en los que se fundamenta:
Francisco Prieto Donate
9
Transmisión de Imágenes de Vídeo mediante Servicios Web XML sobre J2ME
•
Máquina Virtual: Ya que el mercado de venta de los dispositivos a los que se
refiere J2ME es tan variado y heterogéneo, existiendo un gran número de
fabricantes con distintos equipos hardware y distintas filosofías de trabajo, J2ME
proporciona una máquina virtual Java completamente optimizada que permitirá
trabajar con diferentes tipos de procesadores y memorias comúnmente utilizados.
•
Configuración y Perfil: Como los dispositivos sobre los que trabaja J2ME son
tan reducidos en lo que se refiere a potencia de cálculo y capacidad de memoria,
J2ME proporciona una máquina virtual Java muy reducida que permite solo
aquellas funciones esenciales y necesarias para el funcionamiento del equipo.
Además, como los fabricantes diseñan distintas características en sus equipos y
desarrollan continuos cambios y mejoras en sus aplicaciones estas
configuraciones tan reducidas deben poder ser ampliadas con librerías
adicionales. Por ello se han considerado dos conceptos extremadamente
importantes, que son las Configuraciones y los Perfiles. El objetivo de realizar
esta distinción entre Perfiles y Configuraciones es el de preservar una de las
principales características de Java, la portabilidad.
Figura 2.2: Capas en un dispositivo con soporte J2ME
10
Francisco Prieto Donate
2. J2ME
2.3.1 Máquina Virtual
En la actualidad existen dos implementaciones de máquina virtual para ejecución
de programas Java en dispositivos móviles:
•
K Virtual Machine
La tecnología KVM define una máquina virtual Java específicamente pensada
para su funcionamiento en dispositivos de pequeño tamaño y de características muy
reducidas y limitadas. El objetivo de esta tecnología fue el de crear la mínima máquina
virtual posible pero que mantuviese los aspectos fundamentales del lenguaje Java, todo
ello funcionando en un dispositivo con una capacidad de memoria de tan solo unos
cuantos centenares de KB (de ahí el nombre de la máquina virtual).
KVM puede trabajar con microprocesadores de 16/32 bits tales como teléfonos
móviles, PDAs, equipos de audio/vídeo portátiles, etc.
La mínima cantidad ideal de memoria necesaria para la KVM es de 128 KB en los
cuales se incluyen la propia máquina virtual, un mínimo número de librerías y espacio
libre para las aplicaciones. A pesar de esto, una implementación típica real necesita de
unos 256 KB de los que aproximadamente se utilizan la mitad para las aplicaciones, de
60 a 80 KB para la máquina virtual y el resto para las librerías.
•
CLDC HotSpot ImplementationTM
Es una máquina virtual optimizada que presenta una diferencia de rendimiento
muy alta frente a la KVM. Está pensada para funcionar en dispositivos de nueva
generación con mayores capacidades de memoria. Incluye características que soportan
una ejecución más rápida de aplicaciones y una gestión de recursos más eficientes,
manteniendo los requisitos en cuanto a plataforma de ejecución.
El CLDC HotSpot ImplementationTM está diseñado para trabajar en
microprocesadores o microcontroladores RISC/CISC de 32 bits. La cantidad mínima de
memoria necesaria es de 512 KB en los cuales se incluyen la propia máquina virtual, un
conjunto de librerías y espacio libre para las aplicaciones.
Francisco Prieto Donate
11
Transmisión de Imágenes de Vídeo mediante Servicios Web XML sobre J2ME
2.3.2 Configuraciones
Una Configuración J2ME define una plataforma mínima para una categoría
horizontal de dispositivos con similares características de memoria y procesamiento. A
su vez, proporciona una definición completa de máquina virtual y el conjunto mínimo
de clases Java que todo dispositivo o aplicación debería tener. Más concretamente, una
configuración especifica:
•
Las características del lenguaje Java soportadas por el dispositivo.
•
Las características soportadas por la máquina virtual Java.
•
Las librerías y APIs Java soportadas.
En un entorno J2ME una aplicación es desarrollada para un Perfil en particular, el
cual se basa en una Configuración específica. De esta forma una Configuración define
una plataforma común tanto para la fabricación de dispositivos como para el posterior
desarrollo de aplicaciones sobre éstos.
Por tanto, todos los dispositivos que se encuadren dentro de una Configuración
concreta deben cumplir todas las características de ésta, y todas las aplicaciones que
corran sobre estos dispositivos deben cumplir las restricciones del Perfil que se monta
sobre dicha Configuración.
El objetivo de esta diferenciación entre Configuraciones y Perfiles es evitar la
fragmentación y limitar en lo posible el número de Configuraciones desarrolladas por
los fabricantes. Concretamente, solo existen dos Configuraciones estándar permitidas,
que son:
12
•
CLDC (Connected Limited Device Configuration), que abarca el conjunto de los
dispositivos móviles personales, tales como teléfonos móviles, PDAs, etc.
Implementa una serie de librerías y APIs que no se encuentran en J2SE y que son
específicas para este tipo de dispositivos.
•
CDC (Connected Device Configuration), que comprende fundamentalmente el
conjunto de dispositivos de información compartida, fijos y de conexión
permanente, tales como televisores, terminales de comunicación, etc. Incluye un
conjunto de librerías mucho mayor que el anterior, siendo CLDC un subconjunto
de ésta.
Francisco Prieto Donate
2. J2ME
Figura 2.3: Relación J2SE-J2ME
La mayoría de las funcionalidades de CLDC y CDC son heredadas de J2SE, de
forma que toda clase perteneciente a CDC y CLDC debe ser exactamente igual a su
correspondiente en J2SE o bien un subconjunto de ésta. Pero además ambas
configuraciones pueden añadir características que no se encuentren en J2SE y que sean
específicas del dispositivo en sí.
2.3.3 Perfiles
Un Perfil de dispositivo es una capa definida sobre una Configuración concreta,
de forma que el Perfil extienda las posibilidades de dicha Configuración. Un Perfil está
pensado para garantizar la interoperabilidad de una familia vertical de dispositivos, y se
compone de una serie de librerías de clases más específicas del dispositivo que las de la
Configuración.
Para un dispositivo será posible soportar varios tipos de Perfiles. Algunos de éstos
serán específicos del propio dispositivo y otros serán específicos de alguna aplicación
que corra sobre el dispositivo. Las aplicaciones son diseñadas para un Perfil concreto y
solo podrán funcionar en él y no en otro Perfil, ya que harán uso de las funcionalidades
propias de éste. Según esto podemos considerar que un Perfil no es más que un conjunto
de librerías de clases que proporciona funcionalidades adicionales a las de las
Configuración que reside debajo de él.
Actualmente el único Perfil que existe y está en funcionamiento para la
configuración CLDC es MIDP, el cual está pensado para teléfonos móviles.
Francisco Prieto Donate
13
Transmisión de Imágenes de Vídeo mediante Servicios Web XML sobre J2ME
2.3.4 Capas altas
Sobre las capas anteriores se implementan las distintas aplicaciones que corren
sobre el dispositivo. Pueden ser de tres tipos:
•
Una aplicación MIDP, también llamada MIDlet, es una aplicación que solamente
hace uso de librerías Java definidas por las especificaciones CLDC y MIDP.
•
Una aplicación OEM-specific es aquella que no solo utiliza clases propias de
MIDP, sino que también hace uso de clases de la especificación OEM (Original
Equipment Manufacturer, o fabricante original del equipo). Estas clases
normalmente no son portables de un equipo a otro, ya que son propias de cada
fabricante.
•
Una aplicación Nativa es aquella que no está escrita en lenguaje Java sino que va
montada sobre el software nativo del propio equipo.
Figura 2.4: Arquitectura de alto nivel de un dispositivo móvil
2.4 Seguridad
Tanto empresas como usuarios individuales dependen cada vez más de
información crítica almacenada en computadoras y redes, por lo que el uso de sistemas
y aplicaciones de seguridad se ha convertido en algo extremadamente importante. En el
14
Francisco Prieto Donate
2. J2ME
ámbito de los dispositivos móviles y redes inalámbricas la utilización de sistemas de
seguridad resulta esencial.
La plataforma de desarrollo de Java es muy útil en estos aspectos debido a su
inherente arquitectura de seguridad. En la plataforma J2SE el modelo de seguridad
proporciona a los desarrolladores de aplicaciones funcionalidades con las que crear
distintas políticas de acceso y articular permisos independientes para cada usuario.
Desafortunadamente la cantidad de código con el que se consigue este modelo y
que se encuentra en la plataforma J2SE excede en mucho las capacidades de memoria
de los dispositivos sobre los que trabaja J2ME, por lo que se hacen necesarias una serie
de simplificaciones que reduzcan este código pero que mantengan cierta seguridad. El
modelo de seguridad definido en CLDC en conjunto con MIDP se basa en tres niveles:
1. Seguridad de bajo nivel: También conocida como seguridad de la máquina
virtual. Asegura que un fichero de clase, o un fragmento de código
malintencionado no afecte a la integridad de la información almacenada en el
dispositivo móvil. Esto se consigue mediante el verificador de ficheros de clase,
el cual asegura que los bytecodes almacenados en el fichero de clase no
contengan instrucciones ilegales, que ciertas instrucciones no se ejecuten en un
orden no permitido y que no contengan referencias a partes de la memoria no
válidas o que se encuentren fuera del rango de direccionamiento real. Debido a
esto el estándar CLDC exige que bajo él se encuentre una máquina virtual que
realice estas operaciones de seguridad.
2. Seguridad de nivel de aplicación: Este nivel de seguridad asegura que las
aplicaciones que corren sobre el dispositivo sólo puedan acceder a aquellas
librerías, recursos del sistema y otros dispositivos que tanto el equipo como el
entorno de aplicación permitan. El verificador de ficheros de clase sólo puede
garantizar que la aplicación dada es un programa Java válido. Por lo tanto existen
una serie de aspectos que se escapan del control del verificador de clases, como
por ejemplo el acceso a recursos externos: ficheros de sistema, impresoras,
dispositivos infrarrojos o la red. La seguridad en este nivel se apoya en tres
conceptos básicos:
Modelo Sandbox: En el modelo CLDC y MIDP el nivel de seguridad de
aplicación se obtiene mediante un sandbox, un contenedor virtual que
asegura un entorno cerrado. En este entorno una aplicación solo puede
acceder a aquellas librerías que han sido definidas por la Configuración, el
Perfil y las clases específicas OEM del dispositivo. El sandbox asegura que
la aplicación no se escape de él y acceda a recursos o funcionalidades no
permitidas. Más concretamente el uso de un sandbox asegura que:
Francisco Prieto Donate
15
Transmisión de Imágenes de Vídeo mediante Servicios Web XML sobre J2ME
Los ficheros de clases han sido preverificados y las aplicaciones Java
son válidas.
La Configuración, el Perfil y las clases OEM han determinado un
conjunto de APIs válidas para la aplicación.
La descarga y gestión de aplicaciones Java dentro del dispositivo se
encuentran en su lugar correcto de almacenamiento, no permitiéndose el
uso de clases y aplicaciones de descarga diseñadas por el usuario que
podrían dañar a las del sistema.
El programador de aplicaciones no puede descargar al dispositivo
librerías que contengan nuevas funcionalidades nativas o que accedan a
funcionalidades nativas no permitidas.
Protección de clases de sistema: Una de las características del CLDC es la
habilidad de soportar la descarga dinámica de aplicaciones a la máquina
virtual del dispositivo. Podría existir por tanto una falta de seguridad, ya
que una aplicación podría ignorar o sobreescribir ciertas clases del sistema.
No obstante, CLDC y MIDP se encargan de que esto no ocurra.
Restricciones adicionales en la carga dinámica de clases: Existe una
restricción de seguridad muy importante en la carga dinámica de clases que
consiste en que por defecto una aplicación Java solo puede cargar clases
pertenecientes a su Java Archive file (JAR). Esta restricción asegura que las
distintas aplicaciones que corran sobre un dispositivo no puedan interferir
entre sí.
3. Seguridad punto a punto: Garantiza que una transacción iniciada en un
dispositivo móvil se encuentre protegida a lo largo de todo el camino recorrido
entre el dispositivo y la entidad proveedora del servicio. Este tipo de seguridad
no está recogida en el CLDC ni en el MIDP, por lo que será siempre una solución
propietaria del fabricante y del proveedor de servicios.
2.5 Objetivos, requisitos y alcance de J2ME
Desde el principio todo el diseño de la tecnología J2ME ha pretendido lograr una
serie de objetivos muy concretos para facilitar un funcionamiento adecuado a los
dispositivos sobre los que se va a montar. Con el fin de conseguir una cierta
16
Francisco Prieto Donate
2. J2ME
portabilidad ha sido necesario además establecer una serie de requerimientos mínimos
que deben cumplir los dispositivos con soporte J2ME.
2.5.1 Objetivos
Todos los objetivos que la tecnología J2ME ha conseguido hacen que despierte un
gran interés, por ello resulta interesante conocer algunas de sus características:
•
Reparto dinámico de contenidos y aplicaciones Java: Uno de los grandes
beneficios que aporta la tecnología Java a estos dispositivos de reducidas
prestaciones es el reparto dinámico y con total seguridad de servicios interactivos
y aplicaciones sobre diferentes redes lo cual se consigue gracias al CLDC y al
MIDP. Desde que aparecieron los primeros teléfonos móviles y hasta el día de
hoy en el que el uso de Internet está mundialmente extendido, los fabricantes han
intentado diseñar dispositivos con mayores posibilidades de comunicación y con
mayores facilidades en lo que concierne al desarrollo de aplicaciones, motivo que
impulsó el despliegue de esta tecnología.
•
Desarrollo de aplicaciones Third-party: El enfoque de J2ME en cuanto al
reparto dinámico de aplicaciones que CLDC y MIDP aportan no favorece
únicamente a los diseñadores y a los fabricantes de equipos y sus programadores
de aplicaciones, sino también a los diseñadores de aplicaciones independientes o
third-party. Se prevé que una vez que los dispositivos portátiles sean de uso de
común e imprescindible para el usuario serán los desarrolladores third-party los
que abarcarán todo el mercado de diseño de aplicaciones J2ME, por eso en
CLDC y MIDP se han incorporado una serie de librerías que favorezcan a estos
desarrolladores en sus diseños.
•
Independencia de las tecnologías estándar de comunicación: Existe un amplio
rango de tecnologías de comunicación inalámbrica actualmente en uso por todo
el mundo, las cuales varían entre sí respecto de niveles de sofisticación,
compatibilidad e interoperabilidad. En la Segunda Generación (2G) destacan,
entre otras, tecnologías tales como GSM, TDMA o CDMA. La tecnología 2,5G,
a caballo entre 2G y 3G, cuenta con GPRS, EDGE, CDPD, etc. En la actual
Tercera Generación (3G) tenemos W-CDMA, CDMA2000 y TD-SCDMA. Y en
la recién llegada 3,5G podemos hablar de HSDPA. Debido al gran número de
tecnologías existentes, cada una con sus características propias e incompatibles
con las demás, J2ME se ha esforzado en definir una serie de soluciones que se
adapten a todas ellas de forma estándar. Esto se ha conseguido huyendo de
aquellas APIs que solo puedan ser encuadradas en un tipo de tecnología, así
como realizando soluciones que se adapten tanto a las características de ancho de
banda de comunicación actual como a las futuras características de comunicación
de banda ancha.
Francisco Prieto Donate
17
Transmisión de Imágenes de Vídeo mediante Servicios Web XML sobre J2ME
•
Compatibilidad con otros estándares inalámbricos: Una característica muy
interesante de J2ME es que no es una nueva tecnología inalámbrica que viene a
desbancar a las demás ya existentes, sino que puede ser utilizada para favorecer y
mejorar a estas otras tecnologías. Así teléfonos móviles provistos de las
tecnologías WAP o i-Mode pueden mejorar sus posibilidades gracias a J2ME, ya
que se puede utilizar código Java para ampliar, por ejemplo, la funcionalidad de
los navegadores Web.
2.5.2 Requisitos
Los estándares CLDC y MIDP exigen una serie de requisitos tanto hardware
como software a cumplir por los dispositivos sobre los que se montan aplicaciones
J2ME.
•
Requisitos CLDC
CLDC tiene en cuenta la gran cantidad de dispositivos existentes en el mercado así
como de las grandes diferencias existentes entre éstos, por ello solo se imponen
restricciones respecto de la capacidad de memoria. Considerando que la KVM, las
librerías de Configuración y de Perfil y las aplicaciones corriendo sobre el
dispositivo sólo deben ocupar entre 160 y 512 KB, se exigen al menos 128 KB de
memoria no volátil para la KVM y las librerías, y al menos 32 KB de memoria
volátil para la KVM en funcionamiento.
En lo concerniente al software ocurre algo parecido: debido a la gran diversidad de
software nativos que pueden correr en el dispositivo, el CLDC sólo exige la
existencia de un software muy sencillo, tal que cuente con una entidad de control de
programas para que pueda correr la KVM. No es necesario que dé soporte para
espacios de direccionamiento separados para cada proceso ni tampoco que ofrezca
garantías de un buen funcionamiento en tiempo real.
•
Requisitos MIDP
Los requisitos exigidos por el MIDP son algo más estrictos, ya que debe tratar
aspectos complejos tales como la presentación en pantalla. De esta forma se exigen
128 KB de memoria no volátil para componentes MIDP, 8 KB de memoria no volátil
para almacenamiento de datos de aplicación de forma persistente y 32 KB de
memoria volátil para la KVM en ejecución. Los requisitos en el display del equipo
son un tamaño de 96 x 54 mm2, una profundidad de 1 bit y una relación de aspecto
en el display de 1:1. La interfaz de entrada debe tener al menos uno de los siguientes
mecanismos: pantalla táctil o teclado a una o dos manos. En lo relativo a la red se
18
Francisco Prieto Donate
2. J2ME
pide una conexión bidireccional inalámbrica con un ancho de banda limitado que
puede ser intermitente.
En lo referente al software, MIDP exige varias características: la existencia de un
kernel mínimo que controle el hardware y proporcione la entidad de control de
programas anteriormente mencionada, un mecanismo de lectura/escritura de
memoria no volátil para dar soporte a las APIs de almacenamiento de datos
persistentemente, un mecanismo de lectura/escritura para dar soporte a las APIs de
red, un mecanismo que proporcione soporte de temporización, una capacidad mínima
para escribir en la pantalla del dispositivo y un mecanismo para capturar la entrada
de datos por parte del usuario.
2.5.3 Alcance
Basado en la especificación JSR-30 (CDLC 1.0), tanto CLDC como MIDP tienen
definidos una serie de alcances o aspectos que pueden abarcar.
•
Alcance CLDC
La especificación del CLDC indica que los campos que este estándar cubre son los
siguientes:
1. Lenguaje Java y características de la KVM
2. Librerías básicas: java.lang.*, java.io.*, java.util.*.
3. Entrada/salida
4. Red
5. Seguridad
•
Alcance MIDP
De todas las posibles funcionalidades que se pueden encontrar en un dispositivo, el
MIDP Expert Group decidió abarcar en MIDP solo aquellas que realmente aseguren
la portabilidad:
Francisco Prieto Donate
19
Transmisión de Imágenes de Vídeo mediante Servicios Web XML sobre J2ME
1. Modelo de Aplicación: estructura que debe seguir una aplicación
2. Interfaz de usuario, tanto pantalla como entrada de datos.
3. Almacenamiento persistente de datos
4. Red
5. Temporización
2.6 CLDC (Connected
Configuration)
Limited
Device
El objetivo del CLDC es definir una plataforma Java para dispositivos pequeños y
de reducidas prestaciones:
•
De 160 a 512 KB de memoria
•
Procesador de 16-32 bits
•
Bajo consumo de la batería de alimentación
•
Conexión a redes inalámbricas, de forma intermitente y de ancho de banda
reducido (normalmente 9600 bps o menos)
En este grupo de dispositivos podemos incluir a los teléfonos móviles, PDAs y
terminales punto de venta.
En la actualidad existen dos versiones de CLDC, la 1.0 y la 1.1. En adelante,
cuando hablemos de CLDC nos estaremos refiriendo a la versión 1.0. Una vez
explicadas las características de CLDC 1.0, pasaremos a ver las novedades que aporta la
versión 1.1.
20
Francisco Prieto Donate
2. J2ME
2.6.1 CLDC Expert Group
La especificación del CLDC ha sido desarrollada por el Sun’s Java Community
Process (JCP) y el resultado se encuentra en la norma JSR-30. Este grupo de fabricantes
y desarrolladores de software está formado por las siguientes empresas:
•
•
•
•
•
•
•
•
•
America Online
Bull
Ericsson
Fujitsu
Matsushita
Mitsubishi
Motorola
Nokia
NTT DoCoMo
•
•
•
•
•
•
•
•
•
Oracle
Palm Computing
Research In Motion
Samsung
Sharp
Siemens
Sony
Sun Microsystems
Symbian
2.6.2 Modelo de Aplicación de CLDC
2.6.2.1 Arquitectura
Tal y como se comentó anteriormente, la arquitectura que se sigue en J2ME se
divide en tres capas. La primera es la llamada Host Operating System, que se encarga de
proporcionar la capacidad de controlar el hardware subyacente. Sobre ésta se encuentra
el CLDC, el cual tiene en su interior la máquina virtual y una serie de librerías con los
que damos al móvil la posibilidad de trabajar con lenguaje Java corriendo sobre una
máquina virtual Java. Como última capa tenemos el Perfil MIDP, el cual aporta un
conjunto de librerías que completan a las del CLDC.
Para el CLDC el concepto de aplicación Java se refiere a una colección de
ficheros de clases Java que contienen un único método public static void main (String[]
args) e identifica el punto de lanzamiento de la aplicación. De esta forma la máquina
virtual iniciará la ejecución de la aplicación llamando a este método.
Figura 2.5: Modelo de capas de J2ME
Francisco Prieto Donate
21
Transmisión de Imágenes de Vídeo mediante Servicios Web XML sobre J2ME
2.6.2.2 Gestor de aplicaciones
Con el fin de poder mantener almacenadas las aplicaciones dentro del dispositivo
para posteriormente ser ejecutadas desde memoria existe el denominado gestor de
aplicaciones. Este gestor suele estar programado en lenguaje C o bien en cualquier
lenguaje de bajo nivel que controle al hardware y que sea dependiente de él, pero nunca
en lenguaje Java, ya que la realización de estas operaciones es tarea del propio
dispositivo, y por tanto está fuera del alcance de J2ME. El gestor de aplicaciones es el
encargado de realizar las siguientes operaciones:
•
Descargar e instalar aplicaciones Java
•
Inspeccionar la existencia de aplicaciones Java almacenadas en el dispositivo
•
Seleccionar y lanzar aplicaciones Java
•
Borrar de memoria aplicaciones Java almacenadas en el equipo
2.6.3 Compatibilidad
Specification
con
JavaTM
Virtual
Machine
Debido a las fuertes restricciones de memoria que se dan en los dispositivos con
los que trabaja J2ME, existen ciertas diferencias entre la maquina virtual definida en
J2SE y la máquina virtual que proporciona CLDC. En esta última se observan una serie
de limitaciones a la hora de desarrollar aplicaciones.
•
Inexistencia de punto flotante: Debido a que la mayoría de dispositivos
hardware subyacentes no soportan por sí mismos numeración en punto flotante,
tendría que conseguirse ésta mediante el software, pero debido a las fuertes
restricciones de capacidad de memoria el CLDC Expert Group decidió no
implementarlo en el estándar. De esta forma, toda clase y método de usuario debe
cumplir las siguientes reglas:
1. Ningún campo puede tener los tipos float, double, array, o array de arrays de
estos tipos.
2. Ningún método puede tener como argumento o como tipo devuelto float,
double, array, o array de arrays de estos tipos.
22
Francisco Prieto Donate
2. J2ME
3. Ninguna constante puede ser de tipo float o double.
•
Inexistencia de Java Native Interface (JNI): La forma en que la máquina
virtual del CLDC invoca una funcionalidad nativa es dependiente del dispositivo.
El motivo por el que se ha eliminado esta funcionalidad es la falta de capacidad
de memoria y que el CLDC asume que el conjunto de funciones nativas es
cerrado por motivos de seguridad.
•
Inexistencia clases y programas diseñados por el usuario de carga de
aplicaciones: La propia máquina virtual diseñada por el CLDC tiene ya cargador
de clases que por motivos de seguridad no se puede sobrescribir o sustituir por
una solución de usuario.
•
Inexistencia de reflexión: No existen en la máquina virtual del CLDC
funcionalidades de reflexión que permitirían a las aplicaciones Java inspeccionar
el número y contenido de clases, objetos, métodos, campos, hilos y demás
características de ejecución en el interior de la máquina virtual. De esta forma no
será posible implementar Remote method invocation (RMI), serialización de
objetos, JVMDI (Debbugging Interface), JVMPI (Profiler Interface), etc.
•
Inexistencia de Grupos de hilos e hilos demonio: No se permite el uso de hilos
demonio ni de grupos de hilos. Los hilos solo podrán ser lanzados y parados uno
a uno.
•
Inexistencia de finalización: En las librerías del CLDC no aparece el método
java.lang.Object.finalize(), por lo que no hay soporte para finalización de
instancias de clases.
•
Limitaciones en la captura de errores: La máquina virtual del CLDC soporta el
lanzamiento y captura de excepciones. No obstante, existe una gran limitación en
el conjunto de clases de errores permitidas respecto de las que se dan en J2SE.
Esto es debido a dos aspectos: por un lado que los propios dispositivos
reaccionan de forma distinta a los errores (algunos sencillamente resetean
mientras que otros intentan recuperarse), por otro lado la implementación de la
gran riqueza de lanzamientos y capturas de errores que se da en J2SE es
extremadamente costoso en términos de memoria, lo que supondría la necesidad
de una gran cantidad de espacio.
Francisco Prieto Donate
23
Transmisión de Imágenes de Vídeo mediante Servicios Web XML sobre J2ME
2.6.4 Verificación de ficheros de clase
Al igual que la máquina virtual de J2SE, la máquina que implementa el CLDC
debe ser capaz de detectar ficheros de clases no válidas. No obstante, como las
necesidades de memoria serían excesivas si implementásemos la solución que aporta
J2SE, se ha desarrollado una solución alternativa.
El espacio en memoria que se necesitaría si usásemos la solución aportada por
J2SE sería de un mínimo de 50 KB sólo para el verificador de clases y al menos de 20 a
100 KB de memoria RAM para ejecución. La potencia de cálculo de la CPU debería ser
además bastante alta. En cambio, la solución aportada por CLDC solamente toma 12
KB para la verificación y al menos 100 Bytes de memoria RAM para ejecución.
El nuevo verificador pensado para CLDC solamente realiza un escaneo lineal de
bytecodes y se fundamenta en dos fases:
•
Una primera fase en la que los ficheros de clases se hacen pasar por una
herramienta de preverificación con el fin de completar dichos ficheros con
información adicional que permita realizar la verificación a mayor velocidad y
con menor carga de trabajo. Este proceso se realiza en la estación de trabajo en la
que se esté diseñando la aplicación mediante emuladores de dispositivo.
•
La segunda fase se da en ejecución, momento en el que el verificador en tiempo
de ejecución de la máquina virtual utiliza la información adicional que el
preverificador añadió para verificar por completo los ficheros de clase.
Figura 2.6: Verificación de clases
24
Francisco Prieto Donate
2. J2ME
La interpretación de los bytecodes del fichero de clases podrá comenzar
únicamente cuando el fichero de clases haya pasado correctamente la verificación.
Puesto que el preverificador añade a los ficheros de clases una serie de atributos
adicionales podría pensarse que dichos ficheros, tras sufrir el proceso de
preverificación, dejarían de ser compatibles con el verificador del estándar J2SE. Esto
no es lo que ocurre en realidad, ya que el verificador J2SE ignora automáticamente
dichos atributos añadidos, manteniéndose por tanto la compatibilidad con el estándar.
2.6.5 Librerías de CLDC
Tanto J2SE como J2EE cuentan con unas librerías de funciones muy ricas con
funcionalidades que sacan todo el provecho de las estaciones de trabajo sobre las que se
montan. Desafortunadamente en J2ME no ocurre lo mismo debido al escaso espacio de
almacenamiento con el que cuentan los dispositivos.
Las librerías que se han desarrollado para J2ME cuentan con un número mínimo
de funciones, pero debido al gran número de dispositivos existentes en el mercado es
totalmente imposible contar con librerías que cubran todas las necesidades de todos los
dispositivos en tan reducido espacio de almacenamiento. Aún así se han conseguido una
serie de funcionalidades bastante útiles para todos ellos.
Con el fin de asegurar compatibilidad entre las librerías de J2ME y de sus
homólogos J2SE y J2EE, la mayoría de las librerías del CLDC son un subconjunto de
las que se dan en J2SE y J2EE. Las librerías definidas en el CLDC se pueden dividir en
dos categorías:
•
Clases derivadas del J2SE
Estas clases son un subconjunto de las existentes en las librerías del J2SE, todas
tienen el mismo nombre que se les daba en J2SE y pertenecen a paquetes del mismo
nombre que en el J2SE. Los paquetes en los que se encuentran son java.lang, java.util,
java.io:
1. Clases de sistema
java.lang.Object
java.lang.Class
java.lang.Runtime
java.lang.System
java.lang.Thread
Francisco Prieto Donate
25
Transmisión de Imágenes de Vídeo mediante Servicios Web XML sobre J2ME
java.lang.Runnable
java.lang.String
java.lang.StringBuffer
java.lang.Throwable
2. Clases de tipos de datos
java.lang.Boolean
java.lang.Byte
java.lang.Short
java.lang.Integer
java.lang.Long
java.lang.Character
3. Clases de Colecciones de objetos
java.util.Vector
java.util.Stack
java.util.Hashtable
java.util.Enumeration
4. Clases de Entrada/Salida
java.io.InputStream
java.io.OutputStream
java.io.ByteArrayInputStream
java.io.ByteArrayOutputStream
java.io.DataInput
java.io.DataOutput
java.io.DataInputStream
java.io.DataOutputStream
java.io.Reader
java.io.Writer
java.ioInputStreamReader
java.ioOutputStreamReader
java.ioPrintStream
5. Clases de Temporización y Calendario
java.util.Calendar
java.util.Date
java.util.TimeZone
6. Clases de Adicionales
26
Francisco Prieto Donate
2. J2ME
java.util.Random
java.util.Math
7. Clases de Errores
java.lang.Error
java.lang.VirtualMachineError
java.lang.OutOfMemoryError
8. Clases de Excepciones
java.lang.Exception
java.lang.ClassNotFoundException
java.lang.IlegalAccesException
java.lang.InstantiationException
java.lang.InterruptedException
java.lang.RuntimeException
java.lang.ArithmeticException
java.lang.ArrayStoreException
java.lang.ClassCastException
java.lang.IlegalArgumentException
java.lang.IlegalThreadStateException
java.lang.NumberFOrmatException
java.lang.IlegalMonitorStateException
java.lang.IndexOutOfBoundsException
java.lang.ArrayIndexOutOfBoundsException
java.lang.StringIndexOutOfBoundsException
java.lang.NegativeArraySizeException
java.lang.NullPointerException
java.lang.SecurityException
java.util.EmptyStackException
java.util.NoSuchElementException
java.io.EOFException
java.io.IOException
java.io.InterruptedIOException
java.io.UnsupportedEncodingException
java.io.UTFDataFormatException
•
Clases específicas del CLDC
Las clases específicas del CLDC tienen como objetivo permitir una serie de
funcionalidades que el dispositivo puede realizar y que las clases anteriores no
implementan. Estas clases se encuentran en el paquete javax.microedition.
El conjunto de librerías que existen en J2SE y J2EE enfocadas a dar
funcionalidades de entrada y salida de datos desde y hacia redes es extremadamente
rico: tan solo el paquete java.io de J2SE cuenta con 60 clases e interfaces y más de 15
Francisco Prieto Donate
27
Transmisión de Imágenes de Vídeo mediante Servicios Web XML sobre J2ME
excepciones, y el paquete java.net cuenta con unas 20 clases y unas 10 excepciones.
Para almacenar todas estas clases se necesitan aproximadamente 200 KB, cantidad de
memoria imposible de alcanzar en un dispositivo móvil. Debido a ello no es posible
reaprovechar dichas librerías y por tanto hay que diseñar todo un conjunto de librerías
propias del J2ME que aporten estas características. Teniendo en cuenta que no todas las
funcionalidades de red son aplicables a los dispositivos móviles y que los fabricantes no
hacen uso del amplio rango de posibles comunicaciones en red existentes (en la mayoría
de los casos estos dispositivos no cuentan con soporte TCP/IP o incluso se restringen a
ciertos protocolos como IrDA o Bluetooth), el problema se simplifica enormemente.
De esta forma, en el CLDC de J2ME se rediseñaron las clases para entrada/salida
y para el soporte a conexiones de red de J2SE, definiendo lo que se denomina CLDC
Generic Connection Framework. El CLDC Generic Connection Framework define una
serie de interfaces para dar soporte a la variedad de tipos de conexiones que nos
podemos encontrar en dispositivos móviles, pero no implementa ninguna de ellas, sino
que es en los perfiles donde se debe realizar esta implementación.
Objeto javax.microedition.io.Connector
En este objeto reside una interfaz en la que J2ME encapsula las conexiones a red.
Dependiendo del dispositivo y de la red a la que se conecta será necesario un protocolo
u otro. En este objeto el Generic Connection Framework puede encapsular cualquiera de
las posibles conexiones que se puedan dar. Indistintamente del tipo que sea, el Generic
Connection Framework se encarga de asegurar compatibilidad.
El Generic Connection Framework es implementado según una jerarquía de
interfaces de conexión encapsuladas en el objeto Connection, que suman en total seis
tipos: una entrada serie, una salida serie, una conexión orientada a datagrama, una
conexión orientada a circuito, un mecanismo de notificación de conexiones y una
conexión a un servidor Web:
Figura 2.7: Jerarquía de la interfaz de conexión
28
Francisco Prieto Donate
2. J2ME
Métodos
Sobre el objeto Connector existen una serie de métodos con los cuales es posible
hacer uso de las distintas funcionalidades de comunicación que permite J2ME.
Con el método public void open(“<protocol> : <address> ; <parameters>”) es
posible abrir y establecer una comunicación. Cuenta con la ventaja de permitir varios
protocolos de comunicación, no solo los protocolos que ya se están utilizando, sino que
está preparado para adaptarse a los nuevos posibles protocolos que puedan llegar en el
futuro. Así algunos ejemplos son:
HTTP
Connector.open(“http://www.sun.com”);
Sockets
Connector.open(“socket://129.144.111.222:2800”);
Comunicación por puertos
Connector.open(“comm:0;baudrate=9600”);
Datagramas
Connector.open(“datagram://129.144.111.222:2800”);
Ficheros
Connector.open(“file:/foo.dat”);
Las principales interfaces, con sus métodos correspondientes, son:
Interfaz Connection
public void close() throws IOException
Interfaz InputConnection
public InputStream openInputStream() throws IOException
public DataInputStream openDataInputStream() throws IOException
Interfaz OutputConnection
public OutputStream openOutputStream() throws IOException
public DataOutputStream openDataOutputStream() throws IOException
Interfaz Connection
public String getType()
public String getEncoding()
public long getLength()
Interfaz StreamConnectionNotifier
public StreamConnection acceptAndOpen() throws IOException
Interfaz DatagramConnection
public int getMaximumLength() throws IOException
public int getNominalLength() throws IOException
public void send(Datagram datagram) throws IOException
public void receive(Datagram datagram) throws IOException
public Datagram newDatagram(int size) throws IOException
Francisco Prieto Donate
29
Transmisión de Imágenes de Vídeo mediante Servicios Web XML sobre J2ME
public Datagram
IOException
public Datagram
IOException
public Datagram
addr) throws
newDatagram(int size, String addr) throws
newDatagram(byte[] buf, int size) throws
newDatagram(byte[] buf, int size, String
IOException
2.6.6 CLDC 1.1
CLDC 1.1 es una revisión de la especificación CLDC 1.0 e incluye nuevas
características como son punto flotante o soporte a referencias débiles, junto con otras
mejoras. CLDC 1.1, especificado en la norma JSR-139, es compatible con versiones
anteriores y sigue soportando dispositivos pequeños o con recursos limitados.
A continuación se detallan las mejoras que introduce CLDC 1.1:
30
•
Se añade soporte para operaciones en punto flotante, permitiendo el uso de todos
los bytecodes asociados al mismo.
•
Se añaden las clases Float y Double.
•
Se añaden métodos a otras librerías para la gestión de operaciones en punto
flotante.
•
Se añade soporte para referencias débiles.
•
Se han rediseñado las clases Calendar, Date y TimeZone para adecuarse mejor a
J2SE.
•
La gestión de errores se ha mejorado y se ha añadido una nueva clase de error,
NoClassDefFoundError.
•
Los objetos Thread tienen nombre con los subprocesos en J2SE. Se ha
introducido el método Thread.getName() y la clase Threadclass incorpora nuevos
constructores heredados de J2SE.
•
Se han cambiado bibliotecas y se han corregido algunos defectos, entre los que se
incluyen los siguientes métodos y campos:
Francisco Prieto Donate
2. J2ME
Boolean.TRUE y Boolean.FALSE
Date.toString()
Random.nextInt(int n)
String.intern()
String.equalsIgnoreCase()
Thread.interrupt()
•
Se ha elevado el mínimo de memoria necesaria de 160 a 192 KB, debido
principalmente a la adición de funcionalidad de punto flotante.
•
Se ha mejorado y actualizado la especificación.
•
Se ha detallado la especificación del verificador de bytecode para CLDC (CLDC
Byte Code Typechecker Specification).
2.7 MIDP
Profile)
(Mobile
Information
Device
El estándar MIDP es una arquitectura y un conjunto de librerías que aportan un
entorno de desarrollo de aplicaciones abiertas Third-Party para dispositivos móviles de
información (MIDs). Ejemplos típicos de dispositivos MIDP son teléfonos móviles,
PDAs con conexión inalámbrica, etc.
Actualmente existen dos versiones de este Perfil: la especificación MIDP 1.0 y la
versión revisada MIDP 2.0. En adelante cuando hablemos de MIDP nos estaremos
refiriendo a la primera versión. Posteriormente veremos las mejoras que aporta la
especificación MIDP 2.0.
El conjunto mínimo de requisitos que debe cumplir cualquier dispositivo sobre el
que se quiera implementar MIDP es el siguiente:
Francisco Prieto Donate
31
Transmisión de Imágenes de Vídeo mediante Servicios Web XML sobre J2ME
•
Memoria: 128 KB de memoria no volátil para los componentes MIDP, 8 KB de
memoria no volátil para datos de aplicaciones almacenados de forma persistente
y 32 KB de memoria volátil para la ejecución de la máquina virtual.
•
Pantalla: Tamaño de pantalla: 96 x 54 píxeles, profundidad de display de 1 bit y
relación de aspecto 1:1.
•
Interfaz de entrada: Al menos uno de los siguientes mecanismos: teclado a una
mano, teclado a dos manos, pantalla táctil.
•
Red: Conexión bidireccional, inalámbrica, posiblemente intermitente y con
ancho de banda limitado.
2.7.1 MIDP Expert Group
La MIDP Specification fue producida por el MIDPEG (Mobile Information
Device Profile Expert Group) como parte del Java Community Process (JCP) en la
norma de estandarización JSR-37. Este grupo está formado por un conjunto de
empresas:
•
•
•
•
•
•
•
•
•
•
•
America Online
DDI
Ericsson
Espiral Group
Fujitsu
Hitachi
J-Phone
Matsushita
Mitsubishi
Motorola
NEC
•
•
•
•
•
•
•
•
•
•
•
Nokia
NTT DoCoMo
Palm Computing
Research In Motion
Samsung
Sharp
Siemens
Sony
Sun Microsystems
Symbian
Telecordia Technologies
El MIDP ha sido diseñado para extender las funcionalidades del CLDC. De esta
forma la especificación MIDP define una serie de APIs que añaden un conjunto mínimo
de funciones comunes a los distintos tipos de dispositivos MIDP:
•
32
Soporte de interfaz de usuario: LCDUI (Limited Connected Device User
Interface)
Francisco Prieto Donate
2. J2ME
•
Soporte de red, basado en el protocolo HTTP y en el Generic Connection
Framework introducido por el CLDC
•
Soporte de almacenamiento persistente de datos: RMS (Record Management
System)
•
Una serie de clases adicionales de interesante utilidad como temporizadores y
excepciones.
2.7.2 Modelo de Aplicación de MIDP
Debido a las fuertes restricciones de memoria con las que se enfrenta y a los
requisitos exigidos por el estándar, MIDP no soporta el modelo de Applet introducido
en el J2SE, sino que utiliza un nuevo modelo de aplicación gráfica que permite
compartir e intercambiar datos entre aplicaciones, así como un funcionamiento
concurrente sobre la KVM.
En el MIDP la unidad mínima de ejecución es el MIDlet, el cual no es más que
una clase que extiende a la clase javax.microedition.MIDlet.
A continuación se muestra la implementación del MIDlet más sencillo posible, el
clásico “Hola Mundo”:
import javax.microedition.midlet.*;
import javax.microedition.lcdui.*;
public class HolaMundo extends MIDlet implements CommandListener{
private TextBox tb;
private Command Salir;
public HolaMundo(){
tb = new TextBox("Hola MIDlet", "Hola Mundo!", 15, 0);
Salir = new Command ("Salir", Command.EXIT, 1);
tb.addCommand(Salir);
tb.setCommandListener(this);
}
protected void startApp(){
Display.getDisplay(this).setCurrent(tb);
}
protected void pauseApp(){}
protected void destroyApp(boolean u){}
public void commandAction(Command c, Displayable s){
if(c == Salir){
Francisco Prieto Donate
33
Transmisión de Imágenes de Vídeo mediante Servicios Web XML sobre J2ME
destroyApp(false);
notifyDestroyed();
}
}
}
La salida de este sencillo código ejemplo se muestra en la figura:
Figura 2.8: Salida del MIDlet Hola Mundo
El estado en el cual se encuentra el MIDlet en esta figura es tal que el método
startApp acaba de terminar su ejecución. Si en este momento pulsásemos el botón
superior izquierdo del teclado del móvil se invocaría al método commandAction y éste,
al detectar el comando ejecutado, llamaría al método destroyApp y al método
notifyDestroyed.
En este ejemplo se encuentran un conjunto de elementos típicos de todos los
MIDlets:
34
•
En primer lugar la clase
javax.microedition.midlet.MIDlet.
•
En segundo lugar, la clase HolaMundo cuenta con un constructor que en el
modelo de aplicación del MIDP se ejecuta una sola vez, exactamente al instanciar
el MIDlet. Por lo tanto, todas aquellas operaciones que queramos que se realicen
al lanzar el MIDlet por primera vez se deben encontrar en este constructor.
HolaMundo
extiende
a
la
clase
Francisco Prieto Donate
2. J2ME
•
La clase javax.microedition.midlet.MIDlet define tres métodos abstractos que
deben ser sobrescritos en todos los MIDlets, estos métodos son: startApp,
pauseApp y destroyApp.
El método startApp es ejecutado al arrancar y rearrancar el MIDlet. Su función es
la de adquirir (al arrancar por primera vez) o readquirir (al reanudar tras una pausa) una
serie recursos necesarios para la ejecución. Este método puede ser llamado más de una
vez, bien sea al arrancar el MIDlet por primera vez o cada vez que se quiera reanudar al
MIDlet tras una pausa.
El método pauseApp es llamado por el sistema con el fin de parar
momentáneamente al MIDlet, liberando así durante la pausa una serie de recursos que
puedan ser usados en ese tiempo por otros MIDlets.
Por último, el método destroyApp es llamado por el sistema cuando el MIDlet está
a punto de ser destruido. También puede ser llamado indirectamente por el propio
MIDlet mediante el método notifyDestoyed. Este método juega un papel muy
importante, ya que es el encargado de liberar definitivamente todos aquellos recursos
que el MIDlet ha tomado y ya no necesitará después de ser destruido.
Debido a la existencia de estos tres métodos, un MIDlet puede pasar por una serie
de estados diferentes a lo largo de su ejecución, dándose en cada estado una serie de
procesos sobre dicho MIDlet y pasando de un estado a otro mediante cada uno de estos
métodos. Gráficamente es sencillo entender estas transiciones:
Figura 2.9: Estados y transiciones de un MIDlet
Francisco Prieto Donate
35
Transmisión de Imágenes de Vídeo mediante Servicios Web XML sobre J2ME
Como podemos ver en la figura, un MIDlet puede encontrarse en tres posibles
estados:
•
Parado: Un MIDlet se encuentra en estado parado cuando está a punto de ser
arrancado pero aún no ha sido ejecutado el método startApp, o también como
resultado de pauseApp o notifyPaused. En este estado el MIDlet debería ya haber
acaparado tantos recursos como le sean necesarios. Además en este estado
pueden también recibirse notificaciones asíncronas.
•
Activo: Un MIDlet entra en estado activo mediante el método startApp o bien
desde el estado parado mediante la ejecución del método resumeRequest. En este
estado el MIDlet puede acaparar y emplear todos aquellos recursos que necesite
para realizar una ejecución óptima.
•
Destruido: El MIDlet se encuentra en estado destruido cuando vuelve de los
métodos destroyApp o notifyDestroyed. Tras llegar a este punto, el MIDlet no
puede pasar a ningún otro estado.
Para pasar de un estado a otro existen una serie de métodos que hacen posibles las
distintas transiciones del MIDlet. Ya hemos comentado los métodos startApp, pauseApp
y destroyApp, que son llamados por el sistema de forma automática. Existen también
una serie de métodos que realizan estas transiciones y que en su caso son utilizados por
el programador de la aplicación con la intención de forzar dichas transiciones cuando
sea conveniente. Estos métodos son:
36
•
resumeRequest: Este método puede ser llamado por un MIDlet parado para
indicar su intención de volver a estar activo. Un ejemplo típico es el caso del
cumplimiento de un temporizador el cual necesite reanudar la aplicación para