SINCRONIZACIÓN DE DATOS

Los usuarios móviles tienen la comodidad de acceder información desde cualquier lugar y en cualquier momento. Sin embargo, la información que ellos necesitan no siempre puede estar en el dispositivo en el momento que lo deseen.

Por ejemplo, un celular necesita los números telefónicos que pueden estar almacenados en una PDA y esta a su vez necesita los e-mails de los empleados de cierta empresa y que se encuentran en el servidor corporativo. Para lograr que los distintos datos que hay en cada uno de estos elementos puedan intercambiarse se tiene que encontrar una forma de comunicación y de compartición de información. La figura 3.7 describe este escenario, donde los dispositivos móviles se comunican entre ellos y a su vez se pueden comunicar con un servidor de datos y viceversa.

Figura 3.7: Comunicación entre dispositivos y un servidor de datos

Debido a situaciones como la anterior, los usuarios tienen la necesidad de acceder información desde el dispositivo y no simplemente eso, si no, actualizar esa información por medio de una red de conexión. Los usuarios móviles no pueden estar todo el tiempo conectados a la red para acceder a la información y poder actualizarla mientras estén conectados, especialmente cuando se tiene que pagar por el tiempo de conexión o tiempo aire, de manera que, los usuarios desean adquirir sus datos y tenerlos disponibles en su dispositivo aún cuando estén sin conexión. Una vez que los usuarios tengan disponible la información deseada, querrán realizar ciertas acciones u operaciones con esa información, es decir, pueden modificar la información, eliminar parte de ella, agregar nueva información, etc.

De forma periódica, los usuarios móviles se pueden reconectar a la red para enviar los cambios locales, cambios hechos a la información en el dispositivo mientras estuvo desconectado. De igual manera se puede recibir de nuevo información del servidor de datos ya que posiblemente haya cambiado. Este proceso puede acarrear varios conflictos entre las actualizaciones hechas a las dos copias, del dispositivo y del servidor y que de alguna manera se necesitan resolver. A esta serie de operaciones, donde las actualizaciones son intercambiadas y los conflictos son resueltos se le conoce como sincronización de datos [20].

La sincronización de datos entonces es el proceso de realizar ajustes en los datos locales y remotos de manera que queden idénticos. En el caso de los dispositivos móviles, la sincronización se aplica a los datos que se almacenan localmente. La sincronización de datos se realiza mediante un protocolo de comunicación, y define la comunicación del dispositivo móvil con el servidor de datos durante una sesión de sincronización cuando el dispositivo móvil esté conectado a la red. Este protocolo de sincronización debe soportar identificación de registros (datos) y operaciones a realizarse para sincronizar datos locales (en el dispositivo) y remotos (en el servidor de datos) así como la identificación y resolución de conflictos de sincronización. La sincronización debe ser simétrica, es decir, se debe sincronizar los datos del servidor con los datos del dispositivo móvil y de igual manera se debe sincronizar la información de los dispositivos móviles con los datos del servidor. La sincronización se puede realizar con diferentes dispositivos, incluyendo PDA’s, Celulares, Tablet PC’s, Laptop’s y computadoras de escritorio. Un usuario puede

acceder y manipular el mismo conjunto de datos desde diferentes dispositivos. Algunos dispositivos tienen una base de sincronización que les permite una conexión directa para subir y bajar datos del dispositivo a la PC. Sin embargo, esto puede ser que solo soporte el intercambio de información básica como, la información de los contactos, avisos y el calendario de actividades.

Los usuarios de alguna manera desean poder transferir archivos más complejos tales como texto u hojas de cálculo entre distintas máquinas y de manera muy especial a través de distintas aplicaciones y plataformas [16]. Hoy en día muchas aplicaciones necesitan mantenerse actualizadas, algunos ejemplos son: actualizar precios y existencias de productos en un almacén; los cambios hechos de las citas del jefe en la computadora de la oficina necesita almacenarse en el dispositivo. Con la sincronización se puede soportar muchos tipos de datos, incluyendo e-mail, calendarios, información de contactos, bases de datos y documentos en el Web.

En la Figura 3.8 se describen todos los dispositivos móviles (PDA’s, Tablet PC’s, Celulares, Laptops) que pueden ser sincronizados con un servidor de datos que tiene una base de datos. La gráfica muestra que los dispositivos móviles se comunican con una base de datos para mantener la información idéntica entre ellos. Cada uno de los dispositivos tienen una especie de “base de datos” para poder almacenar la información, esta base de datos se almacena en la memoria del dispositivo y es enviada por el servidor.

Figura 3.8 Sincronización de Dispositivos Móviles con una Base de Datos

