Aplicaciones moviles empresariales con Servicios Web y J2ME
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Aplicaciones moviles empresariales con Servicios Web y J2ME

  • 16,118 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
16,118
On Slideshare
15,958
From Embeds
160
Number of Embeds
12

Actions

Shares
Downloads
1,169
Comments
2
Likes
4

Embeds 160

http://pagayvamonos.blogspot.com 118
http://www.pagayvamonos.blogspot.com 14
http://pagayvamonos.blogspot.com.es 11
http://pagayvamonos.blogspot.ru 6
http://naiguayo.wikispaces.com 2
http://pagayvamonos.blogspot.mx 2
http://pagayvamonos.blogspot.fr 2
http://localhost 1
http://www.linkedin.com 1
http://localhost:3000 1
http://www.blogger.com 1
https://www.linkedin.com 1

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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
  • 63. IV. IMPLEMENTACION DEL SISTEMA PARA LA ADMINISTRACIÓN DE SERVICIOS WEB EN TELEFONIA MOVIL A TRAVES DE LA PLATAFORMA J2ME. 4.1. ESPECIFICACIONES GENERALES. Para describir el desarrollo de esta aplicación se tiene en cuenta aspectos generales de Ingeniería del Software con el fin de detallar aspectos como el patrón de diseño utilizado en la implementación, casos de usos y diagramas de clases que permiten observar una visión general de la estructura de la aplicación final. Esta aplicación final consta de dos Servicios Web, el primero maneja la información relacionada con precios y proveedores de algunas artesanías de Colombia, el segundo muestra la hora y lugar en donde se van a presentar las películas en la cartelera actual para las algunas salas de cine de Colombia. 4.1.1. Patrón de diseño MVC. El Sistema para la Administración de Servicios Web en telefonía móvil hace uso del patrón de arquitectura de software MVC (Modelo Vista Controlador), en el cual “la interacción con la interfaz de usuario se divide en tres roles distintos. En una aplicación MVC la vista y los componentes del controlador trabajan en conjunto como la IU (Interfaz de Usuario), el cual se ocupa de cómo presentar la información al usuario a través de interacciones y pantallazos” [9], además “permite resolver el problema de la actualización de vistas de una aplicación ” [12]. En el momento en que el usuario altera los datos en la pantalla e inicia una acción, esta acción va al controlador. El controlador es quien define que tipo de petición ha sido solicitada a través de la acción y realiza un llamado a las interfaces apropiadas del modelo. Este modelo puede consistir de muchos componentes, clases o paquetes, esto depende de la tecnología sobre la que esta soportada la lógica del negocio de la aplicación. 63
  • 64. Implementar este patrón de diseño tiene sus beneficios:  La capa de presentación y el modelo de datos están claramente separados.  MVC permite la realización de distintas vistas para el mismo modelo.  Los objetos no visuales de la aplicación en la capa del modelo son más fáciles de usar usando herramientas automáticas, en vez de ser usadas en la IU. La Figura 6 muestra los principales componentes de esta arquitectura y sus interacciones con el usuario. Notificaciones de Modelo actualización Cambios y acciones Registros Vista Controlador Representación de la interfaz de Acciones del usuario usuario Usuario Figura 6. Componentes del patrón de diseño MVC. 4.1.2. Diagramas de Casos de Usos. Los diagramas de Casos de Usos de cada uno de los Servicios ofrecidos a través del sistema implementado describen las características resaltantes de la interacción entre el usuario y la aplicación final. 4.1.2.1. Diagrama de Caso de Uso del Servicio Artesanías de Colombia: el diagrama de casos de usos de la aplicación que maneja la información relacionada con las Artesanías de Colombia se presenta 64
  • 65. a continuación (Figura 7): Figura 7. Diagrama de Caso de Uso del Servicio Artesanías de Colombia. El usuario interactúa con la aplicación a través de tres funcionalidades:  Ver Datos Artesanías: permite observar datos de artesanías como el nombre, región de origen y una imagen que describe la artesanía consultada.  Contactos Proveedores: muestra la información de los proveedores de la artesanía consultada a través de una dirección Web.  Ayuda: este menú informa al usuario de cómo manipular y navegar a través del aplicativo. 4.1.2.2. Diagrama de Caso de Uso del Servicio Cine: en la Figura 8 se detalla el diagrama de casos de usos de la aplicación que administra la información de horarios de películas y Salas de Cine de Colombia. 65
  • 66. Figura 8. Diagrama de Caso de Uso del Servicio Cine. El usuario tiene acceso al aplicativo por medio de dos funcionalidades:  Ver Cartelera: informa acerca de la Sala de Cine y el precio de la película consultada, desplegando una imagen que describe la película.  Ver Horarios Películas: describe en que Sala de Cine y la hora exacta en la que se va a presentar la película. 4.1.3. Diagramas de Clases. Estos diagramas permiten visualizar la adaptación del patrón de diseño MVC implementado en la realización del sistema propuesto. 4.1.3.1. Diagrama de Clases del Servicio Artesanías de Colombia: Se utiliza un componente MVC general que administra la interfaz de Usuario de la aplicación, y las subclases especifican las operaciones descritas en el Servicio Web. Cada una de estas subclases maneja controladores para el acceso al Servidor en donde está alojado el Servicio Web y maneja los parámetros necesarios para la creación de la Vista que es administrada por la clase general ComponenteMVC. El diagrama de clases se muestra en la Figura 9. 66
  • 67. Figura 9. Diagrama de Clases del Servicio Artesanías de Colombia. 4.1.3.2. Diagrama de Clases del Servicio Cine: la clase general que distribuye la interfaz de usuario de cada una de las opciones previstas en la aplicación del Servicio Cine es llamada ComponenteMVC1, las demás subclases (MenuPeliculas, HorarioLugarPeliculas, VerListaPeliculas) heredan de ésta y cada una de forma independiente maneja la forma en como carga el modelo y accede al Servicio Web. La Figura 10 muestra el diagrama de clases del Servicio Cine. 67
  • 68. Figura 10. Diagrama de Clases del Servicio Cine. 4.2. HERRAMIENTAS UTILIZADAS EN LA IMPLEMENTACION DEL SISTEMA. Para llevar a cabo la implementación y prueba de la aplicación fue necesario el uso de las herramientas mostradas en la Tabla 6, detallando las licencias y empresas u organizaciones que las distribuyen. Herramienta/Software Proveedor Licencia Maquina Virtual Java Sun MicroSystems GPL v2 jdk1.6.0_06 Sun Java Wireless Toolkit Sun MicroSystems GPL v2 2.5.2 Apache Tomcat 6.0 Apache Software Apache Software License Foundation Axis Apache Software Apache Software License Foundation Nokia Prototype SDK 4.0 for Nokia Free Java ™ ME Sony Ericsson SDK 2.5.0.2 Sony Ericsson GPL v2.0 for the Java ™ ME Platform JCreator Pro 4.5 Xinox Software EULA Tabla 6. Herramientas y Software usado para la implementación. 68
  • 69. A continuación se detalla cada una de las funcionalidades que tienen estas herramientas en el desarrollo de la aplicación final.  Maquina Virtual Java jdk1.6.0_06: esta plataforma permite la ejecución de toda aplicación soportada sobre la tecnología Java, siendo ésta la base estructural de J2ME que es el eje central sobre el que se llevara a cabo la implementación.  Sun Java Wireless Toolkit 2.5.2: herramienta que proporciona todos los medios posibles para la creación y ejecución de aplicaciones móviles a través de un emulador incorporado.  Apache Tomcat 6.0: Servidor de aplicaciones sobre el que se montara el Servicio Web desde el que accederá la aplicación cliente en desarrollo.  Axis: framework de desarrollo que permiten la creación de Servicios Web.  Nokia Prototype SDK 4.0 for Java ™ ME: emulador de aplicaciones móviles que soporta paquetes para el desarrollo de Servicios Web en J2ME.  Sony Ericsson SDK 2.5.0.2 for the Java ™ ME Platform: emulador de Sony Ericsson para la ejecución de aplicaciones desarrolladas bajo la plataforma J2ME.  JCreator Pro 4.5: editor de archivos fuentes Java. 4.3. DETALLES DE LA IMPLEMENTACION. La implementación se realiza a través de cuatro fases resumidas a continuación:  Fase 1: en esta fase se realiza la búsqueda de herramientas necesarias para la implementación, estudiando características y viabilidad con el fin de agilizar la ejecución del proyecto.  Fase 2: estudio de las APIs y patrones de diseño sugeridos para la 69
  • 70. implementación de la aplicación final.  Fase 3: se lleva a cabo la instalación del Servidor de aplicaciones Apache Tomcat 6.0 y la configuración del framework Axis sobre éste. Se realizan los dos Servicios Web propuestos en la implementación a través de Axis, y posteriormente son desplegados en el servidor instalado.  Fase 4: en esta fase final se ejecuta el desarrollo final de la aplicación a través del uso de las herramientas y paquetes seleccionados en la primera y segunda fase respectivamente. Se utilizó además el patrón de diseño de Software MVC. 4.4. EMULACIÓN DEL SISTEMA EN LA HERRAMIENTA J2ME WIRELESS TOOLKIT 2.5.2. 4.4.1. Características de la herramienta. J2ME Wireless Toolkit en su versión 2.5.2 lanzada en el año 2007, consta de un conjunto de herramientas que permiten la creación y ejecución de aplicaciones MIDP con las siguientes características:  Construcción y empaquetado: después de tener digitado el código fuente de la aplicación la herramienta puede compilar, preverificar las clases y empaquetar la aplicación en una MIDlet suite.  Ejecución y monitoreo: se puede ejecutar la MIDlet suite directamente sobre el emulador o instalarla en un dispositivo móvil a través de una aplicación que permita tal instalación. Un monitor de memoria y de red son proporcionados para analizar las operaciones de los MIDlets.  Firma digital de MIDlet suites: esta herramienta contiene paquetes para firmar digitalmente MIDlet suites. Esto es usual para probar la operación de MIDlets en diferentes dominios de protección [13]. 70
  • 71. También permite la firma de MIDlets, el manejo de certificados digitales, emulación integrada sobre el aire (OTA) y más funcionalidades. Las Figuras 11 y 12 muestran la ejecución del Sistema para la administración de Servicios Web en el emulador de la herramienta J2ME Wireless Toolkit 2.5.2. 71
  • 72. Figura 11. Flujo de Ejecución de la Aplicación para Artesanías de Colombia en J2ME Wireless Toolkit 2.5.2. 72
  • 73. Figura 12. Flujo de Ejecución de la Aplicación para Cines de Colombia en J2ME Wireless Toolkit 2.5.2. 73
  • 74. 4.5. EMULACIÓN DEL SISTEMA EN LA HERRAMIENTA NOKIA PROTOTYPE SDK 4.0 FOR JAVA ™ ME. 4.5.1. Características de la herramienta. Nokia Prototype SDK 4.0 para JAVA ™ ME puede ser usado y soportado con Entornos de Desarrollo Integrado (EDI). El Kit de Desarrollo (SDK) ofrece soporte a MIDP 2.0, emulación en ámbitos como seguridad, Bluetooth, gráficos móviles en 3D y API de ubicación. Esta herramienta tiene los siguientes componentes:  Emuladores: el primer emulador es Prototype 4.0 S40 MIDP Emulator con resoluciones de 128x128, 128x160, 208x208 y 240x320 píxeles, además esta el Prototype 4.0 S60 MIDP Emulator con resoluciones de 176x208, 240x320, 352x416 pixeles, Prototype 4.0 S80 MIDP Emulator con resolución 640x200 píxeles y Prototype 4.0 Nokia 7710 MIDP Emulator con resolución de 640x320 píxeles.  Nokia Connectivity Framework (NCF): ofrece un entorno de comunicación fácil y rápida. La comunicación con productos NCF compatibles puede ser establecida a través de diversas tecnologías de comunicación [14]. Las Figuras 13 y 14 muestran la ejecución del Sistema para la administración de Servicios Web en el emulador de la herramienta Nokia Prototype SDK 4.0 for JAVA ™ ME. 74
  • 75. Figura 13. Flujo de Ejecución de la Aplicación para Artesanías de Colombia en Nokia Prototype SDK 4.0 for JAVA ™ ME. 75
  • 76. Figura 14. Flujo de Ejecución de la Aplicación para Cines de Colombia en Nokia Prototype SDK 4.0 for JAVA ™ ME. 76
  • 77. 4.6. EMULACIÓN DEL SISTEMA EN LA HERRAMIENTA SONY ERICSSON SDK 2.5.0.2 FOR THE JAVA ™ ME PLATFORM. 4.6.1. Características de la herramienta. Sony Ericsson SDK 2.5.0.2 para la Plataforma JAVA ™ ME tiene soporte para MIDP 2.0 y Symbian. El Kit de Desarrollo (SDK) es una modificación de la herramienta Sun Java Wireless Toolkit en su versión 2.5.0. Sony Ericsson SDK 2.5.0.2 para la Plataforma JAVA ™ ME además de soportar las APIs que pueden soportar las demás componentes herramientas añade la especificación JSR 239 (Java Binding para OpenGL) que sirve para el reconocimiento de gráficas nativas en 3D. Consta de los siguientes elementos:  ODD (Depuración en el Dispositivo): permite a los desarrolladores realizar aplicaciones y depurarlas directamente desde el teléfono móvil.  Conexión Proxy: interfaz para la conexión entre el PC y el teléfono.  Explorador de Dispositivo: permite la manipulación de MIDlets y aplicaciones Java en el teléfono directamente desde el PC.  Monitor de Recursos: ayuda a la obtención de información acerca de los recursos del sistema que incluye el teléfono [15]. Las Figuras 15 y 16 muestran la ejecución del Sistema para la administración de Servicios Web en el emulador de la herramienta Sony Ericsson SDK 2.5.0.2 para la Plataforma JAVA ™ ME. 77
  • 78. Figura 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
  • 79. Figura 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
  • 80. V. MARCO HISTORICO DEL PROYECTO. 5.1. ESTADO DEL ARTE. Desde el año 2003, luego que se estandarizará la plataforma J2ME por parte de la Sun Microsystems Incorporation a través de JCP (Comunidad de Procesos Java), se ha venido trabajando sobre las capacidades que se pueden ofrecer en los teléfonos móviles por medio del uso de la plataforma J2ME a través de aplicaciones de conectividad, como lo son los Servicios Web implementando JSR (Requerimientos de Especificación Java). El JSR referido a la implementación de Servicios Web en telefonía móvil es denominado JSR 172 “J2ME Web Services Especification” (Especificación de Servicios Web en J2ME). El grupo de expertos que han permitido un completo desarrollo de la especificación está compuesto por 30 corporaciones e individuos líderes en la industria. Fabricantes como Nokia, Motorola, Sony/Ericsson, LG, Siemens, Sharp y RIM, distribuidores de software como Symbian, IBM, Borland, BEA y Sun Microsystems además de distribuidores de servicios inalámbricos como NTT y Cingular hacen parte de este grupo. A continuación se muestran los trabajos relacionados a nivel internacional y nacional en cuanto a la implementación de la plataforma J2ME para aplicaciones que tengan acceso a Servicios Web en telefonía móvil. 80
  • 81. 5.1.1. Fuentes Primarias – Trabajos Relacionados – Internacional  Universidad de la Laguna (España) [16]. Acceso Dinámico a Servicios de una Infraestructura Web desde Teléfonos Móviles. Sánchez Nielsen, E., Martín Ruiz, S., Rodríguez Pedrianes, J. 2007.  Proyecto de Software Cliente para Servicios Web Móviles [17]. Karimo, H. 2005. Desarrollo de una aplicación cliente para el acceso a Servicios web en telefonía móvil usando el Modelo Vista Controlador.  Universidad de Piura (Piura, Perú), Universidad de Ciencias Aplicadas del Sur de Suiza (Suiza) [18]. Servicios Web para Entornos Informáticos. Arauco, E., Sommaruga, L. 2003. Descripción de la arquitectura abierta de J2ME y estándares mundiales para el desarrollo de Servicios Web en telefonía móvil.  Escuela Politécnica de Pernambuco [19] Servicio de distribución de contenidos RSS para dispositivos móviles a través de Servicios Web. Bandeira de Oliveira, R. 2005.  Platinum Solutions. Aplicaciones conectadas de J2ME, Santanu Dutt, 2004. Explicación sobre capacidades de J2ME en aplicaciones que necesitan conexión inalámbrica a través de la implementación de un marco genérico de conexión. 81
  • 82.  Escuela Superior de Ingenieros (Sevilla España). Localización de terminales móviles mediante GPS y Push Registry (J2ME), Antonio J. Sierra Collado, Carlos Bueno López, María Carrión García, 2006. Implementación de una aplicación cliente que permita el manejo de ubicaciones geográficas para un conjunto de terminales móviles a través de GPS y Push Registry. 5.1.2. Fuentes Primarias – Trabajos Relacionados – Nacional.  Universidad del Cauca, Facultad de Ingeniería Electrónica y Telecomunicaciones Departamento de Telemática [20]. Aplicaciones para dispositivos móviles utilizando la tecnología de Agentes. Barrera Campo, José F., Martínez Vásquez, David A. 2004. Diseño de servicios basados en la tecnologías de agentes con el Modelo de Referencia para el Desarrollo de Servicios con Orientación a Agentes versión 1.0 (MR-DSOA 1.0) que pueden ser accedidos a través de dispositivos móviles.  Universidad Santo Tomas, Medellín [21]. Proveedor de Servicios Basados en Localización para Dispositivos Móviles. Castañeda, Hernán A., Gómez, Juan D., Leal, Alexander. 2006.  Universidad El Bosque, Facultad de Ingeniería de Sistemas, Bogotá [22]. Streaming de Audio a través de Dispositivos Móviles utilizando J2ME. Prieto, Felipe A., Rodríguez, Luisa F. 2007. 82
  • 83. Implementación de una aplicación móvil a través de J2ME que permite el manejo y edición de contenido multimedia desde dispositivos móviles haciendo usos de recursos disponibles en la red.  Grupo Cóndor S.A., Bucaramanga. Desarrollo y Comercialización de soluciones móviles en diversos sectores. Desarrollo de software móvil a la medida de su empresa. Ofrece soluciones en diferentes plataformas como Symbian OS, J2ME orientadas a soluciones empresariales integrales que agilicen los procesos [23].  Universidad San Martín, Facultad de Ingenierías, Ingeniería de Sistemas, Bogotá [24]. Búsqueda de rutas para el sistema de Transporte Masivo Transmilenio utilizando la tecnología J2ME. Martínez Chaparro Francy. 2007. Implementación de un sistema que gestiona la búsqueda de rutas para Transmilenio a través de J2ME. 83
  • 84. PRESUPUESTO ECONOMICO MARCO ECONOMICO 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 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. J2ME además de ser una plataforma libre ofrece robustez y gran capacidad para la ejecución de este tipo de sistemas que se pretende implementar. Actualmente existen en el mercado sistemas operativos móviles como Windows Mobile Pocket PC y Apple que permiten la ejecución de este tipo de aplicaciones. El problema radica en que obtener licencias de este tipo es costoso si se desea hacer un desarrollo como el propuesto en esta tesis.  CALCULOS DE LOS COSTOS DE INVERSIÓN 1) Presupuesto de medios básicos Balance de Inversiones en: Software y equipos Denominación CANTIDAD COSTO COSTO Proveedor Observaciones del Renglón UNITARIO TOTAL General Maquina Virtual 1 $0 $0 Sun Java jdk1.6.0_06 MicroSystems Sun Java 1 $0 $0 Sun Wireless Toolkit MicroSystems 2.5.2 Servidor de 1 $0 $0 Apache Software Aplicaciones Foundation Apache Tomcat 6.0 Axis 1 $0 $0 Apache Software Foundation 84
  • 85. Nokia Prototype 1 $0 $0 Nokia SDK 4.0 for Java ™ ME Sony Ericsson 1 $0 $0 Sony Ericsson SDK 2.5.0.2 for the Java ™ ME Platform JCreator Pro 4.5 1 $0 $0 Xinox Software Computador 1 $0 $0 CICOM Asignado en Laboratorio P103 por CICOM Total de la $0 inversión en el renglón general Tabla 7. Medios Básicos. 2)Presupuesto de medios de Rotación Balance de Inversiones en: Medios de Rotación Denominación CANTIDAD COSTO COSTO Proveedor Observaciones del Renglón UNITARIO TOTAL General Arriendo 5 $100.000 $500.000 Señora Marlenys Luz 5 $25.000 $75.000 CENS Agua 5 $28.000 $140.000 EmpoPamplona Internet 300 horas $0 $0 Universidad de Asignado en Pamplona Laboratorio P103 por CICOM Total de la $715.000 inversión en el renglón general Tabla 8. Medios de Rotación. 85
  • 86. 3)Presupuesto para gastos en personal Cargo Días Salario Auxilio de Salud Pensión Total NETO A Trabajados Básico Transporte Deducido PAGAR Ingeniero 90 $850.000 $90.000 $90.00 $65.000 $785.000 $2355.000 0 Total nomina anual $2.355.000 Tabla 9. Gastos en Personal. 86
  • 87. FUENTES DE FINANCIACION Las fuentes de financiación que garantizan la ejecución del proyecto están a cargo del Señor Aliro José Rincón Montero quien apoya de forma económica al autor de la tesis. 87
  • 88. MARCO LEGAL LICENCIA DE APACHE VERSIÓN 2.0 Esta licencia es compatible con otras licencias de Código Abierto bajo la cual la Fundación de Software de Apache (Apache Software Foundation) garantiza el uso, la reproducción y distribución de código fuente del software libre y propietario. LICENCIA DE Sun Microsystems Garantía limitada por 90 días a partir de la adquisición y registro del software. No se puede crear ni modificar las clases, interfaces o subpaquetes que componen el núcleo del software hecho en Java. La licencia se ajusta a las licencias que maneje la empresa que recibe o utiliza el software. GPL v2.0 Esta licencia permite lo siguiente: 1. Usted puede copiar y distribuir copias literales del código fuente del Programa, según lo has recibido, en cualquier medio, supuesto que de forma adecuada y bien visible publique en cada copia un anuncio de copyright adecuado y un repudio de garantía, mantenga intactos todos los anuncios que se refieran a esta Licencia y a la ausencia de garantía, y proporcione a cualquier otro receptor del programa una copia de esta Licencia junto con el Programa. Copiar y distribuir copias del código fuente de programas. 2. Puede modificar su copia o copias del Programa o de cualquier porción de él, formando de esta manera un trabajo basado en el Programa, y copiar y distribuir esa modificación o trabajo. 3. Puede copiar y distribuir el Programa. 4. No puede copiar, modificar, licenciar bajo otro tipo de licencia o distribuir el 88
  • 89. Programa excepto como prevé expresamente esta Licencia. Cualquier intento de copiar, modificar licenciar bajo otro tipo de licencia o distribuir el Programa de otra forma es inválida, y hará que cesen automáticamente los derechos que te proporciona esta Licencia. En cualquier caso, las partes que hayan recibido copias o derechos de usted bajo esta Licencia no cesarán en sus derechos mientras esas partes continúen cumpliéndola. 5. Existe ausencia de garantía. [25] Licencia de Usuario Final (EULA) Es una licencia por la cual el uso de un producto sólo está permitido para un único usuario (el comprador). En este tipo de contrato, el dueño de los derechos de un producto insta al usuario final de éste a que reconozca tener conocimiento de las restricciones de uso, de los derechos del autor (copyright), de las patentes, etc. y que acepte de conformidad. El conocimiento del contenido de los contratos es difícil antes de la compra del producto ya que las cajas de los productos raramente contienen una copia completa del mismo, dándose que el comprador en la mayor parte de las ocasiones conoce su contenido después de la compra [26]. 89
  • 90. ANALISIS DE PROTECCIÓN E HIGIENE DEL TRABAJO Para la realización del sistema que gestiona el acceso de Servicios Web ubicados de forma remota se tuvo en cuenta las especificaciones de la plataforma J2ME, verificando requerimientos que permitan la ejecución de este tipo de aplicaciones en los teléfonos celulares, con el fin de evitar la mala administración de los recursos con los que cuentan los emuladores sobre los que se va a probar la aplicación final. 90
  • 91. INFLUENCIA AMBIENTAL DEL TRABAJO La influencia social que puede tener el resultado de este proyecto es el conocimiento amplio de plataformas abiertas que permitan la ejecución de aplicaciones sobre cualquier tipo de teléfono celular, de forma segura. El proyecto no tiene ninguna influencia ambiental según las normas sobre las que se rige el desarrollo de este tipo de aplicaciones en el proyecto, es decir el sistema implementado no influye directamente en el bienestar del usuario final. 91
  • 92. SERVICIOS WEB EN TELEFONÍA CELULAR Web Services in Cell Phone RESUMEN LUZ MARINA SANTOS JAIMES La evolución de la telefonía móvil ha permitido el desarrollo de estándares con Ingeniera de Sistemas. M. Sc el fin de facilitar la adquisición y conocimiento de Servicios Web a los usuarios Docente Tiempo Completo de móviles. La llegada de nuevas tecnologías como SOA (Service Orient to Directora Grupo de Investigación Architecture) abre un amplio campo de posibilidades para el desarrollo de Ciencias Computacionales diversas aplicaciones cuyo propósito es facilitar el acceso a contenido Categoría C inscrito en Colciencias informativo e interactivo. Este artículo presenta el estado actual de la Universidad de Pamplona implementación de tecnologías emergentes como los Servicios Web en Telefonía lsantos@unipamplona.edu.co Celular, teniendo como base para dicha implementación la plataforma J2ME (Java 2 Micro Edition). ANDRÉS ARLEY RINCÓN PACHECO PALABRAS CLAVES: J2ME, Servicios Web, SOA. Estudiante Ingeniería de Sistemas Universidad de Pamplona ABSTRACT aarp@unipamplona.edu.co The evolution of the mobile telephony has allowed the developed of standards arpa1986@hotmail.com with the purpose of facilitating the acquisition and knowledge of Web Services to andresrincon@ingenieros.com the users of mobiles. . The coming of new technologies like SOA (Service Orient to Architecture) open an extensive field of possibilities for the development of diverse applications whose purpose is to facilitate the access to interactive and informative content. This article presents the current state of the implementation of emergent technologies as the Web Services in Cellular Telephony, having like base for this implementation the platform J2ME (Java 2 Micro Edition). KEYWORDS: J2ME, SOA, Web Services. 1. INTRODUCCIÓN La implementación de servicios Web en telefonía móvil a través de la plataforma J2ME permite a los El auge que tiene la telefonía móvil repercute en la usuarios de telefonía móvil la interacción con creciente necesidad de que sus usuarios y clientes servicios ubicados en la red accediendo desde el tengan acceso a diferentes tipos de servicios a teléfono celular, PDA, etc. Dicha implementación través de la red. Con el fin de manejar la búsqueda se lleva a cabo manejando metodologías de de servicios en móviles, los Servicios Web son la programación soportadas por J2ME que conllevan solución más conveniente para orientar e integrar al desarrollo de aplicaciones empresariales como lo aplicaciones que permitan realizar y estandarizar son los Servicios Web, a través del estudio de las las metodologías de búsqueda de una forma segura generalidades, características de la plataforma y al igual que se hace con una computadora personal. APIs (Interfaz de Programación de Aplicaciones) El desarrollo de aplicaciones para la tecnología de la Referencia de implementación de Servicios móvil se esta convirtiendo en una prioridad a nivel Web en J2ME. mundial con el fin de dar más comodidad a los Se utiliza el patrón de desarrollo MVC (Modelo usuarios de estos dispositivos en cuanto al acceso Vista Controlador) en la ingeniería del software, de forma rápida, manejo de contenido interactivo, usando múltiples capas que aseguren la integridad gestores de búsqueda en la Web, juegos, etc. El de la aplicación final. Este patrón permite dividir poco conocimiento y aplicación de herramientas por módulos el desarrollo, es decir, separa la lógica abiertas y robustas ha impedido el desarrollo de de la aplicación del manejo de datos y de la interfaz este tipo de aplicaciones de forma generalizada a gráfica de la aplicación. nivel nacional. 92
  • 93. 2. AVANCES EN EL MARCO CONCEPTUAL La investigación se basa en conceptos que de aplicaciones con las mismas reglas para obtener caracterizan a los Servicios Web relacionando el resultado deseado. aspectos como su funcionalidad, aplicabilidad y Una de las características más importantes de los tecnologías usadas para su implementación, además servicios Web es que no esta ligado a una del estudio de especificaciones como la JSR 172 tecnología especifica, se ejecuta en cualquier que va a permitir la implantación de las tecnologías plataforma dejando ver de lado su interoperabilidad. que soportan los Servicios Web en telefonía celular. Entre las características más resaltantes de este tipo de aplicación basada en la Arquitectura SOA se La identificación de fuentes principales junto con la tienen: consideración de avances significativos y manejo de actualidad en áreas del conocimiento  Basados en XML: el Lenguaje de relacionados con el tema de Servicios Web se ha Marcado Extensible (XML) edifica la convertido en un factor clave para el desarrollo de representación estándar de datos para la investigación. todos los protocolos y tecnologías que implementan Servicios Web. 2.1 Servicios Web  Acoplamiento débil: el cliente no esta La Arquitectura Orientada a Servicios (SOA) ha atado al Servicio Web de forma directa, es permitido habilitar el entorno distribuido para que decir, el carácter de flexibilidad que ofrece la gran mayoría de las aplicaciones basadas en el entorno de ejecución del Servicio Web componentes puedan operar entre sí, brindando implica que cualquier cambio que tenga heterogeneidad al famoso mundo de las este último no compromete de manera aplicaciones distribuidas. Esta arquitectura da una alguna la capacidad de interacción del visión de que el software debe ser entregado como cliente con el Servicio Web. un servicio, orientando al mercado del software  Granularidad: la tecnología de Servicios hacia un entorno más competitivo con soporte para Web deja entrever la individualidad con la los negocios. Esto a su vez permite de forma que son manejados los métodos que dinámica la creación e implantación de nuevos implementa el servicio. Estos métodos en servicios basados en los servicios ya existentes. su forma individual proporcionan Algunas definiciones que delimitan el campo de capacidades para ser usados en un nivel acción de los Servicios Web: corporativo. “Una aplicación software identificada por una URI, cuyas interfaces y vinculaciones son  Capacidad de ser implementados de capaces de ser definidas, descritas y forma síncrona o asíncrona: de forma descubiertas como artefactos XML. Un síncrona se observa el enlace directo del Servicio Web soporta la interacción con otros cliente con la ejecución del servicio. El agentes software mediante el intercambio de cliente espera que el servicio complete la mensajes basado en XML a través de operación para luego continuar. En la protocolos basados en Internet.”1 forma asíncrona el cliente esta en la capacidad de ejecutar una operación e “Los servicios Web son aplicaciones invocar un servicio de forma simultanea. modulares que se pueden describir, publicar, 2 La forma asíncrona le da el carácter de localizar e invocar a través de la Web.” acoplamiento débil a los Servicios Web. “Los Servicios Web son aplicaciones basadas en la Web compuestas por funcionalidades de ____________________________ granularidad gruesa que son accesibles a través 1 [1]http://www.w3.org/TR/ws-arch/wsa.pdf de Internet.”3 2 [2]http://www.redbooks.ibm.com/redbooks/pdfs/sg247257.pdf 3 [3]http://www.csdl.computer.org/comp/mags/co/2003/10/rx035. Los Servicios Web tienen como primer objetivo la pdf integración a través de la combinación de diversos componentes dentro de un sistema. El segundo objetivo es la conformidad, es decir la integración 93
  • 94.  Soporte para Llamado de  XML: el Lenguaje de Marcado Extensible Procedimientos Remotos (RPC): los (XML) es la base para muchas de los Servicios Web están en capacidad de estándares especificados para los Servicios permitir a los clientes la invocación de Web. Se caracteriza por ser un lenguaje procedimientos, funciones y métodos en genérico que sirve para describir cualquier lugares remotos a través de XML. Esto se tipo de contenido de forma estructurada. logra a través de la implementación de  SOAP: el Protocolo de Acceso a Objetos componentes distribuidos como los EJBs Simple (SOAP) es un protocolo ligero que (Enterprise JavaBeans). permite el empaquetamiento y posterior  Soporte para el intercambio de transporte de mensajes con formato XML. documentos: XML proporciona una Se encarga del intercambio de información forma de representación de documentación y documentos en un entorno distribuido compleja, a través de diferentes sobre diferentes tecnologías estándar de protocolos. Internet incluyendo SMTP, HTTP y FTP. También establece mecanismos básicos de  Auto-contenidos: particularmente en el comunicación entre el cliente y los lado del cliente no se necesita ningún Servicios Web. Al igual que XML es software adicional, solamente basta con independiente de la plataforma y la forma recurrir a soporte para XML y HTTP. En en que sea implementado. el lado del servidor es necesario únicamente un servidor que soporte el  WSDL: el Lenguaje de Descripción de manejo de mensajes SOAP (Protocolo de Servicios Web (WSDL) es un esquema Acceso Simple a Objetos) y protocolos basado en XML que sirve para describir un como HTTP. servicio. WSDL estandariza la forma en como un Servicio Web representa la  Independientes de lenguaje e entrada y salida de datos a partir de una interoperables: tanto las aplicaciones del invocación externa del Servicio Web, cliente y servidor para el uso y la especifica las operaciones que ofrece un ejecución de Servicios Web pueden ser Servicio Web y la estructura de las implementadas en diferentes entornos. mismas. También describe a los servicios Básicamente cualquier lenguaje de como un conjunto de nodos o puertos. programación puede ser usado para Estos nodos o puertos asocian direcciones implementar Servicios Web. de red y la colección o unión de los La interoperabilidad como tal es una de las mismos definen el servicio. características más resaltantes en este tipo  UDDI: el estándar para el Descubrimiento, de aplicaciones permitiendo así la Descripción e Integración Universal utilización de otras tecnologías que le dan (UDDI) proporciona mecanismos para la gran robustez y soporte a la ejecución de publicación y el descubrimiento de los Servicios Web en diferentes información de los Servicios Web, plataformas. Desde otro punto de vista describiendo también el tipo de puede verse como una ventaja ante otras operaciones que estos ofrecen. UDDI aplicaciones que se ejecutan sobre como estándar industrial nace bajo la entornos distribuidos. necesidad de crear plataformas Debido a lo joven que es la tecnología de independientes que permitiera a las los Servicios Web, subyacen un conjunto organizaciones integrar, descubrir, de estándares que permiten dar describir y categorizar los negocios. A confiabilidad, refiriendo todo lo través de mensajes SOAP, otras personas, relacionado con el modo de operación, empresas u organizaciones pueden hacer el descripción, localización y envío y descubrimiento de los Servicios Web recepción de mensajes de los Servicios registrados. Web. La Figura 1 representa la interacción de las Las siguientes son las tecnologías que tecnologías nombradas anteriormente: conforman el núcleo a través del cual se pueden implementar y ejecutar Servicios Web: 94
  • 95. requiere de unos cuantos Kilobytes de memoria para poder funcionar de manera correcta, incluyendo además un recolector de basura pequeño. La arquitectura J2ME esta 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 Figura 1. Escenario de Servicios Web Java, optimizadas para diferentes tipos de procesamiento. Al igual que los fabricantes desarrollan nuevas características en sus dispositivos, los proveedores 2.2 Generalidades de J2ME de servicio desarrollan nuevas aplicaciones, estas configuraciones mínimas pueden ser expandidas con librerías adicionales que administran las La plataforma J2ME se orienta al desarrollo de necesidades de un segmento del mercado en aplicaciones para pequeños dispositivos con particular. Existen cuatro conceptos esenciales, que limitaciones graficas, de procesamiento y memoria conforman el corazón de la arquitectura de J2ME: (teléfonos móviles, PDAs, Beepers, etc.). J2ME consta de un conjunto de especificaciones para definir una colección de plataformas, apropiadas 1. Máquina Virtual. para un subconjunto del amplio rango de 2. Configuración. dispositivos para usuarios existentes en el mercado 3. Perfil. 4 . 4. Paquetes Opcionales. J2ME esta conformado por los siguientes La configuración utilizada en la implementación de componentes: Servicios Web en telefonía celular es CLDC en conjunto con el perfil MIDP (Perfil de Información  Múltiples máquinas virtuales especifica para el Dispositivo Móvil). para cualquier tipo de dispositivo pequeño. 2.3 Servicios Web en J2ME  Configuraciones, clases básicas orientadas para implementaciones en dispositivos con J2ME al igual que la Edición Empresarial de Java 2 características específicas. Las dos (J2EE) tiene capacidades para el soporte de configuraciones manejadas en J2ME son: Servicios Web y análisis de datos XML a través de Configuración de Dispositivos Limitados la adaptación de APIs implementadas en J2EE, pero con Conexión, CLDC usada en no con todas las funcionalidades debido a las dispositivos con restricciones de características restrictivas que impone J2ME. procesamiento y memoria, y CDC, La especificación que maneja el soporte de Configuración de Dispositivos Conectados Servicios Web es la JSR-172 (Solicitud de para dispositivos con más recursos. Especificaciones Java 172). Esta especificación lanzada el 3 de marzo de 2004 permite a través de  Los Perfiles, librerías Java para familias de dos APIs o paquetes opcionales el manejo del flujo dispositivos específicas, con clases para la de datos XML y la comunicación con el Servicio implementación de funcionalidades de más Web. El objetivo de esta descripción de Servicios alto nivel. Web es la interoperabilidad para un marco general que pretende estandarizar el desarrollo de entornos Debido a las limitaciones de recursos que son empresariales en J2ME. manejadas en la telefonía celular, la maquina virtual ___________________________ con respecto a las demás plataformas Java se 4 [4]http://www.lcc.uma.es/~galvez/ftp/libros/J2ME.pdf denomina KVM (Máquina Virtual Kilo) ya que solo 95
  • 96. 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 Figura 2. Servicios Web en J2ME 6 procesamiento de documentos en formato XML  2.3.1 Estado del arte “permita el rehúso de conceptos de servicio cuando se están diseñando Desde el año 2003, luego que se estandarizará la clientes J2ME en aplicaciones plataforma J2ME por parte de la Sun Microsystems empresariales” 5 Incorporation a través de JCP (Comunidad de Procesos Java), se ha venido trabajando sobre las  permita la interoperabilidad de los clientes capacidades que se pueden ofrecer en los teléfonos J2ME con Servicios Web móviles por medio del uso de la plataforma J2ME a través de aplicaciones de conectividad, como lo son  proporcione un modelo de programación para la comunicación de clientes J2ME los Servicios Web implementando JSR (Requerimientos de Especificación Java). El JSR con Servicios Web. referido a la implementación de Servicios Web en Dos paquetes opcionales definen la Especificación telefonía móvil es denominado JSR 172 “J2ME de Servicios Web establecida a través de JSR 172. Web Services Especification” (Especificación de Estos paquetes son: Servicios Web en J2ME).  API Java para el Procesamiento de XML El grupo de expertos que han permitido un (JAXP) v1.2 (JSR 063): Soporta el análisis completo desarrollo de la especificación esta de documentos XML en la plataforma compuesto por 30 corporaciones e individuos J2ME. lideres en la industria. Fabricantes como Nokia, Motorola, Sony/Ericsson, LG, Siemens, Sharp y  API Java para Llamado de Procedimientos RIM, distribuidores de software como Symbian, Remotos basado en XML (JAX-RPC) v1.1 IBM, Borland, BEA y Sun Microsystems además (JSR 101): Permite a los dispositivos de distribuidores de servicios inalámbricos como móviles el acceso a Servicios Web NTT y Cingular hacen parte de este grupo. ubicados de forma remota. 2.3.1.1 Fuentes Primarias – Trabajos La arquitectura típica para el consumo de Servicios Relacionados - Internacional Web a través de la plataforma J2ME muestra la interacción entre las tecnologías que hacen posible 7  Universidad de la Laguna (España) el acceso que pueden tener los teléfonos celulares Acceso Dinámico a Servicios de una sobre los servidores que soportan la ejecución de Infraestructura Web desde Teléfonos los Servicios Web (VER Fig. 2). Móviles. Sánchez Nielsen, E., Martín Ruiz, S., Rodríguez Pedrianes, J. ____________________________ 2007. 5 [5]http://www.cs.wichita.edu/~chang/lecture/cs898t/lecture/j2  Proyecto de Software Cliente para me-webservice-spec.ppt Servicios Web Móviles8. Karimo, H. 6 2005. [6]http://developers.sun.com/mobility/reference/techart/index.js p ____________________________ 7 [7]http://www.w3c.es/Eventos/2007/MWeb/Comunicaciones/P apers/p3.pdf 8 [8]http://www.cs.helsinki.fi/u/chande/courses/cs/MWS/seminar /Articles/11.pdf 96
  • 97.  Universidad de Piura (Piura, Perú),  Realizar una documentación técnica acerca Universidad de Ciencias Aplicadas del Sur del funcionamiento de la aplicación final. 9 de Suiza (Suiza) . 3. Conclusiones Servicios Web para Entornos Informáticos. Arauco, E., Sommaruga, L. 2003. La visión de la Web actual tiende a la integración  10 de tecnologías y aplicaciones con el fin de Escuela Politécnica de Pernambuco universalizar el acceso a cada una de los servicios Servicio de distribución de contenidos ofrecidos en la red. RSS para dispositivos móviles a través de Servicios Web. Bandeira de Oliveira, R. La telefonía celular esta incursionando en estos 2005. aspectos dejando entrever la necesidad de los usuarios de conocer nuevos servicios ofrecidos a 2.3.1.2 Fuentes Primarias – Trabajos través de este tipo de dispositivos. Relacionados – Nacional  Universidad del Cauca Facultad de J2ME como plataforma Java proporciona la Ingeniería Electrónica y robustez necesaria para llevar a cabo la Telecomunicaciones Departamento de implementación de aplicaciones del lado del cliente Telemática 11. que permitan descubrir las funcionalidades y Aplicaciones para dispositivos móviles ventajas de los Servicios Web como tecnología utilizando la tecnología de Agentes. especifica para entornos distribuidos. Barrera Campo, José F., Martínez Es de resaltar la gran importancia que cumple la Vásquez, David A. 2004. implantación de patrones de desarrollo con el fin de darle integridad a las aplicaciones desarrolladas  UNIVERSIDAD SANTO TOMAS, sobre J2ME. Medellín 12. Proveedor de Servicios Basados en Localización para Dispositivos Móviles. Castañeda, Hernán A., Gómez, Juan D., Leal, Alexander. 2006. 2.4 Logros en relación con los objetivos  Realización de análisis bibliográfico profundo referente a las características relevantes de la plataforma J2ME, identificando así el hecho de por que se utiliza en la implementación de Servicios Web en telefonía celular.  Análisis del estado del arte referente a la implantación de Servicios Web en telefonía celular tanto a nivel nacional como a nivel internacional. ____________________________  Evaluación de las funcionalidades que 9 [9]http://www.ti.ch/dt/da/spaa/temi/oasi/Pubblicazioni/ ofrecen los emuladores para la ejecución doc/2004_IEMS_Web_services_for_environmental_informatics. de la aplicación ubicada en el teléfono pdf 10 celular que tiene acceso a los Servicios [10]http://www.poli.br/arquivos/DOWNLOADS/TCC/COMP Web. UTACAO/20052/RafaelBandeira.pdf 11 [11]http://ingenieria.udea.edu.co/~vision/Grupo/Cv/Agentes/  Implementación del sistema que MR-DSOA.pdf administra el acceso a Servicios Web 12 [12]ftp://jano.unicauca.edu.co/cursos/Electiva_sat/presentacio ubicados de forma remota desde el nes/SAT-sesion02-Servicios.pdf teléfono celular. 97
  • 98. 4. BIBLIOGRAFÍA U. Wahli, O. Burroughs, O. Cline, A. Go, L. Tung, Web Services for WebSphere Application M. Juntao Yuan, Enterprise J2ME Developing Server Version 6.1. IBM, Sep. 2006. [Online]. Mobile Java Applications. New Jersey: Available: Prentice Hall PTR, 2004, ch. 17. http://www.redbooks.ibm.com/redbooks/pdfs/s V. Lee, H. Schneider, R. Schell, Mobile g247257.pdf. Applications Architecture, Design and J. Y. Chung, K. J. Lin, and R. G. Mathieu, quot;Web Development. New Jersey: Prentice Hall PTR, Services Computing: Advancing Software 2004. Interoperability,quot; IEEE Computer Society, p. 1, I. Garcia, M. Polo, F. Ruiz, M. Piattini, Servicios Oct. 2003. Available: Web. Universidad de Castilla, La Mancha, http://www.csdl.computer.org/comp/mags/co/2 España, En. 2005. [Online]. Available: 003/10/rx035.pdf www.info- C. E. Ortiz, quot;Introduction to J2ME Web Services,quot; b.uclm.es/descargas/thecnicalreports/DIAB-05- Sun Developer Network, Sun Microsystems, 01-1/ServiciosWeb.pdf. Apr. 2004. Available: http://developers.sun.com/mobility/reference/te chart/index.jsp 98
  • 99. CONCLUSIONES La visión de la Web actual tiende a la integración de tecnologías y aplicaciones con el fin de universalizar el acceso a cada una de los servicios ofrecidos en la red. En el mercado de la Telefonía Móvil, específicamente el de la Telefonía celular en su afán de conseguir brindar más servicios a los usuarios ha permitido la creación y adaptación de tecnologías que cumplan con este objetivo. J2ME es una buena opción para la ejecución de aplicaciones del lado del cliente que ofrezcan accesos a Servicios Web ubicados en la red. Pero es la Especificación de Servicios Web soportada sobre la plataforma J2ME quien contextualiza los medios necesarios para llevar a cabo la implementación de aplicaciones que tengan acceso de forma rápida y sincronizada a los Servicios Web que están soportados sobre una arquitectura distribuida. Esta especificación llamada JSR 172 rige todos los protocolos que permiten la realización de tales aplicaciones. Existe una característica importante en Java que es la interoperabilidad. Esta característica ha permitido que empresas dedicadas al desarrollo de tecnología adecuen sus propias APIs para el desarrollo y ejecución de software que cumpla con los requisitos exigidos por la JSR 172, como es el caso de la Organización Enhydra con los paquetes kXML y kSOAP. Es de resaltar la gran importancia que cumple la implantación de patrones de desarrollo con el fin de darle integridad a las aplicaciones desarrolladas sobre J2ME. 99
  • 100. OBSERVACIONES Y RECOMENDACIONES Es necesario tener en cuenta que para la implementación de este tipo de aplicaciones y debido a que J2ME es una plataforma poco conocida localmente debe hacerse un extenso y minucioso estudio que le de soporte al posterior desarrollo del sistema propuesto. Se pretende hacer una investigación profunda sobre la instalación y configuración de redes inalámbricas que soporten la tecnología móvil con el fin de refinar el sistema desarrollado y poder ejecutar dicha aplicación en teléfonos móviles que soporten la especificación de Servicios Web en J2ME. El acceso de aplicaciones remotas implica de manera obligada el ajuste de un esquema que asegure las peticiones y respuestas involucradas en la comunicación del Servidor con el cliente móvil, que intenta obtener beneficios de las funcionalidades ofrecidas en un entorno distribuido como el que soportan las tecnologías de los Servicios Web. La adaptación de arquitecturas de diseño de software como MVC intenta hasta cierto punto manejar la seguridad requerida, pero no controla el acceso inadecuado al que esta expuesto un software de este tipo. Para esto es necesario el estudio de metodologías que ayuden a implementar seguridad en el acceso a Servicios Web. 100
  • 101. BIBLIOGRAFIA [1] Sun MicroSystems. Introducción a J2ME y KVM, 8 páginas, San Antonio California, Estados Unidos 2000. [Online: http://java.sun.com/j2me/docs/zip/cldc11api.zip]. [3] Rojas Gálvez Sergio, Lucas Ortega Díaz. Java a tope: J2ME (Java 2 Micro Edition), 200 páginas, Universidad de Málaga, Málaga, España 2003. [Online: http://www.lcc.uma.es/~galvez/ftp/libros/J2ME.pdf]. [3] Garcia I., Polo M., Ruiz F., Piattini M. Servicios Web, 200 páginas, Universidad de Castilla, La Mancha, España 2005. [Online: www.info- ab.uclm.es/descargas/thecnicalreports/DIAB-05-01-1/ServiciosWeb.pdf]. [4] Ortiz E. C. Introducción a Servicios Web J2ME, 1 página Sun Microsystems, San Antonio California, Estados Unidos 2004 [Online: http://developers.sun.com/mobility/reference/techart/index.jsp]. [5] Armstrong S. J2ME Web Services Specification, 8 páginas, East Texas Data Service, Texas, Estados Unidos 2001 [Online: http://www.cs.wichita.edu/~chang/lecture/cs898t/lecture/j2me-webservice- spec.ppt]. [6] Ellis J., Young M. J2ME Web Services 1.0, 88 páginas, Sun Microsystems, Santa Clara California, Estados Unidos 2003. [Online: http://www.sun.com/software/communitysource/j2me/wsa/download.xml/j2me_ web_services-1_0-fr-spec.pdf]. [7] Sun MicroSystems. JAXP Developers Tutorial, 18 páginas, Sun Microsystems, Santa Clara California, Estados Unidos 2003. [Online: http://www.sun.com/software/communitysource/j2me/wsa/download.xml/j2me_ web_services-1_0-src.zip/j2me-ws-1.0/doc/JAXP_Tutorial.pdf]. [8] Sun MicroSystems. JAX-RPC Developers Tutorial, 18 páginas, Sun Microsystems, Santa Clara California, Estados Unidos 2003. [Online: http://www.sun.com/software/communitysource/j2me/wsa/download.xml/j2me_ 101
  • 102. web_services-1_0-src.zip/j2me-ws-1.0/doc/JAXRPC_Tutorial.pdf]. [9] Juntao Yuan M., Colson J. Enterprise J2ME Developing Mobile Java Applications, 486 páginas, Prentice Hall PTR, New Jersey, Estados Unidos 2004. [10] kXML. kXML API, 1 página, 2003. [Online: http://kxml.sourceforge.net/kxml2/javadoc/]. [11] kSOAP. kSOAP API, 1 página, 2004. [Online: http://ksoap2.sourceforge.net/doc/api/]. [12] Kontio M. The MVC design pattern in MIDP development. 1 página, IBM developerWorks. 2004. [Online: http://www- 128.ibm.com/developerworks/wireless/library/wi-arch6/]. [13] Sun Developer Network. Sun Java Wireless Toolkit for CLDC Download, 1 página, Sun Microsystems 2007. [Online: http://java.sun.com/products/sjwtoolkit/download.html]. TM [14] Forum Nokia. Installation Guide for Nokia Prototype SDK 4.0 for Java ME, 9 páginas, Nokia, 2006. [Online: http://sw.nokia.com/id/c2295ccf-c349- 46b7-bb8c-d51b3d3c2eb5]. [15] Sony Ericsson. Sony Ericsson SDK 2.5.0 for the Java ME Platform Readme, 1 página, Sony Ericsson, 2007. [Online: https://developer.sonyericsson.com/getDocument.do?docId=96958]. [16] Sánchez Nielsen, E., Martín Ruiz, S., Rodríguez Pedrianes, J. Acceso Dinámico a Servicios de una Infraestructura Web desde Teléfonos Móviles, 8 páginas, Universidad de la Laguna, Tenerife, España 2007. [Online: http://www.w3c.es/Eventos/2007/MWeb/Comunicaciones/Papers/p3.pdf]. [17] Karimo, H. Mobile Web Services client Software project, 27 páginas, 2005. [Online: http://www.cs.helsinki.fi/u/chande/courses/cs/MWS/seminar/Articles/11.pdf]. [18] Arauco, E., Sommaruga, L. Web Services for Enviromental informatics, 7 102
  • 103. páginas, Universidad de Piura, Universidad de Ciencias Aplicadas del Sur de Suiza (Suiza), Piura, Perú, 2003. [Online: http://www.ti.ch/dt/da/spaa/temi/oasi/Pubblicazioni/ doc/2004_IEMS_Web_services_for_environmental_informatics.pdf]. [19] Bandeira de Oliveira, R. Servicio de distribución de contenidos RSS para dispositivos móviles a través de Servicios Web, 96 páginas, Escuela Politécnica de Pernambuco, Pernambuco, Brasil 2005. [Online: http://www.poli.br/arquivos/DOWNLOADS/TCC/COMPUTACAO/20052/Rafae lBandeira.pdf]. [20] Barrera Campo, José F., Martínez Vásquez, David A. Aplicaciones para dispositivos móviles utilizando la tecnología de Agentes, 1 página, Universidad del Cauca Facultad de Ingeniería Electrónica y Telecomunicaciones Departamento de Telemática, Popayán, Colombia 2004. [Online: http://ingenieria.udea.edu.co/~vision/Grupo/Cv/tesis-jfbc.htm]. [21] Castañeda, Hernán A., Gómez, Juan D., Leal, A. Proveedor de Servicios Basados en Localización para Dispositivos Móviles, 158 páginas, UNIVERSIDAD SANTO TOMAS, Medellín, Colombia 2006. [Online: http://ingenieria.udea.edu.co/~vision/Grupo/Cv/Agentes/MR-DSOA.pdf]. [22] Prieto, Felipe A., Rodríguez, Luisa F. Streaming de Audio a través de Dispositivos Móviles utilizando J2ME, 123 páginas, Universidad El Bosque, Facultad de Ingeniería de Sistemas, Bogotá, Colombia 2007. [Online: http://www.unbosque.edu.co/facultades/sistemas/webinves/tesis0602/DocPri etoRodriguez.pdf]. [23] Grupo Condor S.A. Bucaramanga, Colombia 2008. [Online: http://www.grupo-condor.net/index.htm]. [24] Martínez Chaparro F. Búsqueda de rutas para el sistema de Transporte Masivo Transmilenio utilizando la tecnología J2ME, Universidad San Martín, Bogotá, Colombia 2007. [Online: http://ingenieria.sanmartin.edu.co/graduacion/notasGraduacion20071.p 103
  • 104. hp]. [25] Gonzáles Barahona J., Quirós Pedro de las H. Licencia Pública GNU (Traducción oficial), 3 páginas, España 1991. [Online: http://es.tldp.org/Otros/gples/gples.html]. [26] Wikipedia, La enciclopedia libre. Licencia de Software, 1 página, 2008. [Online:http://es.wikipedia.org/wiki/CLUF]. 104
  • 105. ANALISIS BIBLIOGRAFICO  Juntao Yuan M., Colson J. Enterprise J2ME Developing Mobile Java Applications, 486 páginas, Prentice Hall PTR, New Jersey, Estados Unidos 2004. Este libro especifica técnicas de desarrollo de aplicaciones empresariales en J2ME, además muestra algunos casos de estudios sobre dichas implementaciones.  http://java.sun.com/javame/index.jsp. En esta página se encuentra referenciada toda la documentación relacionada con la plataforma J2ME proporcionada por la Sun Microsystems.  http://www.lcc.uma.es/~galvez/ftp/libros/J2ME.pdf. La dirección hace referencia a un manual que puede ser el punto de partida para el estudio de las características generales de J2ME como plataforma.  http://java.sun.com/javame/reference/apis.jsp. Página que maneja información acerca de especificaciones para paquetes opcionales de J2ME como JSR 172 (Especificación de Servicios web en J2ME).  http://kxml.sourceforge.net/kxml2/javadoc/. Información del paquete opcional para el análisis de documentos XML sobre J2ME.  http://ksoap2.sourceforge.net/doc/api/. Información del paquete opcional para el llamado a procedimientos remotos, envió y recepción de mensajes SOAP sobre J2ME. Cumples casi la totalidad de las funcionalidades que tiene JSR 172. 105
  • 106. GLOSARIO DE TERMINOS Applet: aplicaciones Java que se ejecutan en el contexto o que componen otro programa como por ejemplo una pagina Web. Framework: representa una arquitectura de software definida en la cual otro proyecto de software puede ser organizado y desarrollado. Interoperabilidad: habilidad que tiene un sistema o producto para trabajar con otros sistemas o productos sin un esfuerzo especial por parte del usuario. Java Server Pages: también conocida como JSP, es una tecnología basada en Java que permite la generación de contenido dinámico para páginas Web. MIDlets: aplicación J2ME desarrollada bajo la especificación MIDP. Servlet: tecnología Java que consta de un mecanismo consistente para la extensión de funcionalidades de un Servidor Web. 106
  • 107. ABREVIATURAS UTILIZADAS A. API: Interfaz de Programación de Aplicaciones. AWT: Herramienta para Ventanas Abstracta. C. CDC: Configuración de Dispositivos con Conexión. CLDC: Configuración de Dispositivos Limitados con Conexión. CISC: Computadoras con Conjuntos de Instrucciones Complejas. E. EJB: Componentes Empresariales de Java. EULA: Licencia de Usuario Final. F. FTP: Protocolo de Transferencia de Archivos. H. HTTPS: Protocolo de Transferencia de Hipertexto Seguro. J. JAXP: API Java para el Procesamiento de XML. JAX-RPC: API Java para XML-basado en RPC. JCP: Comunidad de Procesos Java. 107
  • 108. JDBC: Conectividad de Bases de Datos Java. J2EE: Java 2 Edición Estándar. J2ME: Java 2 Edición Micro. J2SE: Java 2 Edición Estándar. JSR: Requerimiento de Especificaciones Java. M. MIDP: Perfil de Información del Dispositivo Móvil. MVC: Modelo Vista Controlador. P. PDA: Asistente Digital Personal. R. RISC: Computadoras con Conjuntos de Instrucciones Reducida. RMS: Administración de Almacenamiento de Registros. RPC: Llamado a Procedimientos Remotos. S. SAX: API Simple para XML. SDK: Kit de Desarrollo Estándar. SMTP: Protocolo Simple de Transferencia de Correo. SOAP: Protocolo de Acceso Simple a Objetos. U. UDDI: Descubrimiento, Descripción e Integración Universal. 108
  • 109. URI: Identificador Uniforme de Recursos. W. WSDL: Lenguaje de Descripción de Servicios Web. X. XML: Lenguaje de Marcado eXtensible. 109
  • 110. ANEXOS 110
  • 111. Anexo 1. MANUAL DE USUARIO PARA EL SISTEMA DE ADMINISTRACIÓN DE SERVICIOS WEB EN TELEFONÍA MOVIL A TRAVES DE LA PLATAFORMA J2ME 111
  • 112. Contenido. Pág. 1. INTRODUCCIÓN. 113 1.1. Objetivos de desarrollo. 113 1.2. Entornos de desarrollo. 113 1.3. Descripción del sistema. 113 2. RUTAS DE NAVEGACIÓN. 115 2.1. Artesanías de Colombia. 115 2.2. Cines de Colombia. 116 112
  • 113. 1. INTRODUCCIÓN. Este manual de usuario describe las características generales de las aplicaciones que componen el Sistema para la administración de Servicios Web en J2ME, mostrando sus rutas de navegación y especificaciones generales que permitan al usuario final del sistema una mejor adaptación y entendimiento de la ejecución del mismo. 1.1. Objetivos de Desarrollo. Esta implementación tiene por objetivo conocer las características de la plataforma J2ME en cuanto al desarrollo de aplicaciones móviles que permitan el acceso a entornos distribuidos que soportan Servicios Web ubicados de forma remota. 1.2. Herramientas de desarrollo Para el desarrollo del sistema se utilizaron las siguientes herramientas:  Maquina Virtual Java jdk1.6.0_06: entorno de ejecución y librerías de Java.  Sun Java Wireless Toolkit 2.5.2: herramienta para el desarrollo de aplicaciones móviles de Java.  Apache Tomcat 6.0: servidor de aplicaciones para alojar Servicios Web.  Axis: Framework para el desarrollo de Servicios Web.  Nokia Prototype SDK 4.0 for Java ™ ME: emulador de Nokia para aplicaciones J2ME.  Sony Ericsson SDK 2.5.0.2 for the Java ™ ME Platform: emulador de Sony Ericsson para aplicaciones J2ME.  JCreator Pro 4.5: editor de archivos fuentes Java. 1.3. Descripción del sistema. El Sistema para la Administración de Servicios Web esta compuesto por dos 113
  • 114. Servicios Web alojados en el servidor de aplicaciones Tomcat. Además consta con dos aplicaciones que acceden de forma independiente los Servicios Web. La primera aplicación tiene el control sobre los datos de algunas Artesanías de Colombia distribuidas a nivel nacional. La segunda administra la información obtenida a partir del Servicio Web que se refiere a las Salas de Cine en cuanto a varías películas, horarios y salas de cines en todo el país. Se utilizo una arquitectura de diseño conocida como MVC para poder desarrollar de manera separada la Interfaz de Usuario y el acceso a Servicios Web. 114
  • 115. 2. RUTAS DE NAVEGACIÓN. 2.1. Artesanías de Colombia. La pantalla A representa la pantalla principal de acceso al sistema, mostrando dos opciones, cada una describe que Servicio Web pretende acceder. En este caso al dar clic en Menú y escoger la opción 1. Ingresar se muestra la pantalla del menú principal del Servicio Artesanías de Colombia. Este menú consta de tres opciones:  Pantalla 1, opción Ver datos Artesanías. Se presiona el comando Menú y la opción Seleccionar. Al hacer esto se despliega la pantalla 1a que lista las diferentes artesanías. Si se escoge una de la lista, se presiona el comando Menú y la opción Seleccionar, se podrá navegar a través del Servicio Web en la pantalla 1b mostrando de forma detallada el precio, región de origen y una imagen descriptiva de la artesanía seleccionada en la pantalla 1a.  Pantalla 2, opción Contacto Proveedores. Se presiona el comando Menú y la opción Seleccionar. Al hacer esto se despliega la pantalla 2a que lista las diferentes artesanías. En este caso se escoge Sombrero Vueltiao al igual que en la Pantalla 1, al presionar el comando Menú y la opción Seleccionar se podrá navegar a través del Servicio Web en la pantalla 2b mostrando información de los proveedores que distribuyen la artesanía seleccionada en la pantalla 2a.  Pantalla 3, opción Ayuda. Esta opción muestra con la activación del comando Menú información relacionada que sirve de ayuda al usuario de la aplicación, dando pautas mínimas para el conocimiento del sistema. Las rutas de navegación para Artesanías de Colombia se observa con mayor claridad en la Figura 1. 115
  • 116. 2.2. Cines de Colombia. La pantalla B representa la pantalla principal de acceso a la aplicación de Cines de Colombia, mostrando dos opciones, cada una describe que Servicio Web pretende acceder. Bajar y escoger la opción Cine, dar clic en Menú y escoger la opción 1. Ingresar se muestra la pantalla del menú principal del Servicio Cines de Colombia. Este menú consta de dos opciones:  Pantalla 1, opción Ver Cartelera. Se presiona el comando Menú y la opción Seleccionar. Al hacer esto se despliega la pantalla 1a que lista las diferentes películas. Si se escoge una de la lista, en este caso Hellboy 2, se presiona el comando Menú y la opción Seleccionar, se podrá navegar a través del Servicio Web en la pantalla 1b mostrando de forma detallada la sala de cine, el precio y una imagen descriptiva de la película seleccionada en la pantalla 1a.  Pantalla 2, opción Ver Horarios Películas. Se presiona el comando Menú y la opción Seleccionar. Al hacer esto se despliega la pantalla 2a que lista las diferentes películas. En este caso se escoge Hellboy 2 al igual que en la Pantalla 1, al presionar el comando Menú y la opción Seleccionar se podrá navegar a través del Servicio Web en la pantalla 2b mostrando información de la sala de cine y el horario en que será presentada la película seleccionada en la pantalla 2a. Las rutas de navegación para Cines de Colombia se observa con mayor claridad en la Figura 2. 116
  • 117. 1a 1b 1 A 3 2a 2b 2 3a Figura 1. Rutas de Navegación para la Aplicación Artesanías de Colombia. 117
  • 118. 1a 1b 1 B 2 2a 2b Figura 2. Rutas de Navegación para la Aplicación Cines de Colombia. 118
  • 119. RESEÑA BIOGRAFICA DEL DIRECTOR Msc. Ing. Luz Marina Santos Jaimes Nivel de Educación. Ingeniera de Sistemas Magíster en Ingeniería de Sistemas y Computación Perfil profesional. Redes TCP/IP, Sistemas Distribuidos y Seguridad Computacional. Experiencia profesional. Docencia: -Informática -Programación I -Programación II -Programación III (Programación orientada a objetos) -Herramientas y utilidades computacionales (Programación Estructurada) -Estructura de datos -Sistemas operativos -Paradigmas de programación -Redes de Computadores y Sistemas Distribuidos I -Redes de Computadores y Sistemas Distribuidos II -Comunicaciones Industriales -Protección de Sistemas Informáticos -Electiva de Ingeniería I – Sistemas Distribuidos- Desarrollo de aplicaciones para computación móvil -Electiva de Ingeniería II- Trabajo Cooperativo -Electiva de Ingeniería III- Java Enterprise System
  • 120. Dirección de proyectos de pregrado: -Simulador de redes virtuales basado en el Superstack III 3300 de 3COM, Ingeniería Electrónica, 2001 -Simulador de redes virtuales basado en el superstack III Switch 4007 y 4900 de 3COM,Ingeniería Electrónica, 2001 -Simulador de redes virtuales basado en office connect 56k Lan MODEM dual e ISDN Lan MODEM de 3COM, Ingeniería Electrónica, 2001 -Diseño e Implementación de un portal WAP para la Universidad de Pamplona, Ingeniería Electrónica, 2003 -Ambiente virtual para el Campus de la Universidad de Santander UDES sede Cúcuta para acceso interactivo a través de Internet bajo plataforma java, Ingeniería de Sistemas Cúcuta, 2004 -Diseño e Implementación de un Sistema Colaborativo de Mensajería Electrónica para la Universidad de Pamplona, 2006 -Metodología para el Análisis Forense en Linux, Ingeniería de Sistemas, 2006 -Análisis del Protocolo IPSec en ambientes IPv6, Ingeniería de Sistemas, 2006 -Metodología para la Detección de Intrusos en Linux, Ingeniería de Sistemas, 2006 -Análisis de tráfico entre LANs y VLANs para el laboratorio de redes de la Universidad de Pamplona, Ingeniería de Sistemas, 2007 -Aplicación de técnicas inteligentes basadas en lógica difusa como soporte para la evaluación de trabajos de grado, Ingeniería de Sistemas, 2007 Investigación -Directora Grupo de Investigación Ciencias Computacionales “CICOM” -Presidente de “CICOM’05 Congreso Binacional en Sistemas, Informática e Ingeniería del Conocimiento”, Pamplona, noviembre de 2005, ISSN 1900-7329 -Presidente de “CICOM’07”, Mayo 2007, ISSN 1900-7329 -Presidente del Seminario Modelado, Automatización e Integración de Procesos, Pamplona, Noviembre de 2006 -Proyecto Red IPv6 Universidad de Pamplona Ponencias
  • 121. -Ponencia “Guía para la evaluación de seguridad en un Sistema, II Jornada nacional de Seguridad Informática”, Asociación colombiana de ingenieros de Sistemas, Bogotá, 2002 -Ponencia “Tutorial de Lógicas Descriptivas”, Euro America Conference on Telematics and Information Systems (EATIS 2006), ISBN: 958-8166-37-3 --Ponencia: “Un razonador de Lógicas Descriptivas en Sistemas Inteligentes”, I Congreso de Computación Aplicada, CCA06, Universidad Nacional Experimental del Táchira, San Cristóbal, 2006 --Ponencia: “Similaridad estructural difusa entre trayectorias”, I Congreso de Computación Aplicada, CCA06, Universidad Nacional Experimental del Táchira, San Cristóbal, 2006 -Expositor- I Jornada Ciencia Tecnología e Innovación, Colciencias, Pamplona, 2006 -Ponencia “Pruebas de IPSec empleando el protocolo IPv6”, CICOM’07 Congreso Binacional en Sistemas, Informática e Ingeniería del Conocimiento, Universidad de Pamplona, Mayo de 2007, ISSN:1900-7329 -Ponencia “Arquitectura y proceso de desarrollo de aplicaciones Smart Client”, CICOM’07 Congreso Binacional en Sistemas, Informática e Ingeniería del Conocimiento, Universidad de Pamplona, Mayo de 2007, ISSN: 1900-7329 Artículos -Artículo “Desarrollo de ambientes virtuales en Java 3D”, Revista Colombiana de Tecnologías de Avanzada, Universidad de Pamplona, 2005, ISSN: 1692-7257 -Artículo “La Expresiva SHIQ como Lenguaje Ontológico para la Web Semántica”, Revista Colombiana de Tecnologías de Avanzada, Universidad de Pamplona, 2006, ISSN: 1672-7257 -Artículo “IPv6 En la Universidad de Pamplona: Estado del Arte”. Revista Scientia et Technica, Universidad Tecnológica de Pereira, 2007, ISSN: 0122- 1701