Link-all para aplicaciones móviles

Transcripción

1 Link-all para aplicaciones móviles Alvaro Rivoir, Fabricio Alvarez, Dayvis Malfará Taller de Sistemas de Información 4 Instituto de Computación, Facultad de Ingeniería Universidad de la República Montevideo, Uruguay 2005 Resumen En el presente documento se describe la solución propuesta a un problema planteado en la asignatura Taller de Sistemas de Información 4, dictada en la Facultad de Ingeniería, Universidad de la República, Montevideo, Uruguay en el año Este trabajo consiste en exponer funcionalidades de la plataforma Link-all mediante Web Services, permitiendo su acceso y consulta a través de dispositivos móviles. La solución propuesta comprende una aplicación integrada a la plataforma que brinda servicios de consulta de productos ofrecidos por las comunidades Link-all y dos aplicaciones móviles desarrolladas en Java y.net que utilizan dichos servicios siendo capaces de operar tanto en forma conectada o desconectada de la plataforma. Palabras clave: Aplicaciones móviles, Link-all, J2ME,.NET, J2EE Introducción El Proyecto Link-ALL [1] provee de tecnologías de la información a diferentes actores de América Latina teniendo como objetivo integrar y fomentar la cooperación en los sectores de Agricultura, Eco-Agro Turismo y Cultura. El desarrollo del mismo se encuentra a cargo de varios socios entre los cuales se encuentra el Instituto de Computación, contando actualmente con una plataforma desarrollada principalmente sobre J2EE e interconectada mediante Web Services. Este trabajo tiene como principal objetivo el desarrollo de clientes inalámbricos que se valen de los servicios brindados por la plataforma Link-All y otorgan a los usuarios de las comunidades la posibilidad de trabajar utilizando aparatos móviles. Dichos clientes se implementarán sobre dos plataformas J2ME [3] y.net de forma de poder comparar las diferencias encontradas en el desarrollo, investigar sobre interoperabilidad y soporte de Link-all a tecnologías móviles. El desarrollo de dichas aplicaciones posibilitará a los usuarios poder consultar la información no sólo desde su PC de escritorio sino también fuera de su casa u oficina. Otro aspecto a tener en cuenta es que el uso de la tecnología móvil facilitará el acceso a los servicios de Link-all en zonas de difícil acceso.

2 Estado del arte Java 2 Micro Edition (J2ME) J2ME es la versión de la plataforma JAVA orientada a dispositivos móviles. Dadas las limitantes de estos dispositivos esta es una versión reducida de la plataforma java J2SE. La misma está pensada para trabajar sobre dispositivos con limitantes en lo que refiere a potencia de cálculo y memoria y que disponen de una comunicación de red. J2ME permite la portabilidad y compatibilidad característica de JAVA, lo que permite desarrollar una aplicación y ejecutarla en distintos tipos y marcas de dispositivos móviles con características distintas. Dada la gran cantidad de equipo y sus características dispares J2ME lo que hace es separar la plataforma en configuraciones y perfiles donde en la configuración está la implementación de la máquina virtual JAVA y las librerías comunes para el equipo. Las configuraciones generan la separación de los dispositivos en familias dadas por la configuración que soportan. Aquí se encuentran las posibles configuraciones CLDC y CDC para equipos celulares y PDA. La configuración CLDC para equipos con 16bit y menos de 2MB de RAM y la CDC para equipos con 32bits y más de 2MB de memoria RAM. Los perfiles trabajan sobre la configuración, generando grupos de dispositivos en las familias. Los perfiles son grupos más específicos de APIs, que adicionan funcionalidad a las provistas por la configuración. Para la configuración CLDC existen dos perfiles MIDP y MIDP 2.0. En el actual trabajo se utilizó la configuración CLDC 1.1 y el MIDP 2.0, este último porque entre las funcionalidades provistas se encuentran las APIs para manejo de comunicación a través de Web Services y procesamiento de XML..NET Compact Framework.NET Compact Framework es una versión reducida del.net framework de Microsoft. Este framework posibilita escribir programas en Visual Basic.NET o C# utilizando las mismas técnicas que para.net permitiendo escribir una aplicación de escritorio y luego reutilizar parte del código para escribir versiones para móviles, aunque se debe reescribir parte del mismo debido a las limitaciones en cuanto a memoria, base de datos y resolución de la pantalla. Los programas escritos pueden ser ejecutados en Pocket PC o Smartphones que ejecuten el.net Compact Framework, tales como los aparatos con sistema operativo Windows Mobile [7] 2002 o superior. NET Compact Framework provee soporte para XML y SOAP haciendo que el trabajo con Web Services sea tan sencillo como lo es con aplicaciones de escritorio (sólo agregar una Web Reference a la ubicación del WSDL del servicio). Web Services en Java, formatos y estilos Java API para RPC [8] basados en XML (JAX-RPC) es la API para desarrollar y usar servicios basados en SOAP y que se describen utilizando WSDL. JAX-RPC y su nombre están basados en el modelo RPC básico pero ofrece rasgos que van más allá de eso ya que es posible desarrollar Web Services a los que se les pasa documentos completos y fragmentos de documentos.