Remote Synchronization Local Synchronization PDA Data Server BD Laptop Cell Tablet PC

En las bibliotecas digitales personales (PDLib) se puede realizar la sincronización de la información, es decir, se pueden almacenar diversos datos en el dispositivo, desconectarse de la red de forma predecible y realizar algunas operaciones directamente en el dispositivo con la información almacenada (operaciones sin conexión con el servidor). Una vez hechas las modificaciones deseadas, el usuario se puede reconectar al servidor de datos y enviarle la información modificada para que se sincronice con el servidor de datos. Por otra parte el servidor puede tener información que ha sido modificada por el usuario por cualquier medio de acceso, ya sea con el mismo dispositivo móvil o con otros clientes móviles o fijos. De esta manera, la sincronización de una biblioteca digital se puede realizar con los dispositivos móviles.

A continuación se presentan diferentes métodos para sincronizar los clientes móviles con el servidor de datos de PDLib.

ƒ Sincronización de una vía: El servidor de datos envía información al cliente móvil (Figura 3.9). En este escenario el servidor es el dominante y le envía datos al cliente para que lo almacene o actualice en su Base de Datos. En la figura 3.10 se ejemplifica el caso del cliente móvil cuando actualiza la información del servidor de datos, en cualquiera de las dos figuras el servidor se tomó directamente sin embargo en este trabajo de tesis el cliente se conecta directamente al MCM. Aquí el dispositivo es el dominante y le manda al servidor la información que tenga que actualizar.

Figura 3.9: El Servidor de Datos actualiza al cliente móvil mediante el MCM

Figura 3.10: El cliente móvil actualiza al mediante el MCM

ƒ Sincronización de dos vías: En este método el servidor y el cliente se actualizan mutuamente (figura 3.11), de manera que los dos se pasan información para que se actualicen sus Bases de Datos respectivamente.

El enfoque de esta tesis se basa en la sincronización de una vía, primero se da la sincronización del servidor al cliente, donde el servidor (Data Server) actualiza la biblioteca local del cliente móvil enviándole el Skeleton.xml, posteriormente se da la sincronización del cliente al servidor, donde el cliente envía las operaciones offline que se realizaron y almacenaron en el dispositivo al Data Server.

A continuación se describe el proceso general para la sincronización del servidor al cliente y es cuando se obtiene la estructura lógica de la biblioteca digital (Skeleton).

1. En primera instancia, el usuario móvil debe de obtener el esqueleto (skeleton.xml) de su biblioteca, para lograr esto, el usuario primero se autentica como usuario PDLib proporcionando su nombre de usuario y contraseña, el cliente obtiene y almacena el identificador de la biblioteca (LibraryId) en un RMS mediante el mecanismo de almacenamiento del identificador de la biblioteca digital. Todo este proceso se realiza considerando que existe una conexión activa con el MCM.

2. El cliente por la capacidad limitada de ancho de banda necesita que se le envíe el esqueleto por partes o segmentos pequeños, así, le pide al MCM el número de segmentos en que se divide la biblioteca esto lo realiza mediante el identificador de la biblioteca y que el cliente ya tiene almacenado en el RMS LibraryId. El número de segmentos le servirá al cliente para saber en cuantos paquetes o segmentos está dividido el esqueleto

3. El MCM con el LibraryId que le envió el cliente móvil le pide la información de colecciones, metadatos y documentos al Data Server, enviándole como parámetro el LibraryId de la biblioteca que desea obtener la información. Cabe aclarar que esta información es nada mas respecto a nombres e identificadores de colecciones y metadatos de los documentos, de tal manera, que no se pide ningún documento físico de la biblioteca digital.

4. El MCM al recibir la información pedida en el paso 3, genera todo el esqueleto de la biblioteca digital (skeleton.xml) mediante el mecanismo de construcción de la estructura lógica de la biblioteca digital, el MCM lo divide en segmentos o paquetes pequeños y le envía al cliente el número total de segmentos en que se dividió. Esta segmentación del Skeleton se realiza con el fin de que sean paquetes pequeños que se le envíen al cliente y no toda la estructura Cabe mencionar que el mecanismo de construcción de la estructura lógica se realiza cada vez que el usuario móvil hace la petición, es decir, cada vez que se pida el esqueleto de la biblioteca.

5. El cliente al obtener el número total de segmentos de su biblioteca, le va pidiendo al MCM los segmentos de uno en uno, de tal manera que lo va almacenando en un RMS (Skeleton) hasta obtener la estructura completa de la biblioteca digital. Esto lo realiza mediante el mecanismo Library Skeleton Storage.

