Este documento presenta un resumen de 3 oraciones de un trabajo de grado sobre la 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 trabajo describe la especificación y características de J2ME, los servicios web, y detalla la implementación del sistema usando herramientas de emulación.

1. UNIVERSIDAD DE PAMPLONA
FACULTAD DE INGENIERIAS Y ARQUITECTURA
DEPARTAMENTO DE INGENIERIAS ELECTRICA ELECTRÓNICA
SISTEMAS Y TELECOMUNICACIONES
PROGRAMA DE INGENIERIA DE SÍSTEMAS.
TRABAJO PRESENTADO PARA OPTAR POR EL TITULO DE
INGENIERO DE SÍSTEMAS
TEMA
IMPLEMENTACIÓN DE UN SISTEMA PARA LA ADMINISTRACIÓN DE
SERVICIOS WEB EN TELEFONÍA MÓVIL A TRAVÉS DE LA
PLATAFORMA J2ME
AUTOR: ANDRÉS ARLEY RINCÓN PACHECO
DIRECTOR: Msc. ING. LUZ MARINA SANTOS JAIMES
PAMPLONA - COLOMBIA
SEPTIEMBRE 2008
1

2. UNIVERSIDAD DE PAMPLONA
FACULTAD DE INGENIERIAS Y ARQUITECTURA
DEPARTAMENTO DE INGENIERIAS ELECTRICA ELECTRÓNICA SISTEMAS Y
TELECOMUNICACIONES
PROGRAMA DE INGENIERIA DE SÍSTEMAS
TRABAJO PRESENTADO PARA OPTAR POR EL TITULO DE
INGENIERO DE SÍSTEMAS
TITULO
IMPLEMENTACIÓN DE UN SISTEMA PARA LA ADMINISTRACIÓN DE
SERVICIOS WEB EN TELEFONÍA MÓVIL A TRAVÉS DE LA PLATAFORMA J2ME
FECHA DE INICIO DEL TRABAJO: MARZO 2008
FECHA DE TERMINACIÓN DEL TRABAJO: SEPTIEMBRE 2008
NOMBRES Y FIRMAS DE AUTORIZACIÓN:
__________________________________ ______________________________
ANDRÉS ARLEY RINCÓN PACHECO Msc. Ing. LUZ MARINA SANTOS J.
Autor Trabajo de Grado Director Trabajo de Grado
_________________________________
Msc. Ing. CARLOS ARTURO PARRA
Director de Programa
JURADO CALIFICADOR:
__________________________________ _____________________________
Esp. Ing. SERGIO PEÑALOZA ROJAS Ing. LAWRENCE FATULE
Presidente Oponente
_________________________________
Ing. DEWAR RICO
Secretario
PAMPLONA - COLOMBIA
SEPTIEMBRE 2008
2

3. UNIVERSIDAD DE PAMPLONA
FACULTAD DE INGENIERIAS Y ARQUITECTURA
DEPARTAMENTO DE INGENIERIAS ELECTRICA ELECTRÓNICA SISTEMAS Y
TELECOMUNICACIONES
PROGRAMA DE INGENIERIA DE SÍSTEMAS
ACTA DE CALIFICACIÓN DE TRABAJO DE GRADO
EL JURADO CALIFICADOR CONFORMADO POR: (Nombres y apellidos)
PRESIDENTE:_________________________________________________
VOCAL: ________________________________________________
SECRETARIO:_________________________________________________
EN SU SESIÓN EFECTUADA EN ___________________________________________ A
LAS _____ HORAS, DEL DIA____DEL MES _____DEL AÑO________
TERMINADAS SUS DELIBERACIONES HA LLEGADO A LAS SIGUIENTES
CONCLUSIONES:
PRIMERA CONCLUSIÓN:
En correspondencia con el artículo 35 parágrafo segundo del reglamento estudiantil,
emitido en el acuerdo No. 186 del 02 de diciembre del año 2005, del Concejo
Académico Superior de La Universidad de Pamplona.
OTORGAR LA CALIFICACION DE:
EXCELENTE APROBADO INCOMPLETO
FIRMAR EN LA CALIFICACION
AL TRABAJO DE GRADO
TITULADO:________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
DEL
AUTOR:___________________________________________________________________
DIRECTOR:________________________________________________________________
3

4. SEGUNDA CONCLUSION:
RECOMENDAR:
No. DESCRIPCION ACEPTABLE
SI NO
1. Recomendar para presentar en eventos científicos.
2. Recomendar para publicación.
3. Incluir en el fondo bibliográfico de la Universidad de Pamplona.
4. Recomendar para ser continuado en otros trabajos.
5. Recomendar para patente.
6. Recomendar continuar como trabajo de maestría.
7. Recomendar para meritorio.
8. Recomendar para laureado.
9. Recomendar continuar como trabajo de doctorado.
10. Otras.
Otras:
___________________________________________________________________
TERCERA CONCLUSIÓN: OTORGAR
EL TITULO DE INGENIERO
___________________________________________________________________
Firmas del jurado:
______________________________ __________________________ __________________________
PRESIDENTE OPONENTE SECRETARIO
4

5. DEDICATORIA
Dedico este trabajo a Dios que con su voluntad divina
y su compañía me ha dado la fuerza para seguir
adelante. A mis padres: Araminta Pacheco y
Aliro José Rincón; a mis hermanos Audry y
Francisco Rincón; por su apoyo incondicional en este
largo y duro camino para conquistar el sueño de ser
profesional.
5

6. PENSAMIENTO
El éxito del perseverante es alcanzar sus metas sin sacrificar
sus principios.
Roberto Palomo Cea.
El hombre juzga su éxito por lo que tiene y no por lo que ha
dejado de tener.
Esteban Edwards.
6