3 Los consumidores del servicio pueden interactuar con el servicio en dos patrones comunes: interacción basada en RPC e interacción basada en documentos. En la interacción basada en RPC el Web Service es visto por el consumidor como una sola aplicación lógica o componente con datos encapsulados, donde el WSDL descrito por la interfase expuesta públicamente y el XML en los mensajes SOAP intercambiados son formateados para mapearse a las operaciones discretas expuestas por la aplicación. Los mensajes se mapean directamente en los parámetros de entrada y salida de las llamadas a procedimientos u operaciones y típicamente tales invocaciones ocurren sobre un protocolo de transporte como es HTTP. En la interacción basada en documento, el consumidor del servicio interactúa con él utilizando documentos que serán procesados como entidades completas. Estos documentos típicamente toman la forma de XML que es definido por un esquema definido previamente en acuerdo mutuo entre proveedor del servicio y el consumidor. Un mensaje SOAP puede ser representado en estilo RPC o estilo documento. Cuando el atributo style del WSDL es rpc los elementos hijos en el cuerpo son interpretados por el servicio como la representación XML de una invocación a un método. Cuando el atributo es document el cuerpo del mensaje SOAP puede contener XML arbitrario y el servicio no sigue las reglas relacionadas a RPC. Codificación o encoding refiere a cómo los datos son serializados y enviados. Es especificado por el atributo use del WSDL y puede tomar el valor de encoded o literal. Las partes involucradas pueden acordar un esquema de encoding o usar un esquema XML directo para definir los tipos de datos. Combinando las opciones de binding style y data encoding tenemos cuatro opciones: RPC-encoded RPC-literal Document-Literal Document-Encoded Especificación del problema Sistema a Construir El sistema a construir esta basado en la exportación de operaciones sobre la plataforma Link-all en la forma de Web Services. Dichas operaciones van a ser consumidas desde clientes móviles, basados en las tecnologías J2ME o.net, quienes presentarán de forma simple y práctica la información al usuario, partiendo de las limitaciones que conlleva las restricciones de este tipo de dispositivos. El sistema permitirá que desde los móviles se pueda consultar la información sobre productos que Link-all disponga, se permitirá hacer búsquedas sobre los productos y obtener detalles de los mismos. Las aplicaciones móviles tendrán un modo de operación dual siendo capaces de operar tanto en modo offline como online.