6. Una vez obtenida la estructura completa, el cliente obtiene del RMS (Skeleton) el documento XML (skeleton.xml) y mediante el mecanismo de construcción de la biblioteca local, parsea el documento y se lo muestra al usuario. El usuario móvil en este momento se puede desconectar del MCM, sin perder la información de su biblioteca ya que la mantiene en su dispositivo. En la figura 3.12 se muestra la secuencia de los puntos 1 al 6.

Figura 3.12: Diagrama de secuencia para obtención del skeleton

A continuación se describe la sincronización del cliente al servidor, es decir, el proceso donde el usuario ejecuta las operaciones offline.

1. El usuario al obtener su biblioteca digital local puede trabajar y realizar operaciones (operaciones offline) con su biblioteca local como si lo estuviera haciendo en línea. Cuando el usuario realiza operaciones offline algunas se almacenan en el dispositivo por medio de un RMS llamado Sync_Commands. Las operaciones que se almacenan en son las que serán enviadas del cliente al servidor para su ejecución posterior, en la seccion 3.7 se presentarán estas operaciones. Este proceso lo realiza el mecanismo de construcción de las operaciones offline.

2. Cuando el usuario así lo desee y tenga conexión activa con el MCM le envía esas operaciones (Sync_Commands.xml).

3. El MCM recibe cada operación y mediante el mecanismo de construcción de las operaciones de PDLib le envía al Data Server las peticiones de ejecución de las mismas. Así, al servidor solo le llegarán las operaciones correspondientes a ejecutar, no tiene que interpretar nada y solamente se limita a ejecutar esas operaciones, tal y como lo hiciera con peticiones en línea por parte de los diversos usuarios.

4. Las operaciones offline se realizan en el Data Server y por lo tanto se reflejan los cambios en la biblioteca digital remota. En la figura 3.13 se muestra la secuencia de los puntos 1 al 6.

Client MCM Data Server

LibraryId LibraryId

Collection/Metadata Information Send Segments Number

Send Segment getLibraryId(user,password) getLibraryId(user,password) getNumSegments(LibraryId) getLibraryInformation(LibraryId) getSegment(num)

Figura 3.13: Diagrama de secuencia para la ejecución de las operaciones offline

Durante el proceso de sincronización pueden ocurrir una serie de conflictos que a continuación se listan. Algunos de estos conflictos no se solucionaron en este trabajo de tesis, ya que se salían de los objetivos del mismo, sin embargo se mencionan posibles soluciones que pueden ser implementados en trabajos futuros.

ƒ Transferencia del Skeleton debido a su tamaño.

Una consideración importante es referente al tamaño del esqueleto, ya que varía de acuerdo al número de colecciones y documentos que contenga la biblioteca. Este tamaño puede ser muy grande y puede afectar durante la transmisión del mismo, debido a que el ancho de banda en el que un dispositivo móvil puede transmitir es muy pequeño, haciendo que la comunicación se interrumpa y no llegue el documento completo al cliente. Así, el esqueleto de la biblioteca se dividió en segmentos o paquetes pequeños para evitar problemas durante su transmisión, este trabajo lo realiza el MCM y es quien le envía los paquetes al cliente. Para determinar el tamaño adecuado de los paquetes se realizaron pruebas con varios tamaños, 500KB, 300KB y 100KB. Estas pruebas consistieron en cambiar la variable para el tamaño de los paquetes y verificar cual es el que menos ocasiona problemas durante la transferencia. Se seleccionaron paquetes de 100KB ya que resultaron los más rápidos y no ocasionaron problemas durante la transmisión.

ƒ Almacenamiento del Skeleton

Si el esqueleto es muy grande puede ser que el dispositivo no logre almacenarlo completamente, por lo tanto al usuario se le presentará el mensaje de “out of memory”. En este trabajo de tesis no se implementó un mecanismo que pueda solucionar este conflicto, ya que no es el objetivo de la misma, sin embargo se puede manejar que el MCM construya “vistas” de acuerdo al tamaño máximo de almacenamiento permitido

Client MCM Data Server

Operaciones Offline

Send Ok Send Ok

sendOperationOffline(operation)

en el cliente, desde luego la información del tamaño máximo permitido lo enviaría el cliente al MCM.

ƒ Conflicto con la transferencia de los paquetes del Skeleton

