FRAMEWORK DE MANEJO DE MENSAJES PARA DISPOSITIVOS MOVILES (CELULARES)

Transcripción

1 PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERIA CARRERA INGENIERIA DE SISTEMAS PROPUESTA DE TRABAJO DE GRADO Fecha de Presentación: Trabajo No.: ENTREGA FINAL SOLICITANTE Nombre: John Alexander Neira Rubiano Documento: de Bogotá Teléfonos: Casa: Celular: Correo Electrónico: TITULO FRAMEWORK DE MANEJO DE MENSAJES PARA DISPOSITIVOS MOVILES (CELULARES) OBJETIVO GENERAL Construir un marco de trabajo (Framework) de manejo de mensajes sencillo, que provea utilidades que permitan diseñar una arquitectura liviana en el desarrollo de un Web Service o J2EE orientado al uso de dispositivos móviles (Celulares). DIRECTOR Nombre: Ing. Luís Roberto Ojeda Teléfono: Casa: Empresa: Pontificia Universidad Javeriana Correo Electrónico: lojeda@javeriana.edu.co FIRMA DE LOS SOLICITANTES JOHN ALEXANDER NEIRA RUBIANO FIRMA DEL DIRECTOR DEL PROYECTO FIRMA DEL DIRECTOR DE CARRERA ING. LUIS ROBERTO OJEDA ING. HILDA CHAPARRO

2 FRAMEWORK DE MANEJO DE MENSAJES PARA DISPOSITIVOS MOVILES (CELULARES) John Alexander Neira Rubiano PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERÍA CARRERA DE INGENIERÍA DE SISTEMAS BOGOTA D.C. Febrero de

3 FRAMEWORK DE MANEJO DE MENSAJES PARA DISPOSITIVOS MOVILES (CELULARES) Autor: John Alexander Neira Rubiano Proyecto de grado para optar el título de Ingeniero de Sistemas Director: Ing. Luís Roberto Ojeda PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERÍA CARRERA DE INGENIERÍA DE SISTEMAS BOGOTA D.C. Febrero de

4 PONTIFICIA UNIVERSIDAD JAVERIANA FACULTAD DE INGENIERÍA CARRERA DE INGENIERÍA DE SISTEMAS Rector Magnífico Padre Gerardo Remolina Vargas S.J. Decano Académico Facultad de Ingeniería Ingeniero Roberto Enrique Montoya Villa Decano del Medio Universitario Facultad de Ingeniería Padre Antonio José Sarmiento Nova S.J. Director Carrera de Ingeniería de Sistemas Ingeniera Hilda Cristina Chaparro López Director Departamento de Ingeniería de Sistemas Ingeniero Germán Alberto Chavarro Florez. 4

5 Nota de Aceptación: Director del proyecto Jurado Jurado Bogotá D.C., Viernes, 4 de Febrero de

6 Artículo 23 de la Resolución No. 1 de Junio de 1946 La Universidad no se hace responsable de los conceptos emitidos por sus alumnos en sus proyectos de grado. Sólo velará porque no se publique nada contrario al dogma y la moral católica y porque no contengan ataques o polémicas puramente personales. Antes bien, que se vean en ellos el anhelo de buscar la verdad y la Justicia 6

7 TABLA DE CONTENIDO RESUMEN INTRODUCCIÓN OBJETIVO GENERAL OBJETIVOS ESPECIFICOS JUSTIFICACION ASPECTOS FUNDAMENTALES SOBRE J2ME TECNOLOGÍA J2ME HISTORIA INICIAL CONCEPTOS BÁSICOS ARQUITECTURA J2ME EL MIDLET CICLO DE VIDA DEL MIDLET ENTORNO DE EJECUCION DE MIDLETS DISTRIBUCION DE MIDLETS INTERFACES DE USUARIO MIDP ALTO NIVEL (HIGH LEVEL API) BAJO NIVEL (LOW LEVEL API) DESARROLLO DE WEB SERVICE Y J2EE DEFINICIÓN WEB SERVICE ARQUITECTURA WEB SERVICE NIVEL FÍSICO NIVEL LÓGICO PROTOCOLO SOAP WEB SERVICES PARA DISPOSITIVOS MÓVILES ARQUITECTURA WAP ESPECIFICACIÓN JSR 172 WSA MANEJO WEB SERVICE SOBRE J2ME KSOAP BY ENHYDRA XML-RPC VS SOAP LA EDICIÓN DE J2EE ARQUITECTURA J2EE HERRAMIENTAS PARA EL DESARROLLO DEL PROYECTO IDE JDEVELOPER 10G JAVA WEB SERVICE DEVELOPERS PACK 1.3 (JWSDP) J2ME WÍRELESS TOOLKIT JBOSS

8 7. PATRONES DE INGENIERÍA DE SOFTWARE Y FRAMEWORK O MARCO DE TRABAJO DEFINICIÓN PATRÓN CATALOGO DE DISEÑO DE PATRONES GOF CATALOGO DE PATRONES J2EE CAPA DE PRESENTACION CAPA DE NEGOCIO CAPA DE INTEGRACIÓN FRAMEWORK DEFINICIÓN FRAMEWORKS FRAMEWORK DE MANEJO DE MENSAJES PARA DISPOSITIVOS MÓVILES (CELULARES) ANÁLISIS ARQUITECTURA ARQUITECTURA FÍSICA ARQUITECTURA LÓGICA: DIAGRAMA DE PAQUETES DIAGRAMA DE CLASES PROTOTIPO FUNCIONAL APLICATIVO TRIQUI CASOS DE USO ARQUITECTURA: DIAGRAMA DE PAQUETES: DIAGRAMA DE CLASES: DIAGRAMA BASES DE DATOS: MANUAL DE USUARIO: MANUAL TÉCNICO: APLICATIVO RENTATOOLS CASOS DE USO: ARQUITECTURA: DIAGRAMA DE PAQUETES: DIAGRAMA DE CLASES: DIAGRAMA BASES DE DATOS: MANUAL DE USUARIO: MANUAL TÉCNICO: CONCLUSIONES PRIMERA CONCLUSIÓN SEGUNDA CONCLUSIÓN TERCERA CONCLUSIÓN CUARTA CONCLUSIÓN QUINTA CONCLUSIÓN SEXTA CONCLUSIÓN SEPTIMA CONCLUSIÓN OCTAVA CONCLUSIÓN NOVENA CONCLUSIÓN GLOSARIO DE SIGLAS

9 11. BIBLIOGRAFIA ANEXOS ANEXO A DIAGRAMAS DE CLASE DEL FRAMEWORK ANEXO B CASOS DE USO PROTOTIPO FUNCIONAL TRIQUI CASOS DE USO PROTOTIPO FUNCIONAL RENTATOOLS ANEXO C DIAGRAMAS DE CLASE TRIQUI DIAGRAMAS DE CLASE RENTATOOLS ANEXO D ANEXO D CASOS DE PRUEBA PROTOTIPO FUNCIONAL TRIQUI CASOS DE PRUEBA PROTOTIPO FUNCIONAL RENTATOOLS ANEXO E DIAGRAMAS DE COLABORACION ANEXO F INSTRUCCIONES DE USO DEL FRAMEWORK ANEXO G PRUEBAS DE CARGA Y ESTRES

10 TABLA DE IMAGENES FIGURA 4.3A: PACKET (PAQUETE) FIGURA 4.3B: ESQUEMA INTERCAMBIO DE DATOS FIGURA 4.4: ARQUITECTURA J2ME FIGURA 4.5.1: CICLO DE VIDA DEL MIDLET FIGURA 4.6: JERARQUÍA DE CLASES FIGURA 5.2.1: ARQUITECTURA MULTICAPAS FIGURA 5.2.2: INTERCAMBIO DE DATOS FIGURA 5.4.1: NIVEL FÍSICO FIGURA 5.5 ARQUITECTURA WSA FIGURA 5.7 ARQUITECTURA KSOAP FIGURA 5.8: ARQUITECTURA SOAP FIGURA ARQUITECTURA J2EE FIGURA 6.1 IDE ORACLE JDEVELOPER FIGURA 6.3 IDE J2ME WIRELESS TOOLKIT FIGURA 6.4 CICLO DE VIDA FIGURA 8.1: DIAGRAMA CASOS DE USO FRAMEWORK FIGURA 8.2: ARQUITECTURA GENERAL DEL FRAMEWORK DE MANEJO DE MENSAJES FIGURA 8.2.1:ARQUITECTURA FISICAGENERAL DEL FRAMEWORK DE MANEJO DE MENSAJES FIGURA 8.2.2A ESTRUCTURA MENSAJE FIGURA 8.2.2B: ARQUITECTURA LÓGICA FIGURA 8.3: DIAGRAMA DE PAQUETES FIGURA : DIAGRAMA CASOS DE USO TRIQUI FIGURA : ARQUITECTURA PROTOTIPO FUNCIONAL TRIQUI FIGURA : DIAGRAMA DE PAQUETES FIGURA : DIAGRAMA DE BASES DE DATOS FIGURA : PANTALLA CELULAR TRIQUI FIGURA : PANTALLA CELULAR TRIQUI FIGURA : PANTALLA CELULAR TRIQUI FIGURA : DIAGRAMA DE CASOS DE USO RENTATOOLS FIGURA : ARQUITECTURA PROTOTIPO FUNCIONAL RENTATOOLS FIGURA : DIAGRAMA DE PAQUETES DE RENTATOOLS FIGURA : DIAGRAMA DE BASES DE DATOS FIGURA : PANTALLA CELULARRENTATOOLS FIGURA : PANTALLA CELULARRENTATOOLS

11 RESUMEN La industria de Web Services ha evolucionado cada vez más y ha llevado a una gran variedad de negocios a implementarlos dentro de sus áreas de trabajo. Los Web Services son hoy en día tan importantes que las empresas deben tomarlos en cuenta si no quieren ser aventajadas por otras. Debido a la limitada capacidad de recursos que posee un dispositivo móvil y para facilitar la labor de desarrollo de un aplicativo que involucra las tecnologías de J2ME, J2EE, WAP y/o Web Services, se presenta la idea de construir un marco de trabajo (Framework) que ofrezca utilidades, que permitan diseñar una arquitectura liviana en el diseño de un Web Service para dispositivos móviles, para el caso especifico de esta investigación en celulares. Aplicando algunos de los patrones de diseño, los cuales son experiencias de otros desarrolladores para mejorar un diseño y con los cuales se puede obtener características tales como una mayor escalabilidad (fácil crecimiento), un bajo acoplamiento (No este totalmente ligada) y una alta cohesión (mantenga unida) sobre el trabajo realizado. Para ello se trabajó con tecnologías de Java, utilizando el IDE de Oracle (JDeveloper 10g) de la siguiente manera: Con Java 2 Micro Edtion (J2ME) para el desarrollo de la aplicación sobre el dispositivo móvil (Celular). Con Java 2 Enterprise Edition (J2EE) la parte Servidor con Enterprise Java Beans (EJBs) y con el IDE de Oracle para generar el Web Service. Se utilizó el Java Web Service Developer Pack 1.3 (JWSDP), que es una herramienta para montar Web Services y finalmente Jboss para manejar la parte de J2EE. Se utiliza el emulador de J2ME Wireless Toolkit 2.1 con el cual se emula el prototipo funcional bajo la plataforma J2ME para la validación del framework con varios servicios que se encuentren montados sobre un Web Service o sobre J2EE y que requieran el uso de éste. Igualmente cada uno de los servicios que operen sobre el Web Service o sobre J2EE, interactuarán con alguna de las interfaces o clases abstractas que el framework tenga, validando así la parte de manejo de mensajes. 11

12 INTRODUCCIÓN La tecnología evoluciona cada vez más, brindando herramientas informáticas que permiten realizar diversas actividades dentro del campo de los negocios y de la cultura, de una manera más eficiente y compacta. Los dispositivos móviles tienen un gran impacto en la actualidad, llevando a que exista más de un billón de subscritores con celular en el mundo 1. Con esto se puede observar que la popularidad que está adquiriendo el teléfono celular es bastante grande y es un motivo para que se estén utilizando tecnologías para la comunicación de estos, tales como la WAP y el J2ME; siendo la tecnología de J2ME la que ha generado un mayor impacto de modo que cada vez un mayor número de estos dispositivos móviles utilizan esta tecnología 2. Es esto lo que lleva a ver la verdadera importancia de un Web Service para dispositivos móviles y la necesidad de que los desarrolladores puedan obtener una herramienta que les brinde una mayor facilidad en la construcción de un Web Service, en especial si su aplicación trabaja con mensajes. Estos mensajes serian básicamente como los que se envían regularmente a través del correo electrónico, pero que también se podrían ver reflejados en otras aplicaciones, como por ejemplo en un alquiler de automóviles en el que se ingresaran los datos a través del celular con respecto a una reserva (tipo vehículo, marca, fecha), lo cual se convertirá en un mensaje SOAP que será enviado al servidor y se encargara de realizar la lógica del negocio, para luego retornar un mensaje de éxito vía SOAP. Otras posibles aplicaciones serian algunas como una agenda en la que se pondría un mensaje por cada cita que tenga, ver el estado del tiempo, etc. Son estos mensajes los que permitirán hacer la aplicación de una manera distribuida a través de la Web. El framework se basará en patrones de software y trabajará con un objeto llamado mensaje, el cual emulara la parte del mensaje SOAP y lo llevara desde el dispositivo móvil (Celular) hasta el Servidor, delegándole toda la parte del manejo del Web Service o de los EJBs al Servidor. También ofrecerá un patrón Mediador que consiste en poder obtener el mensaje y luego reenviarlo a otro destino que éste especifique. Todo estos servicios los ofrecerá a través de una interface con la que el desarrollador pueda trabajar para realizar la comunicación entre el dispositivo móvil (Celular) y el Web Server. 1 Ergon. J2ME wireless application framework Agosto de Kevin Curley. Accessing Web Services from Your Cell Pone. Agosto de

13 El proyecto se llevará a cabo en utilizando una metodología de tipo descriptiva y explicativa, ya que se cuenta con algunos elementos iniciales para el desarrollo del Framework y se adicionarán algunos aspectos que permitan realizar las tareas eficientemente. Este documento inicialmente dará a conocer: primero algunas bases fundamentales sobre el manejo de J2ME para el desarrollo de aplicaciones. En segunda instancia se tiene la parte Servidor, en donde se maneja todo el procesamiento del servidor como el manejo del Web Service y la plataforma J2EE para este proyecto. La tercera parte mostrara las herramientas que se utilizaron para llevar a cabo el proyecto, como JWSDP, J2ME Wireless Toolkit y el IDE de JDevelper. Al tener toda esta parte teórica clara, se pasara a la cuarta parte ha definir que es un Framework y como se relaciona con el desarrollo de esté proyecto. Una vez queden completamente claros estos conceptos se entra en la quinta parte en la que se define el desarrollo del proyecto llamado Framework de manejo de mensajes para dispositivos móviles y como se podría utilizar en una aplicación que involucre las tecnologías de J2ME, J2EE, WAP y/o Web Services. Finalmente, encontraremos las conclusiones del proyecto. 13

14 1. OBJETIVO GENERAL Construir un marco de trabajo (Framework) de manejo de mensajes sencillo, que provea utilidades que permitan diseñar una arquitectura liviana en el desarrollo de un Web Service o J2EE orientado al uso de dispositivos móviles (Celulares). 14

15 2. OBJETIVOS ESPECIFICOS Realizar un análisis del protocolo SOAP, que permite la comunicación de procesos a través de Internet y de esta manera poder establecer como se va ha utilizar dentro del diseño del framework. Realizar un análisis de lo que pueden brindar las tecnologías de J2ME y J2EE, en la construcción de un prototipo funcional que interactúa con el framework al exponer los servicios de dicho prototipo sobre el Web Service. Establecer una arquitectura que obedezca el objetivo del proyecto, con los elementos que se incluirán en la construcción del framework, en donde se pueda observar como se transmitirán los mensajes a través de la red. Comprender el uso de Patrones de Software en la construcción de un Framework y como encajan dentro del desarrollo del proyecto. Establecer la existencia de algunos marcos de trabajo o frameworks, con los que se pueda comparar el que se va a desarrollar en este proyecto. Realizar un comparativo de lo que brindar la tecnología J2ME frente a la de la WAP (Wireless Application Protocol). Validar el marco de Trabajo (Framework de Manejo de Mensajes) mediante la construcción de dos prototipos funcionales que interactúen con esté. 15

16 3. JUSTIFICACION La necesidad del uso de los dispositivos móviles para los empresarios de hoy en día, son de vital importancia dentro del desarrollo de sus actividades. Motivo por el cual, cada vez se crean nuevas soluciones que se ajusten a estas necesidades. Muchos de los desarrolladores de aplicaciones para dispositivos móviles buscan darle solución a todas estas necesidades haciendo uso de tecnologías como J2ME y J2EE, con las cuales deben implementar algunos servicios que pueden ser invocados desde un celular y que luego son procesados por un servidor Web. Es aquí donde se presenta la necesidad del uso de un framework que facilite la implementación de un tipo de solución como la anterior y que además provea una solución escalable, de baja cohesión y flexible. Un problema con el que se encuentran las aplicaciones que hacen uso de un Web Service que interactúan con un dispositivo móvil, es que deben recurrir al uso de paquetes creados por terceros para el manejo de intercambio de mensajes vía Internet, lo cual puede ser algo pesado, ya que estos paquetes constituyen una carga adicional para el dispositivo móvil, como el caso de KSOAP 3 un paquete de 42Kb. El framework de manejo de mensajes busca resolver el problema, al bajar esta carga haciendo uso de manejo de mensajes como otra alternativa más liviana con un paquete que este entre los 16Kb y 22Kb sobre el dispositivo y ofrezca utilidades que el desarrollador pueda utilizar en el desarrollo de un aplicativo que mezcle las tecnologías J2ME, WAP, J2EE y Web Services. Desde la perspectiva de Ingeniería de Sistemas, poder ver la importancia de técnicas de ingeniería de software como la aplicación de patrones de software, los cuales constituyen 3 Proyecto Enhydra. Marzo

17 una buena práctica de desarrollo sobre la realización de este proyecto y como se enfrenta ha una situación real que constituye un punto de justificación. 17

18 4. ASPECTOS FUNDAMENTALES SOBRE J2ME Inicialmente se quiere comprender el manejo de la tecnología de J2ME en la construcción de aplicaciones para dispositivos móviles, sobre la cual se implementará el prototipo funcional al final de la investigación. 4.1 TECNOLOGÍA J2ME (Java 2 Micro Edition) Es una plataforma sobre la que los programadores pueden construir e implementar programas para controlar dispositivos pequeños de cómputo. El equipo de Java agrupó las características de Java en tres ediciones, cada una teniendo un kit de desarrollo de software (SDK). La edición original de java, llamada Java 2 Standard Edition (J2SE) consiste de interfaces de programación de aplicación (APIs) necesarias para construir una aplicación en Java o un applet. J2ME contiene el API utilizado para crear aplicaciones para dispositivos móviles. J2EE es una versión extendida de J2SE que se acomoda sobre arquitecturas multicapas y tiene el API para construir aplicaciones de una arquitectura multicapas. 4.2 HISTORIA INICIAL J2ME apareció en la conferencia de JavaOne Developers a mediados de 1999 y fue dirigido a desarrolladores de dispositivos inalámbricos y pequeños dispositivos de cómputo, quienes necesitaban incluir una plataforma funcional en sus productos. 18

19 Los desarrolladores que buscan construir aplicaciones que corran en los teléfonos celulares, asistentes digitales personales y varios equipos consumidores y industriales deben mantener un balance entre un cliente Grueso y uno delgado. Un cliente grueso es un software de front-end que contiene la lógica que maneja una gran cantidad de procesamiento de información para el sistema. Un cliente delgado es un software de front-end que depende del software en el back-end para la mayoría de su procesamiento. Organización J2ME Primero definieron un ambiente de Java run-time y las clases principales que operan en cada dispositivo, llamado Configuración. La configuración define la JVM para un dispositivo de cómputo pequeño en particular. Luego se definió un perfil (Profile) de categorías de dispositivos de cómputo pequeños. Un Perfil consiste de un grupo de clases que pueden implementar características encontradas en un grupo relacionado de dispositivos de cómputo pequeños. Existen dos configuraciones para J2ME, estas son Conected Limited Device Configuration (CLDC) y la de Conected Device Configuration (CDC). Siete perfiles han sido definidos y estos son el Foundation Profile, Game Profile, Mobile Information Device Profile, PDA Profile, Personal Profile, Personal Basis Profile y RMI Profile. Un beneficio de J2ME, es su compatibilidad con cualquier dispositivo móvil que disponga de Java. Un dispositivo móvil que disponga de Java contiene la KVM, como por ejemplo Ericsson, Motorola, Nextel, Nokia, Panasonic y RIM. Adicionalmente, mantiene las características de seguridad del lenguaje Java. J2ME y dispositivos móviles: El protocolo Wireless Aplication Protocol (WAP) se convirtió en la industria inicial que creo estándares para la tecnología móvil. Formada por Ericsson, Motorola, Nokia y Unwired Planet en Es un mejoramiento de HTML, XML y TCP/IP. Muchas aplicaciones sofisticadas para comunicaciones en dispositivos móviles requerían que el dispositivo procesara la información, fuera de las capacidades de WAP. J2ME desarrollo un estándar para tapar este vacío que tenia la WAP. 4.3 CONCEPTOS BÁSICOS Tecnología Inalámbrica La tecnología de radio se basa en el fenómeno de las ondas. Las ondas son medidas de dos maneras: por el alto de la onda (amplitud) y por la frecuencia que es medida por el número de ondas por segundo. Las ondas de radio son medidas en watts. La transmisión de radio consiste de dos componentes: el transmisor y el receptor, los cuales deben estar ajustados en la misma frecuencia. Se utilizan antenas repetidoras para que la señal se mantenga. También llamada transceiver. Incrementando de esta forma la distancia en la que la señal viaja. 19

20 Radio Data Networks: La información es decodificada en variaciones de la onda. Esto es hecho al modificar la amplitud de la onda, llamada modulación de amplitud (AM), y al modificar la frecuencia, llamada modulación de frecuencia (FM). Los transmisores de radio, las repetidoras y los receptores son organizados para formar una red de radio que permite extender transmisiones sobre grandes distancias. Existen tres tipos: low-power single frequency, high-power single frequency y spread spectrum. Las redes de radio digitales, utilizan una tecnología de intercambio de packets para transmitir múltiples mensajes simultáneamente sobre un canal de comunicaciones. Cada mensaje es dividido en pequeñas piezas y colocadas en un sobre electrónico llamado packet (Figura 4.3a). Figura 4.3a: Packet (paquete) Dirección de Origen Información Dirección de Destino Código de Secuencia Error Check En la telefonía móvil se establece por medio de radio celular. El sistema de redes de radio para este tipo de comunicación recibe el nombre de células. Cada célula tiene un radio de 1,5 a 2,4 km y está equipada con una emisora de radio con su propia gama de frecuencias radiofónicas. Desde el punto de vista de un usuario que posee un dispositivo móvil como el celular y se desplaza con éste a través de la red de células, se van conmutando de una célula a otra mediante un sistema automatizado. Algunas de las empresas mas importantes que se destacan en la fabricación de estos dispositivos son Ericsson, Nokia y Motorola. Inglaterra fue el primer país en ofrecer servicios de redes de comunicación personal (PCN), que permiten utilizar este tipo de teléfonos en casa, en el trabajo o de forma portátil siempre que exista cobertura de la red. Las PCN operan con una frecuencia de unos 1,8 gigahercios. Originalmente los sistemas celulares eran analógicos, pero hoy día son casi todos digitales, como sucede con los GSM (Global System for Mobile Communication) y los de tercera generación de telefonía móvil. Los conceptos de KVM (Kilo Virtual Machine) y CVM (Compact Virtual Machine) corresponden a los nombres de maquinas virtuales para la configuración CLDC (KVM) y CDC (CVM), desarrolladas para su funcionamiento en los dispositivos móviles. Sin embargo, hay que tener en cuenta que ninguna de las especificaciones CLDC y CDC requieren el uso de KVM o CVM, sino solamente el uso de una maquina virtual Java que cumpla con los requisitos de la especificación en cuestión. 20

21 La figura 4.3b muestra el esquema de intercambio de datos entre aplicaciones J2ME y proveedores de contenidos a través de redes inalámbricas, ampliando la visión del uso de J2ME. Figura 4.3b: Esquema Intercambio de Datos Dispositivos Cliente Portales, Transporte Inalámbrico Servidores de Contenidos Gateway Cliente Móvil WAP, i-mode TCP/IP Aplicaciones Java Micro navegador J2ME Sistema Operativo Intercambio de datos TCP Servidor de Aplicaciones Correo electrónico Calendario Directorios Descarga de Aplicaciones Servidor Web Aplicaciones Java El proceso de comunicación que se realiza entre el dispositivo móvil (Celular) y el servidor se da mediante un gateway, el cual se encarga de recibir la comunicación mediante el protocolo WAP y luego la transforma al protocolo HTTP con el cual realiza el intercambio de datos con un servidor. El mismo proceso ocurre cuando se envía la respuesta hacia el dispositivo móvil, en el que el gateway toma la respuesta y la envía al dispositivo móvil mediante el protocolo WAP y este es ejecutado en el caso de J2ME mediante un MIDlet que se encuentra instalado sobre éste. 4.4 ARQUITECTURA J2ME La arquitectura de J2ME consiste de capas localizadas sobre el sistema operativo nativo de dispositivos móviles al que se le llama Connected Limited Device Configuration (CLDC) conformado por las dos primeras capas descritas a continuación y es el que forma el ambiente run-time para pequeños equipos de computo. 21