4 En el modo online todos los pedidos de información y búsquedas son realizados al servicio de Link-all, almacenándose de forma persistente en el aparato inalámbrico los datos obtenidos para su posterior consulta cuando esté desconectado. En este modo el procesamiento estará a cargo del servidor pero tiene limitaciones como ser el consumo de ancho de banda, tiempo y fallas en la comunicación. En el modo offline el usuario podrá navegar los datos de los productos previamente obtenidos del servidor. La información descargada y persistida localmente podrá ser consultada sin necesidad de conectarse al servidor, este punto es de gran importancia dado que no siempre los dispositivos móviles tendrán una conexión habilitada hacia el mismo. Las operaciones deberán tener un mejor desempeño dado que se evitarán las demoras y fallas en la conexión. Operar en este modo implica abordar la problemática de las limitaciones en cuanto a procesamiento, memoria y cantidad de almacenamiento persistente que poseen los dispositivos móviles. A modo de simplificación los datos almacenados en el aparato son de sólo lectura, es decir que el usuario no podrá editarlos desde el móvil y como se mencionó anteriormente el modelo de dominio de las aplicaciones inalámbricas será reducido en comparación con el que maneja Linkall ya que sólo se trabajará con productos y servicios. Los usuarios que utilicen las aplicaciones desarrolladas en Java 2 Micro Edition serán capaces de compartir información utilizando servicios de mensajería. Es decir que un usuario operando de forma online y descargando información de la plataforma tendrá la posibilidad de compartirla a otro usuario enviándole la información por correo. Esta funcionalidad tiene la ventaja de que las aplicaciones no están ligadas a una única forma de comunicación ya que podrán recibir información a través de Web services y a través de mensajes. Requerimientos Funcionales 1. Autenticación El esquema de seguridad de la plataforma Link-ALL exige la autenticación de los usuarios para poder consultar los productos de las distintas comunidades. El cliente móvil por lo tanto deberá autenticarse para obtener la información a través de los Web Services. 2. Servicio de la plataforma Link-all para aplicaciones móviles Se deberá implementar un servicio de consulta de los productos de Link-all. Dicho servicio retornará los productos vía Web Services y para obtener la información utilizará los servicios de la plataforma, como por ejemplo el Federador de Datos y el componente encargado de administrar las Sesiones y la Seguridad. 1. Servicio de autenticación Este servicio permite realizar la autenticación del usuario frente a la plataforma Link-all. XmlResponse loginoperation(xmlrequest) El XML que recibe como parámetro especifica el usuario y contraseña para la autenticación. El XML de respuesta indica el resultado de la operación y el identificador de sesión en caso de que la autenticación sea exitosa.

5 2. Servicio de consulta de productos Este servicio permite realizar consultas sobre la información de los diferentes productos ofrecidos por las comunidades de Link-all. XmlResponse getproductlist(xmlrequest) Obtiene un listado de productos filtrados por un filtro y un sector. El resultado no puede exceder la cantidad de productos máxima indicada y será un xml con productos, donde cada producto será un par (id, name). XmlResponse getproduct(xmlrequest) Obtiene la información detallada de un producto en particular, el resultado es un XML con la información de este. El XML del pedido incluye el identificador del producto solicitado y el identificador de la sesión del usuario. 3. Aplicación wireless sobre plataforma.net y J2ME El cliente móvil que utilizará los servicios de la plataforma Link-ALL será implementado para las dos plataformas más importantes para el desarrollo de aplicaciones wireless.net y J2ME. 1. Consultar productos de Link-All de forma on-line Los usuarios utilizando su cliente móvil podrán realizar consultas y búsquedas en línea al servicio que ofrecerá Link-All y se mencionó anteriormente. 2. Consultar productos de Link-All de forma off-line De forma offline el usuario podrá navegar los datos descargados y persistidos en el cliente durante la operación online del usuario. Solución propuesta Consideraciones generales A continuación se presentan algunas consideraciones tenidas en cuenta en el diseño del la solución propuesta. 1. Seguridad Para mejorar la experiencia del usuario y evitar procedimientos de autenticación engorrosos la solución propuesta para los clientes móviles provee una característica de login automático. Esta característica es configurable y en caso de estar habilitada la aplicación almacena localmente usuario y password para luego autenticarse automáticamente cuando se realizan pedidos al servicio.