Durante la transferencia de los segmentos del Skeleton del MCM al cliente móvil pueden perderse algunos de ellos debido a alguna falla en la red o porque el usuario se desconectó, si esto ocurre, el usuario debe realizar de nuevo la petición de todos los segmentos al MCM, es decir empezar de nuevo con la transferencia de todos los paquetes. García [3], implementó un método de descargas parciales, esto permite que se almacenen los segmentos en el cliente, de tal manera, si hay una desconexión con el MCM los paquetes o segmentos faltantes se pierden, pero posteriormente, en una nueva conexión con el MCM el cliente pide los segmentos faltantes, de manera que el MCM envía solamente esos segmentos. El mecanismo que propone García [3] es la solución para no perder paquetes durante la transferencia, sin embargo, en este trabajo de tesis no se implementó debido principalmente al tiempo límite para el desarrollo de este trabajo, por lo que se optó por no almacenar en el dispositivo los paquetes, por lo tanto, el dispositivo lanzará un error si se pierde algún paquete y el usuario debe de realizar la sincronización de nuevo.

ƒ Conflictos en las fechas de sincronización

Durante la sincronización pueden existir conflictos con las fechas. Si un cliente tiene una fecha de actualización en cierta colección y el servidor tiene otra fecha más reciente, la información puede quedar inconsistente. En este trabajo de tesis decidí asignar al servidor de datos como el único que puede cambiar las fechas de actualización y de creación en los elementos. El servidor cuando envía el skeleton al cliente, le envía de igual manera las fechas de actualización de cada elemento, el cliente almacena esta información pero no modifica fechas en caso de alguna actualización en su modo offline. De tal manera que al realizarse una sincronización se le envía al servidor la fecha que el mismo envió con el skeleton. El servidor recibe el elemento modificado y compara las fechas de actualización tanto de la operación como de la que él tiene almacenado, si la fecha que tiene almacenado es una fecha más reciente, entonces, la operación offline se desecha y no la ejecuta. Si verifica que la fecha que tiene almacenada no es más reciente, entonces, se ejecuta la operación offline y la fecha de actualización del elemento será la que tenga el servidor en el momento en que ejecute esta operación. Por lo tanto se toman en cuenta los tiempos de la última actualización, pero siempre del lado del servidor, el cliente no modifica las fechas.

ƒ Optimización

Antes de enviarse las operaciones offline, el mecanismo de optimización (Optimization) verifica que no haya operaciones offline redundantes. Este mecanismo se encarga de verificar cada una de las operaciones offline en el RMS Sync_Commands eliminando aquellas que se pueden anular. Las operaciones que pueden ser eliminadas antes de enviarse al MCM son las siguientes:

Crear colección – Eliminar colección: Estas operaciones se anulan desde el dispositivo si se trata de la misma colección. Con esto se eliminan de igual manera todos los

documentos y colecciones que haya dentro de la colección. Por ejemplo: Un usuario crea una colección llamada “My Collection”, posteriormente decide eliminarla. El cliente elimina tanto la operación de crear colección como la de eliminar colección, así como todas las operaciones que se hayan hecho en esta colección (crear documentos y/o colecciones).

Crear documento texto- Eliminar documento texto: De igual manera estas operaciones se anulan desde el dispositivo si se trata del mismo documento. Por ejemplo: Un usuario crea un documento llamado “My Document”, posteriormente decide eliminarlo. El cliente elimina tanto la operación de crear documento como la operación de eliminar documento antes de enviarse todo el conjunto de operaciones al MCM, de tal manera que esas dos operaciones no se le envían al MCM.

ƒ Conflictos durante la ejecución de las operaciones offline.

Las operaciones se envían de una en una estableciéndose una comunicación de envío y recepción de mensajes entre el cliente y el MCM, así cada vez que se ejecuta una operación correctamente, el MCM se lo notifica al cliente, el cliente elimina de su lista (del Sync_Commands) esa operación, y le envía la siguiente operación al MCM. Si ocurre una falla en la ejecución de alguna operación se le notifica al cliente y la operación se intenta mandar de nuevo, y eso se realiza cada vez que la operación falla. Si se pierde la conexión con el MCM y no se logra restablecer, el cliente no obtendrá respuestas de parte del servidor sobre si se ejecutaron correcta o incorrectamente las operaciones, en este caso consideré en esta investigación que el cliente intente de nuevo mandar las operaciones cuando se tenga la conexión activa, las operaciones que no se ejecutaron permanecen en el cliente de tal manera que al obtener de nuevo una conexión con el MCM se enviarán al servidor siempre y cuando el cliente así lo disponga.

El proceso general de la sincronización se describió en la sección anterior y como se comentó este proceso es manual, el usuario móvil decide realizar la sincronización del servidor al cliente y también decide cuando realizar la sincronización del cliente al servidor. Estas sincronizaciones aunque se mencionan que es del servidor al cliente o del cliente al servidor cabe recordar que se realiza con el MCM como intermediario entre estos elementos.

En el apéndice A y B se describen los métodos con sus argumentos que se desarrollaron