7. AGRADECIMIENTOS
A Dios por darme la sabiduría y voluntad para seguir
adelante a pesar de las adversidades. A mis padres por su
confianza, su entrega y apoyo depositado en mí para cumplir
este sueño.
A la Msc. Ing. Luz Marina Santos Jaimes, directora
de tesis por su apoyo y colaboración en la ejecución del trabajo.
A mis amigos y amigas gracias por su apoyo y compañía
en esta gran etapa de mi vida.
7

8. RESUMEN
Con la ejecución de este proyecto se desea implementar un sistema que permita el
acceso de Servicios Web en telefonía móvil a través de la plataforma J2ME,
evaluando las características de la plataforma J2ME, las tecnologías involucradas en
el desarrollo de Servicios Web y las APIs necesarias para llevar a cabo la
implementación del sistema.
En el Capitulo I se hace un estudio de las características relevantes de la plataforma
J2ME.
El Capitulo II es una introducción a las generalidades de los Servicios Web en
cuanto a las tecnologías y formas de implementación usadas.
El Capitulo III evalúa a fondo la ESPECIFICACIÓN DE SERVICIOS WEB DE J2ME,
la cual permite la implementación de aplicaciones en telefonía móvil para tener
acceso a Servicios Web ubicados de forma remota.
El Capitulo IV describe la IMPLEMENTACION DEL SISTEMA DE ADMINISTRACION
DE SERVICIOS WEB EN TELEFONIA MOVIL A TRAVES DE LA PLATAFORMA
J2ME, enfoque principal que se le ha dado a la ejecución del PTG.
Por último se realizaron investigaciones minuciosas acerca del estado del arte
referente a la implementación de aplicaciones clientes que tengan acceso a
Servicios Web en telefonía móvil a nivel nacional e internacional.
8

9. ABSTRACT
With the execution of this project it is wanted to implement a system allowing access
of Web Services in mobile telephony across the platform J2ME, evaluating the
characteristics of the J2ME platform, technologies involved in the development of
Web Services and APIs necessary to carry out the implementation of the system.
In Chapter I made a study of relevant features of the platform J2ME.
Chapter II is an introduction to the generalities of the Web Services on technologies
and ways of implementation used.
Chapter III assesses thoroughly the SPECIFICITY OF J2ME WEB SERVICES, which
enables the implementation of applications for mobile access Web Services of
remotely located.
Chapter IV describes the SYSTEM IMPLEMENTATION MANAGEMENT WEB
SERVICES IN MOBILE PHONE OVER THE J2ME PLATFORM, main approach to it
has given to the implementation of PTG.
Lastly were conducted thorough investigations about the state of the art concerning
the implementation of applications customers have access to Web Services mobile
nationally and internationally.
9

10. INDICE GENERAL
PAG
DEDICATORIA
PENSAMIENTO
AGRADECIMIENTO
RESUMEN
ABSTRACT
INDICE DE FIGURAS 14
INDICE DE TABLAS 15
INTRODUCCION 16
JUSTIFICACION 18
NECESIDADES Y PROBLEMAS 19
DELIMITACIÓN 20
CAPITULO I. GENERALIDADES DE J2ME. 21
1.1. INTRODUCCIÓN. 21
1.2. ANALISIS COMPARATIVO. 22
1.3. CARACTERISTICAS DE J2ME. 25
1.4. ARQUITECTURA DE J2ME. 26
1.4.1. Máquina Virtuales. 27
1.4.2. Configuraciones. 32
1.4.3. Perfiles. 36
1.4.4. Paquetes Opcionales. 41
CAPITULO II. SERVICIOS WEB. 45
2.1. INTRODUCCIÓN. 45
2.2. GENERALIDADES DE LOS SERVICIOS WEB. 45
10

11. 2.2.1. Definición. 45
2.2.2. Características. 46
2.3. COMPONENTES DE SERVICIOS WEB. 48
2.3.1. Agentes y Servicios. 48
2.3.2. Cliente y Proveedor. 48
2.3.3. Descripción del Servicio. 49
2.3.4. Semánticas. 49
2.4. TECNOLOGÍAS ESTÁNDAR PARA SERVICIOS WEB. 49
2.5. ESCENARIOS DE SERVICIOS WEB. 51
CAPITULO III. ESPECIFICACIÓN DE SERVICIOS WEB EN J2ME. 53
3.1. INTRODUCCIÓN. 53
3.2. GENERALIDADES. 53
3.3. JSR 172: PAQUETES OPCIONALES. 54
3.3.1. API JAXP. 55
3.3.1.1. Requerimientos de Plataforma. 55
3.3.1.2. Requerimientos del API. 55
3.3.1.3. Paquetes del API JAXP. 55
3.3.1.4. Implementación de JAXP. 57
3.3.2. API JAX-RPC. 57
3.3.2.1. Requerimientos de Plataforma. 58
3.3.2.2. Requerimientos del API. 58
3.3.2.3. Paquetes del API JAX-RPC. 58
3.4. OTROS PAQUETES. 60
3.4.1. kXML. 60
3.4.1.1. Requerimientos del API. 61
3.4.1.2. Paquetes del API kXML. 61
3.4.2. kSOAP. 61
3.4.2.1. Requerimientos de Plataforma. 61
3.4.2.2. Requerimientos del API. 61
11