6 2. Usabilidad 1. Personalización Un cliente móvil tiene limitaciones en cuanto a sus recursos como por ejemplo memoria, almacenamiento persistente y de poder de procesamiento. Es importante optimizar el uso de los recursos y una forma de hacerlo es por ejemplo descargar la cantidad de información que el usuario prefiera (personalización de la aplicación). 2. Mejoras en las respuestas El poder trabajar desconectado del servidor produce una disminución considerable del tiempo de respuesta. Al descargar listados de productos no se descargará toda la información de cada producto sino sólo lo mínimo dependiendo del usuario si desea ver en detalle dicha información. Esto ayuda a disminuir la cantidad de datos transferidos y evitar descargar datos inútiles. Diseño La figura siguiente despliega una vista global del sistema: Fig. 1. Vista global del sistema 1. Arquitectura 1. General El sistema como se aprecia en la fig. 2 contará con un servidor en donde estará instalada la plataforma Link-all y la aplicación que exporta los Web Services que serán consumidos por ambos clientes J2ME y.net.

7 Fig. 2. Vista de deployment de la arquitectura 2. Arquitectura de los móviles Fig. 3. Arquitectura de los dispositivos Ambos dispositivos.net y J2ME, poseen una macro arquitectura idéntica. Cada uno contará con 4 componentes, que se detallan a continuación: Presentación: Posee las clases que representan los formularios, y contiene la navegabilidad de la aplicación, desde ésta se accede a la lógica para obtener los datos que se desplegarán en los formularios, ya sean datos de productos, como también opciones de configuración y búsqueda. Lógica: Sirve a la presentación para brindarle la información deseada, decidiendo cuando es necesario acceder a los datos locales o a los datos de Link-all. LocalData: Se encarga del almacenamiento de la información de productos descargada del servicio, así como también almacena información de configuración y autenticación.

8 LinkAllWebServices: Recibe peticiones de la lógica para descargar información de Link-all y realiza el llamado al Web Service para obtenerla. Este componente sólo es utilizado cuando la aplicación se encuentra funcionando en modo online. 3. Arquitectura del servicio El servicio es una aplicación desarrollada utilizando J2EE y se encuentra instalada en la plataforma Link-all. Recibe los pedidos de los clientes, utiliza los componentes de Link-all para la autenticación, obtener sesiones e información de productos. La cantidad máxima de productos a retornar será restringida a la especificada por el cliente, esto permite evitar que los clientes se sobrecarguen de información. 2. Diseño de los componentes 1. Presentación En la implementación del cliente J2ME se siguió el patrón Model-View-Controller (MVC) lo que permitió dividir la aplicación en 3 componentes principales modelo, vista, controlador y desacoplar sus respectivas responsabilidades. Fig. 4. Arquitectura MVC del cliente móvil desarrollado en J2ME La capa de presentación, como se aprecia en la figura está conformada principalmente por las clases que forman la interfaz de usuario (UI) y el controlador. Las clases como por ejemplo MainMenuUI implementan las vistas, UIController implementa el controlador principal y es el encargado de controlar el flujo global de las vistas y el acceso al modelo. La capa de presentación del cliente.net por su parte está conformada por cada uno de los formularios que representan cada una de las vistas. Este cliente no sigue el patrón MVC ya que las vistas trabajan directamente con la fachada del modelo. 2. Lógica En la capa lógica se encuentra el modelo local y el proxy de acceso al modelo remoto. En esta capa se utilizó el patrón de diseño estructural Fachada para ocultar la complejidad de la implementación del modelo de datos en el cliente y brinda además una interfaz única y simplificada. El controlador de la capa de presentación desconoce si se accederá a datos locales o

