Microservidor web local para PDA
De MorfeoWiki
Tabla de contenidos |
Introducción
Objetivo
El presente documento es el manual de usuario del microservidor web local para PDAs. Se explica en que consiste el componente, el tipo de aplicaciones que permite desarrollar y se indican los mecanismos de instalación.
Audiencia
Este documento va dirigido a los desarrolladores de aplicaciones que utilicen el componente, así como a los responsables de instalación del mismo.
Documentación relacionada
- MyMobileWeb: Manual del Programador para cliente ligero.
- MyMobileWeb: Guía Rápida de Desarrollo de Aplicaciones.
- MyMobileWeb: Manual de Usuario del Componente de Gestión de Dispositivos
- MyMobileWeb: Guía de Referencia del Lenguaje de Definición de Presentaciones
- MyMobileWeb: Manual de Usuario de las Herramientas de Despliegue de Presentaciones
El desarrollo de la plataforma MyMobileWeb se enmarca dentro de la Comunidad de Software Libre Morfeo. La última versión de la documentación y del software se encuentra siempre disponible en http://www.morfeo-project.org.
Visión general
Introducción
En muchas ocasiones en el contexto de movilidad se plantea la necesidad de construir aplicaciones en las que su correcto funcionamiento no dependa de una conexión permanente (on-line) con los sistemas centrales que contienen la lógica de negocio y los datos. Esta necesidad surge por distintos motivos:
- El nivel de disponibilidad de las redes móviles, el cual esta muy por debajo de los de las redes fijas. Todavía se está muy lejos del sueño de disponer de una conexión móvil en todo momento y lugar.
- La existencia de posibles zonas de sombra en la cobertura.
- El bajo ancho de banda y latencia de las redes móviles, lo que hace que las salidas al servidor sean costosas en tiempo.
- La necesidad de optimizar las comunicaciones de forma que se pueda ahorrar tráfico.
- La existencia de zonas de prohibición de uso de comunicaciones inalámbricas (gasolineras, alrededores de edificios oficiales ...)
Las razones anteriores implican la necesidad de disponer aplicaciones móviles que funcionen en modo off-line o sincronizado, esto es, aplicaciones en las que se garantice el funcionamiento en tanto en cuento se disponga del terminal móvil, independientemente de que, en un momento dado, no se disponga de la capacidad de conexión al sistema central.
Tipos de aplicaciones
Las aplicaciones off-line siguen el paradigma store and forward, esto es, el resultado de las operaciones realizadas por el usuario es almacenado en los terminales móviles y posteriormente enviado hacia el servidor central. Dentro de las aplicaciones off-line y sincronizadas podemos destacar los siguientes tipos, ordenados de mayor a menor con respecto al modo de trabajo off-line:
- Aplicaciones off-line puras. Este tipo de aplicaciones se caracterizan porque para cubrir la funcionalidad que aportan no realizan ningún tipo de conexión con el servidor. Las únicas conexiones con el servidor se realizan para pasar la información modificada en el terminal móvil hacia el servidor central y para descargar del servidor central nuevos datos. Este proceso recibe el nombre de sincronización. En estas aplicaciones la sincronización se produce habitualmente al comienzo y al final del día en puestos especiales conectados a una red fija. Estas aplicaciones pueden funcionar con terminales móviles que no dispongan de conectividad inalámbrica.
- Aplicaciones off-line con sincronización eventual. Se trata de aplicaciones que, aun siendo off-line, ante determinados eventos solicitan una sincronización con el servidor central. Los eventos que desencadenen una sincronización serán aquellos que impliquen Operaciones de Aplicación cuya ejecución o resultado deba ser conocida inmediatamente por el servidor central. También podría darse el caso de aplicaciones que sincronicen periódicamente o en instantes de tiempo concretos con el servidor central. Dado que la sincronización puede desencadenarse eventualmente y en campo, para ejecutar este tipo de aplicaciones será necesario disponer de un terminal con conectividad inalámbrica.
- Aplicaciones mixtas off-line / on-line. Son aplicaciones para las cuales determinadas operaciones de negocio se resuelven de manera off-line, mientras que otras operaciones de negocio se resuelven on-line, es decir con conexión directa vía red móvil con el servidor central. Las operaciones de negocio a resolver on-line serán aquellas que requieran una respuesta inmediata por parte del sistema central. Un ejemplo claro es una aplicación para instaladores de servicios de telefonía básica. Una vez realizada la instalación del servicio, el operario tendrá que solicitar al sistema central un test de línea para verificar el correcto funcionamiento y/o el diagnostico de fallos. La aplicación de gestión de la actividad del operario puede funcionar en modo off-line, pero la solicitud de la prueba deberá realizarse on-line, puesto que no se puede resolver en local y tampoco tiene sentido enviarla en diferido, ya que lo que se requiere es un resultado en el menor tiempo posible.
- Aplicaciones inteligentes off-line / on-line. En este caso se trata de aplicaciones cuyo modo de funcionamiento normal es on-line. Sin embargo, están preparadas para conmutar a un modo de funcionamiento off-line en caso de que se detecte la pérdida cobertura o cualquier problema de red. Cuando la capacidad de conexión a la red se recupera la aplicación es capaz de sincronizar la información con el servidor central, de forma transparente al usuario.
- Aplicaciones on-line con minimización de interacciones con el servidor. Este tipo de aplicaciones aun siendo on-line, están construidas de forma que el número de interacciones con el servidor central se minimiza. Son un caso particular de aplicaciones mixtas donde todas las operaciones de negocio son on-line, existiendo una sincronización de datos, combinada con un almacén persistente, que permite minimizar el número de conexiones con el servidor central. Estrictamente hablando, este tipo de aplicaciones no podrían considerarse off-line. Sin embargo, lo detallamos en este apartado para recalcar el hecho de que es posible diseñar aplicaciones on-line que minimicen el número de salidas al servidor, mejorando la experiencia del usuario y ahorrando costes de tráfico. Adicionalmente es posible combinar las estrategias definidas por los dos casos anteriores y actual para obtener una aplicación inteligente off-line / on-line que además minimiza el número de interacciones con el servidor.
El componente descrito en el presente documento permite desarrollar todos los tipos de aplicaciones descritos en los puntos anteriores.
Sincronización
Las aplicaciones off-line funcionan en los dispositivos móviles en modo "stand-alone", realizando operaciones locales sobre el dispositivo y accediendo a datos almacenados en el propio dispositivo. Periódicamente debe realizarse una sincronización. La sincronización es el proceso de propagación al sistema central de cambios realizados en el dispositivo (upload) y viceversa, esto es, el proceso de envío hacia los terminales de nuevos datos relacionados con el usuario (download). Los cambios que se propagan serán aquellos ocurridos desde el proceso de sincronización anterior, garantizándose la resolución de conflictos si los hubiere, siguiéndose las directrices marcadas por el diseñador de la aplicación (políticas de resolución de conflictos).
Estrategias de sincronización
En el desarrollo de aplicaciones de movilidad off-line, existen dos estrategias de sincronización:
- Sincronización orientada a los datos. La sincronización orientada a los datos consiste en sincronizar datos presentes en la capa de datos de la aplicación móvil hacia la aplicación central y viceversa. Se trata de un método de sincronización que es bastante eficiente ya que puede ser combinado con técnicas de compresión de datos. El problema puede surgir cuando existe lógica adicional asociada al proceso de sincronización. En este caso la sincronización orientada a los datos no es suficiente.
- Sincronización orientada a la aplicación. En muchos casos la sincronización lleva incorporada lógica que requiere unos mecanismos más sofisticados que los que proporciona la sincronización de datos. La sincronización orientada a la aplicación consiste en la solicitud diferida, resuelta en primera instancia en el terminal móvil, de la ejecución de una operación de negocio.
En general se puede afirmar que los mejores resultados se logran cuando es posible combinar ambos tipos de técnicas. La sincronización orientada a los datos se debe utilizar para sincronizar conjuntos de datos básicos, mientras que la sincronización orientada a la aplicación deberá utilizarse para la sincronización de operaciones que lleven asociada lógica de negocio que implique acceso, modificación y creación de múltiples datos en la aplicación central.
La diferencia entre ambos tipos de sincronización se va a detallar mediante ejemplos.
- Ejemplo 1: Se dispone de una aplicación móvil off-line de registro de lecturas de contadores eléctricos o de gas. En el terminal móvil el operario va registrando la lectura de un contador de un cliente, quedando registrada en el dispositivo. Posteriormente esa lectura debe ser sincronizada contra la aplicación central. En este caso con una sincronización orientada a los datos es suficiente para lograr la funcionalidad requerida.
- Ejemplo 2: Se tiene una aplicación de gestión de inventario de materiales de un operario. La aplicación permite hacer descuentos de materiales del inventario del operario según los va utilizando en instalaciones. Se puede pensar inicialmente en una sincronización orientada a los datos. Cada vez que el operario utilizara un material se descontaría en uno la cantidad y se grabaría la nueva cantidad en el terminal móvil. Posteriormente esa cantidad modificada tendría que llevarse a la aplicación central. Ahora bien, puede darse el caso de que, antes de que se produzca la sincronización, el inventario del técnico se vea modificado desde la aplicación central aumentando la cantidad disponible de un material. Al realizar la sincronización de datos se producirá un conflicto, debido a que se habrán producido modificaciones en el mismo dato tanto en la aplicación central como en el terminal móvil. En este caso lo adecuado hubiera sido una sincronización orientada a la aplicación, esto es que en el dispositivo hubieran quedado almacenadas una o n operaciones de negocio de descuento de cantidades de material. Posteriormente esas operaciones deberían haber sido reproducidas en la aplicación central. Al reproducirse las operaciones, se habrían efectuado los pertinentes descuentos de material, y no se hubiera producido ningún conflicto. Adicionalmente después de la sincronización de la operación de negocio, debería haberse producido una sincronización de datos en el sentido servidor -> terminal móvil para que la nueva cantidad de material pudiera ser almacenada en el dispositivo.
El ejemplo anterior sirve para llegar a la conclusión que las aplicaciones off-line deben combinar ambos tipos de sincronizaciones.
Alternativas tecnológicas
Existen dos alternativas en el desarrollo de una aplicación cliente off-line:
- Desarrollar un cliente pesado (smartclient). Esta es la opción más genérica y que sirve para distintas categorías de terminales. Presenta el inconveniente de un mayor coste de desarrollo y mayor dificultad en la actualización del software. Las tecnologías que permiten desarrollar smartclient son J2ME, .NET Compact Framework y Symbian.
- Desarrollar un cliente ligero que funcione sobre un MicroServidor Web ejecutado en el propio terminal móvil. Esta opción consiste en desarrollar la aplicación offline como si fuera una aplicación Web, es decir con servlets en el lado servidor y presentación mediante páginas HTML. Dicha aplicación Web se ejecutará sobre el propio dispositivo. Posteriormente mediante un programa de sincronización, se podrá realizar la sincronización de los datos y de las operaciones realizadas previamente por el usuario.
La segunda aproximación presenta la ventaja de que tanto el desarrollo como la distribución de actualizaciones es sencilla, reutilizándose skills de desarrolladores Web convencionales.
MicroWebServer MyMobileWeb
El producto MyMobileWeb incorpora un microservidor Web local para PDAs que permite la ejecución de aplicaciones Web locales basadas en cliente ligero. Se trata de un microservidor Web desarrollado 100% en Java y con características de diseño que permiten su ejecución en un entorno restringido como es J2ME Personal Profile.
El componente sirve tanto contenido estático (páginas HTML, imágenes, etc) como servlets Java, los cuales permiten generar contenido dinámico. El servidor sigue el estándar Java Servlet y ocupa únicamente 60 Kb.
Además proporciona una librería que permite almacenar formularios en XML (sincronización orientada a la aplicación). Posteriormente esos formularios pueden enviarse en diferido hacia el servidor central mediante una herramienta de sincronización.
Figura 2.1 .- Arquitectura de las aplicaciones off-line
Arquitectura de las aplicaciones
La figura de arriba muestra un diagrama de arquitectura de las aplicaciones off-line construidas con el componente. En la PDA se ejecuta el microservidor Web el cual está a la escucha de peticiones HTTP. En la PDA también se arranca el navegador Web, el cual realiza peticiones HTTP a la dirección ‘localhost’ y al puerto en el que esté a la escucha el microwebserver.
Por tanto, la interfaz del usuario será el navegador convencional de la PDA con páginas HTML, CSS y Javascript. La única diferencia con respecto a una aplicación on-line es que el navegador hará conexiones HTTP locales y no remotas, las cuales requerirían de una conexión de datos (GPRS, Wi-Fi, UMTS ...).
Algunas de las peticiones desencadenarán la ejecución de código Java presente en JavaServlets. El usuario realizará operaciones sobre la aplicación mediante formularios (POST), que serán almacenados en XML para su posterior envío al servidor central. El envío de formularios se realizará posteriormente, utilizándose la herramienta de sincronización (SyncTool).
La herramienta de sincronización realiza el envío de los datos de los formularios al servidor central mediante HTTP, reproduciendo exactamente (en diferido) el POST que realizó el usuario en local. Ese POST en el lado servidor puede ser procesado por un motor de sincronización, o cualquier elemento software capaz de reproducir en diferido la operación del usuario.
Instalación y configuración
Introducción
En el presente apartado se detallarán los mecanismos de instalación y configuración del componente de cara a disponer de una aplicación off-line plenamente operativa en una PDA.
Requisitos previos
Para poder ejecutar el microservidor Web se necesitan los siguientes elementos:
- PDA Pocket PC 2002 o superior con al menos 64 Mb de RAM
- Máquina Virtual Java que soporte la especificación ‘Personal Java’ o bien la configuración J2ME-CDC con al menos el perfil "Foundation Profile" (Por ejemplo, Smertec JBED, Creme ó Mysaifu JVM)
- Paquete de distribución del componente MyMobileWeb_PDAWebServer_xxx_tar.gz
Instalación
El proceso de instalación es totalmente manual.
El componente se distribuye en un fichero .tar.gz el cual deberá ser descomprimido en un PC de escritorio en un directorio. Posteriormente se deberá crear en la PDA un directorio de instalación del componente de nombre \PDAWebServer y en él copiar todo el software. Es recomendable instalar el componente en un soporte físico tipo memoria flash, de cara a evitar perder información. Los directorios que aparecen al descomprimir el componente son:
- config. Contiene ficheros de configuración del microservidor Web local.
- webapps. Bajo este directorio deben residir las aplicaciones Web locales (a razón de una aplicación por directorio). Se incluye una aplicación de ejemplo en la distribución. Cada aplicación deberá incluir al menos el directorio ‘WEB-INF’ con el fichero XML descriptor de la aplicación (web.xml).
- lib. Contiene las librerías necesarias para la ejecución del servidor
- log Contiene los logs del servidor Web local
- offline Es el directorio en el que se almacenarán los formularios en XML rellenados por el usuario. Estos ficheros XML permanecerán ahí mientras no se produzca una sincronización.
- install. En este directorio residen unos enlaces directos que podrán copiarse al Menú Inicio de la PDA
Una vez descomprimido el software deberá copiarse la carpeta install/TIDOfflineTools al directorio \windows\Menú Inicio\Programas. Esto hará que bajo la carpeta ‘Programas’ de la PDA aparezca una nueva carpeta ‘TIDOffLineTools’. En esta carpeta aparecerán dos iconos que permiten el acceso directo a los dos ejecutables que incorpora el componente: ‘MicroWebServer’ y ‘SyncTool’. El ejecutable ‘MicroWebServer’ arranca el microservidorweb en la PDA, mientras que ‘SyncTool’ arranca la herramienta de sincronización.
Configuración
Configuración del servidor local
La configuración del servidor local para PDA se realiza editando el fichero config/server.xml. En la figura de abajo se muestra un ejemplo de fichero. En este fichero se configura el puerto en el que arrancará el servidor local (en este caso el 8081), el directorio base a partir del cual cuelgan las aplicaciones web (webapps), el directorio donde se van a guardar los formularios a sincronizar (offline) y el directorio de logs (log).
Bajo el apartado <web-app> se especifican los recursos off-line. Estos recursos se identifican por un nombre, la URI real sobre la que deberán ser invocados cuando se sincronicen, un usuario y contraseña a utilizar (opcionales) y una página de éxito temporal a redirigir cuando el formulario sea procesado y almacenado localmente. En el ejemplo, de la figura se declara un recurso off-line (formulario) de nombre ‘CambioDePar’. En este caso, cuando se invoque el formulario y se almacenen los datos en XML en el dispositivo, la página que será mostrada automáticamente será ‘CambioOK.html’.
Figura 3.1 .- Fichero server.xml para la configuración del microservidor Web
<?xml version="1.0" encoding="ISO-8859-1"?>
<server>
<port>8081</port>
<docbase>webapps</docbase>
<offline-dir>offline</offline-dir>
<log-dir>log</log-dir>
<web-app>
<offline-resource>
<resource-name>CambioDePar</resource-name>
<resource-uri>http://escanda:9966/GDialogo</resource-uri>
<success-page>/CambioOK.html</success-page>
</offline-resource>
</web-app>
</server>
Configuración de la herramienta de sincronización
La herramienta de sincronización se configura mediante un fichero XML (config/sync.xml). En la figura se muestra el formato de este fichero. Como se puede observar, se debe configurar cual es el directorio en el que se situarán los ficheros XML con los formularios a sincronizar (a razón de un directorio por cada recurso offline) (tag <offline-dir>). También debe configurarse el directorio en el que la herramienta deje los ficheros trazas (tag <log-dir>).
La declaración de recursos off-line es opcional, ya que la propia herramienta de sincronización permite la introducción de la URL de sincronización, usuario, contraseña, etcétera.
Figura 3.2 .- Fichero sync.xml para la configuración de la herramienta de sincronización
<?xml version="1.0" encoding="ISO-8859-1"?>
<sync>
<offline-dir>offline</offline-dir>
<log-dir>log</log-dir>
<offline-resource>
<resource-name>Form2</resource-name>
<resource-uri>http://muesli:2525/servlet/Encuesta</resource-uri>
</offline-resource>
<offline-resource>
<resource-name>CambioDePar</resource-name>
<resource-uri>http://escanda:9966/GDialogo</resource-uri>
<success-page>/CambioOK.html</success-page>
</offline-resource>
</sync>
Descriptor de la aplicación
Cada aplicación deberá tener un descriptor XML (fichero WEB-INF/web.xml) con el formato especificado por el estándar JavaServlet. Dado que se trata de un formato estándar, no se describe en este documento.
Dentro del propio directorio WEB-INF existirán los subdirectorios ‘classes’ y ‘lib’ donde dejar los servlets y librerías externas a utilizar.
Descripción detallada
Introducción
En este capítulo se va a realizar una descripción más detallada del componente.
Ejecución del microwebserver
La clase principal del microwebserver es org.morfeo.mws.Startup. Para que el microservidor funcione correctamente es necesario que la propiedad de sistema (parámetro –D de la JVM) ‘user.dir’ esté correctamente establecida y con un valor igual al directorio base de instalación del componente (habitualmente \PDAWebServer). Además se debe garantizar que se encuentran en el CLASSPATH los ficheros pdawebserver.jar, mjasper-runtime.jar, mws-util.jar, servlet.jar y kxml2-2.2.2.jar
La instalación proporciona un acceso directo (en el directorio TIDOfflineTools) para la ejecución del microwebserver (ver Figura 4-1: Accesos directos) utilizando la máquina virtual Jeode (ahora conocida como JBed). Si se deseara utilizar el microservidor bajo otra máquina virtual deberán crearse accesos directos a tal efecto (con la configuración que exija cada máquina virtual). El acceso directo en cuestión se llama ‘MicroWebServerStartup’ y asume que el directorio en el que se instaló el componente es \PDAWebServer.
En el caso de la JVM Jeode cuando el servidor arranca correctamente se puede ver una pantalla como la que se muestra en
Figura 4.1 .- Accesos directos
Figura 4.2 .- Ejecución correcta del microwebserver utilizando Jeode
Ejecución de la SyncTool
La clase principal de la herramienta de sincronización es org.morfeo.mws.sync.SynchronizerStartup. Para que la herramienta de sincronización funcione correctamente es necesario que la propiedad de sistema (parámetro –D de la JVM) ‘user.dir’ esté correctamente establecida y con un valor igual al directorio base de instalación del componente (habitualmente \PDAWebServer). Además se debe garantizar que se encuentran en el CLASSPATH los ficheros mws-util.jar, synctool.jar y kxml2-2.2.2.jar.
La instalación proporciona un acceso directo (en el directorio TIDOfflineTools) para la ejecución de la herramienta de sincronización utilizando la máquina virtual Jeode (ahora conocida como JBed). Si se deseara utilizar la herramienta bajo otra máquina virtual deberán crearse accesos directos con la configuración y parámetros adecuados para cada máquina virtual. El acceso directo en cuestión se llama ‘SyncTool’ y asume que el directorio en el que se instaló el componente es \PDAWebServer.
En la Figura 4-3: La herramienta de sincronización se puede ver el aspecto de la herramienta de sincronización. Como se ve se puede especificar la URL contra la que se realizará la sincronización, el usuario y la contraseña. En el combo ‘Operación’ aparecen todos los tipos de formularios a sincronizar y en la lista de abajo aparecen los distintos formularios guardados. Al pulsar sobre el botón ‘Sincronizar’ se produce el envío de los formularios. Al pulsar el botón ‘Opciones’ se permite configurar un proxy a través del cual realizar la sincronización.
Figura 4.3 .- La herramienta de sincronización
Formato de los ficheros XML con los formularios a ser sincronizados
En el directorio ‘offline’ aparecen tantos subdirectorios como tipos de formularios estén almacenados en la PDA. Dentro de cada uno de esos directorios aparecen tantos ficheros como veces se haya rellenado ese formulario y no se haya sincronizado. Los ficheros se llaman igual que el formulario y añaden un sufijo con el timestamp que indica en que momento se rellenó el formulario.
En la figura se muestra un ejemplo de fichero XML que contiene datos de un formulario para ser sincronizado. Como se ve se almacena el método con el que será enviado, los valores de los parámetros y la target URI (que podrá ser especificada mediante la herramienta de sincronización cuando se envíe el formulario en diferido).
Figura 4.4 .- Fichero XML con datos a ser sincronizados
<?xml version="1.0" encoding="ISO-8859-1"?>
<form>
<method>POST</method>
<params>
<param-name>entonno</param-name>
<param-value>89</param-value>
<param-name>caja</param-name>
<param-value>777777</param-value>
<param-name>tlf</param-name>
<param-value>979771909</param-value>
</params>
<target-uri>http://escanda:9966/GDialogo</target-uri>
</form>
Ejemplo de uso
Introducción
En este capítulo se describe como utilizar el componente. La instalación incorpora una aplicación ejemplo de utilización del producto. Se trata de una pequeña aplicación que permite el cambio de los datos de un par telefónico fijo.
Estructura de la aplicación ejemplo
La aplicación se sitúa sobre el directorio ‘webapps’ de la instalación del servidor local. En la Figura 5-1: Estructura de la aplicación ejemplo se puede ver los ficheros y directorios que la componen. Se observa que aparece el directorio WEB-INF estándar JavaServlet.
Esta aplicación no proporciona ningún servlet de ejecución en el servidor local, sino un conjunto de páginas HTML y Javascript estáticas.
Existe un único formulario que se almacena en la PDA. Este formulario se encuentra en la página HTML ‘CambiarPar.html’. En el POST del formulario aparece la URI ‘/servlet/CambiarPar’. Este recurso será declarado off-line para el servidor, con lo cual cada vez que se haga un POST sobre el mismo, éste será almacenado localmente, permitiéndose la sincronización posterior del mismo mediante la SyncTool.
Figura 5.1 .- Estructura de la aplicación ejemplo
Configuración de la aplicación ejemplo
Para poder declarar el recurso ‘CambiarPar’ como offline se necesita una configuración en el fichero config\server.xml como la de abajo.
Figura 5.2 .- Configuración del server.xml en la aplicación ejemplo
<?xml version="1.0" encoding="ISO-8859-1"?>
<server>
<port>8081</port>
<docbase>webapps</docbase>
<offline-dir>offline</offline-dir>
<log-dir>log</log-dir>
<web-app>
<offline-resource>
<resource-name>CambioDePar</resource-name>
<resource-uri>http://escanda:9966/GDialogo</resource-uri>
<success-page>/CambioOK.html</success-page>
</offline-resource>
</web-app>
</server>
Ejecución de la aplicación ejemplo
Para ejecutar la aplicación ejemplo primero se debe arrancar el servidor local mediante el enlace directos correspondientes (ver Figura 4-1: Accesos directos). Una vez arrancado debe ejecutarse un explorador en la PDA contra la dirección http://localhost:8081. Una vez hecho lo anterior aparecerán pantallas como las de las figuras siguientes.
Figura 5.3 .- Menú inicial de la aplicación
Figura 5.4 .- Cambio de par
Ficheros XML con formularios almacenados
Una vez realizado un cambio de par puede comprobarse que los ficheros XML con el contenido de los formularios se han almacenado en el directorio ‘offline’ de la instalación del servidor local. En la figura se ve que se ha creado un directorio ‘CambioDePar’ y que se han creado varios ficheros XML con los datos de los distintos formularios rellenados. Cada fichero XML tiene un sufijo que indica el timestamp en el que se rellenó el formulario y fue guardado el XML.
Figura 5.5 .- Formularios guardados localmente
Sincronización de formularios
La sincronización de los formularios deberá hacerse con la herramienta de sincronización que se arranca desde los accesos directos (ver Figura 4-1: Accesos directos).
Instalación y Configuración detallada con Mysaifu JVM
El ejemplo está basado en el emulador Windows Mobile 5.0.
Software necesario
- Mysaifu JVM
- PDA Web Server (Enlace a la nigthly build, versión probada y con bugs reparados frente a la versión 3.2)
- Windows Mobile 5.0 (Standalone Emulator)
Instalación
- Instalar máquina virtual Mysaifu en la PDA.
- Copiar el fichero cab en la carpeta 'Program Files' de la PDA.
- Ejecutar dicho fichero desde el emulador.
- Se habrá creado una carpeta con el nombre 'Mysaifu JVM' si la instalación ha sido satisfactoria.
- Instalar PDAWebServer
- Crear carpeta 'Micro' bajo el directorio 'Program Files'.
- Copiar todo la estructura de ficheros del PDAWebServer en la carpeta recientemente creada.
Estructura de ficheros del PDAWebServer
Configuración y ejecución del microwebserver
- Arrancar la interfaz de la máquina virtual Mysaifu.
Figura 6.1 .- Interfaz Mysaifu
- En el campo name se ha de introducir la clase principal del microwebserver la cual es:
org.morfeo.mws.Startup
- Pulsar el botón Options... -> Se abrirá una nueva ventana donde se deberá configurar las librerías que conformorán el CLASSPATH.
Figura 6.2 .- Configuración CLASSPATH y directorio actual
- La ruta a añadir a la CLASSPATH es la siguiente:
\;\My Documents;\Program Files\Micro\lib\pdawebserver.jar;\My Documents;\Program Files\Micro\lib\mjasper-runtime.jar;\My Documents;\Program Files\Micro\lib\mws-util.jar;\My Documents;\Program Files\Micro\lib\servlet.jar;\My Documents;\Program Files\Micro\lib\kxml2-2.2.2.jar
- Configurar el directorio actual (instalación del microwebserver):
\Program Files\Micro
- Antes de ejecutar grabar los cambios actuales
File -> Save As...
Figura 6.3 .- Guardar cambios recientes
- Seleccionar Show console para avisar de posibles errores en el momento de arrancar el microwebserver.
- Pulsar el botón Execute.
Figura 6.4 .- Microwebserver arrancado
- Comprobar que la aplicación Web funciona. Abrir navegador e introducir la URL http://localhost:8081.
Figura 6.5 .- Aplicación Web
Configuración y ejecución de SyncTool
- Arrancar la interfaz de la máquina virtual Mysaifu (ver Figura 6.1).
- En el campo name se ha de introducir la clase principal de la herramienta de sincronización:
org.morfeo.mws.sync.SynchronizerStartup
- Pulsar el botón Options... -> Se abrirá una nueva ventana donde se deberá configurar las librerías que conformorán el CLASSPATH.
Figura 6.6 .- Configuración CLASSPATH y directorio actual
- La ruta a añadir a la CLASSPATH es la siguiente:
\;\My Documents;\Program Files\Micro\lib\synctool.jar;\My Documents;\Program Files\Micro\lib\mws-util.jar;\My Documents;\Program Files\Micro\lib\kxml2-2.2.2.jar
- Configurar el directorio actual (instalación de la herramienta de sincronización):
\Program Files\Micro
- Antes de ejecutar la herramienta grabar los cambios recientes
File -> Save As...
Figura 6.7 .- Guardar cambios recientes
- Seleccionar Show console para avisar de posibles errores en el momento de ejecutar SyncTool.
- Pulsar el botón Execute.
Figura 6.8 .- SyncTool arrancado