12. 3.4.2.3. Paquetes del API kSOAP. 61
CAPITULO IV. IMPLEMENTACIÓN DEL SISTEMA PARA LA ADMINISTRACIÓN
DE SERVICIOS WEB EN TELEFONIA MÓVIL A TRAVÉS DE LA
PLATAFORMA J2ME. 63
4.1. ESPECIFICACIONES GENERALES. 63
4.1.1. Patrón de Diseño MVC. 63
4.1.2. Diagramas de Casos de Usos. 64
4.1.2.1. Diagrama de Caso de Uso del Servicio
Artesanías de Colombia. 64
4.1.2.2. Diagrama de Caso de Uso del Servicio Cine. 65
4.1.3. Diagramas de Clases. 66
4.1.3.1. Diagrama de Clases del Servicio Artesanías de
Colombia. 66
4.1.3.2. Diagrama de Clases del Servicio Cine. 67
4.2. HERRAMIENTAS UTILIZADAS EN LA IMPLEMENTACION
DEL SISTEMA. 68
4.3. DETALLES DE LA IMPLEMENTACION. 69
4.4. EMULACIÓN DEL SISTEMA EN LA HERRAMIENTA J2ME
WIRELESS TOOLKIT 2.5.2. 70
4.4.1. Características de la herramienta. 70
4.5. EMULACIÓN DEL SISTEMA EN LA HERRAMIENTA NOKIA PROTOTYPE
SDK 4.0 FOR JAVA ™ ME. 74
4.5.1. Características de la herramienta. 74
4.6. EMULACIÓN DEL SISTEMA EN LA HERRAMIENTA SONY ERICSSON
SDK 2.5.0.2 FOR THE JAVA ™ ME PLATFORM. 77
4.6.1. Características de la herramienta. 77
12

13. CAPITULO V. MARCO HISTORICO DEL PROYECTO. 80
5.1. ESTADO DEL ARTE. 80
5.1.1. Fuentes Primarias – Trabajos Relacionados – Internacional. 81
5.1.2. Fuentes Primarias – Trabajos Relacionados – Nacional. 82
PRESUPUESTO ECONOMICO. 84
FUENTES DE FINANCIACIÓN. 87
MARCO LEGAL. 88
ANALISIS DE LA PROTECCIÓN E HIGIENE DEL TRABAJO. 90
INFLUENCIA AMBIENTAL DEL TRABAJO. 91
ARTICULO CIENTIFICO. 92
CONCLUSIONES. 99
OBSERVACIONES Y RECOMENDACIONES. 100
BIBLIOGRAFIA. 101
ANALISIS BIBLIOGRAFICO. 105
GLOSARIO DE TERMINOS. 106
ABREVIATURAS UTILIZADAS. 107
ANEXOS. 110
RESEÑA BIOGRAFICA DEL DIRECTOR. 119
13

14. INDICE DE FIGURAS
Fig. Pág
1. Arquitectura de la plataforma Java 2 de Sun. 24
2. Arquitectura de J2ME. 27
3. Pre-verificación de clases en J2ME. 30
4. Entorno de ejecución para J2ME. 37
5. Escenario de Servicios Web. 52
6. Componentes del patrón de diseño MVC. 64
7. Diagrama de Caso de Uso del Servicio Artesanías de Colombia. 65
8. Diagrama de Caso de Uso del Servicio Cine. 66
9. Diagrama de Clases del Servicio Artesanías de Colombia. 67
10. Diagrama de Clases del Servicio Cine. 68
11. Flujo de Ejecución de la Aplicación para Artesanías de Colombia en
J2ME Wireless Toolkit 2.5.2. 72
12. Flujo de Ejecución de la Aplicación para Cines de Colombia en J2ME
Wireless Toolkit 2.5.2. 73
13. Flujo de Ejecución de la Aplicación para Artesanías de Colombia
en Nokia Prototype SDK 4.0 for JAVA ™ ME. 75
14. Flujo de Ejecución de la Aplicación para Cines de Colombia en Nokia
Prototype SDK 4.0 for JAVA ™ ME. 76
15. Flujo de Ejecución de la Aplicación para Artesanías de Colombia Sony
Ericsson SDK 2.5.0.2 for the JAVA ™ ME. 78
16. Flujo de Ejecución de la Aplicación para Cines de Colombia Sony Ericsson
SDK 2.5.0.2 for the JAVA ™ ME. 79
14

15. INDICE DE TABLAS
Tabla Pág.
1. Librerías de Configuración CDC. 34
2. Librerías de Configuración CLDC. 35
3. Librerías del Foundation Profile. 37
4. Librerías del Personal Profile. 38
5. Librerías del perfil MIDP. 41
6. Herramientas y Software usado para la implementación. 68
7. Medios Básicos. 85
8. Medios de Rotación. 85
9. Gastos en Personal. 86
15

16. 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 esta 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), 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 esta 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/u 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
16

17. 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.
El trabajo de grado se realiza en la Modalidad de Investigación con el fin de referir
características fundamentales y básicas de la plataforma J2ME debido al poco
conocimiento en la Universidad de Pamplona.
17

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

19. 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 esta 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.
19

20. DELIMITACIÓN
 OBJETIVO GENERAL
Implementar un sistema prototipo para la administración de Servicios Web en
telefonía móvil sobre la plataforma J2ME de Java.
 OBJETIVOS ESPECIFICOS
Realizar un análisis bibliográfico sobre las características resaltantes de la
plataforma J2ME.
Estudiar las APIs necesarias que permitan el desarrollo del sistema.
Reconocer el estado del arte sobre la implementación de Servicios Web en
teléfonos móviles a través de J2ME.
Desarrollar el sistema para la administración de Servicios Web en telefonía
móvil con las herramientas y APIs necesarias.
Llevar a cabo la simulación del sistema para la administración de Servicios
Web a través de emuladores de diversos teléfonos móviles.
Redactar un artículo referente a la implementación de Servicios Web en
teléfonos móviles a través de J2ME.
20

21. MARCO TEÓRICO
I. 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 esta 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:
21

