Los desarrolladores de aplicaciones móviles independiente de la tecnología que utilicen manejan el concepto de computación ocasionalmente conectada (OCC).
Las aplicaciones OCC tienen que tomar una decisión de arquitectura muy importante para enfrentar este problema: Data-Centric y Service-Oriented.
Las aplicaciones que utilizan la estrategia de Data-Centric tienen una base de datos relacional (RDBMS) en el cliente. Las capacidades de esta base de datos son utilizadas para propagar los cambios en los datos locales al servidor, administrando el proceso de sincronización, detectando y resolviendo los conflictos de datos.
La segunda aproximación es utilizar Service-Oriented, que almacena los datos locales en mensajes que son puestos en colas cuando el cliente está fuera de línea. Después que se restablece la conexión esos mensajes son enviados al servidor para ser procesados.
A continuación se desarrollan ambas aproximaciones.
Cuando se usa está aproximación, el servidor publica los datos a ser utilizados y los clientes se suscriben a los datos que necesitan, entonces obtienen una copia de los datos que necesitan antes de desconectarse.
Mientras la aplicación esta fuera de línea, los cambios son hechos sobre los datos locales mediante la interacción de la aplicación con sus datos locales.
Cuando el dispositivo vuelve a conectarse, la base de datos local propaga los cambios realizados a los datos locales. También, los cambios hechos en el servidor central son propagados hacia el cliente.
Cualquier conflicto ocurrido durante la fase de unión de los datos es manejado por el motor de resolución de conflictos, en base a reglas. Estas reglas son implementadas tanto en el servidor como en el cliente, de acuerdo a las propias reglas de negocio de la aplicación.
El proceso de fusión (Merge) de los cambios en los datos es conocido cómo Merge Replication. Los cambios pueden ocurrir de manera autónoma tanto el servidor como en el cliente, por esto no se utilizan transacciones ACID. En vez de una transacción, cuando se realiza el merge, todos los suscriptores recibirán el dato cambiado en el publicador.
La principal ventaja de usar esta aproximación es que todo el seguimiento de los cambios está contenido dentro de las funcionalidades de la base de datos. Generalmente, la base de datos incluye código para detectar conflictos de datos a nivel de filas y columnas a nivel de base de datos, códigos de validación y restricciones del dato. En este sentido el único trabajo que se debe hacer es armar el esquema de replicación para la aplicación móvil que optimice la resolución de conflictos y actualización de datos.
En este modelo, la sincronización de los datos es responsabilidad del motor de datos, por lo tanto, no es necesario codificar funcionalidades para ello. Se define que tablas son las que necesitan ser sincronizadas y el motor de datos se encarga de llevar el rastro de los datos, sincronizarlos y resolver conflictos. En este punto, la resolución de conflictos, si los criterios que vienen no son suficientes, pueden extenderse utilizando código.
Por otra parte, al existir una base de datos central, después que los clientes sincronizan los datos, se puede asegurar la convergencia de los datos es completa.
Las desventajas que aparecen al usar este modelo son las siguientes:
- No puede ser usado en dispositivos son base de datos.
- El deploy de las aplicaciones es cliente por cliente, por la configuración de la base de datos.
- El deploy debe ser hecho por un administrador del cliente.
- Cambios en el esquema de la base de datos central afectan todos los clientes.
- Está atada a un motor de datos.
- Si ningún criterio de resolución de conflictos resuelve el problema, este debe ser solucionado por el administrador.
Los escenarios recomendados para usar esta aproximación son:
- Se controlan los dispositivos clientes para la instalación de la DB.
- No se requiere interactuar con múltiples bases de datos.
Ø Se puede sincronizar utilizando HPPTS, VPN o la LAN.
Con esta aproximación, los clientes interactúan con el servidor central consumiendo servicios a través de mensajes definidos. Pueden tener o no un cache de datos local. La ventaja es que no se necesita una base de datos local instalada en el cliente. Esto significa que está aproximación puede ser aplicada a muchos tipos de dispositivos sin las restricciones del uso de un motor de base de datos local.
El uso de está aproximación de servicios es particularmente apropiada cuando las aplicaciones deben operar en ambientes como Internet y Extranet. Esto porque es posible habilitar en el firewall la entrada de las peticiones de los clientes, por ejemplo Web Service.
El uso de servicios permite mantener bajo acoplamiento, lo que significa que puede interactuar con diferentes esquemas de base de datos.
La principal desventaja de está aproximación es que es responsabilidad del constructor del sistema codificar toda la funcionalidad que guarda relación con el modelo transaccional de Store and Forware de mensajes, como también implementar la contención de transacciones cuando el cliente está fuera de línea.
El uso de una aproximación de servicios se desempeña mejor en escenarios en los que la aplicación necesita interactuar con muchos servicios diferentes, provistos por diferentes servidores. Se comporta muy bien con múltiples trasportes, ya que es independiente el mensaje al trasporte usado. Por ejemplo un trasporte es Web Services.
Los escenarios recomendados para usar esta aproximación son:
- Se quiere una solución desacoplada del cliente y servidor.
- Se quiere tener todo el control y flexibilidad sobre la conciliación de los datos.
- Se tiene experiencia en desarrollo de software de infraestructura.
- Se requiere un cliente liviano.
- Existe una arquitectura SOA en la organización dónde instalar el sistema.
- Se requiere funcionalidad específica de negocio, la cual se encuentra en el Back-End.
- Se requiere flexibilidad en los esquemas de bases de datos del servidor.
- La aplicación opera en Extranet o Internet.
Si se quiere desarrollar aplicaciones OCC utilizando una orientación de servicios se deben considerar los siguientes puntos principales:
- Uso de mensajería asíncrona preferentemente.
- Administrar la interacción con la red.
- Data Caching.
- Implementación del mecanismo Store and Forward.
- Administrar los datos y las reglas de negocio para solucionar conflictos de datos.
[1] Smart Client Architecture and Design Guide
..:: Liarjo of Locksley ::.. 