9 remotos ya que la fachada es la que decide a quien solicitarle la información dependiendo de la configuración actual del usuario. Fig. 5. Lógica y comunicaciones 3. Persistencia de los datos La persistencia permite almacenar los datos de los productos descargados, posibilitando el modo de operación offline, así como también información acerca de la configuración y preferencias del usuario. En el cliente J2ME la especificación MIDP provee un mecanismo para que los MIDlets puedan persistir y recuperar datos. Este mecanismo de almacenamiento persistente se denomina Record Management System (RMS) y es una base de datos simple orientada a registros. La API RMS provee métodos para comparar, enumerar, filtrar, monitorear registros y almacenes de registros. Como se aprecia en la figura 6 la clase LocalModel utiliza tres clases para almacenar la información de configuración, productos y sectores respectivamente. Cada una de dichas clases es una implementación de una clase base Database y permite brindar una interfaz de alto nivel, por encima de RMS. Estas clases permiten recibir y retornar objetos cuando internamente usan RMS para almacenar la información de dichos objetos como array de bytes. Fig. 6. Persistencia El cliente.net persiste la información en archivos planos almacenados en el sistema de archivos del Smartphone (la información se serializa y almacena en formato XML). La persistencia en archivos es el único medio disponible para Smartphones ya que.net Compact Framework provee una edición compacta de Sql Server (Sql Server Compact Edition) pero sólo está disponible para PDA debido a los requerimientos de la misma. 4. Comunicaciones La comunicación del cliente.net o J2ME con el servicio se realiza vía Web Services pero eventualmente dos clientes J2ME podrían compartir información de productos vía mensajes multimedia o texto.

10 Como se aprecia en la figura 5 se utilizó el patrón de diseño Proxy para abstraer la lógica que trata con el acceso a los datos remotos. La clase WSCommunicationHandler es la encargada de realizar la invocación concreta al Web Service y de aislar los errores que se produzcan durante dicha invocación. Es oportuno aclarar que la aplicación podría ser fácilmente extendida anexando otro handler que permita manipular otra forma de comunicación con el servicio como por ejemplo transferencia binaria cliente-servidor. La fachada del modelo posee un agente de mensajería el cual controla dos manejadores, uno para la comunicación SMS y otro para MMS, pudiendo ser fácilmente extendido a otra forma de comunicación como por ejemplo EMS. Problemas encontrados Acceso al Web Service con el cliente J2ME Los estándares WS-I soportan solamente RPC/literal y Document/literal como modos de operación de los Web Services. La implementación de JAX-RPC para el acceso a los Web Services desde dispositivos móviles debe usar Document/Literal para el mapeo de una descripción de un servicio basada en WSDL a la representación Java correspondiente. La implementación del servicio desarrollado sobre la plataforma J2EE utiliza AXIS como motor de Web Services el cual por defecto genera Web Services con estilo RPC/encoded. Debido a esto fue necesario modificar la generación del Web Service ya que de otra forma el cliente J2ME no podía acceder al mismo. Si el servicio hubiera sido desarrollado sobre plataforma.net no hubieran existido problemas dado que.net genera por defecto Web Services de tipo Document/Literal. Conjunto reducido de librerías en las plataformas de desarrollo Las plataformas, tanto J2ME como.net Compact Framework, poseen un conjunto reducido de librerías en comparación con J2SE o.net respectivamente. Esta diferencia originó tener que realizar modificaciones al momento de reutilizar código. En el cliente J2ME por ejemplo, implicó el uso de SAX ya que es el único parser de XML disponible y utilizar la clase Vector para el manejo de colecciones, al no contar con clases como por ejemplo ArrayList. Diseño de interfaz de usuario y usabilidad Los clientes J2ME tienen habilidades de GUI limitadas en comparación con clientes desarrollados en J2SE. Las herramientas open source con que se trabajó poseen limitantes, Eclipse ME [4] [5] no tiene diseñadores para las interfaces GUI pero permite control total del código así como también la integración de Wireless Toolkit de los principales fabricantes de celulares además del provisto por SUN Microsystems [6]. Netbeans [9] con el pack de desarrollo para aplicaciones móviles (Mobility pack) permite diseñar GUIs además de la navegación de las mismas pero posee la restricción de que no se permite editar el código generado. Visual Studio 2003 posee por su parte la capacidad de diseñar la GUI de la aplicación pero el emulador de Smartphone que se le puede integrar es estándar, lo que no se adecua totalmente a la realidad, ya que en el mercado existen aparatos que ejecutan Windows Mobile y poseen diferentes distribuciones de teclado y dimensiones de las pantallas.