22. 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:
 Maquinas 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 cambio
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
22

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

24. La Figura 1 muestra las diferentes ediciones de la Plataforma Java 2 y sus mercados
objetivos.
Figura 1. Arquitectura de la plataforma Java 2 de Sun.
J2ME es dividido en dos categorías que se enfocan en consumidores sofisticados y
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 de 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.
24

25. 1.3. 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 ofrecen 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.
25

26.  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 Limitados). 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 especificas 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 Limitados con
Conexión, 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.4. ARQUITECTURA DE J2ME.
La arquitectura J2ME está proyectada para ser modular y escalable, además que
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.
26

27. 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.
Paquete(s) Opcional(es)
Perfil(es)
Librerías
Configuración { JVM
Sistema Operativo
Figura 2. Arquitectura de J2ME.
1.4.1. Máquinas Virtuales.
La Maquina 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 este 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
27

28. operativo del dispositivo, lo cual la convierte en interoperable.
A diferencia de las ediciones de Java J2SE y J2EE, J2ME utiliza una maquina
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.
28

29. 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, posee 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
29

30. 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 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.
Fase No. 1 Fase No. 2
Dispositivo Cliente
Estación de Trabajo
KVM
Aplicación.java
Descarga
Verificador
javac
Aplicación.class Interprete
Pre-verificador
Aplicación.class
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
maquina virtual usa los atributos adicionales StackMap generados por el pre-
30

31. verificador 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
Maquina 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:
2. Sistema de memoria avanzado
3. Tiempo de espera bajo para el recolector de basura
4. Separación de la funcionalidad de la Máquina Virtual del sistema de
memoria.
5. Consta de un Recolector de Basura modularizado.
6. Portabilidad.
7. Sincronización rápida.
8. Ejecución de clases a través de la implementación de la memoria
de solo lectura ROM.
9. Soporte nativo de hilos.
10. Las clases tienen baja ocupación de la memoria.
11. Tiene soporte para interfaces y servicios en Sistemas Operativos de
Tiempo Real.
12. Conversión de hilos Java a hilos nativos.
13. Soporte para JNI, referencias débiles, RMI (Invocación de Métodos
31

32. Remotos), Interfaz de Depuración de la Máquina Virtual (JVMDI).
14. Serialización de Objetos.
15. 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:
32

33.  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 la
siguiente lista 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 esta dada debido al uso que se
hace de la KVM, necesaria al trabajar con CLDC.
33

34. 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:
34

35. 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 estandar.
javax.microedition.io Clases de conexión generica para CLDC.
Tabla 2. Librerías de Configuración CLDC.
De acuerdo a la tabla anterior, la Configuración CLDC las siguientes
áreas:
 Lenguaje Java y características de la máquina virtual.
35

36.  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 esta
constituido bajo las bases de una configuración dotando a esta ultima 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.
36

37. Aplicación
RMI Profile Personal Profile
PDA Profile MID Profile
Foundation Profile
CDC CLDC
CVM KVM
Sistema Operativo
Dispositivos Hardware
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
necesario la implementación de otro perfil adicional. Las librerías
usadas por el Foundation Profile se muestran en la Tabla 3.
Paquetes Descripción
java.io Clases de Lectura y Escritura de J2SE.
java.lang Soporte del lenguaje Java.
java.util Soporte para zip y otras funcionalidades
(Timer).
37

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

39. 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 esta
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.
39

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

41. 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 usada 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
41

42. 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 inalambricos, 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 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,
42

43. 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: especifica que permiten
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.
43

44.  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.
44

45. II. SERVICIOS WEB.
2.1. INTRODUCCIÓN.
La Arquitectura Orientada a Servicios (SOA) ha permitido habilitar el entorno
distribuido para que la gran mayoría de las aplicaciones basadas en componentes
puedan operar entre sí, brindando heterogeneidad al famoso mundo de las
aplicaciones distribuidas. Esta arquitectura da una visión de que “el software debe
ser entregado como un servicio” [3], orientando al mercado del software hacia un
entorno más competitivo con soporte para los negocios. Esto a su vez permite de
forma dinámica la creación e implantación de nuevos servicios basados en los
servicios ya existentes.
Es de resaltar el gran soporte que dan los diferentes protocolos y tecnologías de la
Web a SOA. Los servicios definen de manera explícita el modo de funcionamiento y
sus requisitos funcionales y no funcionales a través del uso de formatos definidos y
convenidos por los protocolos que soportan a SOA, permitiendo de esta manera el
descubrimiento, registro y selección automática de servicios. Se puede observar la
implementación de SOA en aplicaciones como los Servicios Web, ya que ellos
definen una aplicación identificada a través de un Identificador de Recursos
Uniformes (URI) basado en estándares de Internet que definen su descripción y
método de transporte.
2.2. GENERALIDADES DE LOS SERVICIOS WEB.
2.2.1. Definición.
Los servicios Web según una definición de la W3C son “una aplicación
software identificada por una URI, cuyas interfaces y vinculaciones son
capaces de ser definidas, descritas y descubiertas como artefactos XML. Un
Servicio Web soporta la interacción con otros agentes software mediante el
intercambio de mensajes basado en XML a través de protocolos basados en
45

46. Internet” [3].
De una forma más general se puede decir que “los servicios Web son
aplicaciones modulares que se pueden describir, publicar, localizar e invocar
a través de la Web” [3]. Un servicio Web designa operaciones, a través de
las cuales se pueden realizar cualquier tipo de solicitud simple para cualquier
proceso de negocio. Una vez el servicio Web es desplegado, otras
aplicaciones u otros servicios Web pueden descubrir e invocar el servicio
Web desplegado.
Los Servicios Web también pueden ser considerados como una pieza
fundamental que describe la lógica del negocio, ubicado en algún lugar de
Internet, accesible a través de protocolos basados de Internet como HTTP.
Uno de los objetivos primordiales de los Servicios Web es el de “automatizar
procesos que de lo contrario sería llevado en forma manual” [3].
2.2.2. Características.
Una de las características más importantes de los servicios Web es que no
está ligado a una tecnología específica, se ejecuta en cualquier plataforma
dejando ver de lado su interoperabilidad. Entre las características más
resaltantes de este tipo de aplicación basada en la Arquitectura SOA se
tienen:
 Basados en XML: el Lenguaje de Marcado Extensible (XML)
edifica la representación estándar de datos para todos los
protocolos y tecnologías que implementan Servicios Web.
 Acoplamiento débil: el cliente no está atado al Servicio Web de
forma directa, es decir, el carácter de flexibilidad que ofrece el
entorno de ejecución del Servicio Web implica que cualquier
cambio que tenga este último no compromete de manera alguna
la capacidad de interacción del cliente con el Servicio Web.
 Granularidad: la tecnología de Servicios Web deja entrever la
46

47. individualidad con la que son manejados los métodos que
implementa el servicio. Estos métodos en su forma individual
proporcionan capacidades para ser usados en un nivel
corporativo.
 Capacidad de ser implementados de forma síncrona o
asíncrona: de forma síncrona se observa el enlace directo del
cliente con la ejecución del servicio. El cliente espera que el
servicio complete la operación para luego continuar. En la forma
asíncrona el cliente está en la capacidad de ejecutar una
operación e invocar un servicio de forma simultánea. La forma
asíncrona le da el carácter de acoplamiento débil a los Servicios
Web.
 Soporte para Llamado de Procedimientos Remotos (RPC):
los Servicios Web están en capacidad de permitir a los clientes
la invocación de procedimientos, funciones y métodos en
lugares remotos a través de XML. Esto se logra a través de la
implementación de componentes distribuidos como los EJBs
(Enterprise JavaBeans).
 Soporte para el intercambio de documentos: XML
proporciona una forma de representación de documentación
compleja, a través de diferentes protocolos.
 Auto-contenidos: particularmente en el lado del cliente no se
necesita ningún software adicional, solamente basta con recurrir
a soporte para XML y HTTP. En el lado del servidor es
necesario únicamente un servidor que soporte el manejo de
mensajes SOAP y protocolos como HTTP.
 Pueden ser publicados, localizados e invocados a través de
la Web: esto se hace con el uso de estándares ligeros como
HTTP, SOAP, WSDL y UDDI.
 Modulares: varios Servicios Web pueden ser integrados usando
47

48. técnicas de Flujo de Trabajo (Workflow). Esto permite la
realización de una cadena de Servicios Web que permitan la
ejecución de funciones de negocio de alto nivel.
 Independientes de lenguaje e interoperables: tanto las
aplicaciones del cliente y servidor para el uso y la ejecución de
Servicios Web pueden ser implementadas en diferentes
entornos. Básicamente cualquier lenguaje de programación
puede ser usado para implementar Servicios Web.
 Dinámicos: el dinamismo de este tipo de aplicaciones depende
en gran parte de la descripción y descubrimiento automático
con el uso de UDDI y WSDL.
2.3. COMPONENTES DE SERVICIOS WEB.
La implementación de servicios Web se rige bajo una serie de criterios e interfaces
con el fin de que pueda ser accedido por cualquier sistema conectado a la red, al
tener permiso para tal fin. Existen unas partes bien diferenciadas que se han de
tener en cuenta al momento de implementar y usar un Servicio Web, ya que definen
las interacciones que se pueden manejar en el entorno de ejecución de los Servicios
Web. Estos componentes son:
2.3.1. Agentes y Servicios.
El agente puede ser visto como un trozo de software que implementa la
funcionalidad que realiza el Servicio Web. Este agente se caracteriza por
tener la capacidad de enviar y recibir peticiones desde y hacia el Servicio
Web. Este agente puede ser descrito en cualquier lenguaje de
programación ejecutándose sobre una plataforma concreta.
2.3.2. Cliente y Proveedor.
La entidad proveedora es la persona u organización encargada que
48

49. desarrolla un agente bajo el cual se soporta el servicio. El cliente es la
persona u organización que desea hacer uso del servicio expuesto por el
proveedor a través de consultas. La interacción entre cliente y proveedor se
hace a través de comunicación tipo petición-respuesta entre agentes,
quienes son los delegados de cada una de las partes implicadas (tanto
cliente como proveedor).
2.3.3. Descripción del Servicio.
Es un componente importante en el momento de guiar el intercambio de
mensajes entre entidades. Esta descripción del servicio permite que este
tipo de transacciones lleguen a feliz término a través del uso del protocolo
WSD (Descripción de Servicios Web) y escrito en un lenguaje denominado
WSDL (Lenguaje de Descripción de Servicios Web). En este formato se
incluyen todos los elementos que pueden ser descritos, tales como, el tipo
de datos, formato de mensajes, protocolos de transporte, rutas de
localización del servicio.
2.3.4. Semánticas.
La semántica define el comportamiento que va tener el Servicio Web al
enviarle un mensaje de petición, estableciendo también las relaciones que
este establece en su contexto de ejecución con otros objetos.
2.4. TECNOLOGÍAS ESTÁNDAR PARA SERVICIOS WEB.
El núcleo de las especificaciones y los protocolos del nivel de aplicación definidos
para los Servicios Web está promovido por la Organización para la Interoperabilidad
de Servicios Web (WS-I) y administrado por el Consorcio de la World Wide Web
(W3C) y la Organización para el Avance de Estándares de Información Estructurada
(OASIS).
49

50. Debido a lo joven que es la tecnología de los Servicios Web, subyacen un conjunto
de estándares que permiten dar confiabilidad, refiriendo todo lo relacionado con el
modo de operación, descripción, localización y envío y recepción de mensajes de los
Servicios Web.
Las siguientes son las tecnologías que conforman el núcleo a través del cual se
pueden implementar y ejecutar Servicios Web:
 XML: el Lenguaje de Marcado Extensible (XML) es la base para
muchas de los estándares especificados para los Servicios Web. Se
caracteriza por ser un lenguaje genérico que sirve para describir
cualquier tipo de contenido de forma estructurada.
 SOAP: el Protocolo de Acceso a Objetos Simple (SOAP) es un
protocolo ligero que permite el empaquetamiento y posterior transporte
de mensajes con formato XML. Se encarga del intercambio de
información y documentos en un entorno distribuido sobre diferentes
tecnologías estándar de Internet incluyendo SMTP, HTTP y FTP.
También establece mecanismos básicos de comunicación entre el
cliente y los Servicios Web. Al igual que XML es independiente de la
plataforma y la forma en que sea implementado.
 WSDL: el Lenguaje de Descripción de Servicios Web (WSDL) es un
esquema basado en XML que sirve para describir un servicio. WSDL
estandariza la forma en como un Servicio Web representa la entrada y
salida de datos a partir de una invocación externa del Servicio Web,
especifica las operaciones que ofrece un Servicio Web y la estructura
de las mismas. También describe a los servicios como un conjunto de
nodos o puertos. Estos nodos o puertos asocian direcciones de red y
la colección o unión de los mismos definen el servicio.
 UDDI: el estándar para el Descubrimiento, Descripción e Integración
Universal (UDDI) proporciona mecanismos para la publicación y el
descubrimiento de información de los Servicios Web, describiendo
también el tipo de operaciones que estos ofrecen. UDDI como
50

51. estándar industrial nace bajo la necesidad de crear plataformas
independientes que permitieran a las organizaciones integrar,
descubrir, describir y categorizar los negocios. A través de mensajes
SOAP, otras personas, empresas u organizaciones pueden hacer el
descubrimiento de los Servicios Web registrados.
2.5. ESCENARIO DE SERVICIOS WEB.
El escenario de interacción se maneja a través del uso de las tecnologías
anteriormente nombradas de la siguiente forma:
 Una vez montada la aplicación del Servicio Web, éste es registrado a
través de un repositorio como lo es UDDI. Este registro permite
categorizar, identificar o especificar el Servicio Web y además da la
ubicación del archivo WSDL en donde se describe el servicio.
 Otro servicio o usuario representado a través de una aplicación
localiza el servicio registrado y lo solicita a través de una búsqueda en
el registro UDDI. La búsqueda se hace por nombre, categoría,
identificador o especificación soportada. Allí se encuentra el WSDL, el
cual contiene información acerca de cómo invocar el Servicio Web y
formatos de cómo hacer solicitudes al servicio especificados en un
esquema XML.
 Este cliente invoca al servicio a través de la creación de una aplicación
haciendo uso de mensajes SOAP basándose en el esquema definido
en el WSDL del registro. La solicitud es enviada a la dirección donde
se encuentra el Servicio Web.
 Esta solicitud llega en formato XML al Servicio Web.
 El Servicio Web procesa la solicitud.
 Este procesamiento se hace a través del llamado a componentes (por
ejemplo EJBs) los cuales encapsulan la lógica de negocio u
operaciones que administra el servicio.
51

52.  Los componentes procesan la información y devuelven los resultados
al servicio.
 El Servicio Web crea y almacena el valor de retorno en un archivo con
formato XML, enviándolo sobre un mensaje de respuesta al cliente.
En la Figura 5 se resume el proceso descrito anteriormente.
Servicio
WSDL
Procesador
SOAP Servidor
HTTP
Red Red
Mensajes SOAP de Registro y
solicitud y Publicación
respuesta
Red
Cliente Registro UDDI
Descubrimiento
del Servicio
Figura 5. Escenario de Servicios Web.
52

53. III. ESPECIFICACIÓN DE SERVICIOS WEB EN J2ME.
3.1. INTRODUCCIÓN.
J2ME al igual que la Edición Empresarial de Java 2 (J2EE) tiene capacidades para el
soporte de Servicios Web y análisis de datos XML a través de la adaptación de APIs
implementadas en J2EE, pero no con todas las funcionalidades debido a las
características restrictivas que impone J2ME. La especificación que maneja el
soporte de Servicios Web es la JSR-172 a través de dos APIs o paquetes opcionales
que permiten el manejo del flujo de datos XML y la comunicación con el Servicio
Web. El objetivo de esta descripción de Servicios Web es la interoperabilidad para
un marco general que pretende estandarizar el desarrollo de entornos empresariales
en J2ME.
3.2. GENERALIDADES.
La especificación JSR-172 lanzada el 3 de Marzo de 2004, “esta diseñada para
trabajar con perfiles J2ME basados en cada una de las configuraciones CDC v1.1 y
CLDC v1.1” [4]. JSR-172 también establece como un dispositivo móvil que soporte
J2ME puede ser cliente de Servicios Web. Aún en la actualidad, no se definen a los
dispositivos móviles como proveedores de Servicios Web. Básicamente se ha
definido el estándar de Servicios Web en J2ME con el fin de proporcionar una
infraestructura que:
 adicione habilidades básicas para el procesamiento de documentos en
formato XML
 “permita el rehúso de conceptos de servicio cuando se están
diseñando clientes J2ME en aplicaciones empresariales” [5]
 permita la interoperabilidad de los clientes J2ME con Servicios Web
 proporcione un modelo de programación para la comunicación de
clientes J2ME con Servicios Web.
53

54. JSR-172 tiene los siguientes requerimientos:
 Tamaño de 35 KB de memoria usado por el dispositivo objetivo para
una completa implementación de la Especificación.
 Soporte para mensajes SOAP en su versión 1.1 y de forma literal.
 No soporta mensajes SOAP 1.1 codificados.
 Soporte para el Perfil Básico WS-I (Perfil Básico para la
Interoperabilidad de Servicios Web).
 Soporte para WSDL en su versión 1.1.
 No soporta UDDI.
 No existe soporte para la funcionalidad del Servicio Web del lado del
servidor.
 La seguridad es proporcionada por la plataforma J2ME.
3.3. JSR 172: PAQUETES OPCIONALES.
Dos paquetes opcionales definen la Especificación de Servicios Web establecida a
través de JSR 172. Estos paquetes son:
 API Java para el Procesamiento de XML (JAXP) v1.2 (JSR 063).
 API Java para Llamado de Procedimientos Remotos basado en XML
(JAX-RPC) v1.1 (JSR 101).
Las APIs que tienen el carácter de opcionales e independientes, son el resultado de
la especificación de Servicios Web en J2ME y sus objetivos son:
 Soportar el análisis de documentos XML en la plataforma J2ME. El
hecho de que los Servicios Web sean aplicaciones empresariales
define de forma inmediata que el formato de los datos manejados en la
interacción entre los Servicios Web y el dispositivo móvil cliente está
basado en XML. Este aspecto estará definido por el API JAXP.
 Facilitar el acceso a Servicios Web basados en XML. Este acceso
54

55. estará determinado por el API JAX-RPC, permitiendo el acceso de los
dispositivos móviles a Servicios Web remotos.
“Tanto JAXP como JAX-RPC cumplirán con los requerimientos de tamaño y
desempeño de la plataforma J2ME de tal forma que puedan ser implementados con
la memoria en tiempo de ejecución y procesar los requerimientos para los
dispositivos móviles” [6].
3.3.1. API JAXP.
El propósito de este paquete opcional es dar soporte de verificación y
análisis de XML a la plataforma J2ME. Esta API está basada en la API JAXP
v1.2 del estándar J2SE. El API JAXP para J2ME ha sido reducido en
tamaño con respecto al API JAXP de J2SE con el fin de ser adecuado a las
limitaciones de la plataforma J2ME y poder ejecutar aplicaciones en el
entorno de memoria reducida que ofrece.
3.3.1.1. Requerimientos de Plataforma.
Necesita 25 KB de memoria para el soporte y ejecución de las clases
que soportan el API.
3.3.1.2. Requerimientos del API.
 “No existe soporte para el Modelo de Objetos para Documentos
(DOM), debido a lo pesado en términos del tamaño de
implementación” [6].
 Soporta el espacio de nombres estándar de XML del W3C y
parte del API Simple para XML (SAX) v2.0.
3.3.1.3. Paquetes del API JAXP.
Los siguientes tres paquetes especifican la funcionalidad del API JAXP:
 javax.xml.parsers: “contiene las clases para obtener y
55

56. referenciar una implementación del analizador de una
plataforma dada” [7].
Esta conformado por las siguientes cuatro clases:
 SAXParser: permite la implementación de un analizador XML
SAX.
 SAXParserFactory: fabrica para la creación de instancias
para un analizador SAX.
 FactoryConfigurationError: excepción para indicar un error
de configuración al invocar la clase SAXParserFactory.
 ParserConfigurationError: excepción lanzada que informa
sobre errores de configuración al invocar la clase SAXParser.
 org.xml.sax: compuesto por un subconjunto de clases e
interfaces del API SAX 2.0 encontrada en J2SE. Las interfaces
incluidas en este paquete son:
 Attributes: maneja la lista de atributos XML.
 Locator: permite la asociación de un evento SAX con una
ubicación del documento.
El paquete también incluye cinco clases:
 InputSource: provee recursos de entrada simple para una
entidad XML.
 SAXException: error o advertencia de SAX.
 SAXNotRecognizedException: excepción lanzada para un
identificador no reconocido.
 SAXNotSupportedException: clase que maneja
excepciones para la identificación de una operación
soportada.
 SAXParseException: error o advertencia del analizador
56

57. XML.
 org.xml.sax.helpers: contiene una clase denominada
DefaultHandler que permite la captura de eventos realizados
por el analizador SAX 2.0.
3.3.1.4. Implementación de JAXP.
El analizador que maneja JAXP esta diseñado para analizar un
documento XML como flujo de entrada para lo cual es necesario lo
siguiente:
 Instanciación del objeto manejador de eventos DefaultHandler.
 Creación de una instancia de SAXParserFactory.
 Uso de la instancia de SAXParserFactory para crear una
instancia del analizador JAXP.
 Dar la referencia del archivo XML de entrada a la instancia del
analizador.
 “Usar los métodos de la clase DefaultHandler para la
manipulación del archivo XML de entrada” [7].
3.3.2. API JAX-RPC.
JAX-RPC implementa la tecnología de Llamado a Procedimientos Remotos
(RPC) que hace parte de la plataforma J2EE. Permite la creación de
clientes de Servicios Web para el intercambio de datos con el servicio, esta
interacción está basada en mensajes SOAP. El desarrollo con JAX-RPC
solicita la ejecución de operaciones remotas de servicios que se ejecutan en
maquinas remotas de tal forma que pueden ser invocados en objetos
locales. En este entorno no es importante la forma en cómo es
implementado el servicio haciendo de los Servicios Web una aplicación
portable.
57

58. 3.3.2.1. Requerimientos de Plataforma.
Es necesario 50 KB de RAM y 25 KB de ROM para la implementación
del API JAX-RPC.
3.3.2.2. Requerimientos del API.
 Existe soporte para lineamientos del Perfil Básico WS-I con el
fin de proporcionar interoperabilidad al API.
 Soporte para el transporte de mensajes SOAP a través de
HTTP.
 Permite la representación literal de mensajes SOAP
administrada en el formato de una solicitud/repuesta RPC,
además del reconocimiento de documentos WSDL (Lenguaje de
Descripción de Servicios Web).
 Específica la forma en cómo son mapeados los tipos de datos
XML a tipos Java bajo la definición de stub para el manejo de
documentos XML basado en comunicación RPC.
 Establecimiento de mecanismos en tiempo de ejecución que
toleren los stubs generados.
3.3.2.3. Paquetes del API JAX-RPC.
El API JAX-RPC está compuesta por tres partes:
1. Subconjunto de JAX-RPC: sirven para el desarrollo de
Servicios Web y esta compuesto por los cuatro paquetes:
 com.sun.j2mews.xml.rpc: “contiene clases para la
implementación del API en tiempo de ejecución” [8].
Contiene las siguientes clases:
 OperationImpl: implementación de la clase
58

59. javax.microedition.xml.rpc.Operation el cual corresponde
a una operación del Servicio Web definido en el WSDL.
 SOAPDecoder: permite el descifrado de mensajes
SOAP.
 SOAPEncoder: sirve para codificar mensajes SOAP.
 javax.microedition.xml.rpc: conformado por una interfaz
simple FaultDetailHandler implementada por stubs. Tiene las
siguientes clases:
 Complextype: manejo de instancias de tipos de datos
XML complejos (xsd:complexType) definidos en un
WSDL.
 Element: instanciación de elementos (xsd:element)
definidos en el WSDL del Servicio Web.
 Operation: hace referencia a la (s) operación (es) de un
Servicio Web.
 Type: tipo de enumeración para la identificación de tipos
simples en WSDL.
 FaultDetailException: “excepción lanzada para valores
detallados específicos del servicio” [8].
 javax.xml.namespace: conformado por una clase simple
llamada Qname, que representa un nombre calificado y es
definido a través de las especificaciones de Esquemas, Tipos
de Datos y Espacios de Nombres XML.
 javax.xml.rpc: núcleo del API JAX-RPC. Está estructurada
de la siguiente manera:
 Stub: interfaz común para las clases stub.
 NamespaceConstants: clase que define prefijos para los
espacios denombres definidos en XML.
59

60.  JAXRPCException: excepción lanzada por el API JAX-
RPC relacionada con el tiempo de ejecución de JAX-
RPC.
2. Paquete para la Invocación de Métodos Remotos (RMI):
conformado paquete java.rmi el cual a su vez maneja una
interfaz y tres excepciones definidas a continuación:
 Remote: interfaz para la identificación de métodos que
pueden ser invocados desde una máquina virtual no local.
 MarshalException: esta excepción ocurre si otra excepción
es lanzada al momento de manejar el flujo de E/S mientras
se ordena la cabecera, los argumentos o valores de retorno
de un llamado remoto.
 RemoteException: excepción relacionada con la
comunicación que ocurre en la ejecución del llamado de un
procedimiento remoto.
 ServerException: esta excepción es el producto de una
invocación al servidor del método remoto.
3. Interfaz del Proveedor del Servicio SPI: permite a los stubs
ser portables e interoperables sin importar la implementación
de la Especificación de Servicios Web de J2ME.
3.4. OTROS PAQUETES.
Los siguientes paquetes no pertenecen a la especificación de Servicios Web en
J2ME (JSR 172), pero cumplen con los requerimientos mínimos para la
manipulación de aplicaciones que permitan al acceso a los Servicios Web y esta
soportado por el perfil MIDP. Entre estos paquetes se pueden encontrar:
3.4.1. kXML.
“Esta API tiene soporte para análisis de documentos XML” [9].
60

61. 3.4.1.1. Requerimientos del API.
 Soporte para analizadores como SAX, XMLPull (basado en
pilas) y kDOM (Modelo de Documentos).
3.4.1.2. Paquetes del API kXML.
El API kXML en su versión 2.0 consta de 6 paquetes:
 “org.kxml2.io: contiene manejo de análisis XML con XMLPull.
 org.kxml2.kdom: realiza la implementación de análisis XML
con DOM.
 org.kxml2.wap: soporte para analizadores con Wbxml.
 org.kxml2.wap.syncml: sincronización en documentos XML.
 org.kxml2.wap.wml: maneja un analizador para documentos
wml.
 org.kxml2.wap.wv: paquete wireless village”. [10]
3.4.2. kSOAP.
Este paquete lanzado en Noviembre del año 2002 permite el manejo de
servicios web a través mensajes SOAP.
3.4.2.1. Requerimientos de Plataforma.
 42 KB de memoria ROM para ejecutar el API.
3.4.2.2. Requerimientos del API.
 Soporte para mensajes SOAP codificados y literales.
 “Es opcional la serialización de mensajes SOAP” [11].
3.4.2.3. Paquetes del API kSOAP.
 “org.ksoap2: clases básicas requeridas para el manejo de
cabeceras SOAP y XML literal.
 org.ksoap2.serialization: contiene soporte para la
especificación de Serialización de SOAP”. [11]
61

62.  org.ksoap2.servlet: clase para la implementación de Servlets.
 org.ksoap2.transport: permite la ejecución de métodos de
conexión a través de HTTP.
62