22 Esta compromete tres capas (Figura 4.4). La primera capa es la de configuración que incluye la maquina virtual de java (JVM), la cual interactúa directamente con el sistema operativo nativo. La JVM corresponde a una implementación específica de la maquina virtual para cada uno de los dispositivos, de manera que se pueda adaptar y soportar el Sistema Operativo que se ejecute sobre el dispositivo. La capa de configuración también maneja interacciones entre el perfil (Profile) y la JVM. Esta es una capa muy importante para los desarrolladores de perfiles, ya que define la parte común de las librerías y características de java que van a estar disponibles para un conjunto de dispositivos. La segunda capa es la de perfil (Profile) ubicada en los J2ME APIs, la cual consiste del mínimo conjunto de interfaces de programación de una aplicación (APIs) para el pequeño equipo de cómputo y esta orientada a la aplicación. La tercera capa es la de Mobile Information Device Profile (MIDP), es la que contiene los java APIs para las conexiones a la red, persistencia y interfaces de usuario. El corazón del perfil de MIDP es un MIDlet, el cual se explicará mas adelante. El pequeño equipo de cómputo tiene dos componentes dados por el fabricante (OEM). Estas son clases que interactúan con el MIDP para el intercambio de mensajes con el dispositivo. Figura 4.4: Arquitectura J2ME OEM Aplic. OEM classes MIDP J2ME APIs Configuración Java Virtual Machine Sistema Operativo Capa 3 Capa 2 Capa EL MIDLET Esta es la base sobre la que se corren las aplicaciones y se define así: Un MIDlet es una aplicación J2ME desarrollada sobre el perfil MID, es decir, una aplicación para dispositivos de información móviles cuyas limitaciones caen dentro de la especificación MIDP CICLO DE VIDA DEL MIDLET El encargado de manejar los estados en los que puede entrar el MIDlet es el Gestor de Aplicaciones (Application Managemente Software - AMS). Los estados en los que puede 4 Guía Práctica para Usuarios J2ME. Alonso Álvarez García, José Ángel Morales Grela. Ediciones Anaya Multimedia. España

23 entrar el MIDlet son en estado de Espera, que se presenta cuando es interrumpido por el Gestor de de aplicaciones. El estado de Activado, en donde se da la ejecución normal. Y finalmente el estado de Destruido que se da cuando el MIDlet termina su ejecución. En la Figura se encuentra descrito el ciclo de vida del MIDlet. Figura 4.5.1: Ciclo de vida del MIDlet ENTORNO DE EJECUCION DE MIDLETS La especificación MIDP define el entorno en el cual debe ejecutarse una aplicación J2ME, este entorno de ejecución lo compárate el Application Management Software (AMS), el cual es el responsable del lanzamiento de MIDlets y suites de MIDlets (un conjunto de MIDlets). Todas las clases que necesite el MIDlet dentro de una suite deben estar en la librería CLDC, en la librería MIDP o en el propio fichero JAR de distribución de la aplicación DISTRIBUCION DE MIDLETS Siempre que se construye una aplicación J2ME destinada para un dispositivo móvil de escasos recursos de memoria se crea un archivo JAR. En este se incluyen los ficheros o clases que implementan los MIDlets, cualquier recurso que necesiten como imágenes, iconos, etc. y un archivo de tipo JAD que describe el contenido del archivo JAR. Las opciones de instalación son propias del fabricante de dispositivos móviles, ya que ellos definen diferentes características que pueden ser utilizadas sobre el dispositivo como tal, aunque el proceso que se siguió para la instalación del prototipo funcional se encuentra descrito en la figura 4.5.3, es solo algo general de cómo hacerlo. Para una guía mas detallada de cómo hacerlo por favor remítase al libro de J2ME que se encuentra en la bibliografía de este documento. Para que este proceso se pueda dar es indispensable que el dispositivo posea la maquina virtual o KVM, y así se pueda ejecutar, teniendo en cuenta la especificación que se utilizó (MIDP 2.0 o MIDP 1.0) ya que la KVM debe ajustarse a esta especificación. 23

24 Figura 4.5.3: Proceso de Instalación sobre Dispositivo Solicita la instalación de la suite Envía la página Web de instalación El usuario selecciona el enlace Envía el fichero descriptor: RentaTools.jad El usuario confirma la instalación HTML JAD JAR Servidor WEB Cliente Móvil Envía el fichero de la suite: RentaTools.jar RentaTools.jar Lanza KVM y aplicación 4.6 INTERFACES DE USUARIO MIDP Para el desarrollo de interfaces sobre un dispositivo móvil se definió un API diferente basado en un análisis del MIDP Expert Group. Para ofrecer flexibilidad a los desarrolladores este API se dividió en dos partes: ALTO NIVEL (HIGH LEVEL API) Este se creo pensando en aplicaciones de negocio, donde el MIDlet interactúa como cliente de una aplicación servidor, y cumpliendo con su principal objetivo la portabilidad. En este nivel encontramos todo lo que esta asociado al Screen como el Screen Class, Alert Class, Form Class, Item Class, List Class, Text Box Class y Ticker Class BAJO NIVEL (LOW LEVEL API) Este es para aplicaciones de juegos, que requieren un control total de lo que aparece en pantalla y que usa como mecanismo de entrada de bajo nivel del dispositivo las teclas, las coordenadas del cursor, etc. En este nivel encontramos todo lo que esta asociado con el Canvas como los User Interactions, Graphics, Clipping Regions y la Animación. 24

25 La Figura 4.6 Muestra gráficamente la jerarquía y la relación entre las clases mencionadas en los dos niveles anteriores. Figura 4.6: Jerarquía de Clases Display Command Displayable Screen Canvas List Textbox Alert Form Graphics Item ChoiceGroup TextField DateField Gauge ImageItem StringItem Tenga en cuenta que aquí solo se quiere tratar un panorama general de lo que puede brindar J2ME y con lo que se puede iniciar algo básico. Con toda la información adquirida sobre como trabaja la parte de la interfaces sobre J2ME se cubre el punto sobre lo que puede brindar la tecnología J2ME para el desarrollo del prototipo funcional en la parte del cliente, así como el flujo de datos a través de Internet y que va a ser parte del proceso que debe manejar el framework, el cual se describirá detalladamente mas adelante. El siguiente tema que debe tratarse es el de Web Service y J2EE, así como la relación que se da con estos a nivel de dispositivos móviles en el manejo de la lógica del negocio o del procesamiento de datos. 25

26 5. DESARROLLO DE WEB SERVICE Y J2EE 5.1 DEFINICIÓN WEB SERVICE Existen varias definiciones de lo que realmente es un Web Service pero todas guardan un concepto en común: prestar un servicio a través de una aplicación a otras aplicaciones o usuarios. Tomaremos la definición de la W3C que es la comunidad que se encarga de manejar los estándares en el manejo de la WEB y es la siguiente: Web Service es una aplicación de software identificada por un URI, cuyas interfaces pueden ser definidas, descritas y descubiertas por artefactos XML y soportan interacciones directas con otras aplicaciones de software usando mensajes XML vía protocolos basados en Internet 5 Con esta definición se puede observar que los Web Services trabajan con XML (Extreme Markup Language) el cual es un estándar con el que se pueden comunicar varias tecnologías y en el que se definen algunas cosas como los servicios que se van a prestar. Otra definición en donde tal vez se puede ver un poco mas claro el concepto es la de Patricia Seybold 6 : Web Service es un recurso de software identificado por un URL, que realiza funciones y provee respuestas. Está construido tomando un conjunto de funcionalidades y envolviéndolas con el fin de que sean visibles y accesibles a otras aplicaciones de software. Los Web Services pueden solicitar servicios a otros Web Services y esperar su respuesta. Pueden interoperar de una forma loosely-coupled (bajo-acoplamiento) 7 5 W3C

27 Como se puede observar en las definiciones, los Web Service son una herramienta importante que se está imponiendo cada vez mas, al poder ofrecer la flexibilidad de comunicar varias tecnologías, que es algo con lo que se esta luchando hoy en día. También la importancia de poder comunicar varias aplicaciones le ofrece a los usuarios mejores ventajas, al poder obtener un servicio a través de la Web, llevándolo a que interactúe con metodologías como Business to Business (B2B), Business to Consumer (B2C) y otras, que son las estrategias que deben utilizar las compañías de hoy en día para ofrecer sus servicios. 5.2 ARQUITECTURA WEB SERVICE Ahora se pasa a otro concepto importante en el manejo de un Web Service, que es la arquitectura a nivel Físico y a nivel lógico en el diseño de este tipo de Aplicaciones NIVEL FÍSICO Por lo general estas arquitecturas son diseñadas sobre una arquitectura multi-tier que se refiere al diseño en varias capas. Una que contiene el cliente o la presentación del modelo, otra que maneja la lógica del negocio y finalmente una que maneja los datos. En la figura 5.2.1, proveniente del curso de Sistemas Distribuidos de la Universidad Javeriana, se puede ver detalladamente cada una de estas capas y la flexibilidad que pueden tener un Web Service, que por lo general se monta sobre un servidor Web. Figura 5.2.1: Arquitectura Multicapas 8 Arquitectura multi-tier Client-tier web-tier Business-tier Connector-tier Browser INTERNET Servidor Web Componentes Presentación Componentes (Business rules) EIS-tier RDBMS Celular CORBA Legacy Systems (Cobol, etc.) PDA (Pilot) Portable Escalable Robusta Distribuida Power Builder Visual Basic Delphi Directorio de Servicios ERP/CRM

28 Estos son los componentes que se ven a nivel físico y con los cuales interactúa un Web Service, el cual puede cumplir con las propiedades que se ven descritas en la figura NIVEL LÓGICO A continuación se verá la parte lógica de un diseño de un Web Service que se debe tener en cuenta para que este se lleve a cabo. En la figura 5.2.2, se observa detalladamente como se realiza la comunicación del Web Service con el cliente, el cual interactúa con este, por medio de un browser o un aplicativo que le permite establecer dicha conexión. Algunos de los elementos utilizados se describirán a medida que avancemos en este documento, por ahora la idea es ver como se hace esta comunicación y que instrumentos o elementos se necesitan para que esto sea posible. Figura 5.2.2: Intercambio de datos Encuentr a e l Servicio Link a documento o disco o wsdl UDDI Consumidor de Servicios Còmo hablarle? WSDL XML con descripción de Servicio Hablemos SOAP Servidor Web XML SOAP Body En la figura se muestra que el usuario accede a un servicio primero a través de un directorio de servicios que es UDDI, luego le dice en que dirección se encuentra. Ahora con WSDL sabe como hablarle, pues allí se definen los servicios y lo hace a través de 28

29 XML. Ahora que se sabe donde están los servicios, se habla con el servidor a través del protocolo SOAP, el cual encapsula los mensajes del usuario que se le envían a través de la red. Pero para poder tener mas claro veamos las siglas utilizadas: UDDI: Universal Description, Discovery and Integration. Es un catalogo en donde el proveedor registra su servicio. WSDL: Web Services Description Language. Es el documento en donde el proveedor describe su Web Service o servicio Web. SOAP: Simple Object Access Protocol. Es el protocolo en el que viajan los mensajes a través de la red. XML: Extreme Markup Language. Es un lenguaje sobre el que se describen los servicios y las referencias de los tipos de datos. 5.3 PROTOCOLO SOAP El Simple Object Access Protocol (SOAP) fue creado en 1997 por tres industrias, Userland Software, Microsoft y DevelopMentore. Juntos desarrollaron un protocolo de comunicación que cumpliera con estas tres necesidades: fácil uso, flexible y la interoperabilidad de por siempre 9. Funcionalidad de SOAP: Es una especificación para un sistema de manejo de mensajes donde los datos son representados en texto y definidos como un tipo de dato. El texto que contiene estos datos es llamado el mensaje SOAP, el cual es escrito en XML. Además, de transmitir datos también transmite metadata en el encabezado del mensaje. SOAP es un protocolo de comunicación sin estado, es decir, los datos y el mensaje SOAP no son guardados durante el curso de la transmisión. Por ejemplo SOAP transmite un requerimiento para invocar un proceso remoto al proveedor del servicio. El proveedor responde al requerimiento en un mensaje SOAP y lo devuelve. La relación entre el transmisor y el receptor se rompe una vez que el cliente reciba la respuesta. Estructura del mensaje SOAP: Hay tres partes que componen el mensaje SOAP, que son el sobre, el encabezado y el cuerpo. El sobre de SOAP es una etiqueta requerida en XML que contiene el encabezado y el cuerpo. El encabezado es una etiqueta opcional en XML en el mensaje SOAP que contiene metadata. El cuerpo del mensaje SOAP es requerido y contiene el texto del mensaje. Hay tres tipos de cuerpo en el mensaje SOAP: request (Petición o requerimiento), response (Respuesta) y fault (Cuando ocurre un error). 9 J2ME : the complete reference. Keogh, James Edward, 1948-Berkeley, California : Osborne/McGraw-Hill,

30 5.4 WEB SERVICES PARA DISPOSITIVOS MÓVILES Para el desarrollo de aplicaciones para dispositivos móviles, existen varias tecnologías con las que se puede trabajar, aunque la idea inicial de este proyecto es trabajar con J2ME una plataforma de SUN, también se podría trabajar con otras como IBM con su plataforma de WEBSPHERE,.NET, etc. Ofrecen productos para el desarrollo de aplicaciones para dispositivos móviles ARQUITECTURA WAP La arquitectura no difiere mucho de la que se mencionó anteriormente descrita en la figura 5.2.1, pero se verá reflejada sobre los dispositivos móviles para obtener una mejor idea de lo que estamos utilizando en nuestro caso. Figura 5.4.1: Nivel Físico Gateway Servidor Web WAP HTTP Cliente Móvil En la figura 5.4.1, se puede observar que un mensaje viaja a través del aire inicialmente desde el celular. Luego la señal es tomada por un Gateway que utiliza el protocolo WAP para obtener dicha comunicación y luego pasarla a un servidor Web, el cual se hará cargo de prestar el servicio que la aplicación que se encuentre en el dispositivo móvil le este pidiendo. WAP: Wireless Access Protocol. Es un protocolo utilizado para mostrar Internet en un cliente móvil y de esta manera poder acceder a servicios de información en la Web. La tecnología WAP y J2ME son complementarias 10. No son tecnologías que compiten la una contra la otra, ya que los MIDlets deben ser instalados utilizando el protocolo de WAP para comunicarse con el gateway, el cual convierte la señal que viene por el aire a una señal http. Este punto justifica que las dos tecnologías no se pueden comparar ya que son complementarias. 10 J2ME MIDP and WAP Complementary Technologies Febrero

31 5.5 ESPECIFICACIÓN JSR 172 WSA Esta especificación es la que brinda el soporte en la invocación de servicios remotos y el parsing XML a nivel del dispositivo y es lo que se ha definido en Web Service para J2ME por la comunidad de Java. Los Web Service en J2ME bajo la especificación JSR 172 WSA 11 (Figura 5.5), sigue las mismas especificaciones, arquitectura y modelos de invocación como un Web Service normal. Desde el punto de vista del cliente, JSR 172 WSA trabaja bajo la perspectiva de consumidor de servicios. WSA provee el servicio de invocación remota (API JAX-RPC), un ambiente que permite consumir servicios en la Web. Figura 5.5 Arquitectura WSA Consumidor de Servicios Productor de Servicios Aplicación J2ME JSR 172 JAX-RPC Runtime Red Inalámbrica Internet SOAP XML Firewall Servidor Web Las aplicaciones hechas sobre J2ME invocan servicios a través de los stubs de JRS 172 típicamente sobre HTTP o SOAP. Los stubs y el runtime esconden la complejidad asociada con la invocación de un servicio remoto. Es un servicio que incurre en el uso de algunas librerías y el generar stubs para la comunicación con un Web Service desde el dispositivo y manejando SOAP, lo que lo hace un poco pesado al querer invocar un servicio remoto. 5.6 MANEJO WEB SERVICE SOBRE J2ME SUN espera que para el final del año 2004 existan mas de de teléfonos en el mercado, y con toda la atención que estos han infundido en el mercado, es sorprendente 11 Web Services APIs for J2ME. Julio 20,

32 saber que un desarrollador que desea construir aplicaciones sobre dispositivos inalámbricos utilizando XML y SOAP se quede atrás. Pero porque se presenta esto? Por el limitado espacio de memoria en un dispositivo móvil. Paquetes como Xerces 12 (para XML) y Axis (para SOAP) son muy grandes. Este problema es reconocido por la comunidad SUN en la especificación de JSR 172, que se refiere al uso de XML, SOAP y Web Services en dispositivos móviles. Se espera que pasen al menos unos diez o doce meses antes de que sea terminada e implementada dicha especificación. Pero esto no ha impedido que alguien que quiera hacerlo, no lo pueda hacer. Utilizando una herramienta libre y de código abierta llamada KSOAP producida por Enhydra.org. Muchos de los proveedores de servicio de celulares, utilizan una red de circuitos análogos que abren una conexión constante por el tiempo que dure la comunicación, lo que lo hace más complicado al ser una señal más costosa de mantener y tener un ancho de banda limitado. El intercambio de paquetes se hace costoso, al retransmitir los paquetes que se pierden por uno u otro motivo que se dan cuando son transmitidos en el aire, perjudicando la ejecución de un servicio entre el servidor y el cliente (Celular). Es por esto, que el intercambio de información que se pueda efectuar en un dispositivo móvil debe ser mínimo para asegurar una ejecución óptima. Adicionalmente el dispositivo no dispone de abundantes recursos para procesar los requerimientos y respuestas de una manera rápida, al igual que su capacidad de almacenamiento que es mínima. Dados estos problemas, el manejo de un cliente wireless para un Web Service puede ser una tarea complicada, aunque para esto se utiliza el paquete que se menciono anteriormente (KSOAP). El articulo de Wireles Web Services with J2ME 13 muestra un claro ejemplo en el que se utiliza el protocolo de acceso remoto llamado XML-RPC junto con el proyecto de Enhydra, el cual es el único disponible en el momento de su implementación, para el invocamiento de un Web Service. Para esto se requiere un largo proceso hasta hacer el deployment de la aplicación de ejemplo, junto con un paquete de xmlrpc.jar de 24kb. Como se puede ver es una tarea difícil, teniendo en cuenta todos los factores necesarios para poder comunicar un dispositivo móvil con un Web Service. Es exactamente lo que busca este proyecto, hacer las tareas mas fáciles y con paquetes menos pesados, ya que entre mas livianos mejor va ha ser la comunicación. Aun queda por revisar otro contraste que surge con base a los protocolos que se pueden utilizar, como XML-RPC y SOAP en el manejo de un Web Service. Los dos proveen el mismo servicio, aunque existen algunas diferencias que podrían llevar al desarrollador a decidir cual de los dos utilizar. Estas diferencias serán discutidas mas adelante, por lo 12 Febrero Wireless Web Services with J2ME

33 pronto es bueno saber que opciones hay para el manejo de un Web Service utilizando como cliente un dispositivo móvil (Celular). 5.7 KSOAP BY ENHYDRA Debido a los problemas que se mencionaron anteriormente, Enhydra.org tiene una solución la cual se compone de dos paquetes: KXML Y KSOAP, disponibles en de donde pueden ser descargados y fueron diseñados para permitir que SOAP Y XML trabajen en aplicaciones dentro de KVM (una maquina virtual de baja memoria). Son pequeños y fáciles de utilizar y bien documentados. Combinados en un archivo ksoap-midp.jar toma al menos 42Kb 14. Un ejemplo del paquete se puede observar en la arquitectura en la figura 5.7 en la que se maneja un mensaje SOAP entre un dispositivo móvil y una aplicación J2EE, para obtener una mejor idea de cómo funciona el paquete de Enhydra.org. Figura 5.7 Arquitectura KSOAP 15 Ya que esta la solución es la que mas se encuentra en la búsqueda de paquetes que trabajen con J2ME la resaltamos dentro del proyecto en cual se quiere construir un paquete mucho más liviano y que pueda comunicarse con un Web Service. 5.8 XML-RPC VS SOAP XML-RPC y SOAP son dos protocolos que tienen raíces muy parecidas, al ser ambos protocolos de comunicación para el intercambio de datos, por lo que surge una duda Cuál escoger? Es esto lo que se discute en el articulo de Wireless Web Services with J2ME 16, 14 Low Bandwidth SOAP. Agosto 19, Wireless Web Services with J2ME part II

34 en el cual se encuentran las fortalezas y debilidades de cada uno de estos y así poder tomar una decisión. El protocolo de XML-RPC es un mecanismo liviano para la invocación de servicios basados en XML. Es un protocolo simple que provee un encabezamiento mínimo para la invocación de un servicio remoto. Define seis tipos de datos simples y dos complejos, lo que hace que este protocolo sea muy eficiente y liviano. Los mensajes son sencillos de construir y ejecutar. La cantidad de memoria que utiliza es mínima al construir y ejecutar un mensaje sencillo que sirve de intercambio entre un cliente y un servidor. El protocolo SOAP es más grande, al ofrecer algunas cosas adicionales en el encabezamiento, en el namespace, un mecanismo sofisticado de tipos de datos y manejo de mensajes sencillo. Ofrece cerca de 40 tipos de datos estándar y provee capacidades adicionales para datos tipo custom y datos complejos. La arquitectura (Figura 5.8) de SOAP también introduce una arquitectura de mensajes sencilla, incluyendo mensajes unidireccionales, bidireccionales, multicast y secuencial. El encabezamiento permite ofrecer seguridad, transaccionalidad, y enrutamiento. SOAP soporta comunicación asíncrona mientras que XML-RPC solo soporta comunicación sincrónica. Figura 5. 8: Arquitectura SOAP 17 Pensando en como manejar los mensajes en el framework, es necesario ver la justificación del uso de un protocolo que permita crear una arquitectura que se adapte o bien a uno o a los dos contextos de acuerdo a las necesidades que se estén estableciendo para el desarrollo de una aplicación determinada. Para poder tomar una decisión de acuerdo al tipo de aplicación que se es te construyendo, se encuentra en la tabla 1 las ventajas que brinda cada uno de los protocolos, la cual fue tomada del articulo de Wireless Web Services with J2ME Part II

35 Tabla 1 Justificación para el Uso de cada Protocolo Prioridad Negocio Huellas de Memoria Pequeñas Velocidad y Eficiencia Creación de estructuras simples Ancho de Banda Reducido Fácil mantenimiento y debug del Sistema Intercambio de estructuras de datos robustos con relaciones confusas. Arquitectura de Mensajes flexible Creación de estructuras tipo custom Interoperabilidad con otras partes mas allá de una influencia o control Comunicación Asíncrona Seguridad Adicional mas allá de HTTPS y SSL3 Soporte de Transacciones Protocolo Apropiado XML-RPC XML-RPC XML-RPC XML-RPC XML-RPC SOAP SOAP SOAP SOAP SOAP SOAP SOAP 5.9 LA EDICIÓN DE J2EE La Java 2 Enterprise Edition (J2EE) es una plataforma diseñada para empresas y aplicaciones distribuidas, especialmente en el ambiente del servidor. Este ambiente provee dos cosas: Una infraestructura runtime para el hosting de Aplicaciones. Un conjunto de extensión java APIs para la construcción de aplicaciones. La idea detrás de la plataforma (J2EE) es proveer un simple y único estándar para aplicaciones distribuidas a través de un modelo de aplicación basado en componentes. Es también un modelo multicapas, fundamentado en el desarrollo de componentes, basado en un contenedor de componentes de manejo y soporte de Ediciones Standard de J2EE para promover un estándar de portabilidad ARQUITECTURA J2EE La plataforma J2EE consiste de tecnologías que soportan el desarrollo de aplicaciones distribuidas y de servicios de una empresa. Estas tecnologías caen en tres categorías 35

36 diferentes: en componentes, servicios y comunicación18. Cada una de estas se relaciona con la otra como se puede ver en la figura Figura Arquitectura J2EE 14 Esta arquitectura muestra cuatro contenedores: Un contenedor Web para el hosting de Java Servlets y paginas JSP. Un contenedor EJB para el hosting de componentes Enterprise Java Beans. Un contenedor de Applets. Un contenedor de para correr clientes estándar en Java. J2EE provee a los programadores con herramientas de desarrollo y capacidades durante el tiempo de ejecución, necesarias para construir aplicaciones que respondan a requerimientos de seguridad, estabilidad y de mantenimiento. Dentro de la arquitectura se encuentran varios componentes utilizados en el lado servidor que utilizan tecnologías tales como: Servlets: son programas que permiten que la lógica de una aplicación sea envuelta en un proceso de requerimiento y respuesta vía HTTP. JavaServer Pages (JSPs): provee una manera de envolver componentes en una página en donde los propios componentes hacen su trabajo, al generar la página que eventualmente es enviada al cliente. Enterprise JavaBeans (EJBs): La arquitectura de EJBs es un modelo de componentes distribuido para el desarrollo de componentes seguros, escalables, transaccionales y multiusuario. Java Connectivity Architecture (JVA) Java Message Service (JMS): Es un mecanismo que permite el intercambio de datos de manera asincrona, al permitir enviar y recibir mensajes a través del uso de un message-oriented middleware (MOM). 18 Professinal Java Server Programming J2EE Edition. Subrahmayan Allamaraju, Avedal, Browett, otros. Wrox Press Ltd.Birmingham-UK