11 Conclusiones El trabajo realizado permitió demostrar la factibilidad de exportar servicios de la plataforma Link-all a distintas tecnologías móviles y clientes, a través de un Web Service en común. Las carencias encontradas en la plataforma con respecto a proveer información a dispositivos móviles tienen que ver en su mayor parte con respecto al modelo de datos y al contenido de la información almacenada. En lo que respecta a los objetivos planteados en el proyecto se cumplió con el alcance establecido y se realizó además opcionales propuestos, como mensajería multimedia (MMS) entre clientes J2ME, e internacionalización de las aplicaciones móviles. Este trabajo permite demostrar que es posible que una aplicación (en este caso desarrollada sobre J2EE) ofrezca servicios a plataformas de desarrollo para dispositivos móviles como lo son J2ME y.net Compact Framework, utilizando como vía de comunicación Web Services. Al evaluar ambas tecnologías se puede ver que tienen capacidades similares permitiendo el desarrollo de los mismos proyectos en tiempos y esfuerzos de desarrollo parecidos. La mayoría de los celulares que hoy en día hay en nuestra sociedad, proveen soporte para ejecutar aplicaciones J2ME, dando una pauta del mercado que se abre para este tipo de desarrollos, en el corto tiempo. Trabajo futuro 1. Capacidad de edición o ingreso de datos Se podría permitir a los clientes el ingreso o edición de información de productos desde los dispositivos móviles, de esta forma los clientes se convertirían de simples consumidores a productores de información para la plataforma. 2. Sincronización de los datos Si el estado compartido es de sólo lectura no se requiere sincronización. Los clientes sólo recuperan datos y deberán cada cierto intervalo de tiempo consultar al servicio para obtener datos actuales. Si el estado es compartido puede ser actualizado concurrentemente y entra en juego la consistencia de datos dado que varios clientes pueden estar manejando los mismos datos al mismo tiempo [2]. Para detectar inconsistencias se pueden utilizar técnicas de chequeo de timestamp antes de subir y actualizar datos modificados, y esto puede requerir cooperación del servicio. Otra técnica a utilizar puede ser data locking es decir evitar cambios simultáneos a los mismos datos. También el servicio podría ser capaz de lanzar una excepción específica del mismo indicando que los datos han sido modificados por otro cliente y podrían estar fuera de sincronía.

12 3. Extender el modelo de dominio de las aplicaciones inalámbricas La plataforma Link-all cuenta con una amplia variedad de funcionalidades; en este caso particular se trabajó sólo con los productos y servicios de Link-all, pero el dominio se podría ampliar para incluir otras funcionalidades y hacerlas accesibles desde dispositivos móviles. 4. Capacidad de controlar la cantidad de datos transferidos El ancho de banda para muchos de los aparatos móviles limitan a veces la cantidad de datos que pueden ser transferidos. Es una buena opción el permitir a la aplicación limitar la tasa de datos transferidos para poder adecuarse a la red y también tener en cuenta el costo que ello implica dado que muchos proveedores de red cobran por kilobyte de transferencia. Recordar que actualmente la aplicación puede restringir el número de productos transferidos del servicio al cliente móvil. 5. Pruebas en dispositivos reales Como no se disponía de aparatos móviles las tareas de implementación y testing fueron llevadas a cabo en emuladores. Esto es importante a tener en cuenta dado que un emulador no es totalmente idéntico a un aparato real. Sería necesaria una etapa de testing de las aplicaciones en aparatos reales para poder detectar, corregir fallas y mejorar la performance de dichas aplicaciones. 6. Mejorar la experiencia del usuario La invocación a Web Services muchas veces involucra latencias en las respuestas que es imposible conocerlas de antemano. Por esto es conveniente realizar la invocación al Web Service en segundo plano (background), o sea en un thread diferente y actualizar la interfaz de usuario cuando la información es recibida. En otros casos el cliente puede llegar hasta a abandonar la aplicación ante lo que parece una pantalla congelada o una aplicación trancada o no-funcional, dado que la aplicación se bloquea durante la llamada al Web Service. El cliente J2ME realiza la invocación en background desplegando al usuario una barra de progreso mientras el servicio retorna la información. Este comportamiento se podría implementar en el futuro también para el cliente móvil.net. Otra forma de mejorar la experiencia del usuario con la aplicación móvil es por ejemplo permitir el despliegue de imágenes adjuntas a la información del producto. Dichas imágenes podrían ser codificadas (en base 64 por ejemplo) y transportadas a través del Web Service. Sería necesario crear imágenes de productos en formatos y tamaños adecuados para dispositivos móviles ya que Link-all actualmente no cuenta con ellas. 7. Localización e internacionalización Actualmente el cliente J2ME cuenta con localización integrada a la aplicación en dos idiomas: inglés y español. Esto se podría extender fácilmente a más idiomas así como también que el servicio provea paquetes de idiomas y los usuarios los puedan descargar en caso de que el paquete no se encuentre en el aparato. 8. Posibilidad de salvar el estado de la aplicación El trabajar con aparatos móviles es un medio donde ocurren frecuentes interrupciones ya sea por ejemplo por llamadas entrantes (que obliguen a atender la llamada y dejar de operar con la

13 aplicación). Se debería permitir que la aplicación móvil no pierda su estado si el dispositivo es interrumpido. 9. Mejoras en la seguridad El modo de operación desconectado requiere la persistencia de los datos en el almacenamiento local del dispositivo móvil. Si la información almacenada es sensible se debería proteger su confidencialidad e integridad. En el cliente J2ME, el almacenamiento local RMS restringe el acceso a los registros solamente a la aplicación dueña, por lo tanto un mecanismo simple sería proteger la aplicación misma con un procedimiento de autenticación tales como usuario y password. Además el intercambio de datos entre cliente y servidor debería realizarse utilizando como mínimo un protocolo seguro tal como es HTTPS. 10. Proveer información basándose en la localización del usuario Aprovechar la ventaja de los aparatos móviles para proveer al usuario de información basada en la ubicación en que se encuentra utilizando tecnologías como GPS (Global Positioning System). En el caso de Link-All sería posible ofrecer los productos típicos de la zona en que se encuentra el usuario así como también información sobre los precios y empresas que venden dichos productos. 11. Anexar a la plataforma Link-all información adecuada para dispositivos móviles Se debería anexar a la plataforma Link-all la posibilidad de incorporar información e imágenes adecuadas para dispositivos con GUI limitadas. Esto podría requerir modificaciones en la base de datos como por ejemplo agregado de campos especiales para aplicaciones móviles y también la conversión de imágenes a un formato y tamaño menor al actual. Referencias [1] Garbusi, P., González, L., Piedrabuena, F., Link-all System Architecture Document. Versión Instituto de Computación, Facultad de Ingeniería, Uruguay. [2] Violleau, T., Ortigas, R., Supporting Disconnected Operation in Wireless Enterprise Applications. SUN Microsystems Inc., accedido 07 diciembre 2005, < [3] SUN Microsystems Inc., J2ME website, accedido 01 Noviembre 2005, < [4] EclipseME website, accedido 05 Noviembre 2005, < [5] Eclipse website, accedido 01 Noviembre 2005, < [6] SUN Microsystems Inc., Sun Java Wireless Toolkit website, accedido 05 Noviembre 2005, < [7] Microsoft, Windows Mobile website, accedido 13 Marzo 2006, < [8] SUN Developer Network (SDN), Patterns and Strategies for Building Document-Based Web Services, accedido 13 Marzo 2006, < [9] Netbeans ORG, Netbeans website, accedido 13 Marzo 2006, <