37 Java Management Extensions (JMX) Java Naming and Directory Interface (JNDI): Provee el ejecutamiento de operaciones estándar en un directorio de servicios de recursos tales como LDAP y Novell Directory Services. J2EE lo utiliza para la ubicación de interfaces utilizadas para crear entre otras cosas como la conexión de EJBs y JDBC. Java Database Connectivity (JDBC): Provee al programador con la habilidad de conectarse a un sistema de base de datos relacional. J2EE permite que una amplia variedad de clientes puedan interactuar con estos componentes, incluyendo browsers, Java applets, aplicaciones standalone y cliente inalámbricos. Estos se comunican típicamente utilizando HTML o XML sobre HTTP. El Java Message Service (JMS) 19 API es un Standard de mensajería que permite que los componentes de una aplicación basados en J2EE para crear, enviar, recibir y leer mensajes que se encuentran en una cola de mensajes. Permite una comunicación distribuida de bajo acoplamiento y asíncrona. Para el caso del framework se va ha trabajar con el ejemplo del JMS de Alberto Rodríguez Galdo 20, quien explica paso a paso el propósito del JMS, así como el proceso de construcción de un mensaje para ser enviado y recibido. Aunque no se han mencionado todos los componentes de esta arquitectura, si se han nombrado algunos de los que emplearemos en el diseño del framework. Si desea conocer más acerca de dichos componentes lo puede hacer en la página de java ( Dura nte el proceso de investigación que se dio para este capitulo, se vieron algunos aspectos como el manejo de mensajes SOAP dentro de un Web Service y se encontró que este proceso resulta ser algo pesado para el dispositivo móvil debido a su limitado manejo de recursos, ya que requiere el manejo de XML por lo que se pudo establecer que es mejor delegar responsabilidades y dejar al dispositivo con una carga mucho menor y dejar la parte de manejo pesado del lado servidor. En el diseño del framework se tendrá en cuenta este aspecto y se delegaran las responsabilidades según corresponda. Es decir, el desarrollador se encargará de la implementación del Web Service y sus anexos como el UDDI, el WSDL y los EJBs con base al diseño que desee realizar y solo se apoyará en las utilidades del Framework de Manejo de mensajes para construir un aplicativo para dispositivos móviles (Celular). El desarrollo de un Web Service resulta ser una tarea sencilla hoy en día, debido a la facilidad que prestan algunos de los IDEs para que esto sea posible. En este caso se utilizara el del JDevoloper un IDE que se mencionará en el siguiente capitulo, con el cual se construirá un Web Service que se encargue de consumir los servicios desde un dispositivo móvil (celular) por medio de un prototipo funcional que pretende validar el framework que se esta planteando. En el lado servidor existirá entonces la parte que maneja el Web Service y J2EE, del lado cliente se encontrará el dispositivo móvil (celular) que tendrá la parte de J2ME. 19 Java Message Service. Febrero Introducción a JMS. Febrero

38 Otro concepto que se analizo fue el de WAP, el cual es un protocolo que va de la mano con J2ME, ya que este lo utiliza en su capa de comunicación con el gateway. Por este motivo se pudo concluir que no se puede comparar WAP con J2ME, ya que este es un protocolo que utiliza J2ME en su proceso de comunicación a través de la Web. Ya que se tienen los conceptos de J2ME y J2EE, se puede pasar a ver con que herramientas se va a trabajar en este proyecto, ya que existe una gran variedad de herramientas con las que se puede desarrollar hoy en día. 38

39 6. HERRAMIENTAS PARA EL DESARROLLO DEL PROYECTO 6.1 IDE JDEVELOPER 10G Oracle 9i JDeveloper es una herramienta de desarrollo para aplicaciones sobre la plataforma de J2EE, que ayuda en el diseño desde el cliente hasta el servidor en el desarrollo, debug y deploy de las aplicaciones y de Web Services. Oracle 9i JDeveloper maneja un conjunto de herramientas que ayudan completamente desde el modelo UML, el código, el debug, pruebas, perfilamiento y deploy de las aplicaciones. JDeveloper simplifica el desarrollo de aplicaciones sobre J2EE proveyendo una ayuda paso a paso en el generamiento de componentes de J2EE, tales como applets, JavaBeans, JavaServer Pages (JSP), servlets, y Enterprise JavaBeans(EJB). El framework de componentes del negocio de Oracle para Java (BC4J), simplifican la entrega de aplicaciones enterprise que se adhieren a una arquitectura Model-View- Controller (MVC), generando componentes funcionales para el negocio que implementan los patrones de diseño J2EE. Este IDE (Figura 6.1) es Freeware y puede ser descargado de la página de Oracle 21, en donde se puede encontrar una variedad de ejemplos a través de demostraciones en línea, que ilustran totalmente el manejo de la herramienta. Aunque existen otros IDEs que tienen las mismas características que ofrece el IDE de JDeveloper, es opción del desarrollador utilizar el IDE con el que quiera trabajar, pero 21 Oracle. 39

40 todas las que trabajen con J2EE funcionan con la misma filosofía, por lo que este IDE ilustra claramente el proceso de desarrollo del proyecto. Figura 6.1 IDE Oracle JDeveloper 6.2 JAVA WEB SERVICE DEVELOPERS PACK 1.3 (JWSDP) Es una herramienta libre que puede ser utilizada para construir, probar y desplegar aplicaciones XML, Web Services y aplicaciones Web con la última tecnología y estándares en implementarse. Con este los desarrolladores pueden: Evaluar lo último en tecnologías XML y Web Services. Crear aplicaciones en XML y Web Service que sean seguras, ínteroperables y portables a través de diferentes plataformas y equipos. Simplificar y bajar los costos de integración, intercambio de datos y publicación en ambientes Web para las aplicaciones. Esta herramienta provee el Tomcat, herramienta Web con la que se publicaran los servicios que el framework va ha utilizar. Además, brinda algunos ejemplos de trabajo con servlets y paginas jsp. Es muy sencilla de utilizar y guarda un log con todos los sucesos que ocurren durante el proceso de levantamiento de algún servicio Web. Al igual que en el anterior es opción del programador utilizar cualquier herramienta que permita desplegar aplicaciones Web utilizando un servidor Web. Esta herramienta también 22 puede ser descargada de la pagina de SUN y es sencilla de instalar. 22 Java Web Services Developer Pack (Java WSDP). Febrero de

41 6.3 J2ME WÍRELESS TOOLKIT 2.1 Es una herramienta utilizada para el desarrollo de aplicaciones inalámbricas que están basadas en el Connected Limited Device Configuration (CLDC) y el Mobile Information Device Profile (MIDP) de J2ME 23. Esta diseñada para ejecutarse en teléfonos celulares, en asistentes personales digitales y otros pequeños equipos. Este incluye, ambientes de emulación, características de optimización de ejecución y tuning, documentación y ejemplos que los programadores necesitan para poder traer aplicaciones eficientes y exitosas rápidamente en el mercado. Este puede ser descargado de la página de SUN y soporta el desarrollo de aplicaciones Java que se ejecutan en equipos compatibles con tecnología Java para la especificación de la industria inalámbrica (JSR - 185). Este emulador provee soporte para: Connected Limited Device Configuration (CLDC), version 1.1 (JSR-039) Mobile Information Device Profile 2.0, (JSR-118) J2ME Web Services version 1.0, (JSR-172) Wireless Messaging APIs version 1.1, (JSR-120) Mobile Media APIs version 1.1, (JSR-135) A continuación se presentan algunas de las mejoras que se han realizado sobre el J2ME Wireless Toolkit 2.1: KToolbar Multiple Configuration and Profile Build Options Emulator Performance Improvements Polygon Key Definition J2ME Web Services (JSR-172) stub generator New device skin Demonstrations MIDlets for J2ME Web Services (JSR-172) and CLDC 1.1 (float support) También se pueden desarrollar aplicaciones para CLDC 1.0 y MIDP 1.0 con esta herramienta. En la figura 6.3 se puede apreciar la pantalla de ingreso a la herramienta. 23 J2ME Wireless Toolkit 2.1 Download. Febrero de

42 Figura 6.3 IDE J2ME Wireless Toolkit Se utilizará esta herramienta para emular el funcionamiento del aplicativo funcional con el cual s e presentara la parte del cliente que hará uso del framework para comunicarse con el servidor. 6.4 JBOSS JBoss 24 es una federación dedicada al desarrollo de un modelo de código abierto de alta calidad y debe su crecimiento a factores como: Proyectos líderes en código abierto: Emplea desarrollos lideres y controla una gran cantidad de conocimiento de una numerosa rama de código abierto de java, que incluye proyectos como JBoss Application Server, JBoss AOP, JBoss Cache, Hibernate, Tomcat, Nukes, JGroups, JBoss IDE, Javassist, and JBossMail. Comunidad de desarrollo Activo: Todos lo proyectos son beneficiados de una gran comunidad de participantes activos que aseguran la continua innovación y estabilidad del producto. Extensiva red de socios: Compañías de software independientes utilizan JBoss en más de una de sus aplicaciones alrededor de todo el mundo, incrementando el número de usuarios del producto. Servicios superiores desde su fuente: JBoss provee un soporte de expertos para asegurar que esta sea la decisión mas segura que se toma en la implementación del ciclo de vida de las aplicaciones (Figura 6.4). 24 Professional Open Source from JBoss Inc. Febrero de

43 Figura 6.4 Ciclo de vida DESARROLLO DE APLICACIONES Buen Inicio de Soporte de Desarrollo Entrenamiento público y en línea Educación en línea Documentación Foros Guías de Inicio Socios de Jboss autorizados para el soporte en desarrollos INTEGRAR Y OPTIMIZAR Buen Inicio de Soporte de Desarrollo (en el sitio web o remoto) Socios de Jboss autorizados para el Soporte en desarrollo y migración de servicios. MANTENIMIENTO Y MANEJO 1º Y 2º nivel de soporte en Producción por part e de Jboss inc. y Socios de Jboss. Autorizados. 3º nivel de soporte en Producción por parte de Jboss inc. Identificación de Código Abierto de Jboss. DESPLIEGUE Buen Inicio de Soporte de Desarrollo (en el sitio web o remoto) Socio de Jboss autorizado para el soporte En desarrollo Soporte en Producción por Jboss inc. y socios autorizados. También permite el manejo de la plataforma de J2EE, para lo cual es empleado en el proyecto que se esta realizando aquí. Para el desarrollo del framework se utilizará la herramienta de JDeveloper, con la cual se construirán los prototipos funcionales que pretenden validar el manejo del framework de manejo de mensajes. También se utilizará para el desarrollo del Web Service junto con el OC4J que provee para hacer el despliegue de servicios sobre este. El JWSDP se utilizará para crear allí una capa intermedia que delegara los servicios al servidor correspondiente, de acuerdo al diseño que se realice sobre cada uno de los prototipos funcionales. Por ejemplo, para el caso del Prototipo Funcional de RentaTools se comunicará con el servidor del OC4J. El Wireless Toolkit se utilizará para armar el JAR correspondiente a los MIDlets, que en este caso serán el cliente que interactuará con el servidor de JWSDP. Ahora que se tiene claro el uso que va a tener cada una de las herramientas en la construcción del framework y los prototipos funcionales, se procede al tema de manejo de patrones de diseño, los cuales brindaran un mejor desarrollo del framework de manejo de mensajes. 43

44 7. PATRONES DE INGENIERÍA DE SOFTWARE Y FRAMEWORK O MARCO DE TRABAJO Solo queda una parte teórica por cubrir, la cual se orienta hacia el uso de patrones de software, con los cuales se podrá construir el Framework de manejo de mensajes que se ha planteado en este proyecto. Existen problemas con los que se han encontrando los desarrolladores, ha los cuales se les han hallado soluciones muy parecidas, lo que permite ganar una buena experiencia en el desarrollo de aplicaciones, obteniendo un alto nivel de conocimiento como resultado. Son estas soluciones en las que luego de recurrir varias veces a ellas, se convierten en patrones y son las que permiten con base a experiencias anteriores que se obtenga una solución óptima y reutilizable. 7.1 DEFINICIÓN PATRÓN Según Christopher Alexander dice: Cada patrón describe un problema que ocurre una y otra vez en nuestro ambiente y luego describe el centro de la solución a ese problema, de tal manera que puede utilizar esta solución un millón de veces sin tener que hacerlo de la misma manera dos veces 25 En general un patrón debe tener los cuatro elementos siguientes: Nombre del patrón. 25 Design patterns: elements of reusable object - oriented software Gamma, Erich. Reading, Massachusetts : Addison-Wesley,

45 El Problema que describe cuando aplicarlo. La solución describe los elementos que hacen el, diseño (relaciones, responsabilidades y colaboraciones). Las consecuencias que son los resultados y los intercambios de aplicar el patrón. 7.2 CATALOGO DE DISEÑO DE PATRONES GOF El catalogo que describe Gamma 8 contiene 23 patrones de diseño que dan la base inicial a los patrones de J2EE. Tabla 2 Nombre Patrón Tipo Breve Explicación Abstract Factory Creación Provee una interface para crear familias de objetos relacionados o dependientes, sin especificar sus clases concretas. Adapter Estructural Convierte la interface de una clase en otra interface que el cliente espera. Bridge Estructural Dese ncapsula una abstracción de su implementación de tal manera que los dos puedan variar independientemente. Builder Creación Separa la construcción de un objeto complejo de su representación de tal forma que el proceso de construcción pueda crear diferentes representaciones. Evita el acoplamiento de un remitente a su receptor dándole a más Chain of Comportamiento de un objeto el chance de manejar el requerimiento que este Responsability envía. Command Comportamiento Encapsula un requerimiento como un objeto, permitiendo que parametrice los clientes con diferentes requerimientos. Composite Estructural Compone objetos en estructuras de árboles para representar una parte como un todo. Decorador Estructural Vincula responsabilidades adicionales a un objeto dinámicamente. Facade Estructural Provee una interface unificada a un conjunto de interfaces en un subsistema. Factory Method Creación Define una interface para crear un objeto, pero deja a las subclases decidir cual instancia llamar. Flyweight Estructural Utiliza compartimiento para soportar grandes números de objetos finitos eficientemente. Dado un lenguaje, define una representación para su gramática Interpreter Estructural junto con un intérprete que utiliza la representación para interpretar sentencias en el lenguaje. Iterator Comportamiento Provee una manera de obtener acceso a los elementos de un objeto agregado secuencialmente sin exponer su representación interna. Mediator Comportamiento Define un objeto que encapsula como un conjunto de objetos Mem ento Comportamiento interactúan. Sin violar la encapsulación, captura y expone el estado interno de un objeto de tal manera que el objeto pueda ser restablecido a su estado anterior. Define una dependencia de uno a muchos entre objetos de tal Observer Comportamiento manera que cuando el estado de uno cambia, los otros son notificados y actualizados. 45

46 Prototype Proxy Singleto n State Strategy Template Method Visitor Creación Estructural Creación Comportamiento Comportamiento Comportamiento Comportamiento Especifica el tipo de objetos a crear utilizando una instancia de un prototipo típico y crea nuevos objetos copiando este prototipo. Provee un lugar para otro objeto y poder controlar el acceso a este. Asegura que una clase solo tiene una instancia y provee un punto global de acceso. Permite que un objeto altere su comportamiento cuando su estado interno cambia. Define una familia de algoritmos, encapsula cada uno y los hace intercambiables. Define el esqueleto de un algoritmo en una operación, defiriendo algunos pasos a subclases. Representa una operación a ser ejecutada sobre los elementos de una estructura de un objeto. 7.3 CATALOGO DE PATRONES J2EE El libro de J2EE patterns 26 hace un acercamiento a estos a través de su funcionalidad y en términos de capas ya que J2EE es una plataforma multicapas. Este los separa en tres capas: CAPA DE PRESENTAC CION La capa de presentación se encarga de realizar toda la lógica que pueda presentar el cliente, ya sea sobre una aplicación standalone a través de sus paneles o vía Web a través de páginas de presentación html, jsp, etc. La tabla 3 describe los diferentes patrones que realizan dicha t area. Tabla 3 Nombre Patrón Breve Explicación Intercepting Filter Facilita el pre-procesamiento y el post-procesamiento de un requerimiento. Front Controller Provee un controlador centralizado para el manejo de un requerimiento. View Helper Encapsula lógica que no esta relacionada con el formato de presentación en componentes de ayuda. Composite View Crea y agrega vista desde subcomponentes atómicos. Service to Worker Combina un componente despachador con los patrones de front controller y view helper. Dispathcer View Combina un componente despachador con los patrones de front controller y view helper, difiriendo muchas actividades a un proceso vista CAPA DE NEGOCIO La capa del negocio se encarga de r esolver toda la lógica de trabajo en la que se procesa la información ya se a para enviarla a la base de datos o para realizar algún proceso determinado. La tabla 4 describe los diferentes patrones que realizan dicha tarea. 26 Cor e J2EE patt erns: b est practices and d e sign strategies Alur, Deepak.Upper Saddle River, New Jers ey: Prentice Hall PTR, c

47 Tabla 4 Nombre Patrón Business Delegate Value Object Session Facade Composite Entity Value Object Assembler Value List Handler Service Locator Breve Explicación Desacopla las capas de presentación y servicio y provee unas interfaces de fachada y Proxy a los servicios. Facilita el intercambio de datos entre capas reduciendo el flujo de datos sobre la red. Esconde la complejidad del objeto del negocio y centraliza el manejo del flujo de trabajo. Representa una buena práctica para el diseño de entity beans agrupándolas en un padre y única entity bean. Ensambla un objeto de valor compuesto desde múltiples data sources. Maneja la ejecución de queries, proceso de resultados y el caching de resultados. Encapsula la complejidad de buscar y crear servicios del negocio CAPA DE INTEGRACIÓN La capa de integración tal como lo dice su nombre se encarga de integrar datos de forma transparente dentro de una aplicación. La tabla 5 describe los diferentes patrones que realizan dicha tarea. Tabla 5 Nombre Patrón Data Access Object Service Activator Breve Explicación Abstrae recursos de Datos. Provee acceso transparente a los datos. Facilita el proceso asíncrono para componentes EJB. 7.4 FRAMEWORK Los patrones de software que se explicaron anteriormente, son la base para construir el fr amework, por lo que ahora se puede pasar a ver que es un framework? DEFINICIÓN U n framework es un patrón arquitectónico que proporciona una plantilla extensible para aplicaciones dentro de un dominio. Se puede pensar en un framework como una micro- que incluye un conjunto de mecanismos que colaboran para resolver un arquitectura problem a común en un dominio común Grady Booch, Rumbaugh, Jacobson. El lenguaje Unificado de modelado Ed. Addison Wesley. Madrid

48 7.4.2 FRAMEWORKS El uso de un Framework es esencial en el trabajo de los programadores, ya que estos facilitan sus tareas de programación en cada uno de los aplicativos que son desarrollados a diario. Con base a la experiencia que toman, empiezan a determinar patrones de comp ortamiento en sus desarrollos, llevándolos a encontrar soluciones comunes para los diferentes tipos de aplicaciones que se desarrollan. Son estos patrones los que forman el Framework en algunos casos. Por ejemplo, Ergon 28, compañía que ofrece un framework para J2ME llamado J2ME Wireless Application Framework. Dispone de un conjunto completo de componentes en tecnolo gías tanto para el lado cliente, como para el lado servidor. Brinda manejo de Seguridad, Manejo de Mensajes, in terfaces de usuario y comunicación de datos. Este es un proyecto muy amplio con el que los programadores pueden desarrollar un proyecto Wireless fácilmente, aunque a un alto costo por ser código cerrado y para el cual se debe adquirir una licencia a través de Ergon. Otro framework que brinda otro panorama proveido por Naresh Bhatia, llamado The Simple Messaging Framework 29. Este trabaja sobre una arquitectura cliente (PC) Servidor, con un completo ejemplo de una aplicación sobre una agenda de reuniones entre colegas, que se encuentra implantada como una aplicación standalone y que se quiere llevar a la implementación de un Web Service. Todo esto lo hace utilizando unas clases ya definidas y un conjunto de interfaces para las cuales el desarrollador debe implementar su lógica de trabajo. La funcionalidad de este con siste en tener dos componentes esenciales, uno que es el mensaje inicial (MessageClient) sobre el cual se ponen los datos a transmitir y dos, el component e del mensaje servidor (MessageService). Los dos trabajan sobre un toolkit SOAP que se encargan del intercambio de mensajes vía Web Service entre el Cliente y el Servidor utilizando XML. Como se puede observar este también le brinda al desarrollador una herramienta que facilita el trabajo al construir un aplicativo que requiera Web Services bajo este concepto. Otro Framework que entra en comparación con J2ME, es el de.net CF (Compact Framework), que ofrece utilidades para trabajar con dispositivos móviles igualmente. Microsoft.NET CF se comporta muy bien con los dispositivos móviles que posean su misma tecnología, como los Packet PCs. Mientras que J2ME, necesita de una KVM, la cual ha demostrado ser lo bastante portable entre los diferentes equipos que son fabricados hoy en día y con los cuales trabajan la mayoría de Celulares. Un aplicativo construido en J2ME se comporta bien sobre las Palm y Celulares que soporten la KVM, pero si presenta problemas al montarlo sobre un dispositivo que posea un Sistema Operativo de Microsoft. Este fue un punto que se presentó, cuando se estaban instalando los prototipos funcionales sobre una Palm con Palm OS que contenía la KVM de Java y sobre la cual trabajaron sin ningún inconveniente. Mientras, que en la Packet PC con Windows CE si presentó problemas. A continuación, se tiene un cuadro comparativo entre las dos tecnologías en la Tabla Ergon. J2ME wireless application framework Naresh Bhatia. The Simple Messaging Framework

49 Tabla 6 Características.NET Compact Framework J2ME Enviroment Herramientas Las que suministra Microsoft. Muchas herramientas Algunas por terceros suministradas por terceros Soporte Compañías Externas En espera de ver resultados de Grandes compañías como IBM y.net CF Oracle (Muy Interesadas) Los partners de Microsoft Bastante extensa, en especial de Soporte Redes Inalámbricas tendrán que proveer soporte para comunicaciones en el medio Motorola y Nokia, Sprint PCS y Nextel Soporte en Desarrollo Miles de Desarrolladores que La prensa presenta cerca de 2 estén familiarizados con millones de desarrolladores Microsoft. Flexibilidad y Apertura Esencialmente a un ambiente Microsoft Muy abierta Fortalezas Base de Datos API Base de Datos sobre Dispositivo Móvil XML API Web Services Soporte sobre Dispositivos basados en el Sistema Operativo Microsoft Subconjunto de ADO.NET y DataGrid SQL Server CE, Sybase Interno de ADO.NET y otros estándares Interno del CF Soporte sobre múltiples dispositivos Específicos APIs JDBC de las compañías Implementación especifica de las compañías sobre RMS. Herramientas suministradas por terceros Herramientas suministradas por terceros Herramientas Web Services Integrado con VS.NET KSOAP plug-ins SMS Invoca el SMS del dispositivo Wireless Messaging API Seguridad APIS suministrados por terceros APIS suministrados por terceros El proyecto de Framework de manejo de Mensajes para Dispositivos Móviles (Celulares) se basa inicialmente en algunos de los conceptos que expone cada uno de los dos Frameworks anteriores, que aunque ofrecen un producto que brinda algunas de las ideas para la construccion del framework de manejo de mensajes, también se plantean algunas diferencias como las que se tienen a continuación en la tabla 7. Tabla 7 Características Manejo de Mensajes Co municación de Datos J2ME Wireless Application Framework Si lo tiene pero se desconoce como lo maneja. Se desconoce The Simple Messaging Framework Si lo tiene y lo maneja a través de componentes de mensajería propia sobre XML. Utiliza el intercambio de datos por medio de mensajes SOAP..NET Compact Framework Invoca el SMS del dispositivo Interno del CF Framework de Manejo de Mensajes para Dispositivos Móviles Si lo tiene y lo maneja a través de componentes de mensajería propia sobre mensajes simples de texto. Utiliza un flujo de datos a nivel de bytes para el intercambio de datos dejándole toda la lógica pesada al servidor. 49

50 Seguridad Maneja SSL 3.0 y Maneja autenticación a APIS No se planteó en el algoritmos de través del contenedor suministrados proyecto. encripción. de Servlets. por terceros Manejo de Patrones de Software SI SI SI SI Manejo de J2ME en la construcción de SI NO NO SI aplicaciones Entre cliente y Servidor La parte Servidor se Manejo de XML y Se desconoce se maneja XML y Interno del CF encarga del manejo de SOAP SOAP XML y SOAP Manejo de Servidor MOM ( Message SI NO Invoca MSMQ SI Oriented Midleware) Necesita Licencia SI NO SI NO Debido a la limitante de tiempo que hay para construir el framework, esta investigación plantea algunas de las funcionalidades que se pueden dar y no en su totalidad, como el caso de manejo de seguridad, ya que esto implicaría más tiempo. Pero podría extenderse a futuro si se desea ampliar aun mas el concepto del framework que se esta construyendo aquí. Con base a los conceptos anteriores, se procederá a constr uir el framework de manejo de mensajes, el cual proporciona una plantilla extensible para aplicaciones dentro de este dominio de J2ME, WAP, Web S ervices y J2EE siendo estos, cuatro mundos diferentes pero con un dominio en común que es JAVA. Los patrones que se mencionaron anteriormente maduraron la idea de la construcción del framework de manejo de mensajes, determinado mediante una arquitectura lógica (figura 8.2.2b), que proveerá al desarrollador con algunas utilidades que podrá utilizar en el desarrollo de una aplicación que implique los cuatro mundos que se mencionaron anteriormente. En la tabla 6 se encontraron algunas diferencias entre uno y otro, pero el desarrollo de este proyecto une algunas de las ideas dadas en los dos frameworks anteriores en la construcción de un paquete mucho más liviano y un flujo de datos mas rápido, ya que el dispositivo lo así lo requiere. Con base a estas ideas se puede obtener una mejor perspectiva de lo que va ha realizar en el proyecto que se plantea aquí. Con los conceptos adquiridos en los capítulos anteriores, ahora solo queda construir el framework. 50

51 8. FRAMEWORK DE MANEJO DE MENSAJES PARA DISPOSITIVOS MÓVILES (CELULARES) 8.1 ANÁLISIS Un Web Service requiere de componentes como el SOAP y el XML, los cuales se pueden encontrar en las librerías de Xerces 30, pero que traen un problema y es que son demasiado grandes y debido a la limitada memoria que un dispositivo móvil tiene no se puede utilizar. La solución que enhydra.org brinda es la de utilizar su paquete de KSOAP y kxml el cual también puede tomar recursos que el dispositivo necesita para el manejo del aplicativo. Es por eso que el framework que se utiliza para este proyecto ofrece un paquete más liviano y le delega a la parte servidor el manejo de XML y SOAP. Ahora teniendo en cuenta los cuatro mundos de J2ME y WAP en el lado cliente y el Web Service y J2EE en el lado servidor, se va a establecer un protocolo liviano a través del manejo de Strings o mensajes mediante el uso del framework. Para esto, se deben separar las responsabilidades, unas las que van del lado del cliente y otras que van del lado servidor. Igualmente se plantean los siguientes requerimientos sobre el framework de acuerdo a la investigación en tecnologías para el desarrollo de sistemas para dispositivos móviles (Específicamente Celulares) realizada: Requerimientos No-Funcionales: 30 Febrero

52 1. Debe construirse bajo el patrón N-TIER (Multicapas) Se debe manejar una completa estructura de paquetes. 2. Para el desarrollo se deben aplicar los siguientes patrones: Prototype, Factory, Abstract Factory, Singleton, Bridge, DAO, entre otros. 3. Los datos deben ser almacenados en una cuenta de MS Access. Requerimientos Funcionales: 1. Debe permitir generar una alerta sobre el dispositivo móvil de tipo informativa, advertencia y error. 2. Hacer una administración de envío y recibo de mensajes de tipo String a través de Internet, desde el dispositivo móvil hasta el Servidor. 3. Realizar consultas, borrados, inserciones y actualizaciones (CRUD) a la base de datos por medio de objetos DAO. 4. Localizar Servicios fácilmente hacia los EJBs y hacia las colas de Mensajes. 5. Mantener conexiones activas durante el tiempo que se necesiten a través de un pool de conexiones que las administre. 6. Resolver servicios o peticiones que lleguen desde el dispositivo móvil hasta el servidor por medio de un Generador de Servicios. En la figura 8.1 se presentan los casos de uso para los requerimientos establecidos anteriormente. Figur a 8.1: Diagrama Casos de Uso Framework Para llevar a cabo todos estos requerimientos, se dispondrá de seis componentes, los cuales serán detalladamente explicados en la tabla 8 y 9 de este capitulo. A continuación se mencionará cada uno de estos: 1. Generador de Alertas - Provee alertas de tipo error, advertencia y informativo sobre el dispositivo. 2. Generador de Mensajes - Provee el encapsulamiento y desencapsulamiento de mensajes desde el cliente hacia el servidor y viceversa. 3. Generador de Servicios Resuelve un servicio o petición de un mensaje, delegándole el servicio a quien corresponda. 52

53 4. Localizador de Servicios Provee una manera fácil de ubicar los EJBs y las colas de mensajes a las que se necesite acceso. 5. Persistencia vía DAO Provee un modelo orientado a objetos de acceso a registros específicos en la base de datos. 6. Pool de Conexiones Administra las conexiones de acceso de una determinada base de datos. El proceso que se plantea ahora, es manejar cada uno de los componentes anteriores y resolver una petición o servicio desde el dispositivo móvil, quien se encarga de consumir un servicio de la siguiente manera: LADO CLIENTE: 1. El framework toma la lógica de presentación (lo que muestra en la pantalla del celular) que ya se tenga diseñado y a travez de un Proxy, que contiene los paquetes de framework.mensajes.imensajes y framework.mensajes.fabricamensajes, en los cuales se encuentra la manera de encapsular un requerimiento que va a realizar el dispositivo móvil. 2. Luego, es enviado hacia el servidor mediante un protocolo (figura 8.2.2a) que maneja el framework a través de lo paquetes de framework.mensajes.cliente.itransportehttplistener y framework.mensajes.cliente.transportehttp. El ultimo paquete es el de framework.propiedades.cliente.propiedades, que es en donde se encapsulan todas las constantes que el desarrollador tenga sobre el aplicativo para el dispositivo móvil. Todo esto queda en un JAR que es generado por el proyecto de JDeveloper a través del archivo build.xml, que corre sobre ANT. Este archivo se encuentra en cada uno de los proyectos aquí planteados y sobre el proyecto base que esta anexo en el CD. El JAR que entrega como resultado y que es llamado framework.jar es colocado como librería sobre el proyecto del dispositivo móvil y presenta un paquete de Kb, logrando que sea más liviano que el de KSOAP el cual pesa 42Kb, justificando la razón del proyecto. LADO SERVIDOR: 1. Inicialmente, un Servlet recibe la petición que llama el componente Generador de Servicios que se encuentra en el paquete framework.mensajes.servidor y se encarga de componer el mensaje por medio del Generador de Mensajes ( frameowork.mensajes ). Dentro del paquete de framework.mensajes.servidor existe una implementación del Generador de Servicios, la cual debe ser hecha por el desarrollador del aplicativo, ya que desde aquí puede manejar dos aspectos para pedir el servicio solicitado: a. Uno es mandar la petición directo al Servidor de EJBs, para lo cual hace uso del componente Localizador de Servicios en el paquete framework.mensajes.servidor.j2ee. 53

54 b. El otro enfoque es hacer la petición a un Web Service y luego a los EJBs, por medio de un mensaje SOAP generado en este caso por la herramienta de JDeveloper, al igual que el WSDL. 2. Ahora, para conectarse con la base de datos hace uso de los componentes de Persistencia vía DAO y Pool de Conexiones ubicados en los paquetes de framework.dao y framework.poolconexiones respectivamente. 3. El mensaje a sido descifrado por el Generador de Servicios y lo delega a quien corresponda para el llamado a uno de las reglas del negocio definidas por el desarrollador. 4. Finalmente, la respuesta es devuelta en un String desde el EJB y a través del response del Servlet al Dispositivo móvil, el cual a su vez por medio del Proxy entrega un String con la respuesta para ser mostrada en pantalla. Tenga en cuenta que aquí las responsabilidades se separaron, dejando la carga pesada al servidor y la liviana al Cliente. El desarrollo del aplicativo es totalmente hecho por este, tanto en el lado servidor como el cliente. El desarrollador lo único que hace es uso de l as utilidades que ofrece el framework para ayuda y facilidad de uso en su desarrollo. Vea las instrucciones de uso del framework en el Anexo F. Una vez se comprenda cada uno de los componentes del framework que se mencionaron anteriormente y que serán explicados detalladamente más adelante, el usuario del framework estará en la total capacidad de ampliar el framework si lo desea y construir otros componentes a futuro como lo son los de seguridad, transaccional, etc. o expandir los que ya se encuentran construidos. Al construir un framework de utilidades se puede obtener la flexibilidad, robustez y bajo acoplamiento que se necesita para este tipo de aplicaciones sobre dispositivos móviles. Pero como todo esto es posible? Se vera ilustrado en dos prototipos funcionales con los cuales se realizaron las pruebas para el manejo de mensajes a través de la red y obtener el servicio requerido desde un Web Service o una aplicación J2EE. 8.2 ARQUITECTURA La arquitectura muestra dos enfoques: Uno a través de un Web Service y el otro directamente a un contenedor de EJBs, en donde un cliente Wireless (J2ME) se conecta con un servidor Web, quien le delega el servicio a quien corresponda (Web Service o EJBs) y accede finalmente a la base de datos (figura 8.2). La flecha Verde es el camino para consumir un servicio por medio de un Web Service. La flecha Roja es el camino para consumir un servicio directamente desde un EJB. 54

55 Figura 8.2: Arquitectura General del Framework de Manejo de Mensajes Internet Cliente Móvil J2ME KVM WAP C a pa Me dia Servidor Web (Servlets) JWSDP 1.3 TOMCAT Contenedor Web SOAP JNDI Contenedor OC4J Oracle Servidor de Aplicaciones Servidor de Aplicaciones Contenedor JBOSS (EJBs y Web Service) (EJBs) JDBC Base de Datos MS ACCESS La arquitectura que se va a utilizar se divide en dos secciones, una en la parte física y otra en la parte Lógica del Framework de utilidades que se pondrá en practica en este Proyecto ARQUITECTURA FÍSICA Con base a la investigación que se hizo inicialmente en el manejo de Web Services y aplicaciones sobre el dispositivo móvil con J2ME, se a planteado la siguiente arquitectura para el desarrollo del proyecto, que consiste en tener un cliente (Celular), desde el cual se quiere obtener un servicio enviando un mensaje por medio del framework inicialmente a través del protocolo WAP y luego lo hace de dos formas posibles para poder destacar la flexibilidad del framework. A través del GATEWAY el establece la comunicación la cual mediante un proceso interno convierte el protocolo WAP al protocolo de comunicación HTTP y luego delega responsabilidades de acuerdo al diseño que el desarrollador quiera darle. Un enfoque seria desde el GATEWAY llamar el servicio directamente vía JNDI y desde la capa del negocio que se encuentre desarrollada sobre J2EE (Flecha roja). Otro enfoque es llamar el servicio a través del Web Service vía SOAP y luego vía JNDI la capa 55

56 del negocio que se encuentre desarrollada en J2EE (Flecha verde). Todo esto se ilustra claramente la figura Figura 8.2.1:Arquitectura FisicaGeneral del Framework de Manejo de Mensajes J2EE Servidor Gateway JNDI Cliente Móvil WAP JNDI J2ME SOAP Servidor Web Service ARQUITECTURA LÓGICA: De acuerdo al análisis que se a realizado con base al manejo de mensajes desde el mundo wireless al mundo de los servidores de contenido, se ha establecido un objeto que pretende el manejo de mensajes de una forma mas liviana, que la de utilizar un paquete de KSOAP o otro que involucren una carga adicional para el dispositivo móvil. Entrando mas en materia lo que ofrece el Framework de Manejo de Mensajes para Dispositivos Móviles, es crear un objeto llamado mensaje, el cual se utilizará para transportar la información de un servicio que el dispositivo Móvil (Celular) requiera y el cual esta compuesto por la estructura ilustrada en la figura 8.2.2a: Figura 8.2.2a Estructura Mensaje Tipo Respuesta serviciorequerido parametro1/parametro2/. 56

57 Inicialmente tenemos el tipo de Respuesta en donde se coloca si es void, string, o alguno de los tipos de datos admitidos por el dispositivo. Luego es dividido por el símbolo para encontrar el segundo parámetro que es el servicio, el cual identifica el servicio que se quiere utilizar. Luego se separa con el símbolo en donde se encuentra por ultimo los parámetros que el servicio requiera para ser resuelto y los cuales subdivide con el símbolo /. Teniendo este concepto de mensaje claro, se puede pasar a ver la arquitectura lógica (Figura 8.2.2b) del Framework de Manejo de Mensajes para Dispositivos Móviles (Celular) y como es manejado por cada uno de sus componentes. Cada uno de estos componentes, quiere ofrecer una plantilla para que el desarrollador pueda utilizarla en el momento que corresponda. De acuerdo a la experiencia adquirida en la academia y la investigación aquí realizada, junto con algunos consejos de personas que tienen experiencia en el área, se crearon los componentes que serán parte del framework, los cuales serán explicados uno a uno mas adelante, así como su objetivo y como deben ser utilizados. Cada componente tiene una función especifica, viéndolo desde el punto de vista lógico, lo que se quiere mostrar es que para cada requerimiento funcional que la aplicación pida, se puede utilizar el componente que ataque ese requerimiento. Figura 8.2.2b: Arquitectura Lógica Aplicaciones / Requerimientos Funcionales Generador Alertas Generador Mensajes J2ME Persistencia Vía DAO Pool Conexiones Localizador Servicios Generador Servicios J2EE 57

58 El Framework interactúa con la aplicación o los requerimientos funcionales. Esté esta divido en dos Partes: La parte que trabaja desde el dispositivo Móvil (Celular) y con la tecnología de J2ME. La otra parte es la del servidor, en la que se maneja ya sea el Web Service y/o los EJBs. Estas dos partes a su vez se subdividen de la siguiente manera: Tabla 8: PARTE I J2ME Utilidades Detalle Planteamiento: Generalmente siempre existe la necesidad de invocar una pantalla que genere un mensaje ya sea de advertencia, error o informativo en el desarrollo de una aplicación de J2ME. Otro aspecto es que no se debe generar una nueva instancia cada vez que se necesite dentro de la aplicación para ahorrar recursos en el dispositivo. Propósito: Generar una alerta de tipo advertencia, error o informativo suministrando únicamente el tipo que se desea y el mensaje que se quiere mostrar. Explicación: El proceso que se debe seguir para generar una alerta viéndolo desde el código es el siguiente: Generador Alertas //Generar una instacia de tipo IAlertas del tipo que se defina (informativo) IAlertas inicial = FabricaAlertas.fabricar( INFORMATIVO ); //Pasarle el display (pantalla) con el que se esta trabajando inicial.pasarpantalla(pantalla); //Poner el mensaje a mostrar y el display siguiente al que se quiere ir después de la alerta inicial.mostraralerta(" MENSAJE ", siguiente); Este es útil cuando en cualquier momento se desee generar una alerta por parte del desarrollador y no permite generar una nueva instancia, ahorrando recursos sobre el dispositivo haciendo uso del patrón singleton. Patrones Aplicados: Singleton, Bridge y Factory. El diagrama de colaboración que muestra este proceso se encuentra en el anexo E. La descripción completa la encuentra en el JAVADOC que esta en el CD anexo. Generador Mensajes Planteamiento: Pensando en la necesidad de ahorrar recursos sobre el dispositivo y darle un manejo diferente al llamado de un servicio desde un dispositivo móvil, que presente una carga mas liviana que la de los paquetes de XML mencionados anteriormente, se crea el mensaje que será distribuido por la red para consumir un servicio desde un servidor. Propósito: Generar un mensaje de tipo String en una cadena que será enviada a través de un flujo de bytes desde el servidor al cliente y viceversa. Explicación: El proceso que se debe seguir para generar un mensaje viéndolo desde el código es el siguiente: 58

59 //Generar una instacia de tipo IMensajes del tipo que se defina (RentaTools) IMensajes mensaje = (IMensajes)FabricaMensajes.fabricar( RentaTools ); //Pasa como parámetro un string con el nombre del servicio que requiere mensaje.setservicio( Servicio ); //Pasa como parámetro un string con el nombre del parámetro que necesite. //Si necesita más parámetros, llame el método de nuevo. mensaje.setparametro( Nombre_Parametro ); //Pasa como parámetro el tipo de respuesta en un string (string, int, void, etc.) mensaje.setrespuesta( String ); Este es útil cuando se quiere enviar un mensaje desde el dispositivo móvil hasta el servidor y el desarrollador esta en capacidad de modificarlo si lo desea desde la implementación o desde la interface si desea añadir mas métodos. No permite generar una nueva instancia, ahorrando recursos s obre el dispositivo haciendo uso del patrón singleton. Para ver la estructura del mensaje remítase a la figura 8.2.2a. Patrones Aplicados: Singleton, Bridge, Prototype y Factory. El diagrama de colaboración que muestra este proceso se encuentra en el anexo E. La descripción completa la encuentra en el JAVADOC que esta en el CD anexo. La segunda parte se trata del manejo de los servicios desde el servidor, por lo que se han implementado unas clases que se harán cargo de esta parte. A continuación se presenta cada una de estas clases adicionales, junto con su descripción. Tabla 9: PARTE II SERVIDOR (J2EE o Web Service) Utilidades Explicación Planteamiento: Pensando en la necesidad de separar responsabilidades y utilizar un bajo acoplamiento en el manejo de la persistencia se piensa en un objeto que tiene estas características y es el Objeto de Acceso a datos llamado DAO. Propósito: Generar un objeto DAO que tiene el acceso directo a una parte especifica en la base de datos. Persistencia Vía DAO Explicación: El proceso que se debe seguir para generar un objeto DAO viéndolo desde el código es el siguiente: //Generar una instacia de tipo AbstractFactoryDAO, en este caso de una BD Access. AbstractFactoryDAO fabrica = AbstractFactoryDAO.getInstanceAccess(); //Con la fabrica creo el tipo de DAO que desee generando una instancia de ITablaDAO. ITablaDAO dao = fabrica.nuevotabladao(); //Creo el objeto DTO o data transfer object que contiene los atributos a transferir TablaDTO dto = new TablaDTO( parametros ); //Con el dao llamo los métodos CRUD para tener acceso a la base de datos. Dao.insertar(dto); 59

60 Este es útil cuando se quiere manejar un acceso a la base de datos de una manera desacoplada y fácil de entender. No permite generar una nueva instancia, ahorrando recursos al hacer uso del patrón singleton. Patr ones Aplicados: Singleton, Bridge, Value Object, Abstract Factory y DAO. El di agrama de colaboración que muestra este proceso se encuentra en el anexo E. La descripción completa la encuentra en el JAVADOC que esta en el CD anexo. Planteamiento: Pensando en la necesidad de crear un acceso a la base de datos mas eficiente y rápido y que haga un buen manejo de los recursos disponibles. Propósito: Generar un pool de conexiones con el que se tiene acceso directo a la base de datos. Explicación: El proceso que se debe seguir para generar un Pool de conexiones viéndolo desde el código es el siguiente: Pool de Conexiones //Generar una instacia de tipo IPoolConexiones con el nombre del pool. IPoolConexiones pool = FabricaPoolConexiones.fabricar( Nombre_PoolConexiones ); //Con el pool puede llamar ahora una conexión cada vez que la necesite. Connection con = pool.getconexion(); //Con este método devuelvo la conexión al pool de conexiones. pool.soltarconexion(con); Este es útil cuando se quiere manejar un acceso a la base de datos de una manera eficiente y rápida. No permite generar una nueva instancia, ahorrando recursos al hacer uso del patrón singleton. Patrones Aplicados: Singleton, Bridge y Factory. El diagrama de colaboración que muestra este proceso se encuentra en el anexo E. La descr ipción completa la encuentra en el JAVADOC que esta en el CD anexo.. Planteamiento: Pensando en la necesidad de poder localizar algunos servicios a la parte de J2EE y un manejo eficiente y rápido de los recursos. Propósito: Hacer un llamado de localización de un servicio de una manera eficiente. Explicación: El proceso que se debe seguir para generar un llamado para localizar un servicio es el siguiente: Localizador Servicios //Generar una instancia al home de un aplicativo con el nombre del EJB es un caso. EJB_home home= (EJB_Home)JNDIServiceLocator.getRemoteObject( nombre, EJB_Home.class); //Generar una instancia a la cola de mensajes de un aplicativo con el nombre de la cola. Vector vec = JNDIServiceLocator.getQueue( nombre_contexto_cola, nombre_cola ); Este es útil cuando se quiere localizar un EJB o una Cola eficientemente. No permite generar una nueva instancia, ahorrando recursos al hacer uso del patrón singleton. 60

61 Patrones Aplicados: ServiceLocator y Singleton. El diagrama de colaboración que muestra este proceso se encuentra en el anexo E. La descripción completa la encuentra en el JAVADOC que esta en el CD anexo. Este consiste en una clase que se encarga de crear y localizar los servicios para los EJBs y para JMS, utilizando los patrones ServiceLocator y Singleton. Se encuentra ubicada en el paquete framework.mensajes.servidor.j2ee. JNDIServiceLocator: Este objeto se encarga de crear y localizar un objeto de acuerdo a los siguientes métodos: public synchronized EJBHome gethome(string ejbname, Class cl ase) Este método es sincronizado por lo cual solo uno puede accederlo a la vez y encuentra el EJBHome, pasándole como parámetros el nombre del EJB y la clase Home, con lo que devuelve como resultado el EJBHome. public synchronized Object getremoteobject(string objectname, Class objectclass, Properties conproperties) Este método es sincronizado por lo cual solo uno puede accederlo a la vez y encuentra un objeto EJB remoto, pasándole como parámetros el nombre del objeto, la clase Home y los Properties que necesite para encontrar el contexto que se necesite. public synchronized Object getremoteobject(string objectname, Class objectclass) Este método es sincronizado por lo cual solo uno puede accederlo a la vez y encuentra un objeto EJB remoto, en donde ya están definidas los properties, pasándole como parámetros el nombre del objeto, la clase Home. public synchronized EJBLocalHome getlocalhome (String ejbname) Este método es sincronizado por lo cual solo uno puede accederlo a la vez y encuentra un objeto EJB local, pasándole como parámetro el nombre del objeto. public synchronized DataSource getdatasou rce(string dsname) Este método es sincronizado por lo cual solo uno puede accederlo a la vez y encuentra un objeto DataSource, pasándole como parámetro el nombre del datasource que desea ubicar. public synchronized Object getqueue(string factoryname,string queuename) Este método es sincronizado por lo cual solo uno puede accederlo a la vez y encuentra una cola remotamente y la devuelve en un objeto de tipo Vector en el que guarda el QueueConnectionFactory y el Queue para su posterior uso desde el cliente. public synchronized Object getlocalqueue(string factoryname,string queuename) Este método es sincronizado por lo cual solo uno puede accederlo a la vez y encuentra la cola localmente y lo devuelve en un objeto de tipo Vector en el que guarda el QueueConnectionFactory y el Queue para su posterior uso desde el cliente. Generador Servicios Planteamiento: Pensando en la necesidad de poder separar responsabilidades y tener un d elegador del negocio, con el se pueda separar el manejo directo a los EJBs o a un Web Service, este es el punto donde se debe utilizar. Propósito: Delegar el servicio que se este requiriendo hacia un EJB o hacia un Web Service según sea el caso. Explicación: El proceso que se debe seguir para generar un llamado para generar un servicio es el siguiente: 61

62 //Generar una instancia del IGeneradorServicios para un aplicativo. IGenerador servicios generador = FabricaGeneradorServicios.fabricar( nombre_aplicativo ); //Este resuelve el servicio de acuerdo al requerimiento que llega como buffer. generador.resolverservicio(buffer); Este es útil cuando se quiere delegar responsablidades dentro del manejo del aplicativo entre el cliente y el servidor. No permite generar una nueva instancia, ahorrando recursos al hacer uso del patrón singleton. Patrones Aplicados: Singleton, Bridge y Factory. El diagrama de colaboración que muestra este proceso se encuentra en el anexo E. La descripción completa la encuentra en el JAVADOC que esta en el CD anexo. FabricaGeneradorServicios: Este objeto se encarga de fabricar un recurso de acuerdo al que se le pida (Aplicativo) y se define con el siguiente método: public static IGeneradorServicios fabricar(string recurso) Aquí se define el nombre del recurso como parámetro que se quiera generar. En este ejemplo será una clase llamada GeneradorServiciosAplicativo.. IGeneradorServicios Esta es una interface que define los servicios que debe manejar cualquiera de los recursos que se deseen construir. public String resolverservicio(string buffer) Este método se encarga de resolver el servicio que ha sido invocado por el cliente, el cual llega en la estructura del mensaje y luego es construido y ejecutado para regresar el resultado en un dato de tipo String que el desarrollador debe saber como manejar al llegar al cliente. GeneradorServiciosAplicativo: Este objeto implementa todos los servicios defi nidos en la interface IGeneradorServicios, utilizando las clases de Propiedades y Escuchar Mensajes. Esta clase es el punto de entrada desde el cliente al servidor y funciona como controlador, por lo que le delega el trabajo a otras clases, en este caso una clase que implemente la interface IGeneradorServicios. Se encuentra ubicada en el paquete framework.mensajes.servidor. Maneja el patrón de diseño Proxy. Proxy Servlet ProxyServlet: Esta clase extiende de HttpServlet por lo que implementa los siguientes metodos: public void init(servletconfig config) Aquí se crean las instancias iniciales como son las de las Propiedades y la de la Generadora de Servicios, con las que resuelve el servicio. public void doget(httpservletrequest request, HttpServletResponse response) Aquí se llama el método dopost al que le delega como resolver el mensaje entrante. public void dopost(httpservletrequest request, HttpServletResponse response) Aquí llega el request, que luego es procesado por un método llamado getmensaje, el cual retorna un String con la estructura del mensaje. Luego se la da al Generador de Servicios para que la resuelva. Finalmente llama un método llamado setrespuesta en el que envió la respuesta al cliente. 62

63 Esta clase se encarga de poner y traer mensajes sobre la cola de mensajes que son colo cados en el JMS y en el que se pueden ajustar las configuraciones para su manejo. Maneja los patrones Singleton y Mediator. Utiliza dos métodos, uno para poner el men saje en la cola de mensajes y otro para traerlos. Se encuentra ubicada en el paquete framework.mensajes.servidor.j2ee. Cola_ Mensajes Cola_Mensajes: Su constructor se encarga de crear la cola de mensajes, haciendo uso de la clase JNDIServiceLocator, en donde recibe los parámetros de localización de esta; uno es el QueueConnectionFactory y el otro es el Queue. public void ponermensaje(string datos) Aquí se toma el parámetro llamado datos y se coloca en la cola de mensajes del JMS. public Vector traermensajes() Aquí se hace un llamado a todos los mensajes que se encuentren actualmente en la cola de mensajes y los retorna en un Vector que se compone de cada uno de estos. El desarrollador esta en libertad de modificar cualquiera de los objetos aquí planteados, ya que si desea modificar o añadir nuevos métodos puede hacerlo en la implementación de cada uno de los objetos anteriormente mencionados. La idea es que el framework pueda crecer con base a nuevos recursos que se necesiten. Cada vez que decida añadir nuevas implementaciones lo único que debe hacer el desarrollador es copiar la implementación actual del objeto que desee modificar y empezar a realizar los cambios deseados ya que están claramente explicado s cada uno de estos, con su objetivo y su estructura en la anterior parte. 8.3 DIAGRAMA DE PAQUETES A continuación se podrá observar detalladamente como esta distribuido el framework y como interactúa cada uno de los paquetes en la figura

64 Figura 8.3: Diagrama de Paquetes alertas Cliente Propiedades mensajes Framework servidor Servidor Propiedades cliente dao j2ee aplicativo impl poolconexiones Cada uno de los componentes encontrados en la figura 5.3 tienen una funcionalidad que le brinda al desarrollador una facilidad al crear o utilizar alguno de los recursos, para esto se explicara cada uno de los componentes en un paquete llamado framework y su tarea dentro del proyecto del Framework de Manejo de Mensajes de Dispositivos Móviles. alertas: Este paquete contiene el manejo de alertas y es donde se ubicara cualquier tipo de alerta adicional que se desee implementar. En el se encuentra también la fabrica de recursos y la interface que deben implementar. dao: Este paquete contiene el manejo de daos que se deseen implementar para el acceso a una base de datos según el usuario lo defina. En el se encuentran la fabrica de recursos, el paquete de aplicativo en donde se definen todas las interfaces de los daos. Finalmente en el paquete de impl se encuentra la implementación de dichas interfaces. Mensajes: Este paquete contiene el manejo de los mensajes que se realiza entre el dispositivo móvil y el servidor. En el se encuentran la fabrica de mensajes, la interface y las clases que la implementen. También están los paquetes de servidor (maneja toda la parte de acceso al servidor hasta la ubicación del servicio que se necesite), paquete de cliente (maneja la parte de comunicación desde el dispositivo móvil), y finalmente el paquete de j2ee (maneja el patrón service locutor y el Mediator). 64

65 poolconexiones: Este paquete contiene el manejo del pool de conexiones y es donde se ubicara cualquier tipo de pool adicional que se desee implementar. En el se encuentra también la fabrica de recursos y la interface que deben implementar. propiedades: Este paquete pertenece al cliente y es en donde se definen todas las constantes que se manejen en el dispositivo móvil. propiedades: Este paquete pertenece al servidor y es en donde se definen todas las constantes que se manejen en el lado servidor. 8.4 DIAGRAMA DE CLASES Dentro de los paquetes que se mencionaron anteriormente ubicamos varias clases que hacen parte del framework. Cada uno de los diagramas correspondientes a cada uno de los paquetes puede ser encontrado en el anexo A. La explicación de cada uno de estos componentes se encuentra en el numeral anterior, en el cual se explico claramente cada una de las clases. 8.5 PROTOTIPO FUNCIONAL Para ya poder entrar en materia en la construcción de un aplicativo tentativo, que ilustre el manejo del framework y al cual se le llama Prototipo Funcional, se han definido dos ejemplos de prototipo funcional: Uno es el aplicativo llamado Triqui y dos es un aplicativo llamado RentaTools APLICATIVO TRIQUI Este aplicativo consiste en generar un juego conocido en el que se ubican dos valores una X y una O. Su objetivo es completar en un cuadro de 3 x 3 el lograr ubicar tres de los mismos valores en una línea recta. Por ejemplo si en la parte superior del cuadro hay tres X, se tendrá un ganador. Todo esto se ejecuta utilizando un dispositivo móvil, el cual se comunica con un servidor J2EE a través de la Web por medio del Framework de Manejo de Mensajes. Cuando el jugador (cliente) ejecuta un movimiento, este se comunica con un servidor Web, el cual se encarga de guardar los movimientos realizados y luego realiza un movimiento aleatorio hasta encontrar un ganador CASOS DE USO El prototipo funcional sobre el cual se va ha trabajar, implementa como ejemplo los siguientes casos de uso en orden alfabético, los cuales permitirán mostrar claramente el uso del Framework que se esta planteando aquí: 65

66 Consultar Jugadores Consultar Puntaje Hacer Movimiento CPU Hacer Movimiento Jugador Ingresar Jugador Iniciar Juego Seleccionar Letra Figura : Diagrama Casos de Uso Triqui Cada uno de los casos de uso que se encuentra en la Figura , está debidamente documentado en el anexo B. Aquí se podrá encontrar detalladamente los siguientes puntos con respecto a cada uno de los casos de uso que se plantearon para este prototipo funcional: Actor Descripción Flujo de Eventos Precondiciones Poscondiciones Puntos de Extensión ARQUITECTURA: Aquí se presenta un esquema de la arquitectura del sistema que se trabajará en el desarrollo del prototipo funcional, sobre el cual se tendrá una arquitectura mulicapas y en donde se podrá ver por separado cada una de las capas que existen en la aplicación. Obteniendo de esta forma un mejor análisis de cada uno de los componentes que se encuentran presentes y como la información es transmitida entre cada uno de estos. L a figura muestra claramente como esta distribuida la arquitectura para esta aplicación. 66

67 Figura : Arquitectura Prototipo Funcional Tr iqui Capa Presentación Capa del Negocio WAP INTERNET Servidor Web Cliente Móvil J2ME Capa Persistencia JDBC JWSDP 1.3 Servidor JBoss JNDI Access JBoss En la capa de presentación se puede encontrar el cliente sobre el cual funciona el prototipo funcional utilizando tecnología J2ME, desde allí se invocarán los servicios que este necesite haciendo uso del framework de manejo de mensajes. La conexión con el servidor se hará a través de Internet vía WAP con el servidor Web el cual corre sobre Tomcat dentro de la herramienta JWSDP 1.3. En la capa del negocio se encuentra el Servidor Web, el cual se comunica vía JNDI con otro servidor sobre el que corren los componentes de J2EE. Se utiliza la herramienta de JBoss para el manejo de los EJBs. Final mente esta la capa de persistencia en donde se encuentran todos los datos correspondientes a la aplicación que se hace vía JDBC por medio de los DAOs que utiliza la aplicación con una base de datos MS Access. Ahora viéndolo desde el punto de vista del framework de manejo de mensajes, el proceso que se realiza para llevar a cabo un servicio del triqui, como es el de realizar un movimiento es el siguiente: 1. El cliente esta hecho en J2ME sobre el dispositivo móvil (Celular). Un servicio que presta la aplicación es el de realizar un movimiento por el usuario, el cual ubica una letra sobre el tablero en la posición deseada. 67

68 2. Ahora empieza el framework a hacer su tarea, mediante el componente Generador de Mensajes, genero un mensaje con la siguiente estructura explicada en la sección a string hacermovimientojugador 51/X/. 3. Luego, mediante la capa de transporte de TransporteHttp envió en forma de bytes al servidor en donde hay un Servlet haciendo las peticiones y respuestas. 4. Una vez en el Servlet (ubicado en el JWSDP de la figura ), llama el componente Generador de Servicios, al cual le delega el servicio a la lógica del negocio. Es aquí donde el desarrollador toma su lógica del negocio y la implementa para conectarse con el servidor que contiene los EJBs (ubicado en el JBoss de la figura ) en este caso y los cuales accede mediante el Localizador de Servicios. Igualmente, construye el mensaje de nuevo con el Generador de Mensajes, para luego decidir cual servicio llamar mediante el Generador de Servicios. 5. La lógica del negocio diseñada por el desarrollador, entonces toma el servicio y llama en este caso el componente de Persistencia vía DAO y el Pool de Conexiones para conectarse con la base de datos, y el jugador gana el juego en esta jugada. 6. Retorna una respuesta en un String hacia el Cliente, a través de los mismos componentes ya mencionados anteriormente y por los cuales paso para consumir el servicio. 7. Una vez que llega la respuesta al cliente (Celular), este llama el Generador de Alertas y luego muestra en pantalla el mensaje informativo de A ganado el Juego. Este es solo un ejemplo del consumo de un servicio, aunque para todos se sigue el mismo proceso, haciendo uso del Framework de manejo de mensajes. Como se puede observar, hay una clara separación de responsabilidades por cada capa que el servicio pasa. Así mismo, se debe tener presente que la parte cliente del aplicativo la genera el desarrollador, así como la parte servidor y solo se apoya sobre el framework para hacer uso de sus utilidades que se encuentran en cada uno de los componentes mencionados en la figura b DIAGRAMA DE PAQUETES: A continuación se podrá observar detalladamente como esta distribuido el prototipo funcional con el cual se quiere trabajar y mostrar como interactúa cada uno de los paquetes en la figura

69 Figura : Diagrama de Paquetes Framework aplicacion aplicacion cliente j2me triqui servidor j2ee triqui impl Cada uno de los componentes encontrados en la figura son los que interactúan con el framework y muestran como el aplicativo hace uso de este. Este está divido en dos partes: Un paquete que contiene otros paquetes en el lado cliente: El paquete aplicación dentro del cual se encuentra el paquete cliente, luego el paquete j2me y finalmente el paquete triqui. Es en este paquete final en donde están todas las clases que interactúan con la tecnología de J2ME y hacen uso del Framework de manejo de mensajes. Un paquete que contiene otros paquetes en el lado servidor: El paquete aplicación dentro del cual se encuentra el paquete servidor, luego el paquete j2ee, el paquete triqui, en donde están las interfaces de los EJBs. Finamente esta el paquete impl en el que esta la clase FachadaTriquiBean que es la implementación de las interfaces anteriores. Estas también interactúan con el Framework de manejo de mensajes DIAGRAMA DE CLASES: Dentro del diagrama de paquetes (figura ) se pueden observar algunas clases que hacen uso del framework de manejo de mensajes, él cual describió cada uno de sus componentes en el numeral de arquitectura lógica. Los diagramas correspondientes a los paquetes pueden ser encontrados en el anexo C, bajo el diagrama de clases del Prototipo funcional Triqui DIAGRAMA BASES DE DATOS: Las Bases de datos que utiliza el prototipo funcional están hechas utilizando los DAOs que provee el framework, los cuales son implementados y diseñados por el Programador, quien a partir de la fabrica de DAOs puede producir un DAO para consultar, actualizar, borrar o insertar un elemento dentro de una tabla. Todo esto se encuentra claramente explicado en la arquitectura lógica del Framework que se dio anteriormente (8.2.2 Arquitectura Lógica). 69

70 La base de datos utiliza una conexión vía ODBC para MS Access y la cual es muy sencilla ya que implica únicamente los siguientes elementos (Figura ): Figura : Diagrama de Bases de Datos Esta contiene las tablas de Jugador y Puntaje con sus atributos respectivos MANUAL DE USUARIO: El juego consiste en que el jugador toma inicialmente una opción de la letra con la que desea jugar una X o una O según lo desee. Su objetivo ahora es completar en un cuadro de 3 x 3, el lograr ubicar tres de los mismos valores en una línea recta. Por ejemplo si en la parte superior del cuadro hay tres X, se tendrá un ganador. (Este juego no es inteligente, ya que solo se quiere mostrar un prototipo funcional). Las instrucciones que se darán a continuación, se basan en el uso del emulador (Celular) con el que se esta trabajando durante todo el proyecto, aunque para otro dispositivo podría ser algo muy parecido. Ahora que se sabe el objeto del juego, se puede pasar a la parte inicial en donde el jugador o persona que se encuentre utilizando el dispositivo móvil (Celular), encontrará una pantalla de inicio en donde debe aceptar la opción del juego Triqui, presionando el botón select o launch para dar inicio al juego (Figura a). Una vez que se inicia el juego, se pasará por una pantalla de créditos que luego lo llevará a la pantalla del menú inicial en donde podrá encontrar las siguientes opciones (Figura b): Iniciar Juego Consultar Jugadores Consultar Puntajes 70

71 Figura : Pantalla Celular Triqui a b c La primera opción es la de Iniciar Juego, con la cual se pasará ha una pantalla de ingresar nombre pulsando la tecla ingresar, en donde el sistema se encargará de ingresar el nombre en caso de ser nuevo a la base de datos, o de lo contrario únicamente lo consultará (Figura c). Si desea volver al menú inicial pulse la tecla Salir. Después de esto, aparecerá una pantalla con las opciones de letra (X / O), con la cual el jugador toma una opción con la tecla select para iniciar su juego ( Figura a). Ahora aparece la pantalla de Juego sobre la que el jugador pondrá su jugada con las teclas de números del celular en la posición deseada (Figura b). Posición izquierda-arriba con la tecla número 1. Posición medio-arriba con la tecla número 2. Posición derecha-arriba con la tecla número 3. Posición izquierda-medio con la tecla número 4. Posición medio-medio con la tecla número 5. Posición derecha-medio con la tecla número 6. Posición izquierda-abajo con la tecla número 7. Posición medio-abajo con la tecla número 8. Posición derecha-abajo con la tecla número 9. Después de cada jugada que ejecute el jugador, el sistema automáticamente realizará su jugada, colocando la letra en otra posición. Cuando el jugador o el sistema logran realizar el Triqui (Tres letras en línea recta), esté obtendrá una pantalla de Ganador y pasará inmediatamente después a la pantalla del menú inicial, guardando los puntos del jugador, sí ganó la partida. Pasando a la segunda opción del menú de inicio (Consultar Jugadores), el jugador puede consultar los jugadores que han ingresado al sistema o que han participado de alguna 71

72 manera en el juego al ingresar su nombre anteriormente, desplegando una lista de nombres de estos ( Figura c). Figura : Pantalla Celular Triqui a b c La ultima opción del menú de inicio (Consultar Puntajes), permite que el jugador consulte el puntaje para un jugador determinado. Cuando el jugador toma esta opción, aparecerá la pantalla de ingresar nombre (Figura c), en donde debe digitar exactamente el nombre como lo ingreso inicialmente en el juego, de lo contrario no encontrará el jugador y por lo tanto no podrá consultar el puntaje (Figura a). Figura : Pantalla Celular Triqui a 72

73 El juego que se construyó como prototipo funcional es muy básico, por lo que solo se pretende dar lugar al uso de la herramienta propuesta en este proyecto framework, haciendo uso de este a través de las diferentes funcionalidades que el juego puede presentar MANUAL TÉCNICO: Para el desarrollo de este aplicativo se necesita de las cuatro herramientas que fueron citadas en el capitulo III, con las cuales se seguirá el siguiente procedimiento y con ayuda del Framework de manejo de mensajes para dispositivos móviles, se construirá paso a paso la aplicación. Paso1: Abrir la herramienta JDeveloper 10g desde JDEVELOPER_HOME/jdev/bin, con el archivo ejecutable llamado jdevw.exe. Ahora se procederá ha crear un nuevo espacio de trabajo desde el menú de Archivo con la opción New. Luego, en la pantalla que aparece le da la opción de workspace le asigna la ruta deseada y lo nombre con el nombre que usted desee, para este caso se llamó Proyecto Tesis I. En la siguiente pantalla, igualmente le pone el nombre que desee al proyecto, para este caso se llamó Triqui. Ahora que se tiene el proyecto creado, se puede empezar a crear las clases que necesite el proyecto, pero antes de eso se debe adicionar al proyecto las clases del framework que ya se encuentran creadas. Paso 2: Copiar y renombrar desde alguno de los aplicativos de ejemplo ya creados o desde el inicial los componentes del Framework de manejo de mensajes, los cuales se encuentran ubicados en la carpeta SRC del proyecto creado. Se deben copiar los siguientes paquetes junto con sus clases en el paquete SRC del proyecto creado: alertas: FabricaAlertas IAlertas Advertencia Error Informativa InicialTriqui (clase adicional creada) dao: AbstractFactoryDAO AccessFactoryDAO (En este caso se utiliza conexión a Access) aplicativo ITablaDAO (ejemplo; nombre de la tabla que necesite) IPuntajeDAO IJugadorDAO impl ObjetoDTO (ejemplo; nombre del objeto que necesite) TablaAccessDAO (ejemplo; nombre de la tabla ha implementar) PuntajeDTO PuntajeAccessDAO 73

74 JugadorDTO JugadorAccessDAO mensajes: FabricaMensajes IMensajes Mensaje (ejemplo; nombre del mensaje que desea enviar y traer) MensajeTriqui (mensaje utilizado por el Triqui) cliente ITransporteHttpListener TransporteHttp servidor FabricaGeneradorServicios IGeneradorServicios GeneradorServiciosAplicativo (ejemplo; nombre del aplicativo que se desea implementar) GeneradorServiciosTriqui ProxyServlet j2ee JNDIServiceLocator Cola_Mensajes Propiedades: cliente Propiedades (constantes creadas para el cliente del Triqui) servidor Propiedades (constantes creadas para el servidor del Triqui) Poolconexiones: FabricaPoolConexiones IPoolConexiones PoolConexionesAccessAplicacion (ejemplo; nombre del pool que le desee poner, en este caso para Access) PoolConexionesAccessTriqui (pool de conexiones para el Triqui). Las clases que se utilizaran para el Triqui han sido renombradas con la palabra Triqui y las otras pueden ser borradas. Para tener mas claro que hace cada clase, por favor remítase a la sección Arquitectura Lógica. Paso 3: Una vez copiados, se procede ha realizar las implementaciones necesarias para cada una de las clases mencionadas anteriormente con el aplicativo que se desea desarrollar, en este caso el Triqui. Para ver como se hizo aquí, remítase al código fuente de éste anexo en el CD, en el que encontrará como se implementa cada una de estas clases para el aplicativo del Triqui. Paso4: Ahora puede implementar la lógica del negocio y la lógica de presentación para el aplicativo, de la cual e sta encargado el desarrollador ya que esta es totalmente 74

75 independiente del Framework y para el caso del Triqui se esta guardando en dos paquetes diferentes que hacen uso del Framework. aplicativo: bajo este paquete se tienen las clases que se encargaran de la lógica de presentación del aplicativo Triqui. servidor: bajo este paquete se tienen las clases que se encargan de la lógica del negocio del Triqui. Para construir esta lógica con el JDeveloper, la pagina de Oracle cuenta con un completo tutorial paso a paso en como crear un Session bean. Paso5: Una vez que se tengan definidas todas las cl ases que trabajaran en conjunto con el Framework y la implementación de algunas de las clases del framework, se procede a copiar el archivo de propiedades, el cual es llamado por la clase Propiedades en el servidor para la creación de algunos objetos, brindándole una mayor flexibilidad y fácil mantenimiento al aplicativ o. Debe ser guardado con el proyecto en una carpeta llamada config. Paso 6: Ahora se deben copiar los archivos necesarios en la carpeta llamada lib, para poder compilar el proyecto sin ningún inconveniente para poder continuar con el trabajo. Los archivos son: jbossall-client.jar cldcapi10.jar cldcapi11.jar midpapi10.jar midpapi20,jar servlet-api.jar Paso 7: Después de haber copiado los archivos anteriores, se debe copiar y reformar el archivo build.xml, el cual se en carga a través de la herramienta de Ant que contiene el JDeveloper, de crear los.class y organizarlos en archivos.jar para que estos sean copiados en la ruta que allí se especifica. Este archivo se encuentra dentro de la carpeta del proyecto y debe ser colocado allí junto con un archivo build.properties en el que se especifican las carpetas que se desean utilizar. Se debe correr utilizando el comando build. Paso 8: Después de haber corregido cualquier error que se halla podido presentar en el paso 7, se puede proceder a copiar los archivos del paquete aplicativo en un nuevo proyecto que se crea a partir de la herramienta J2ME Wireless Toolkit 2.1. Allí se debe copiar el archivo framework.jar, que se genera con el build.xml después de haber cambiado dentro del paquete mensaje las propiedades de las clases por las propiedades del cliente, ya que estas están apuntado a las propiedades del servidor. Finalmente las clases que se copian para que el cliente funcione correctamente son: 75

76 aplicativo: cliente j2me Triqui PantallaIngreso PantallaJuego PantallaJugadores PantallaMenu PantallaPuntajes PantallaSeleccion ProxyTriqui Temporizador framework: alertas FabricaAlertas IAlertas InicialTriqui Informativa Error Advertencia Ganador mensajes FabricaMensajes (cambiar propiedades al cliente) IMensajes MensajeTriqui cliente ITransporteHttpListener TransporteHttp propiedades Propiedades (las del paquete cliente) Como se puede observar no existe ninguno de los paquetes que se crearon bajo el paquete de servidor, ya que se esta trabajando con la parte del cliente. Paso 9: Verificar que cuando se hizo el build del xml en el paso 7, haya ubicado el paquete con los archivos necesarios para el servidor en el Tomcat del JWSDP 1.3 y en el JBoss en las carpetas correspondientes para hacer el despliegue de estas. Paso 10: Por ultimo, iniciamos los procesos desde el servidor de la siguiente manera: Iniciar el JWSDP 1.3 desde el menú de inicio con la opción de Start Tomcat. Iniciar el JBoss con el run.exe que se encuentra dentro de la carpeta bin. Correr el cliente desde la herramienta de J2ME Wireless Toolkit 2.1 Recuerde que existen unos settings tanto en el cliente como en el servidor que deben ser ajustados para que el proyecto funcione correctamente. 76

77 8.5.2 APLICATIVO RENTATOOLS Este aplicativo consiste en realizar una reserva de un producto, que es una herramienta ha ser alquilada por un usuario que se encuentra registrado en el sistema, desde un dispositivo móvil (Celular), con el cual ingresa su reserva para una fecha y duración especifica, en donde luego es posteriorment e revisado por el personal de la empresa llamada RentaTools, quienes procederán a hacer entrega del producto reservado para la fecha especifica CASOS DE USO: El prototipo funcional sobre el cual se va ha trabajar, implementa como ejemplo los siguientes casos de uso en orden alfabético, los cuales permitirán mostrar claramente el uso del Framework que se esta planteando aquí: Activar Reserva Autenticar Cliente Cancelar Reserva Consultar Categoría Consultar Productos por Categoría Consultar Reservas Consultar Valor Poner Reserva Pendiente Realizar Reserva Figura : Diagrama de Casos de Uso RentaTools Cada uno de los casos de uso que se encuentra en la Figura , está debidamente documentado en el anexo B. Aquí se podrá encontrar detalladamente los siguientes puntos con respecto a cada uno de los casos de uso que se plantearon para este prototipo funcional: Actor Descripción 77

78 Flujo de Eventos Precondiciones Poscondiciones Puntos de Extensión ARQUITECTURA: Aquí se presenta un esquema de la arquitectura del sistema que se ha planteado para el desarrollo del prototipo funcional, sobre el cual se trabajará con una arquitectura multicapas y en donde se podrá ver por separado cada una de las capas que existen en la aplicación. Obteniendo de esta forma un mejor análisis de cada uno de los componentes que se encuentran presentes y como la información es transmitida entre cada uno de estos. La figura muestra claramente como esta distribuida la arquitectura para esta aplicación. Figura : Arquitectura Prototipo Funcional RentaTools Capa Presentación Capa del Negocio Cliente Móvil J2ME WAP INTERNET Servidor Web HTTP JWSDP 1.3 SOAP Capa Persistencia Servidor JDBC Access OC4J Oracle Web Service En la capa de presentación se puede encontrar el cliente sobre el cual funciona el prototipo funcional, desde allí se invocarán los servicios que este necesite utilizando el framework de 78

79 manejo de mensajes. Para esta aplicación se hace desde un dispositivo móvil (Celular) utilizando tecnología J2ME y un cliente remoto utilizando JSPs. La conexión con el servidor se hará a través de Int ernet vía HTTP con el servidor Web el cual corre sobre el OC4J de Oracle y es en donde se encuentra el Web Service. En la capa del negocio se encuentra el Servidor Web, el cual se comunica vía JNDI con otro servidor sobre el que corren los componentes de J2EE. Se utiliza la herramienta de JBoss para el manejo de los EJBs. Finalmente esta la capa de persistencia en donde se encuentran todos los datos correspondientes a la aplicación que se hace vía JDBC por medio de los DAOs que utiliza la aplicación con una base de datos MS Access. Ahora viéndolo desde el punto de vista del framework de manejo de mensajes, el proceso que se realiza para llevar a cabo un servicio del RentaTools, como es el de realizar la reserva para un producto especifico. 1. El cliente esta hecho en J2ME sobre el dispositivo móvil (Celular). Un servicio que presta la aplicación es el de realizar la reserva por el usuario, para el cual ya siguió un proceso de escoger el producto y ingresar la fecha para la que quiere la herramienta, ahora solo le queda aceptar la reserva. 2. Ahora empieza el framework a hacer su tarea, mediante el componente Generador de Mensajes, genero un mensaje con la siguiente estructura explicada en la sección a string realizarreserva /1/ /15/. 3. Luego, mediante la capa de transporte de TransporteHttp envió en forma de bytes al servidor en donde hay un Servlet haciendo las peticiones y respuestas. 4. Una vez en el Servlet (ubicado en el JWSDP de la figura ), llama el componente Generador de Servicios, al cual le delega el servicio a la lógica del negocio mediante un mensaje SOAP. Es aquí donde el desarrollador toma su lógica del negocio y la implementa para conectarse con el servidor que contiene el Web Service (ubicado en el OC4J de la figura ) en este caso y desde allí accede a los EJBs haciendo uso del Localizador de Servicios. Igualmente, construye el mensaje de nuevo con el Generador de Mensajes, para luego decidir cual servicio llamar mediante el Generador de Servicios y el cual genera el SOAP para comunicarse con el Web Service (Esta implementación corresponde al desarrollador de acuerdo a la lógica de manejo del negocio que este manejando). 5. La lógica del negocio diseñada por el desarrollador, entonces toma el servicio y llama en este caso el componente de Persistencia vía DAO y el Pool de Conexiones para conectarse con la base de datos desde el EJB. 6. Si se puede realizar la reserva, este devuelve una respuesta con el numero de la reserva o en caso de no encontrar unidades disponibles envía un -1 como respuesta en un String hacia el Cliente, a través de los mismos componentes ya mencionados anteriormente y por los cuales paso para consumir el servicio. 7. Una vez que llega la respuesta al cliente (Celular), este llama el Generador de Alertas y luego muestra en pantalla el mensaje informativo de: Si esta disponible el producto Reserva Exitosa junto con el número de la reserva. Si no esta disponible Herramienta no Disponible. 79

80 Este es solo un ejemplo del consumo de un servicio, aunque para todos se sigue el mismo proceso, haciendo uso del Framework de manejo de mensajes. Como se puede observar, hay una clara separación de responsabilidades por cada capa que el servicio pasa. Así mismo, se debe tener presente que la parte cliente del aplicativo la genera el desarrollador, así como la parte servidor que maneja el SOAP y la lógica del negocio, solo apoyándose sobre el framework para hacer uso de sus utilidades que se encuentran en cada uno de los componentes mencionados en la figura b DIAGRAMA DE PAQUETES: A continuación se podrá observar detalladamente como esta distribuido el prototipo funcional con el cual se quiere trabajar y mostrar como interactúa cada uno de los paquetes en la figura Figura : Diagrama de Paquetes de RentaTools Framework beans aplicacion cliente j2me rentatools webservice aplicacion servidor j2ee rentatools cliente impl Cada uno de los componentes encontrados en la figura son los que interactúan con el framework y muestran como el aplicativo hace uso de este. Este está divido en dos partes: Un paquete que contiene otros paquetes en el lado cliente: El paquete aplicación dentro del cual se encuentra el paquete cliente, luego el paquete j2me y finalmente el paquete rentatools. Es en este paquete final en donde están todas las clases que 80

81 interactúan con la tecnología de J2ME y hacen uso del Framework de manejo de mensajes. Un paquete que contiene otros paquetes en el lado servidor: El paquete aplicación dentro del cual se encuentra el paquete servidor, luego el paquete j2ee, el paquete rentatools, en donde están las interfaces de los EJBs. Finalmente esta el paquete impl en el que esta la clase FachadaRentaToolsBean que es la implementación de las interfaces anteriores. Estas también interactúan con el Framework de manejo de mensajes DIAGRAMA DE CLASES: Dentro de los paquetes ubicados en la figura se puede observar como algunas de las clases que se encuentran dentro del paquete del aplicativo interactuan con el framework de manejo de mensajes. Cada uno de los diagramas correspondientes a los paquetes puede ser encontrado en el anexo C, bajo el diagrama de clases del Prototipo funcional RentaTools DIAGRAMA BASES DE DATOS: Las Bases de datos que utiliza el prototipo funcional están hechas utilizando los DAOs que provee el framework y los cuales son implementados y diseñados por el Programador, quien a partir de la fabrica de DAOs puede producir un DAO para consultar, actualizar, borrar o insertar un elemento dentro de una tabla. Todo esto se encuentra claramente explicado en la arquitectura lógica del Framework que se dio anteriormente (8.2.2 Arquitectura Lógica). La base de datos utiliza una conexión vía ODBC para MS Access y la cual es muy sencilla ya que implica únicamente los siguientes elementos (Figura ): 81

82 Figura : Diagrama de Bases de Datos Recibe como parámetro un entero con la llave primaria del registro en la tabla a eliminar. La base de datos contiene 8 tablas cada una con sus atributos correspondientes y las relaciones que se dan con cada una de estas se pueden observar en la figura anterior MANUAL DE USUARIO: Este aplicativo consiste en realizar una reserva de un producto, que consiste en una herramienta ha ser alquilada por un usuario que se encuentra registrado en el sistema, desde un dispositivo móvil (Celular), para el cual debe ingresar su reserva para una fecha y duración especifica, en donde luego es revisado por el personal de la empresa llamada RentaTools, quienes procederán a hacer entrega del producto reservado para la fecha especifica. Las instrucciones que se darán a continuación, se basan en el uso del emulador (Celular) con el que se esta trabajando durante todo el proyecto, aunque para otro dispositivo podría ser algo muy parecido. 82

83 Ahora que se sabe el objeto del aplicativo, se puede pasar a la parte inicial en donde el jugador o persona que se encuentre utilizando el dispositivo móvil (Celular), encontrará una pantalla de inicio en la cual debe aceptar la opción del aplicativo RentaTools, presionando el botón select o launch para dar inicio al aplicativo (Figura a). Una vez que se inicia el aplicativo, se pasará por una pantalla de ingreso al aplicativo, en la cual debe ingresar su usuario y clave y luego presionar el botón ingresar (Figura b). Si su usuario y clave son correctos lo llevará a la pantalla del menú inicial en donde podrá encontrar las siguientes opciones de categorías de herramientas que se pueden encontrar en el establecimiento y que se encuentran disponibles para el alquiler. Debe seleccionar una categoría con el botón select (Figura c). Figura : Pantalla CelularRentaTools a b c Después de haber tomado la decisión de la categoría que se desea, se pasa a una nueva pantalla que despliega el menú de las herramientas disponibles para la categoría elegida. Debe seleccionar una herramienta con el botón select (Figura a). Luego debe ingresar la información con respecto al tiempo de alquiler, en donde el usuario tiene dos tipos de opción: Una en donde selecciona un tiempo de alquiler preestablecido presionando el botón select. La otra opción, es definir el número de días que se desea alquilar la herramienta. Después de haber seleccionado el número de días lo único que queda es indicar la fecha en el formato (aaaa-mm-dd), ingresando dicha información con el teclado y luego presionando el botón aceptar. Debe haber ingresado toda esta información y solo un tipo de opción para hacer la reserva. (Figura b). Inmediatamente el sistema verifica la información ingresada y le dará la opción de alquilar la herramienta, haciendo la reserva pertinente al presionar el botón de aceptar (Figura c). En caso de que la herramienta no se encuentre disponible, el usuario podrá tomar la opción de dejar la reserva en pendiente para que esta sea verificada por el personal del establecimiento y luego su requerimiento sea respondido. 83

84 Por ultimo retornara al menú inicial en donde aparecen las categorías disponibles para poder realizar de nuevo todo el procedimiento en caso de querer alquilar otra herramienta. Figura : Pantalla CelularRentaTools a b c La tabla que mostrara las reservas hechas por cada uno de los usuarios que se encuentran preinscritos en el servicio, podrá ser vista vía Internet por uno de los usuarios del sistema y el cual tiene acceso a estos datos, para luego hacer los procedimientos respectivos, tales como: Cancelar y Activar una reserva. La página que se toma como ejemplo es MANUAL TÉCNICO: Para el desarrollo de este aplicativo se necesita de las cuatro herramientas que fueron citadas en el capitulo III, con las cuales se seguirá el siguiente procedimiento y con ayuda del Framework de manejo de mensajes para dispositivos móviles, se construirá paso a paso la aplicación. Paso1: Abrir la herramienta JDeveloper 10g desde JDEVELOPER_HOME/jdev/bin, con el archivo ejecutable llamado jdevw.exe. Para este aplicativo se deben crear dos proyectos diferentes, ya que uno se va ha hacer cargo de la parte del Web Service y el otro se encargará de la comunicación entre el dispositivo y el servidor Web. Ahora, para cada proyecto se procederá ha crear un nuevo espacio de trabajo, desde el menú de Archivo con la opción New. Luego, en la pantalla que aparece le da la opción de workspace le asigna la ruta deseada y lo nombre con el nombre que usted desee, para este caso el primer workspace se llamó WebService y el segundo Proyecto Tesis II. Luego, en la siguiente pantalla, igualmente le pone el nombre que desee al proyecto, para este caso se llamó RentaTools en los dos proyectos. Ahora que se tienen los proyectos creados, para el 84

85 primero se define únicamente la parte del servidor y las clases que van de este lado junto con el Web Service, a excepción de las clases que van en el segundo proyecto. En el segundo proyecto, deben ir las clases del Generador de Servicios, Proxy, el Generador de Mensajes y su respectivo build.xml. Paso 2: Copiar y renombrar desde alguno de los aplicativos de ejemplo ya creados o desde el inicial los componentes del Framework de manejo de mensajes, los cuales se encuentran ubicados en la carpeta SRC del proyecto creado. Se deben copiar los siguientes paquetes junto con sus clases: Primer workspace: dao: AbstractFactoryDAO AccessFactoryDAO (En este caso se utiliza conexión a Access) aplicativo ITablaDAO (ejemplo; nombre de la tabla que necesite) IAlquilerDAO ICategoriaDAO ICuentaDAO IEstadoDAO IProductoDAO IReservaDAO IUsuarioDAO impl ObjetoDTO (ejemplo; nombre del objeto que necesite) TablaAccessDAO (ejemplo; nombre de la tabla ha implementar) AlquilerDTO AlquilerAccessDAO CategoriaDTO CategoriaAccessDAO ClienteDTO ClienteAccessDAO CuentaDTO CuentaAccessDAO EstadoDTO EstadoAccessDAO ProductoDTO ProductoAccessDAO ReservaDTO ReservaAccessDAO UsuarioDTO UsuarioAccessDAO mensajes: FabricaMensajes IMensajes Mensaje (nombre del mensaje que desea enviar y traer) MensajeRentaTools (mensaje utilizado por el aplicativo RentaTools) 85

86 servidor j2ee JNDIServiceLocator Cola_Mensajes Propiedades: cliente Propiedades (constantes creadas para el cliente del aplicativo RentaTools) servidor Propiedades (constantes creadas para el servidor del aplicativo RentaTools) Poolconexiones: FabricaPoolConexiones IPoolConexiones PoolConexionesAccessAplicacion (ejemplo; nombre del pool que le desee poner, en este caso para Access) PoolConexionesAccessRentaTools(pool de conexiones para el aplicativo RentaTools). Segundo workspace: alertas: FabricaAlertas IAlertas Advertencia Error Informativa InicialRentaTools(clase adicional creada) mensajes: cliente ITransporteHttpListener TransporteHttp servidor FabricaGeneradorServicios IGeneradorServicios GeneradorServiciosAplicativo (ejemplo; nombre del aplicativo que se desea implementar) GeneradorServiciosRentaTools Las clases que se utilizaran para el aplicativo de RentaTools han sido renombradas con la palabra RentaTools con base a un ejemplo. Para tener mas claro que hace cada clase, por favor remítase a la sección Arquitectura Lógica. Paso 3: Una vez copiados todos los archivos necesarios, se procede ha realizar las implementaciones necesarias para cada una de las clases mencionadas anteriormente de acuerdo a las necesidades del aplicativo que se desea desarrollar, en este caso RentaTools. 86

87 Para ver exactamente que se debe copiar y en que lugar lo puede hacer a través del prototipo funcion al, remítase al código fuente de éste anexo en el CD. Paso4: Ahora que ya se tienen los dos proyectos, se empezará ha implementar la lógica del negocio en el primer proyecto y parte de ésta junto con la lógica de presentación en el segundo proyecto. De la lógica de presentación se encuentra encargado el desarrollador, ya que esta es totalmente independiente del Framework y para el caso del aplicativo RentaTools se esta guardando en dos paquetes diferentes que hacen uso del Framework. aplicativo : bajo este paquete se tienen las clases que se encargaran de la lógica de presentación del aplicativo RentaTools. (Pertenece al segundo proyecto) servidor: bajo este paquete se tienen las clases que se encargan de la lógica del negocio del aplicativo RentaTools. Para construir esta lógica con el JDeveloper, la página de Oracle cuenta con un completo tutorial paso a paso en como crear un Session bean y el Web Service (Pertenece al primer proyec to). Tenga en cuenta, que cuando defina el Web Service y pase a crear el cliente, este debe ser creado en el segundo proyecto, bajo el mismo procedimiento, indicándole el wsdl inicial creado en el primer proyecto. Paso5: Ahora se deben copiar los archivos necesarios en la carpeta llamada lib, para poder compilar los dos proyectos sin ningún inconveniente y poder continuar con el trabajo. Los archivos son: Primer workspace: jbossall-client.jar Segundo workspace: jbossall-client.jar cldcapi10.jar cldcapi11.jar midpapi10.jar midpapi20,jar servlet-api.jar soa p.jar http_client.jar Paso 7: Después de haber copiado los archivos anteriores, en el segundo proyecto se debe copiar y reconstruir el archivo buil d.xml, el cual se encarga a través de la herramienta de Ant que contiene el JDeveloper, de crear los.class y organizarlos en archivos.jar para que estos sean copiados en la ruta que allí se especifica. Este archivo se encuentra dentro de la carpeta del proyecto y debe ser colocado allí junto con un archivo build.properties en el que se especifican las carpetas que se desean utilizar. Se puede correr utilizando el comando build. 87

88 Paso 8: Ahora, corregido cualquier error que se halla podido presentar en el paso 7, se puede proceder a copiar los archivos del paquete aplicativo en un nuevo proyecto que se crea a partir de la herramienta J2ME Wireless Toolkit 2.1. Allí se debe copiar el archivo framework.jar, que se genera con el build.xml después de haber cambiado dentro del paquete mensaje las propiedades de las clases por las propiedades del cliente, ya que estas están apuntado a las propiedades del servidor. Finalmente las clases que se copian para que el cliente funcione correctamente son: aplicativo: cliente j2me RentaTools PantallaCategoria PantallaIngreso PantallaPendiente PantallaTiempo PantallaTools PantallaValor ProxyRentaTools RentaTools Temporizador framework: alertas FabricaAlertas IAlertas InicialRentaTools Informativa Error Advertencia mensajes FabricaMensajes (cambiar propiedades al cliente) IMensajes MensajeRentaTools cliente ITransporteHttpListener TransporteHttp propiedades Propiedades (las del paquete cliente) webservices cliente RentaToolsStub (cliente mensajes SOAP) Como se puede observar no existe ninguno de los paquetes que se crearon bajo el paquete del servidor del pri mer proyecto, ya que se esta trabajando con la parte del cliente. 88

89 El paquete de webservices.cliente se crea desde el segundo proyecto, utilizando la herramienta de JDeveloper que permite generarlo de la siguiente manera: Hacer clic en Archivo y luego seleccionar nuevo. Después de esto, selecciona del menú de opciones, la opción de Web Service y por ultimo selecciona la parte de stub/squeleton. Cuando pregunte por el archivo wsdl, debe ser seleccionado desde el primer proyecto. Una vez creada la clase RentaToolsStub, se procede a realizar algunos cambios sobre esta y es cambiar todos los paquetes que pertenecen a Oracle por las de org.apache, de lo contrario el proyecto no funcionará. Paso 9: Verificar que cuando se hizo el build del xml en el paso 7, haya ubicado el paquete con los archivos necesarios para el servidor en el tomcat del JWSDP 1.3 en la carpeta correspondiente para hacer el despliegue de estas, de lo contrario debe actualizar las variables de entorno para poder hacerlo o borrar este paso del build.xml y luego hacerlo manualmente, arrastrando y copiando. Paso 10: Por ultimo, iniciamos los procesos desde el servidor de la siguiente manera: Iniciar el JWSDP 1.3 desde el menú de inicio con la opción de Start Tomcat. Iniciar el OC4J con el run.exe que se encuentra dentro de la carpeta bin del jdeveloper. Correr el cliente desde la herramienta de J2ME Wireless Toolkit 2.1 Recuerde que existen unos settings de donde debe encontrar el servicio el cliente y que es definido utilizando la herram ienta de J2ME Wireless Toolkit 2.1. Igualmente en el servidor se cambio el pue rto del tomcat, para que este no entre en conflicto con el otro. Ahora el último paso es poner a correr el proyecto. Con la creación de los prototipos funcionales, se quiere validar el funcionamiento del framework, en el cual se está n cubriendo las utilidades que este ofrece y con las cuales el desarrollador puede manejar una buena práctica de desarrollo, uno de los objetivos de este proyecto. 89

90 9. CONCLUSIONES 9.1 PRIMERA CONCLUSIÓN Tal y como lo decía la definición del framework: es una micro-arquitectura que colabora en la solución de un problema común. Es precisamente lo que el framework de manejo de mensajes quiere brindar, al dar una solución de diseño y al establecer por medio de su arquitectura una opción de desarrollo que permita construir una aplicación con tecnología J2ME y haciendo uso de un Web Service sea mucho más liviana y flexible. Esto fue posible al implementar unas clases que se encargaban de resolver el servicio que es solicitado por el dispositivo móvil y que luego debe ser resuelto por un Web Service o un EJB. Al ver los dos prototipos funcionales funcionando, se puede ver la flexibilidad del framework al pasar de una arquitectura que trabaja con EJBs a otra que funciona con un Web Service. También, al hacer la transmisión de datos utilizado mensajes de tipo String y no de tipo SOAP desde el dispositivo móvil hasta el servidor, permite que el objeto transmitido sea mucho mas liviano, dejándole toda la carga pesada o mensaje SOAP para resolver dicho servicio al servidor, el cual cuenta con mayores recursos que los del dispositivo. 9.2 SEGUNDA CONCLUSIÓN El manejo de Web Services y la plataforma J2EE son tecnologías que se están imponiendo en el mercado actual. Los mensajes SOAP en los Web Services juegan un papel importante al ser esta una manera flexible y robusta de enviar mensajes, estableciendo un estándar de manejo de dicho mensaje a través de un archivo XML. Hoy en día, este XML es muy potente dentro de las aplicaciones que utilizan Web Services ya que permiten la comunicación entre diferentes plataformas. Aunque, en el manejo con los dispositivos móviles las cosas cambian, ya que es una tecnología que no esta totalmente desarrollada, 90

91 existen varias soluciones que permiten implementar el manejo de mensajes SOAP para los Web Services. Una de estas es el proyecto de Enhydra, el cual es de 42 kb. El framework de manejo de mensajes, gracias al uso de una clase que implementa dicho mensaje puede obtener un paquete de tan solo 13 kb a 15kb. Lo que permite que el desarrollador obtenga mayor espacio en el dispositivo y la carga de datos sea mucho mas liviana, al dejar que la lógica del negocio se encargué de manejar estos mensajes SOAP y al dispositivo solo llegue un mensaje de texto plano. Son estas, parte de las ventajas que se deben tomar en cuenta en el momento de desarrollar una aplicación de este tipo. 9.3 TERCERA CONCLUSIÓN Las tecnologías de J2ME y J2EE tienen un papel importante en la construcción de aplicaciones sobre las empresas de hoy en día, que buscan de una manera u otra resolver las necesidades de sus clientes. La gran mayoría de dispositivos móviles de ahora traen la Java Virtual Machine, sobre el cual corren las aplicaciones de J2ME. Para el desarrollo de los prototipos funcionales fue necesario establecer como se debía realizar la comunicación entre el cliente (cel ular) y el servidor utilizando las tecnologías de J2ME y J2EE de tal manera que se hiciera lo mas liviano posible y que dejara la carga pesada al servidor. Se encontró que aunque J2ME no se encuentra totalmente desarrollado, este brinda los recursos necesarios para realizar la comunicación con un servidor a nivel de bytes por lo que se implementó dentro del framework de mensajes una parte que bajara el men saje a mandar a bytes y luego fuera construido en el lado servidor por medio de un Servlet. En el lado servidor J2EE cuenta con una plataforma bastante buena, que se hace cargo de manejo de transacciones, manejo de mensajes a través del JMS, pasiva y activa los objetos y otros recursos mas que hacen de este un buen recurso en el manejo del servidor. 9.4 CUARTA CONCLUSIÓN La construcción del framework de manejo de mensajes, utilizando los patrones de software de diseño, permitieron que se desarrollará una arquitectura muy bien definida en donde a nivel físico se puede ver claramente como es la transmisión de mensajes y a nivel lógico el framework se hace cargo de forma transparente del manejo de los mensajes desde el lado cliente (celular) hasta llegar al lado servidor, el cual se hace cargo de resolver la lógica del negocio del aplicativo que se este trabajando. 9.5 QUINTA CONCLUSIÓN El crecimiento que esta teniendo la tecnología de hoy en día, esta impactando todas las empresas que quieren tener acceso al mercado sin ser aventajadas por otras que si lo tienen. La ventaja que brindan los dispositivos móviles, hacen que el manejo de algunos procesos dentro de estas entidades sea mucho mas rápido, amigable y confortable al momento de utilizarlo. Son muchas las aplicaciones que existen hoy en día y J2ME hace parte de estas. Aunque aun no se ha desarrollado totalmente esta tecnología, los programadores buscan soluciones para obtener un óptimo desarrollo en sus aplicaciones, llevándolos a encontrar soluciones como el framework que se ofrece en este proyecto, que provee una arquitectura liviana, flexible, robusta y fácil de mantener, gracias a los patrones de software que se emplearon. 91

92 9.6 SEXTA CONCLUSIÓN La experiencia que se adquiere con el desarrollo de aplicaciones, permiten que se encuentren patrones de programación. Gracias a experiencias anteriores, se han podido crear plataformas como la de J2ME y J2EE. Las cuales están envueltas en patrones de diseño que permiten que el programador pueda utilizarlas y a su vez obtener ventajas de flexibilidad, alta cohesión y bajo acoplamiento. Se utilizaron patrones de diseño en la construcción del Framework de manejo de mensajes, tal como se hizo en las arquitecturas de J2ME y J2EE, que son experiencias ya establecidas, con las que se creo una herramienta como el Framework que puede llegar a ser muy potente si el desarrollador así lo desea. 9.7 SEPTIMA CONCLUSIÓN Con base a toda la investigación que se ha realizado y durante el proceso de construcción del framework, se han construido dos prototipos funcionales haciendo uso de tecnologías como J2ME y WAP que van de la mano. J2ME no se puede comparar totalmente con la tecnología WAP, ya que este es un protocolo de acceso en el cual se baso para su construcción. Los dos prototipos funcionales hacen también uso del Tomcat por medio de la herramienta JWSDP, en la que se despliega parte del Framework. Uno utiliza otra herramienta llamada JBOSS para el despliegue de los EJBs y la otra utiliza el OC4J de oracle para el despliegue de los mismos y adicionalmente del Web Service. La utilización de varias tecnologías, permite que el Framework sea flexible y de fácil mantenimiento gracias a la utilización de patrones de diseño. Es esto lo que reflejan los dos prototipos funcionales que se han construido para que el lector, obtenga una mejor idea de cómo todo esto es posible con el uso del Framework. 9.8 OCTAVA CONCLUSIÓN Las utilidades que brinda el framework de manejo de mensajes, permiten que el desarrollador pueda realizar una tarea específica fácilmente. Además, se observó que tiene la oportunidad de poder extenderlo, con solo modificar la implementación o si lo prefiere ampliándola, tal como se logró en los prototipos funcionales que validaron el framework, al generar nuevas alertas, generar nuevos mensajes, etc. Al ser flexible en este aspecto, existe la posibilidad de crear nuevos componentes y brindar nuevas ideas a futuro que permitan extender sus utilidades y darle un valor agregado al proyecto haciendo uso de buenas prácticas de programación con los resultados obtenidos en la investigación. 9.9 NOVENA CONCLUSIÓN En las pruebas realizadas al framework de manejo de mensajes, se comprobó que efectivamente al tener una carga más liviana sobre el dispositivo los procesos permanecieron estables en el lado cliente. En el lado servidor se incremento la carga, al adjudicar la responsabilidad o lógica del negocio que requería un mayor proceso. Al haber separado las responsabilidades, se obtuvieron los resultados esperados, por medio de los prototipos funcionales que se crearon para validar el framework de manejo de mensajes. 92

93 10. GLOSARIO DE SIGLAS UDDI: Universal Description, Discovery and Integration. Es un catalogo en donde el proveedor registra su servicio. WSDL: Web Services Description Language. Es el documento en donde el proveedor describe su Web Service o servicio web. SOAP: Simple Object Access Protocol. Es el protocolo en el que viajan los mensajes a través de la red. XML: Extreme Markup Language. Es un lenguaje sobre el que se describen los servicios y las referencias de los tipos de datos. WAP: Wireless Access Protocol. Protocolo utilizado para la comunicación entre un dispositivo móvil y un servidor WAP, que se encarga de convertir los datos WAP en http. J2ME: Java 2 Micro Edtion. Tecnología java utilizada para el desarrollo de aplicaciones en dispositivos moviles que tengan java. J2EE: Java 2 Enterprise Edition. Tecnología java utilizada para el desarrollo de aplicaciones a gran escala, como grandes compañías. JNDI: Java Naming and Directory Interface. Es un estándar de acceso a los diferentes tipos de directorios de servicios y nombrado. JWSDP: Java Web Service Developer Pack. Herramienta que cuenta con el Tomcat para el levantamiento de aplicaciones Web sobre este servidor. JDBC: Java Database Connectivity. Es un estándar que permite la conexión con bases de datos a través de pooling, transacciones distribuidas, etc. JMS: Java Message Service. Provee el servicio de cola de mensajes, suscribiendo o publicando mensajes para servicios orientados a dispositivos mediadores. DAO: Data Access Object. Es un patrón de diseño que permite el acceso a un objeto de una forma más flexible y sencilla. DTO: Data Transfer Object. Es un patrón de diseño que implementa una manera sencilla de transportar objetos de un tipo específico de un lugar a otro. 93

94 EJB: Enterprise Java Beans. Especifica un marco de trabajo para aplicaciones distribuidas, al proveer una definición estandar de definir componentes en el lado servidor. HTTP: Hypertext Transfer Protocol. Es el protocolo de transferencia de texto que permite leer e interpretar archivos remotos a traves de la World Wide Web (www). HTML: Hypertext Markup Language. Es un formato estándar de documentos de texto que se utiliza para mostrar información a través de la World Wide Web (www). JSP: Java Server Pages. Son páginas de Java que mejoran aplicaciones Web, sobre la plataforma de J2EE. 94

95 11. BIBLIOGRAFIA LIBROS 1. Guía Práctica para Usuarios J2ME. Alonso Álvarez García, José Ángel Morales Grela. Ediciones Anaya Multimedia. España Professinal Java Server Programming J2EE Edition. Subrahmayan Allamaraju, Avedal, Browett, otros. Wrox Press Ltd.Birmingham-UK Core J2EE patterns: best practices and design strategies Alur, Deepak.Upper Saddle River, New Jersey: Prentice Hall PTR, c Design patterns: elements of reusable object - oriented software Gamma, Erich. Reading, Massachusetts: Addison-Wesley, Building Web services with Java: making sense of XML, SOAP, WSDL, and UDDI. Graham, Steve Simeonov, Simeon Boubez, Toufic. Indianapolis, Indiana: Sams, c Java, XML, and Web services bible. Jasnowski, Mike. New York: Hungry Minds, c Professional WAP. Arehart, Charles. Chicago, Illinois ; Birmingham : Wrox, J2ME Java 2 Micro Edition Manual de usuario y Tutorial. Quintas Agustín. Cárdenes Patricia. Alfaomega. México INTERNET 9. Web Services APIs for J2ME. Julio 20, Low Bandwidth SOAP. Agosto 19,

96 11. Wireless Web Services with J2ME Wireless Web Services with J2ME partii Java Web Services Developer Pack (Java WSDP). Febrero de J2ME Wireless Toolkit 2.1 Download. Febrero de Professional Open Source from JBoss Inc. Febrero de Accessing Web Services from Your Cell Phone Febrero de Business Process Standards for Web Services Marzo de Web services and business process management Marzo de Securing web services. Marzo de The Problem with J2EE. Marzo de Developing Asynchronous Web Services with CapeConnect and JMS Marzo de Deploying Web Services on JavaTM 2, Enterprise Edition (J2EETM) WebServices/wsj2ee/ Marzo de More Wireless J2ME Articles. Marzo de The Generic Connection Framework Marzo de Designing and Writing Java Action Games for Small Devices Marzo de Java One. Febrero de Using Wireless Application Protocol (WAP) with WebLogic Server Marzo de Introduction to the Wireless Application Protocol Febrero de The J2ME framework for wireless Aplications. Febrero de SOAP Version 1.2 Part 1: Messaging Framework. de soap12-part / Febrero 31. The Simple Messaging Framework Febrero de

97 12. ANEXOS ANEXO A: DIAGRAMAS DE CLASE DEL FRAMEWORK ANEXO B: DESCRIPCION CASOS DE USO ANEXO C: DIAGRAMAS DE CLASE DE LOS PROTOTIPOS FUNCIONALES ANEXO D: CASOS DE PRUEBA DE LOS PROTOTIPOS FUNCIONALES ANEXO E: DIAGRAMAS DE COLABORACION ANEXO F: INSTRUCCIONES DE USO DEL FRAMEWORK ANEXO G: PRUEBAS DE CARGA Y ESTRÉS. 97

98 ANEXO A DIAGRAMAS DE CLASE DEL FRAMEWORK Alertas 98

99 DAO 99

100 Mensajes (Cliente) Mensajes (Servidor) 100

101 Poolconexiones 101

102 Propiedades P (Cliente) Propiedades (Servidor) 102

103 ANEXO B CASOS DE USO PROTOTIPO FUNCIONAL TRIQUI Caso de Uso Consultar Jugadores Actor Jugador. Descripción El actor toma la opción de consultar los Jugadores que se encuentran actualmente en el sistema. Flujo de Eventos Flujo Básico: 1.1 El sistema despliega una lista con las opciones iniciales del Juego. 1.2 El sistema solicita le sea ingresado la opción de Consultar los Jugadores. 1.3 El actor selecciona y acepta la opción de Consultar los Jugadores. 1.4 El sistema verifica la opción y despliega la lista de los Jugadores que se encuentran actualmente en el sistema. Flujo Alterno: Si en el paso 1.4 el actor no selecciona ninguna opción, el sistema informa del error y retorna al paso 1.1. Precondiciones El sistema posee una lista de registro de los Jugadores. Poscondiciones El sistema despliega una lista con los jugadores que se encuentran actualmente en la base de datos. Puntos de Extensión No Aplica. Caso de Uso Consultar Puntaje Actor Jugador. Descripción El actor toma la opción de consultar el Puntaje actual que este posee en el sistema. Flujo de Eventos Flujo Básico: 1.1 El sistema despliega una lista con las opciones iniciales del Juego. 1.2 El sistema solicita le sea ingresado la opción de Consultar su Puntaje. 1.3 El actor selecciona y acepta la opción de Consultar su Puntaje. 1.4 El sistema verifica la opción y despliega el ingreso del Jugador. 1.5 El sistema solicita le sea ingresado el nombre del Jugador. 1.6 El actor ingresa el nombre del Jugador y acepta. 1.7 El sistema verifica el ingreso del nombre del Jugador y despliega el puntaje corresponde al Jugador. actual que 103

104 Flujo Alterno: Si en el paso 1.4 el actor no selecciona ninguna opción, el sistema informa del error y retorna al paso 1.1. Si en el paso 1.7 el actor no ingresa ningún dato, el sistema informa del error y retorna al paso 1.4. Precondiciones El sistema posee una lista de Registro de los puntajes de los Jugadores. Poscondiciones El sistema despliega el puntaje correspondiente al Jugador. Puntos de Extensión En el paso 1.4 pasa al caso de uso Ingresar Jugador. Caso de Uso Ingresar Jugador: Actor Jugador. Descripción El actor ingresa el nombre del Jugador con el cual se va ha identificar en el Juego. Viene de los casos de uso Iniciar Juego y Consultar Puntaje. Flujo de Eventos Flujo Básico: 1.1 El sistema despliega una casilla para ingresar el nombre del Jugador. 1.2 El sistema solicita le sea ingresado el nombre del Jugador. 1.3 El actor ingresa el nombre correspondiente al Jugador y acepta. 1.4 El sistema verifica el ingreso del nombre y despliega la siguiente opción. Flujo Alterno: Si en el paso 1.4 el actor no ingresa ningún dato, el sistema informa del error y retorna al paso 1.1. Precondiciones El sistema tiene un registro de Jugadores. Poscondiciones El sistema verifica si existe el jugador y lo consulta. De lo contrario lo agrega a la base de datos del sistema como un nuevo jugador. Puntos de Extensión No Aplica Caso de Uso Iniciar Juego Actor Jugador. Descripción El actor toma la opción de iniciar un nuevo Juego para el cual debe estar inscrito. 104

105 Fluj o de Eventos Flujo Básico: 1.1 El sistema despliega una lista con las opciones iniciales del Juego. 1.2 El sistema solicita le sea ingresado la opción de Iniciar Juego. 1.3 El actor selecciona y acepta la opción de Iniciar Juego. 1.4 El sistema verifica la opción y despliega el ingreso del Jugador. 1.5 El sistema solicita le sea ingresado el nombre del Jugador. 1.6 El actor ingresa el nombre del Jugador y acepta. 1.7 El sistema verifica el ingreso del Jugador y despliega las opciones de la letra de Juego (X/O). 1.8 El sistema solicita le sea ingresada una opción de letra de Juego. 1.9 El actor ingresa una opción de letra de Juego El sistema verifica la opción de letra de Juego y despliega el Juego. Flujo Alterno: Si en el paso 1.4 el actor no selecciona ninguna opción, el sistema informa del error y retorna al paso 1.1. Si en el paso 1.7 el actor no ingresa ningún dato, el sistema informa del error y retorna al paso Si en el paso 1.10 el actor no selecciona ninguna opción, el sistema informa del error y retorna al paso 1.7. Precondiciones El sistema posee un registro de los Jugadores. Poscondiciones El sistema inicia un Nuevo Juego para el Jugador Actual. Puntos de Extensión En el paso 1.4 pasa al caso de uso Seleccionar Letra. Caso de Uso Hacer Movimiento Jugador Actor Jugador. Descripción El actor asigna un lugar dentro del Juego a la letra correspondiente, para realizar su respectivo movimiento. Flujo de Eventos Flujo Básico: 1.1 El sistema despliega la pantalla de Juego con los movimientos realizados. 1.2 El sistema solicita le sea ingresada la casilla en donde desea ubicar la letra correspondiente al Jugador. 1.3 El actor ingresa y acepta la ubicación de la casilla en donde desea hacer su movimiento. 1.4 El sistema verifica el ingreso del movimiento del Jugador. 1.5 El sistema realiza su movimiento aleatoriamente sobre las posiciones restantes. 1.6 El sistema despliega el Juego nuevamente con los Movimientos hechos. Flujo Alterno: Si en el paso 1.4 el actor ubica su movimiento sobre uno ya realizado, el sistema informa del error y retorna al paso 1.1. Si en el paso 1.4 el sistema encuentra un ganador, despliega un mensaje de que existe un ganador. 105

106 Precondiciones El sistema tiene un registro de Jugadores. El sistema mantiene el estado del Juego. Poscondiciones El sistema verifica el movimiento realizado por el Jugador y lo realiza. Al mismo tiempo realiza el movimiento del Sistema. Puntos de Extensión No Aplica Cass o d e Uso Hacer Movimiento CPU Actor Sistema. Descripción El actor asigna un lugar dentro del Juego a la letra correspondiente, para realizar su respectivo movimiento. Flujo de Eventos Flujo Básico: 1.1 El sistema despliega la pantalla de Juego con los movimientos realizados. 1.2 El sistema realiza su movimiento aleatoriamente sobre las posiciones restantes. 1.3 El sistema despliega el Juego nuevamente con los Movimientos hechos. Flujo Alterno: Si en el paso 1.3 el sistema encuentra un ganador, despliega un mensaje de que existe un ganador. Precondiciones El sistema tiene un registro de Jugadores. El sistema mantiene el estado del Juego. Poscondiciones El sistema verifica su movimiento realizado y lo realiza. Puntos de Extensión No Aplica Caso de Uso Seleccionar Letra Actor Jugador. Descripción El a ctor se asigna una letra (X/O) con la cual va ha jugar durante el Juego. Flujo de Eventos Flujo Básico: 1.1 El sistema despliega las opciones de la letra de Juego (X/O). 1.2 El sistema solicita le sea ingresada una opción de letra de Juego y acepta. 106

107 1.3 El actor ingresa una opción de letra de Juego. 1.4 El sistema verifica la opción de letra de Juego y despliega el Juego. Flujo Alterno: Si en el paso 1.4 el actor no selecciona ninguna opción, el sistema informa del error y retorna al paso 1.1. Precondiciones El sistema posee un registro de las letras. Poscondiciones El sistema le asigna una letra al Jugador Actual. Puntos de Extensión No Aplica. CASO S DE USO PROTOTIPO FUNCIONAL RENTATOOLS Caso de Uso Activar Reserva Actor Cliente. Descripción Permite que un usuario active una reserva que se encuentra en estado pendiente y la pase a un estado reservado en el que la reserva queda activa. Flujo de Eventos Flujo B ásico: 1.1 El sistema solicita le sea ingresado el numero de la reserva. 1.2 El actor digita el numero de la reserva y acepta. 1.3 El sistema verifica el ingreso de la reserva. Flujo Alterno: Si en el paso 1.3, no se digita ningún dato, el sistema despliega un mensaje de error y retorna al paso 1.1. En el paso 1.3 si la reserva no está registrada en el sistema, este despliega un mensaje de error y retorna al paso 1.1. Precondiciones El sistema tiene el registro de las reservas actuales en el sistema. Poscondiciones El sistema cambia el estado de la reserva de pendiente a activa. Puntos de Extensión No aplica. Caso de Uso Autenticar Cliente Actor Cliente. 107

108 Descripción Permite validar a un usuario a partir de la verificación de su palabra clave Flujo de Eventos Flujo Básico: 1.1 El sistema solicita le sea ingresado el usuario y la palabra clave. 1.2 El actor digita el usuario, la palabra clave y acepta. 1.3 El sistema verifica el ingreso del usuario y la palabra clave. Flujo Alterno: Si en el paso 1.3, no se digita ningún usuario y/o password, el sistema despliega un mensaje de error y retorna al paso 1.1. En el paso 1.3 si el usuario no está registrado en el sistema o la palabra clave no corresponde a la del usuario el sistema despliega un mensaje de error y retorna al paso 1.1. Precondiciones El sistema tiene el registro de los usuarios y passwords de cada uno. Poscondiciones El sistema valida el usuario y su palabra clave. Puntos de Extensión En el paso 1.3, se pasa al caso de uso Consultar Categorías. Caso de Uso Cancelar Reserva Actor Cliente. Descripción Permite que un usuario desactive una reserva que se anulo o que ya ofreció su servicio y se encuentra en estado activo y la pasa a un estado inactivo de la reserva. Flujo de Eventos Flujo Básico: 1.1 El sistema solicita le sea ingresado el numero de la reserva. 1.2 El actor digita el numero de la reserva y acepta. 1.3 El sistema verifica el ingreso de la reserva. Flujo Alterno: Si en el paso 1.3, no se digita ningún dato, el sistema despliega un mensaje de error y retorna al paso 1.1. En el paso 1.3 si la reserva no está registrada en el sistema, este despliega un mensaje de error y retorna al paso 1.1. Precondiciones El sistema tiene el registro de las reservas actuales en el sistema. Poscondiciones El sistema cambia el estado de la reserva de activa a inactiva. Puntos de Extensión No aplica. 108

109 Caso de Uso Consultar Categorías Actor Cliente. Descripción Permite consultar las categorías que existen al clasificar sus productos dentro del almacén. Viene del caso de u so Autenticar Cliente. Flujo de Eventos Flujo Básico: 1.1 El sistema solicita le sea ingresado el usuario y la palabra clave. 1.2 El actor digita el usuario, la palabra clave y acepta. 1.3 El sistema verifica el ingreso del usuario y la palabra clave. 1.4 El sistema despliega una lista los nombres de las categorías disponibles. 1.5 El sistema solicita le sea ingresada una opción. 1.6 El actor selecciona una opción y acepta. 1.7 El sistema despliega una lista con los nombres de los productos correspondientes a una categoría. Flujo Alterno: Si en el paso 1.3, no se digita ningún usuario y/o password, el sistema despliega un mensaje de error y retorna al paso 1.1. En el paso 1.3 si el usuario no está registrado en el sistema o la palabra clave no corresponde a la del usuario el sistema despliega un mensaje de error y retorna al paso 1.1. Si en el paso 1.7, no se selecciona una categoría, el sistema despliega un mensaje de error y retorna al paso 1.5. Precondiciones El sistema tiene el registro de los usuarios y passwords de cada uno. El sistema tiene el registro de las categorías y productos disponibles. Poscondiciones El sistema lista los nombres correspondientes a cada una de las categorías disponibles. Puntos de Extensión En el paso 1.7, se pasa al caso de uso Consultar Productos por Categoría. Caso dee Uso Consultar Productos por Categoría Actor Cliente. Descripción Permite consultar los productos correspondientes a una categoría que existe dentro del almacén. Flujo de Eventos Flujo Básico: 1.1 El sistema solicita le sea ingresada una categoría. 1.2 El actor ingresa una categoría y acepta. 1.3 El sistema verifica el ingreso de la categoría. 1.4 El sistema despliega una lista los nombres de los Productos disponibles. 109

110 Flujo Alterno: Si en el paso 1.3, no se ingresa una categoría, el sistema despliega un mensaje de error y retorna al paso 1.1. Precondiciones El sistema tiene el registro de los Productos disponibles para cada Categoría. Poscondiciones El sistema lista los nombres correspondientes a cada una de los Productos correspondientes a una categoría. Puntos de Extensión No Aplica Caso de Uso Consultar Reservas Actor Cliente. Descripción Permite consultar las reservas que se encuentran actualmente en el sistema. Flujo de Eventos Flujo Básico: 1.1 El sistema solicita le sea ingresado el usuario y la palabra clave. 1.2 El actor digita el usuario, la palabra clave y acepta. 1.3 El sistema verifica el ingreso del usuario y la palabra clave. 1.4 El sistema despliega una lista con el número de reserva, código del cliente, nombre del producto, estado de la reserva, la fecha y el número de días de alquiler. Flujo Alterno: Si en el paso 1.3, no se digita ningún usuario y/o password, el sistema despliega un mensaje de error y retorna al paso 1.1. En el paso 1.3 si el usuario no está registrado en el sistema o la palabra clave no corresponde a la del usuario el sistema despliega un mensaje de error y retorna al paso 1.1. Precondiciones El sistema tiene el registro de las Reservas que se han registrado. Poscondiciones El sistema lista las reservas con lista con el número de reserva, código del cliente, nombre del producto, estado de la reserva, la fecha y el número de días de alquiler. Puntos de Extensión No Aplica Caso de Uso Consultar Valor Actor Cliente. 110

111 Descripción Permite consultar el valor correspondiente al alquiler de uno de los productos. Flujo de Eventos Flujo Básico: 1.1 El sistema solicita le sea ingresado el número de días y la fecha. 1.2 El actor digita el numero de días, la fecha y acepta. 1.3 El sistema verifica el ingreso del número de días y la fecha. 1.4 El sistema despliega el valor a pagar por la reserva. Flujo Alterno: Si en el paso 1.4, el actor no ingresa el número de días, el sistema despliega un mensaje de error y retorna al paso 1.1. Si en el paso 1.4, el actor no ingresa la fecha correctamente, el sistema despliega un mensaje de error y retorna al paso 1.1. Precondiciones El sistema tiene el registro de las Reservas que se han registrado. El sistema tiene el registro de valores de alquiler de cada producto. Poscondiciones El sistema despliega el valor a pagar por la reserva que se desea realizar. Puntos de Extensión En el paso 1.4, puede tomar la decisión de pasar caso de uso Realizar Reserva. En el paso 1.4, puede tomar la decisión de pasar caso de uso Poner Reserva Pendiente. Caso de Uso Poner Reserva Pendiente: Actor Cliente. Descripción Permite poner la reserva actual en un estado de Pendiente para cuando no se encuentra disponible el producto. Viene del caso de uso Consultar Valor. Flujo de Eventos Flujo Básico: 1.1 El sistema solicita le sea ingresado el número de días y la fecha. 1.2 El actor digita el numero de días, la fecha y acepta. 1.3 El sistema verifica el ingreso del número de días y la fecha. 1.4 El sistema despliega el valor a pagar por la reserva. 1.5 El sistema solicita le sea si desea poner la reserva en espera. 1.6 El actor ingresa la opción de poner la reserva en espera. 1.7 El sistema despliega el número de reserva y retorna al caso de uso Consultar Categorías. Flujo Alterno: Si en el paso 1.4, el actor no ingresa el número de días, el sistema despliega un mensaje de error y retorna al paso 1.1. Si en el paso 1.4, el actor no ingresa la fecha correctamente, el sistema despliega un mensaje de error y retorna al paso 1.1. Si en el paso 1.7, el actor no toma una opción, el sistema despliega un mensaje de error retorna al paso

112 Precondiciones El sistema tiene el registro de las Reservas que se han registrado. El sistema tiene el registro de valores de alquiler de cada producto. Poscondiciones El sistema pone la reserva actual en un estado de Pendiente. Puntos de Extensión No Aplica Caso dee Uso Realizar Reserva: Actor Cliente. Descripción Permite realizar la reserva actual para uno de los productos. Viene del Valor. caso de uso Consultar Flujo de Eventos Flujo Básico: 1.1 El sistema solicita le sea ingresado el número de días y la fecha. 1.2 El actor digita el numero de días, la fecha y acepta. 1.3 El sistema verifica el ingreso del número de días y la fecha. 1.4 El sistema despliega el valor a pagar por la reserva. 1.5 El sistema solicita le sea si desea realizar la reserva. 1.6 El actor ingresa la opción de realizar la reserva. 1.7 El sistema despliega el número de reserva. Flujo Alterno: Si en el paso 1.4, el actor no ingresa el número de días, el sistema despliega un mensaje de error y retorna al paso 1.1. Si en el paso 1.4, el actor no ingresa la fecha correctamente, el sistema despliega un mensaje de error y retorna al paso 1.1. Si en el paso 1.7, la reserva no se encuentra disponible, el sistema despliega un mensaje de error y retorna al paso 1.5. Precondiciones El sistema tiene el registro de las Reservas que se han registrado. El sistema tiene el registro de valores de alquiler de cada producto. Poscondiciones El sistema realiza la reserva actual. Puntos de Extensión No Aplica 112

113 ANEXO C DIAGRAMAS DE CLASE TRIQUI A continuació n se presentara el diagrama de clases para el prototipo funcional Triqui, dividido en dos partes: Primero del lado cliente y luego el lado servidor. 113

114 114

115 DIAGRAMAS D DE CLASE RENTATOOLS A continuación se presentara el diagrama de clases para el prototipo funcional RentaTools, dividido en dos partes: Primero del lado cliente y luego el lado servidor. 115

116 116

117 ANEXO D CASOS DE PRUEBA PROTOTIPO FUNCIONAL TRIQUI Especificación de Casos de Prueba del usuario: 1. Caso de Prueba de Consultar Jugadores Historial de Revisiones Fecha Versión Descripción Autor 11/09/ Versión preliminar de Navegación de Pantallas. John Neira 11/12/ Prueba del aplicativo. John Neira Comprobación: Fecha Descripción Validación Condiciones Entradas Resultados Esperados 11/09/2004 Comprobar que se ingresa Ninguna Ninguna El sistema despliega debidamente al aplicativo. la pantalla correctamente 11/09/2004 Comprobar que se ingresa Ninguna Ninguna El sistema despliega debidamente a consultar Jugadores. la pantalla 11/12/2004 Consultar los Jugadores que hay en el sistema. Existan jugadores registrados Ninguna correctamente El sistema despliega los jugadores registrados Evaluación No muestra nada. Pantalla en blanco. Funciona correctamente. Funciona correctamente. 2. Caso de Prueba de Consultar Puntaje Historial de Revisiones Fecha Versión Descripción Autor 11/09/ Versión preliminar de Navegación de Pantallas. John Neira 11/12/ Prueba del aplicativo. John Neira Comprobación: Fecha Descripción Validación Condiciones Entradas Resultados Esperados 11/09/2004 Comprobar que se ingresa Ninguna Ninguna El sistema despliega debidamente a consultar Puntaje. la pantalla correctamente 11/12/2004 Ingresa el nombre de un usuario Existen El nombre El sistema despliega registrado en el sistema usuarios de un el puntaje actual del registrados 11/12/2004 No ingresa nombre de un usuario. Existen usuarios registrados usuario Ninguna usuario. El sistema despliega el mensaje de error. Evaluación Funciona correctamente. Funciona correctamente. Funciona correctamente. 117

118 11/12/2004 Ingresa el nombre de un usuario no registrado en el sistema Existen usuarios registrados El nombre de un usuario El sistema despliega el mensaje de error. Funciona correctamente. 3. Caso de Prueba de Hacer Movimiento CPU Historial de Revisiones R Fecha Versión Descripción Autor 11/09/ Versión preliminar de Navegación de Pantallas. John Neira 11/12/ Prueba del aplicativo. John Neira Comprobación: Fecha Descripción Validación Condiciones Entradas Resultados Esperados Evaluación 11/09/2004 Comprobar que se pasa Ninguna Ninguna El sistema despliega Funciona debidamente el movimiento de la la pantalla correctamente. CPU. correctamente 11/12/2004 Se le asigna una jugada al Exista un Letra y lugar El sistema despliega Funciona computador para que este realice su movimiento. juego. a realizar movimiento la pantalla con la jugada realizada Correctamente 4. Caso de Prueba de Hacer Movimiento Jugador Historial de Revisiones Fecha Versión Descripción Autor 11/09/ Versión preliminar de Navegación de Pantallas. John Neira 11/12/ Prueba del aplicativo. John Neira Comprobación: Fecha Descripción Validación Condiciones Entradas Resultados Esperados 11/09/2004 Comprobar que se hace debidamente Ninguna Ninguna El sistema despliega el movimiento del Jugador. la pantalla correctamente 11/12/2004 El jugador asigna una jugada para Exista un Letra y lugar El sistema despliega que este realice su movimiento. juego. a realizar la pantalla con la movimiento jugada realizada 11/12/2004 Se le asigna una jugada en un lugar Exista un Letra y lugar El sistema despliega ocupado por alguna letra. juego. a realizar un mensaje de error. movimiento Evaluación Funciona correctamente. Funciona Correctamente Funciona Correctamente 118

119 5. Caso de Prueba de Ingresar Jugador Historial de Revisiones Fecha Versión Descripción Autor 11/09/ Versión preliminar de Navegación de Pantallas. John Neira 11/12/ Prueba del aplicativo. John Neira Comprobación: Fecha Descripción Validación Condiciones Entradas Resultados Esperados Evaluación 11/09/2004 Comprobar que se ingresa Ninguna Ninguna El sistema despliega Funciona debidamente el Jugador. la pantalla correctamente. correctamente 11/12/2004 El jugador ingresa su nombre. Exista el Nombre del El sistema despliega Funciona jugador jugador la siguiente pantalla. correctamente. registrado 11/12/2004 El jugador no ingresa ningún dato. Exista el Ninguna El sistema despliega Funciona jugador un mensaje de error. correctamente. registrado 6. Caso de Prueba de Iniciar Juego Historial de Revisiones Fecha Versión Descripción Autor 11/09/ Versión preliminar de Navegación de Pantallas. John Neira 11/12/ Prueba del aplicativo. John Neira Comprobación: Fecha Descripción Validación Condiciones Entradas Resultados Esperados 11/09/2004 Comprobar que se ingresa Ninguna Ninguna El sistema despliega debid amente al inicio del Juego. la pantalla correctamente 11/12/2004 Se selecciona esta opción y se pasa a Ninguna Se toma la El sistema despliega la pantalla de ingresar nombre. opción Iniciar Juego la pantalla correctamente Evaluación Funciona correctamente. Funciona correctamente. 7. Caso de Prueba de Seleccionar Letra Historial de Revisiones Fecha Versión Descripción Autor 11/09/ Versión preliminar de Navegación de Pantallas. John Neira 11/12/ Prueba del aplicativo. John Neira 119

120 Comprobación: Fecha Descrip ción Validación Condiciones Entradas 11/09/2004 Compro bar que se ingresa debidamente a la selección de la letra. Ninguna Ninguna 11/12/2004 Se selecciona una de las letras con Existen las X las que se inicia el juego letras X/ O 11/12/2004 Se selecciona una de las letras con las que se inicia el juego Existen las letras X/ O O Resultados Esperados El sistem a despliega la pantalla correctamente El sistema despliega la pantalla correctamente El sistema despliega la pantalla correctamente Evaluación Funciona correctamente. Funciona correctamente. Funciona correctamente. CASOS DE PRUEBA PROTOTIPO FUNCIONAL RENTATOOLS Especificación de Casos de Prueba del usuario: 1. Caso de Prueba de Activar Reserva Historial de Revisiones Fecha Versión Descripción Autor 11/18/ Versión preliminar de Navegación de Pantallas. John Neira 11/22/ Prueba del aplicativo. John Neira Comprobación: Fecha Descripción Validación Condiciones Entradas Resultados Esperados 11/18/2004 Comprobar que se ingresa Ninguna Ninguna El sistema despliega debidamente a activar Reserva. la pantalla correctamente 11/19/2004 Comprobar que se ingresa Ninguna Ninguna El sistema despliega debidamente a activar Reserva. la pantalla correctamente 11/22/2004 Se ingresa el numero de una reserva Reserva Numero El sistema despliega que esta en estado pendiente Pendiente Reserva 1 la pantalla correctamente 11/22/2004 No se ingresa un número de una Reserva Ninguna El sistema despliega reserva. Pendiente un mensaje de error 11/22/2004 Se ingresa el numero de una reserva Reserva Numero El sistema despliega no existente Pendiente Reserva 0 un mensaje de error Evaluación No Funciona c orrectamente. Faltan Graficas Funciona correctamente. Funciona correctamente. Funciona correctamente. Funciona correctamente. 120

121 2. Caso de Prueba de Autenticar Cliente Historial de Revisiones Fecha V ersión Descripción Autor 11/18/ Versión preliminar de Navegación de Pantallas. John Neira 11/22/ Prueba del aplicativo. John Neira Comprobación: Fecha Descripción Validación Condiciones Entradas Resultados Esperados 11/18/2004 Comprobar que se ingresa Ninguna Ninguna El sistema despliega debidamente a autenticar cliente. la pantalla correctamente 11/22/2004 Se ingresa un usuario y clave Usuarios Usuario y El sistema despliega validos. registrados clave la pantalla correctamente 11/22/2004 Se ingresa un usuario y clave NO Usuarios Usuario y El sistema despliega validos. registrados clave un mensaje de error 11/22/2004 No se ingresa ningún usuario, ni Usuarios Ninguno El sistema despliega clave. registrados un mensaje de error Evaluación Funciona correctamente. Funciona correctamente. Funciona correctamente. Funciona correctamente. 3. Caso de P rueba de Cancelar Reserva Historial de Revisiones Fecha Versión Descripción Autor 11/18/ Versión preliminar de Navegación de Pantallas. John Neira 11/22/ Prueba del aplicativo. John Neira Comprobación: Fecha Descripción Validación Condiciones Entradas Resultados Esperados 11/18/2004 Comprobar que se ingresa Ninguna Ninguna El sistema despliega debidamente a cancelar Reserva. la pantalla correctamente 11/19/2004 Comprobar que se ingresa debidamente a cancelar Reserva. Ninguna Ninguna El sistema despliega la pantalla correctamente Evaluación Funciona correctamente. Faltan Graficas Funciona correctamente. 11/22/2004 Se ingresa el numero de una reserva Reserva Numero El sistema despliega Funciona que esta en estado activo Activo Reserva 1 la pantalla correctamente correctamente. 11/22/2004 No se ingresa un número de una reserva. Reserva Activo Ninguna El sistema despliega un mensaje de error Funciona correctamente. 121

122 11/22/2004 Se ingresa el numero de una reserva no existente Reserva Activo Numero Reserva 0 El sistema despliega un mensaje de error Funciona correctamente. 4. Cas o de Prueba de Consultar Categoría Historial de Revisiones Fecha Versión Descripción Autor 11/18/ Versión preliminar de Navegación de Pantallas. John Neira 11/22/ Prueba del aplicativo. John Neira Comprobación: Fecha Descripción Validación Condiciones Entradas Resultados Esperados 11/18/2004 Comprobar que se ingresa Ninguna Ninguna El sistema despliega debidamente a consultar Categoría. la pantalla correctamente 11/22/2004 Se consultan las categorías Categorías Ninguna El sistema despliega disponibles. Registradas. una pantalla con las categorías. Evaluación Funciona correctamente. Funciona correctamente. 5. Caso de Prueba de Consultar Productos por Categoría Historial de Revisiones Fecha Versión Descripción Autor 11/18/ Versión preliminar de Navegación de Pantallas. John Neira 11/22/ Prueba del aplicativo. John Neira Comprobación: Fecha Descripción Validación Condiciones Entradas Resultados Esperados 11/18/2004 Comprobar que se ingresa Ninguna Ninguna El sistema despliega debidamente a consultar productos la pantalla por Categoría. correctamente 11/22/2004 Se consultan los productos Productos Ninguna El sistema despliega disponibles por categoría. Registrados. una pantalla con las productos. Evaluación Funciona correctamente. Funciona correctamente. Fecha 6. Caso de Prueba de Consultar Reservas Versión Historial de Revisiones Descripción Autor 11/18/ Versión preliminar de Navegación de Pantallas. John Neira 122

123 11/22/ Prueba del aplicativo. John Neira Comprobación: Fecha Descripción Validación Condiciones Entradas Resultados Esperados 11/18/2004 Comprobar que se ingresa Ninguna Ninguna El sistema despliega debidamente a consultar reservas. la pantalla correctamente 11/22/2004 Se consultan las reservas en el Hay reservas Ninguna El sistema despliega sist ema. registradas las reservas Evaluación Funciona correctamente. Funciona correctamente. 7. Caso de P Prueba de Consultar Valor Historial de Revisiones Fecha Versión Descripción Autor 11/18/ Versión preliminar de Navegación de Pantallas. John Neira 11/22/ Prueba del aplicativo. John Neira Comprobación: Fec ha Descripción Validación Condiciones Entradas Resultados Esperados 11/18/2004 Comprobar que se ingresa Ninguna Ninguna El sistema despliega deb idamente a consultar valor. la pantalla correctamente 11/22/2004 Se consulta el valor por la reserva de Hay reservas Producto y El sistem a despliega determinado producto que se y valores numero de el valor de la encuentra en el sistema. registrados días reserva. Evaluación Funciona correctamente. Funciona correctamente. 8. Caso de Prueba de Poner Reserva Pendiente Fecha V ersión Historiall de Revisiones Descripción Autor 11/18/ Versión preliminar de Navegación de Pantallas. John Neira 11/22/ Prueba del aplicativo. John Neira Comprobación: Fec ha Descripción Validación Condiciones Entradas 11/18/2004 Comprobar que se ingresa Ninguna Ninguna deb idamente a consultar productos por Categoría. Resultados Esperados El sistema despliega la pantalla correctamente Evaluación Funciona correctamente. 123

124 11/22/2004 Se pone una reserva en el estado pendiente. El producto no esta disponible Numero reserva, fecha, estado, cliente y n umero días. El sistem a despliega el numero de la reserva temporal Funciona correctamente. 9. Caso de Prueba de Realizar ar Reserv a Historial de Revisiones Fecha Versión Descripción Autor 11/18/ Versión preliminar de Navegación de Pantallas. John Neira 11/22/ Prueba del aplicativo. John Neira Comprobación: Fecha Descripción Validación Condiciones Entradas 11/18/2004 Comprobar que se ingresa debidamente a Realizar Reserva 11/22/2004 Se realiza una reserva y se pone en estado Activo. Resultados Esperados Ninguna Ninguna El sistema despliega la pantalla correctamente El producto esta disponible Numero reserva, fecha, estado, cliente y numero días. El sistema despliega el número de la reserva. Evaluación Funciona correctamente. Funciona correctamente. 124

125 ANEXO E DIAGRAMAS DE COLABORACION Alertas: Proceso de generación de una alerta. DAO: Proceso de generación de una nueva instancia de un DAO. 125

126 Mensaje: Proceso de generación de una nueva del mensaje. Localizador Servicios: proceso de localizar un servicio 126

127 Generador Servicios: proceso de creación de una nueva instancia del Generador Servicios. Pool Conexiones: Proceso de fabricar un pool de conexiones. 127

128 ANEXO F INSTRUCCIONES DE USO DEL FRAMEWORK Cada uno de los componentes que ofrece el framework de manejo de mensajes se encuentran dentro del proyecto base, anexo en una carpeta llamada codigo del CD, el cual fue creado desde el JDeveloper. Para abrirlo, únicamente debe guardar la carpeta proyecto base sobre su computador y luego desde el JDeveloper abrir el archivo ProyectoFinal.jws. Para ver como funciona cada uno de sus componentes, se hará a través de cada uno de los paquetes en que se dividió y puede ser visto expandiendo el Framework.jpr. Luego, seleccione el botón de Show Categories y expanda la carpeta sources y verá cada uno de los paquetes correspondientes al framework mencionados a continuación: 1 framework.alertas: Este paquete se encarga de generar las alertas sobre el dispositivo móvil que el desarrollador decida generar en tiempo de ejecución de la siguiente manera: //Generar una instacia de tipo IAlertas del tipo que se defina (informativo) Generador Alertas IAlertas inicial = FabricaAlertas.fabricar( INFORMATIVO ); //Pasarle el display (pantalla) con el que se esta trabajando inicial.pasarpantalla(pantalla); //Poner el mensaje a mostrar y el display siguiente al que se quiere ir después de la alerta inicial.mostraralerta(" MENSAJE ", siguiente); Puede generar tres tipos de alerta: Informativa, Advertencia y Error. Solo diciéndole a la fábrica que tipo de alerta desea obtener. El paquete contiene a nivel general los siguientes objetos y propósitos: 1.1 FabricaAlertas.java: Instancia el recurso o alerta que necesite mostrar. 1.2 IAlertas.java: Establece una Interface con los métodos necesarios para generar una alerta. 1.3 Informativa: Es la implementación de cada uno de los métodos de la interface IAlertas para generar una alerta de tipo Informativa. 1.4 Advertencia: Es la implementación de cada uno de los métodos de la interface IAlertas para generar una alerta de tipo Advertencia. 1.5 Error: Es la implementación de cada uno de los métodos de la interface IAlertas para generar una alerta de tipo Error. Si en un nuevo aplicativo como en el caso de RentaTools y Triqui desea generar otro tipo de alerta lo puede hacer, copiando la misma implementación que ya tenga alguno de las alertas ya hechas y cambiando esta, a lo que desea que muestre en pantalla. Adicional a esto en la clase FabricaAlertas debe adicionar la instancia que debe llamar para el nuevo recurso. Manteniendo siempre las alertas dentro de este paquete y siguiendo el mismo procedimiento anterior pero fabricándolo con el nombre del nuevo recurso. 128

129 2 framework.dao: Este paquete se encarga de generar una fabrica abstracta de DAOs de acuerdo al recurso que desee instanciar sobre el servidor. El desarrollador decide que fabrica llamar y que DAO utilizar y lo genera en tiempo de ejecución de la siguiente manera: //Generar una instacia de tipo AbstractFactoryDAO, en este caso de una BD Access. AbstractFactoryDAO fabrica = AbstractFactoryDAO.getInstanceAccess(); //Con la fábrica creo el tipo de DAO que desee generando una instancia de ITablaDAO. ITablaDAO dao = fabrica.nuevotabladao(); //Creo el objeto DTO o data transfer object que contiene los atributos a transferir TablaDTO dto = new TablaDTO( parametros ); //Con el dao llamo los métodos CRUD para tener acceso a la base de datos. Dao.insertar(dto); Persistencia via DAO El paquete principal es framework.dao, donde se encuentra la fábrica abstracta. Luego viene el paquete framework.dao.aplicativo, en donde se encuentran las interfaces y finalmente el paquete framework.dao.aplicativo.impl, en donde esta la implementación de las interfaces del paquete anterior y los DTOs. A nivel general se presentan los siguientes objetos y propósitos: 2.1 AbstractFactoryDAO.java: Instancia el recurso a una base de datos especifica, en este caso de MS Access. 2.2 AccessFactoryDAO.java: Instancia el recurso DAO con acceso a una base de datos MS Access que se necesite en tiempo de ejecución. 2.3 ITablaDAO: Establece la interface con los métodos necesarios para hacer el CRUD a la base de datos. 2.4 TablaAccessDAO: Es la implementación de cada uno de los métodos de la interface ITablaDAO para generar un acceso a la base de datos. 2.5 ObjetoDTO: Es un objeto que tiene los métodos sets y gets para de una tabla especifica. Si en un nuevo aplicativo como en el caso de RentaTools y Triqui desea generar nuevos DAOs, puede hacerlo copiando la misma implementación que ya se tiene y cambiando los nombres de Tabla por el de la Tabla especifica que se desea consultar. Adicional a esto en la clase AccessFactoryDAO debe adicionar las instancias nuevas para llamar el nuevo recurso. Manteniendo siempre cada objeto dentro de su paquete correspondiente y siguiendo el mismo procedimiento anterior pero fabricándolo con el nombre del nuevo recurso. 3 framework.mensajes: Este paquete se encarga de generar un mensaje con el servicio o petición que se hace desde el dispositivo móvil y que el desarrollador decida generar en tiempo de ejecución de la siguiente manera: //Generar una instacia de tipo IMensajes del tipo que se defina (RentaTools) IMensajes mensaje = (IMensajes)FabricaMensajes.fabricar( RentaTools ); //Pasa como parámetro un string con el nombre del servicio que requiere mensaje.setservicio( Servicio ); //Pasa como parámetro un string con el nombre del parámetro que necesite. //Si necesita más parámetros, llame el método de nuevo. mensaje.setparametro( Nombre_Parametro ); //Pasa como parámetro el tipo de respuesta en un string (string, int, void, etc.) mensaje.setrespuesta( String ); Componente Generador Servicios 129

130 //Generar una instancia de tipo TransporteHttp con la URL de conexión TransporteHttp envio = new TransporteHttp(url); //Pasarle como parámetros el mensaje y el listener que va a obtener la respuesta. envio.alistarmensaje(mensaje, listener); //Una vez llega al servidor en el servlet generar una instacia de IGeneradorServicios para el aplicativo IGeneradorServicios generador = FabricaGeneradorServicios.fabricar( aplicativo ); //Resolver el servicio y obtener la respuesta dándole un buffer que viene con el mensaje String rta = generador.resolverservicio(buffer); Generador Servicios //El generador resuelve el servicio llamando el EJB que necesite por su nombre FachadaHome home = (FachadaHome)JNDIServiceLocator.getRemoteObject( nombre, FachadaHome.class); //Se crea la instancia de creacion al EJB FachadaAplicativo aplicativo = home.create(); Localizador //Llama los métodos para tener acceso a un servicio con los parámetros correspondientes Servicios aplicativo.llamarservicio(parametros); El paquete principal es framework.mensajes, donde se encuentra la fábrica de mensajes. Luego viene el paquete framework.mensajes.cliente, donde esta la capa de transporte de los mensajes del cliente. Después, el paquete framework.mensajes.servidor, en donde se encuentra el servlet que recibe la petición y se la delega al generador de Servicios. Finalmente, esta el paquete framework.mensajes.servidor.j2ee en donde se encuentra el Loc alizador de servicios y el manejo de la cola de mensajes. A nivel general se presentan los paquetes anteriores en los siguientes objetos y propósitos: 3.1 FabricaMensajes.java: Instancia el recurso o mensaje que necesite. 3.2 IMensajes.java: Establece una Interface con los métodos necesarios para generar un mensaje. 3.3 Mensaje: Es la implementación de cada uno de los métodos de la interface IMensajes, para generar un mensaje de un aplicativo. 3.4 ITransporteHttpListener.java: Estable una interface con los métodos necesarios para devolver la respuesta de una petición al dispositivo móvil. 3.5 TransporteHttp.java: Es un Hilo que se encarga de enviar y recibir los mensajes al servidor para ser consumidos. 3.6 FabricaGeneradorServicios.java: Instancia el recurso o servicio que necesite para resolver una petición. 3.7 IGeneradorServicios.java: Establece una Interface con los métodos necesarios para resolver una petición. 3.8 GeneradorServiciosAplicativo: Es la implementación de cada uno de los métodos de la interface IGeneradorServicios, para resolver la petición de un aplicativo. 3.9 ProxyServlet.java: Este servlet se encarga de delegarle el requerimiento al Generador de Servicios para resolverlo y devolverlo Cola_Mensajes.java: Esta clase se encarga de administrar la cola de mensajes asíncrona, sobre la cual se pueden dejar los mensajes que llegan aquí. 130

131 3.11 JNDIServiceLocato.javar: Esta clase se encarga de localizar los EJBs y las colas de mensajes solo pasándole los nombres del recurso que se necesita. Una vez que se entienda el concepto de cada una de las clases anteriores, se podrá ver que el mensaje llega al Generador de Servicios y quien decide que lógica del negocio seguir es el desarrollador. Es decir si lo hace a través de un Web Service como lo es el caso del RentaTools o directamente a un EJB en el caso del Triqui. El desarrollador únicamente debe cambiar las implementaciones que necesite hacia su aplicativo, nombrándolas con el nombre del aplicativo y manteniendo siempre los objetos dentro del paquete correspondiente. 4 framework.poolconexiones: Este paquete se encarga de generar un pool de conexiones a una base de datos especifica que el desarrollador decida generar en tiempo de ejecución de la siguiente manera: //Generar una instacia de tipo IPoolConexiones con el nombre del pool. IPoolConexiones pool = FabricaPoolConexiones.fabricar( Nombre_PoolConexiones ); //Con el pool puede llamar ahora una conexión cada vez que la necesite. Connection con = pool.getconexion(); //Con este método devuelvo la conexión al pool de conexiones. pool.soltarconexion(con); Pool de Conexiones Al fabricar el pool de conexiones le doy el nombre del recurso que quiero obtener en tiempo de ejecución y luego utiliza los métodos para administrar las conexiones por ejemplo a una base de datos MS Access. El paquete contiene a nivel general los siguientes objetos y propósitos: 4.1 FabricaPoolConexiones.java: Instancia el recurso o pool de conexiones que necesite para el aplicativo. 4.2 IPoolConexioness.java: Establece una Interface con los métodos necesarios para generar un pool de conexiones. 4.3 PoolConexionesAccess: Es la implementación de cada uno de los métodos de la interfaceipoolconexiones para generar un pool de conexiones a la base de datos de MS Access en este caso. Si en un nuevo aplicativo como en el caso de RentaTools y Triqui desea generar otro tipo de pool de conexiones, como por ejemplo a oracle lo puede hacer, copiando la misma implementación que ya tiene el pool de conexiones actual y cambiandola para oracle, o a la base de datos que desee. Adicional a esto en la clase FabricaPoolConexiones debe adicionar la instancia que debe llamar para el nuevo recurso. Manteniendo siempre los pooles dentro de este paquete y siguiendo el mismo procedimiento anterior pero fabricándolo con el nombre del nuevo recurso. Para cada uti lidad que tiene el framework, existe la posibilidad de ampliarla, per el desarrollador quien debe hacerlo y implementarlo en el código aquí presente. Para ver lo que hace cada uno de los métodos de cada clase, se puede remitir al manual de referencia anexo en el CD. 131

132 ANEXO G PRUEBAS DE CARGA Y ESTRES Las pruebas que se realizaran sobre el framework pretenden ver el comportami ento en cuanto a rendimiento y manejo de tramas sobre el servidor y el cliente. Se utilizaran las herramientas de rendimiento y administrador de procesos de Windows, así como la herramienta de JMeter 31. Con esto se podrá demostrar que el framework de manejo de mensajes realmente aguanta la carga y soporta el estrés de los mensajes que fluyen desde el cliente hasta el servidor. A continuación se apreciara detalladamente cada una de las pruebas: 1. La primera prueba muestra la carga que se presenta en el servidor JBoss al subir los servicios de este sin hacer ningún deploy. Figura 1: Los resultados que muestra la figura 1, son que el nivel de carga sube sobre el procesador cuando el servicio sube, luego permanece constante durante el tiempo. 2. La segunda prueba es la del Servidor Web de JBoss, sin hacer ningún deploy al comienzo y luego después de un tiempo se hace deploy del archivo.jar que se generó para el prototipo funcional de Triqui. 31 Apache Jmeter. Software OpenSource del proyecto Apache para realización de Pruebas jakarta.apache.org/jmeter/

133 Figura 2: Los resultados que muestra la figura 2, son que el nivel de carga sube sobre el procesador cuando el servicio sube, luego permanece constante durante el tiempo. Después de hacer deploy del JAR el uso de memoria sube y permanece constante en el tiempo. 3. La tercera prueba es la del Servidor Web de JWSDP 1.3, sin hacer ningún deploy al comienzo y luego después de un tiempo se hace deploy del archivo.war que se genero para el prototipo funcional de Triqui. Figura 3: Los resultados que muestra la figura 3, son que el nivel de carga sube sobre el procesador cuando el servicio sube, luego permanece constante durante el tiempo. Después de hacer deploy el uso de memoria sube y permanece constante en el tiempo. 133

134 4. Ahora, se probara la carga del servidor al mandar varios hilos que simulan varios clientes atacando un servicio sobre el servidor. Aunque el Servidor de JBoss ya soporta el manejo de concurrencia en este caso lo estamos haciendo varios llamados. CONTROL DE CONCURRENCIA AL SERVIDOR Figura 4: Simulación (20 usuarios Simulados por Hilos) En la figura 4 el número de paquetes sobre la red aumenta (línea verde) y la desviación estándar disminuye a través del tiempo, demostrando que el nivel de probabilidad de que falle una trama es cada vez mas bajo. El número de muestras que se tomaron fue de 553 para este ejemplo y demostró que el servicio se mantuvo constante para 20 usuarios. 134

135 CONTROL DE CONCURRENCIA AL SERVIDOR Figura 5: Simulación (30 usuarios Simulados por Hilos) En la figura 5 el número de paquetes sobre la red aumentó, aun más (línea verde) y la desviación estándar disminuye a través del tiempo, demostrando que el nivel de probabilidad de que falle una trama es cada vez mas bajo. El número de muestras que se tomaron fue de 642 para este ejemplo y demostró que el servicio se mantuvo constante para 30 usuarios. CONTROL DE CONCURRENCIA AL SERVIDOR Figura 6: Simulación (50 usuarios Simulados por Hilos) 135

136 En la figura 6 el número de paquetes sobre la red aumentó, aun más (línea verde) y la desviación estándar disminuye a través del tiempo, demostrando que el nivel de probabilidad de que falle una trama subió un poco más, debido a la cantidad de paquetes enviados sobre la red. El número de muestras que se tomaron fue de 650 para este ejemplo y demostró que el servicio se mantuvo constante para 150 usuarios. CONTROL DE CONCURRENCIA AL SERVIDOR Figura 7: Simulación (150 usuarios Simulados por Hilos) En la figura 7 el número de paquetes sobre la red aumentó, aun más (línea verde) y la desviación estándar disminuye a través del tiempo, demostrando que el nivel de probabilidad de que falle una trama subió un poco más, debido a la cantidad de paquetes enviados sobre la red. El número de muestras que se tomaron fue de 784 para este ejemplo y demostró que el servicio se mantuvo constante para 150 usuarios. 136

137 CONTROL DE CONCURRENCIA AL SERVIDOR Figura 8: Simulación (200 usuarios Simulados por Hilos) En la figura 8 el número de paquetes sobre la red aumentó, aun más (línea verde) y la desviación estándar disminuye a través del tiempo, demostrando que el nivel de probabilidad de que falle una trama volvió a bajar con el tiempo. El número de muestras que se tomaron fue de 1142 para este ejemplo y demostró que el servicio se mantuvo constante para 200 usuarios. Con esto se ha probado que soporta una buena carga de usuarios, demostrando poder mantener un buen nivel de estrés a través del tiempo. 5. Ahora se procede a realizar un análisis de los datos adquiridos en cuanto al uso de memoria, haciendo un continuo llamado de servicios desde el cliente hacia el servidor. Figura 9: Carga de Memoria Del FRAMEWORK Consumo de Recursos Kb CARGA DE MEMORIA PRESENTADA POR EL FRAMEWORK CARGA CON SERVICIOS DEL FRAMEWORK y = 1074,1Ln(x) - 288, CARGA SIN SERVICIOS DEL FRAMEWORK TENDENCIA DE CRECIMIENTO Logarítmica (TENDENCIA DE CRECIMIENTO) 137

138 En la figura 9, con un total de 40 muestras las cuales fueron analizadas por medio de un paquete estadístico (spss), con un contaje de 8 cortes de tiempo cada uno de 600 ms (promedio en el cual sube el servidor en la máquina de pruebas), se comparó la diferencia existente entre el consumo de recursos de memoria del servidor sin el uso del framework y con el uso de servicios del framework, el cual determinó un crecimiento relativamente liviano. Para establecer el comportamiento de este proceso se empleo un análisis de tendencia logarítmico, debido a que la prueba se origino tanto a nivel de inicialización como de deployment de los servicios en 8 tiempos, considerando un crecimiento lineal de servicios montados sobre con la ayuda del framework. El proceso de cada prueba se elaboró de la siguiente forma: Se inicializó el servidor sin el montaje de servicios proveídos por el framework. Se tomaron la lista de tiempos con ayuda de la herramienta JMETER 32 (opensource del proyecto Apache), considerando la unidad de referencia un valor medible por la herramienta de 600 ms. Se estableció una tendencia de uso por cada contaje de tiempo en la muestra mediante promedios de carga según la unidad de tiempo establecida En general se obtuvieron datos de 40 repeticiones Nuevamente se realizó el anterior proceso, pero añadiendo el peso de los servicios prestados por el framework en la ejecución del servidor, en igual número de repeticiones Se realizó la diferencia entre cada contaje específico (recursos con FW - recursos sin FW) y se obtuvo una gráfica de tendencia logarítmica para describir el uso de recursos del framework, el cual es relativamente bajo. Esta función de uso se muestra a continuación: y = 1074,1Ln(x) - 288,53 Con este comportamiento se puede concluir que los servicios proveídos por el framework son livianos en cuanto a consumo de recursos de memoria, lo cual lo hace una buena alternativa para servidores con recursos limitados que quieran proveer servicios WAP. Con la ayuda de la herramienta JMeter de Jakarta, se van a efectuar las pruebas para el manejo del Framework de manejo de mensajes. Este se encarga de mirar la carga de paquetes transmitidos a los servidores sobre el protocolo http. La grafica que muestra, representa los datos actuales del ejemplo (Amarillo), el promedio de todos los ejemplos actuales (azul), la desviación estándar actual (red), y el numero de requerimientos por minuto(verde). 32 Apache Jmeter. Software OpenSource del proyecto Apache para realización de Pruebas jakarta.a pache.org/jmeter/

139 6. Ahora se procede a realizar las pruebas con el prototipo funcional de RentaTools, sobre el JWSDP 1.3 para el cual el rendimiento que se presentó fue el siguiente: Figura 10: Los resultados que muestra la figura 10, son que el nivel de carga sube sobre el procesador cuando el servicio sube, luego permanece constante durante el tiempo. Después de hacer deploy el uso de memoria sube y permanece constante en el tiempo. 7. La prueba del servidor de OC4J presento el siguiente rendimiento sobre la maquina: Figura 11: Los resultados que muestra la figura 11, son que el nivel de carga sube sobre el procesador cuando el servicio sube, luego permanece constante durante el tiempo. Después de hacer deploy el uso de memoria sube y permanece constante en el tiempo. 139

140 8. Ahora se procede a realizar las pruebas con el prototipo funcional de RentaTools, sobre el cual se miró el comportamiento de los paquetes de salida desde el cliente (J2ME) simulando 100 clientes (J2ME) por el puerto 9696, por el cual salen los datos hacia el servidor. Figura 12: Paquetes Enviados desde el Cliente (J2ME) En la figura 12, después de pasados 30 minutos y un continuo uso de servicios del framework desde el cliente, encontramos que es muy estable y cada vez que se hace un requerimiento es mínimo por lo que la línea de requerimientos por minuto se mantiene estable. El número de ejemplos que se tomaron como muestras de rastreo de paquetes, que se envían entre el cliente y el servidor, demostró que el manejo de paquetes es mínimo, al fluctuar un mínimo de milisegundos cada vez que se envía un mensaje hacia el servidor (amarillo). Finalmente la desviación fue de 31 lo que quiere decir que es mínima y se mantiene a través del tiempo llevándolo a soportar una buena concurrencia el llamado de servicios, lo que indica que mantiene un buen nivel de estrés para una prueba entre 6 clientes que enviaban peticiones continuamente al servidor. 9. Ahora se procede a realizar las pruebas con el prototipo funcional de RentaTools, sobre el cual se miró el comportamiento de los paquetes sobre el servidor por el puerto 8888, simulando 100 clientes que transmitían mensajes SOAP. 140

141 CONTROL DE CONCURRENCIA AL SERVIDOR Figura 13: Simulación (100 usuarios Simulados por Hilos) En la figura 13 el número de paquetes sobre la red aumentó (línea verde) y la desviación estándar disminuye a través del tiempo y se mantiene constante, demostrando que el nivel de probabilidad de que falle una trama es constante en el tiempo. El número de muestras que se tomaron fue de 1200 para este ejemplo y demostró que el servicio se mantuvo constante para 100 usuarios. 10. La última prueba se procede al realizar las pruebas con el prototipo funcional de RentaTools, sobre el cual se miró el comportamiento de los paquetes sobre el servidor de OC4J por el puerto 1099, simulando 100 clientes que llamaban el servicio de los EJBs. CONTROL DE CONCURRENCIA AL SERVIDOR Figura 14: Simulación (100 usuarios Simulados por Hilos) 141