El Broker de Seguridad supone la implantación de un canal de comunicaciones seguro y fiable entre los terminales con aplicaciones XOne y el servidor central, proporcionando una pasarela segura de recursos aislados. De ese modo, todas las transmisiones efectuadas bajo el protocolo de comunicaciones empleado por XOne ven incrementada su seguridad, aportando una protección contra ataques vía web a los servicios centrales.
El uso de este BROKER se compagina con los siguientes módulos:

MÓDULOS
Servidor de Réplica, tanto para datos como para ficheros.
Sistema de actualizaciones, XOneLive Plus, para instalación y actualización de aplicación y base de datos.
Integración con utilidades de conectividad online: JSON, XML, XMLRPC, SOAP, WSDL, SOA.
Compatible con empleo de Sistema PUSH.


Su empleo, combinado con los elementos de seguridad del cliente, proporciona un plus de seguridad a la arquitectura XOne, evitando la exposición de cualquier componente del sistema de cara al exterior. Dicho sistema evita suplantación de identidad y ataques por denegación de servicio. Para realizarlo, se envían cabeceras distintas para cada comunicación, donde se configura una trama única de identificación de mensajes.

Una vez que una aplicación se monta con el Broker, se consigue que todas y cada una de las comunicaciones entre los dispositivos móviles y el servidor central sean mediante WebSocket o Rest. El uso de una u otra forma, que describiremos más adelante, se realiza mediante la configuración de los módulos de los dispositivos.
Esas comunicaciones, solo están habilitadas bajo el protocolo de SSL, lo que permite el cifrado de los datos transmitidos.

Las comunicaciones utilizadas en este entorno, aun disponiendo de ese Broker intermedio, son bastante ágiles, mejorando el rendimiento del sistema de proxys desarrollado con anterioridad por XOne. Estas mejoras convierten en obsoleto el XOne Proxy.
Este sistema de Broker permite el anidamiento de tantos niveles como consideren necesarios. Sin embargo, el empleo de varios de ellos repercute en la velocidad del sistema.




La implantación del Broker de Seguridad aporta diferentes protecciones, en función del módulo con el que esté realizando el intercambio de información:


Servidor de Réplica


Doble encriptación de las comunicaciones, a través de las propias del protocolo de XOne y posteriormente gracias al empleo de certificado SSL.
El dispositivo móvil no dispone de la ruta real de donde se encuentra instalado el Servidor de Réplica. Éste es así por la siguiente configuración:
- El dispositivo dispone de un Identificador de Mapeo.
- La ruta real del servidor de réplica, solo está disponible en el Broker.
- El Identificador de Mapeo debe estar incluido en el sistema Broker, enrutando las comunicaciones al sistema correspondiente.
- Un único Broker permite emplear infinitos entornos XOne, si se considera necesario, o bien establecer un Broker por cada entorno, aunque no sería necesario.


Sistema de Actualizaciones, XOneLive Plus


Encriptación de comunicaciones vía SSL.
Se independiza la infraestructura de datos y de ficheros del servidor central.
Independencia del sistema de actualizaciones con respecto al servidor de comunicaciones y gestor de datos. Se independiza también la infraestructura de carpetas necesarias para su funcionamiento.



Integración con utilidades de Conectividad Online



Doble encriptación de las comunicaciones, a través de las propias del protocolo de XOne y posteriormente gracias al empleo de certificado SSL.
Seguridad por mantenimiento de sesión. Se necesita un token de sesión que envía el servidor cuando se autentifica y los Framework de los dispositivos la mantienen, para las diferentes comunicaciones entre ellos.



Compatible con empleo de Sistema PUSH


Es posible establecer funcionalidades Push empleando el broker de seguridad.




A la hora de poner en marcha el Broker, podemos optar por dos opciones: WebSocket o Rest.

A continuación, vamos a describir los factores a tener en cuenta para su implantación:

Es necesaria la incorporación de una nueva máquina, que será la que aloje este nuevo servicio. Dicha máquina, debe disponer de sistema operativo Windows Server 2012 o superior. Un único Broker de Seguridad puede dar soporte a varios entornos. También sería posible establecer un bróker por cada entorno, según criterio del cliente.
Si optamos por instalar el servicio con configuración WebSocket, en comparación con Rest:
- dispondremos un mejor rendimiento.
- aumento de la velocidad en las comunicaciones que el entorno montado sobre Rest.
- reducción del overhead de dicho sistema.
- reducción del consumo de datos en los dispositivos móviles.





Un posible diseño de la arquitectura a implementar sería el siguiente:


Las características de esta arquitectura son:

No es necesario disponer de una VPN en los dispositivos móviles a nivel de las tarjetas de datos.
Todas las conexiones entre el dispositivo móvil y la Plataforma Central se realizan por un único puerto.
Los dispositivos móviles se conectan a un servidor de comunicaciones, en el que estará implantado el Broker de Seguridad. Este servidor es independiente del Servidor de Datos y del Servidor XOne (elementos habituales de la arquitectura XOne), y será el encargado de encauzar el tráfico entre el exterior y los diferentes servicios.
El sistema se podrá montar con tantos Broker como se requiera entre el servidor de comunicaciones y el Servidor de XOne.
Las comunicaciones del XOneLive en esta arquitectura, también se realizará con el protocolo mejorado, para lo que es necesario implantar el módulo de XOneLive Plus.
Al sistema de comunicaciones se le puede añadir el uso de certificado X509, tal y como explicamos más adelante.





Los requisitos necesarios para la implantación del Broker de Seguridad son los siguientes:

Windows Server 2012 64 Bits
Microsoft .NET Framework 3.5 con sus Service Pack
Microsoft .NET Framework 4.0 con sus Service Pack
Microsoft .NET Framework 4.5 con sus Service Pack
Internet Information Server 7.0 o superior
Protocolo WebSocket instalado sobre IIS
Los requisitos hardware son los recomendados por el sistema operativo



Las ventajas de este sistema son varias:

Doble encriptación de las comunicaciones, por un lado las propias del protocolo de XOne y posteriormente las del certificado seguro SSL.
El dispositivo móvil no dispone de la ruta real de donden está instalados los componentes de la plataforma únicamente tendrán acceso al bróker, consiguiendo aislar el sistema de actualizaciones, de réplica y de consultas online utilizando en éste ultimo caso XOneJSONSQLSecure.




La réplica de datos es una de las funcionalidades más atractivas de la tecnología XOne, ya que permite que las aplicaciones móviles funcionen independientemente de la existencia de enlaces de comunicación entre los terminales y los centros de datos (servidores).

Es importante tener en cuenta que una de las principales necesidades de un sistema de movilidad es la comunicación con la central, ya que los datos introducidos en los terminales tienen que ser incorporados a los sistemas de gestión. De igual manera los terminales deben recibir datos de la central, de forma que los operadores móviles se mantengan actualizados.

Un ejemplo común es el vendedor que tiene que enviar sus pedidos a la administración y recibir las tarifas y clientes con los que operar, sin esta transmisión de datos, las aplicaciones de movilidad tendrían poco sentido en los sistemas empresariales.
Es en este lugar en el que la réplica ocupa su lugar, ya que permite que esta comunicación se efectúe de manera asincrónica, segura y desatendida. Cuando hay comunicaciones, la réplica transmite y recibe datos. Cuando no la hay, la réplica busca formas de conectarse para comunicar con la central. Mientras tanto, las aplicaciones pueden seguir funcionando con las copias locales de los datos, por lo que los usuarios pueden continuar trabajando, aunque no haya enlace de datos.

Para intercomunicar los distintos dispositivos que se estén utilizando en un proyecto, Android, iPhone, PC, Windows Mobile,… se necesita una herramienta que permita mantener la integridad referencial de todos los datos de forma transparente. El sistema de réplica de datos de XOne, permite que este proceso se pueda efectuar sin que las relaciones entre registros en cada copia de la base de datos pierdan coherencia. Desde el punto de vista de la réplica de datos XOne, lo que se maneja son copias de datos que representan subconjuntos “equivalentes” de la base de datos central (que contiene todos los datos).
Esta equivalencia lo que implica es que los datos tienen que “significar” lo mismo para los usuarios, estén viendo la copia que estén viendo, aunque internamente los datos no se representen de forma exactamente igual, debido a las diferencias de sistemas de bases de datos empleados, así como al hecho de que las copias de los dispositivos no tienen por qué contener todos los datos que existen en la central.

La réplica de datos XOne es un sistema cliente/servidor. La base de datos central es gestionada por una o varias aplicaciones que forman el servidor de réplica. En cada terminal conectado al sistema se ejecuta un cliente de réplica. Para cada una de las Plataformas se ha desarrollado un cliente específico, que explota adecuadamente las posibilidades de entorno de ejecución. Mediante un protocolo propietario, sobre TCP/IP, para el intercambio de comandos e información, todo ello cifrado en varios niveles, los sistemas son capaces de sincronizar sus bases de datos. De este modo, los clientes envían al servidor la información generada por sus usuarios, recibiendo, a su vez, datos según los criterios especificados para cada uno de los clientes de réplica. Además, en la base de datos central se almacena todo el histórico de operaciones enviadas y recibidas por cada uno de los clientes.

La administración de la réplica se puede efectuar de manera centralizada mediante la gestión de tablas de configuración que permiten manipular cada uno de los clientes, decidir qué datos se envían a cada uno, bloquear el acceso, controlar la cantidad de operaciones por lote, etc. Las tablas de réplica del servidor permiten también monitorear el estado de las conexiones de cada uno de los clientes, de manera que un administrador puede conocer en todo momento qué clientes están atrasados, desde cuándo no se conectan, si hay errores en su terminal o en los datos que ha enviado, etc.

El sistema de réplica de datos también permite conectar otras copias de la base de datos central sin selectividad. Estas copias totales funcionan también con clientes de réplica y pueden utilizarse para enlazar sedes de una misma empresa, para mantener servidores de datos locales que no carguen la base de datos central o para mantener una copia separada de la base de datos en una máquina geográficamente alejada del servidor central a modo de resguardo o copia de seguridad. Todo este sistema funciona de manera automática, por lo que se pueden mantener copias de los datos prácticamente en tiempo real.

Para distribuir geográficamente la transmisión de datos se puede distribuir el servidor de réplica en varios nodos en forma de estrella. De esta manera los dispositivos de una zona pueden conectarse a una máquina que a su vez centraliza la subida de esta información hacia la central utilizando un enlace más potente y le quita trabajo al servidor central, ya que la selectividad de los clientes de cada región se ejecutaría en su servidor particular y no en el central. Este mecanismo también permite que al fallar los enlaces en el nodo central las regiones puedan seguir enviando sus datos contra sus propias sedes. Este tipo de topología se denomina réplica multimaster.



El servidor de réplica es el encargado de preparar los datos para que los clientes puedan recibirlos. También se encarga de aceptar los envíos de datos de los clientes para colocarlos en las bases de datos centrales.


Consiste en uno o varios servicios que realizan las siguientes tareas:

Aceptar solicitudes de los clientes. Las solicitudes de clientes son comandos de envío y recepción de datos, configuración y administración, etc. Los comandos se reciben vía TCP/IP
Gestionar la selectividad de los clientes. Las tablas de selectividad contienen las reglas que deben cumplir las operaciones para ir a cada cliente de cada base de datos
Procesar los datos que envían los clientes para insertarlos en las bases de datos


Es importante tener en cuenta que el servidor de réplica puede atender varias bases de datos a la vez, una para cada aplicación que tenga la empresa. De esta manera se pueden movilizar diferentes aplicaciones dentro de una misma empresa empleando el mismo servidor de réplica. Cada base de datos tiene su propio juego de clientes y funciona de manera independiente a las demás. En caso de que haga falta una solución escalable, el administrador del sistema puede optar por separar las bases de datos en servidores de réplica diferentes con muy pocas modificaciones a la configuración de los servidores


Para cada una de estas actividades se pueden configurar módulos de software (servicios) diferentes, lo cual mejora considerablemente la respuesta del servidor ante una carga mayor. Las configuraciones simples emplean un solo servicio para efectuar todas las tareas. Cuando la carga del servidor aumenta se pueden separar los componentes de forma que estos se repartan dicha carga.

Interconexión de distintos sistemas de base de datos, instalados en servidor o cliente de réplica, según el dispositivo a utilizar


Para cualquier aplicación, es posible tener múltiples sistemas de base de datos coexistiendo en el mismo desarrollo. Aunque el sistema central tuviese un motor de base de datos, como pueda ser Oracle, los clientes de réplica no están obligados a usar este mismo motor de base de datos para poder trabajar.


Este sistema heterogéneo permite que en los servidores se puedan instalar bases de datos potentes capaces de gestionar una gran cantidad de información mientras que los dispositivos móviles se benefician de pequeños motores de bases de datos que consumen poca memoria y procesador.

En aquellos casos en que el cliente disponga de CPDs o bases de datos ya instaladas y en funcionamiento, se puede beneficiar de estas infraestructuras para colocar allí los repositorios de réplica sin tener que duplicar ninguna estructura logística ni administrativa, lo cual hace que la solución sea muy atractiva en cuanto a costes de explotación y administración.
De este modo, es posible plantear un desarrollo que presente una arquitectura similar a la siguiente:


Selectividad


Cuando se diseñan los criterios de uso de una aplicación móvil, lo normal es que cada terminal no tenga la información completa del sistema para poder desempeñar las tareas para las que se ha desarrollado. De este modo, es posible que todas las necesidades estén ligadas a criterios que dependen del usuario asociado al terminal o de la región en la que actúa.

Para poder satisfacer esta necesidad se emplea un sistema basado en condiciones SQL que permite acotar la información que ha de enviarse a cada uno de los dispositivos. Estas condiciones componen lo que se denomina “selectividad”, y se establecen para cada una de las entidades que empleadas, que pueden haber sido modeladas en una o varias tablas en la base de datos central. Es necesario destacar que las condiciones son específicas para cada uno de los clientes de réplica, aunque generalmente tienen una estructura similar para todos los clientes, cambiando solamente los valores de aquellas variables que deciden el destino de las operaciones.

Sin embargo, no es obligatorio que así sea, puesto que diferentes clientes pueden tener diferentes condicionantes, consecuencia del tipo de terminal que empleen y de las limitaciones que pueda tener cada uno de ellos; véase por ejemplo la comparación entre un terminal Blackberry y un PC. Incluso para terminales similares, es posible que los perfiles de usuario sean diferentes, y por tanto los requerimientos dentro de la aplicación; por ejemplo, las necesidades de un usuario auto-ventas nada tienen que ver con las de un director comercial que controla dichas ventas.


Actualmente existen dos modelos diferentes para el procesamiento de selectividad:


SELECTIVIDAD EXTERNAEl componente servidor realiza el procesamiento masivo de la información por bloques de tamaño parametrizable. Requiere un mayor empleo de recursos del servidor de réplica que el sistema interno, pero resulta más fácil de implementar, ya que no requiere ningún tipo de trabajo en el servidor de base de datos.
SELECTIVIDAD INTERNAEste modelo, muy similar al anterior, hace uso del potencial del gestor de base de datos, integrando en él todos los procesos de cálculo de selectividad, en lugar de dejar estas tareas a una aplicación externa. Con ello se consigue un rendimiento más óptimo puesto que es el propio motor de base de datos el que realiza las tareas.



Mantenimiento de Integridad


Para lograr un funcionamiento más eficiente de las aplicaciones, XOne en sus diseños emplea relaciones entre tablas mediante IDs autonuméricos. Una vez que se limitan los datos a enviar a los clientes de réplica como consecuencia de la selectividad, las relaciones entre dichas tablas no tienen por qué mantener esos mismos valores de ID. Para resolver este problema, XOne dispone de un sistema que permite generar un identificador único de registro dentro de todo el sistema.
Este identificador será el que permitirá, mediante el empleo de un mecanismo de resolución de relaciones, establecer los enlaces correctos en todos los terminales, manteniendo así la integridad de los datos.

El procesamiento de estos enlaces se efectúa de manera automática y totalmente transparente, por lo que al desarrollar la aplicación no es necesario tenerlo en cuenta. Esto permite beneficiarse de la eficiencia de los enlaces auto-numéricos sin preocuparse por los problemas de coherencia entre bases de datos diferentes.

Seguridad en las transmisiones


Para que el cliente de réplica pueda iniciar una sesión de comunicación con el servidor, XOne dispone de un protocolo binario propio. Todo el intercambio de comandos y datos cliente-servidor se realiza por defecto mediante un cifrado simétrico que depende del sistema en que se ejecute el servidor. Las claves para efectuar estas operaciones se intercambian entre el cliente y el servidor en el momento de iniciar la sesión y se generan aleatoriamente para cada nueva sesión.
Los algoritmos de criptografía que se emplean son los mismos en todos los sistemas, pero en general suele variar la forma en que se derivan las claves, la cantidad de bits empleada para efectuar las funciones criptográficas, etc.

Es por esto que el cliente lo primero que tiene que hacer cuando comienza una sesión se réplica es identificar el servidor. Existe un comando para esto, que le indica al cliente qué tipo de servidor es el que está atendiéndole. Cuando esto se determina, el cliente puede conocer primeramente si dispone de un mecanismo de generación de clave adecuado para ese servidor, y posteriormente genera una clave de sesión adecuada. Con esta clave se procede a efectuar el inicio de sesión, durante el cual se intercambia la clave aleatoria del cliente con la del servidor.

A partir de este momento, todos los comandos se enviarán cifrados con esta pareja de claves. Para el intercambio de las claves simétricas se puede emplear una pareja de claves RSA, o un certificado X509 dependiendo de la licencia de servidor adquirida por el usuario. El algoritmo de criptografía y la longitud de clave también dependerán del sistema operativo y de la licencia adquirida.

Cuando un cliente necesita un algoritmo criptográfico que no está disponible en el servidor, la réplica no puede iniciar sesión. Para los entornos que requieran un mayor nivel de seguridad, el cliente y el servidor se pueden configurar para que regeneren las claves de sesión (rekeying) de manera periódica y obliguen a efectuar un nuevo intercambio de clave, de forma que se dificulte el análisis criptográfico del flujo de datos.

Cuando un cliente posee varios sistemas criptográficos a su disposición buscará emplear el más seguro de los que comparta con el servidor, por lo cual siempre se usará el sistema más restrictivo posible dado cualquier combinación de cliente y servidor. Mediante este mecanismo de intercambio de “capacidad” criptográfica se establece un mecanismo que permite evolucionar sin necesidad de parar todo el sistema para actualizarlo, lo cual minimiza los costes administrativos.

Como el servidor de réplica se puede colocar detrás de un proxy HTTP, además de la criptografía propia del sistema XOne se puede utilizar un canal HTTPS para el envío de los datos, de forma que estos viajarían por un canal SSL además de estar cifrados usando la criptografía propia.

Además de este mecanismo, el cliente puede optar por permitir el acceso a su servidor solamente a través de una VPN o una red IPSec, por lo que además de los dos métodos anteriores, la información viajaría de forma cifrada por la red virtual, con lo que se tendrían tres niveles concurrentes de cifrado en la información del cliente, de los cuales al menos dos están totalmente en manos del administrador del sistema, lo cual lo hace altamente confiable para aquellas aplicaciones en las que se necesita un nivel de seguridad elevado.
Los clientes Blackberry poseen además un nivel de seguridad propio en su red privada, tenga o no una infraestructura BES.


Clusterización


Los proyectos que tienen una cantidad muy grande de terminales de réplica o que procesan una cantidad muy grande de datos se pueden beneficiar de la posibilidad de repartir el trabajo entre componentes separados. En caso de que incluso así las tareas sean demasiadas para una sola máquina servidora, se pueden separar estos componentes en máquinas diferentes, de forma que cada una de ellas realice una tarea distinta.

Incluso se pueden tener varias máquinas repartiéndose la misma actividad (i.e. Atendiendo solicitudes de clientes) de forma que cuando la carga aumente la respuesta a los clientes de réplica no sufra degradación por exceso de carga en el servidor.


Balance de carga


Si se puede disponer de varios servidores para alojar una aplicación, se puede optar por el uso de este módulo para controlar la carga de trabajo de cada uno de ellos. Así, el esquema general sería similar al de la siguiente imagen.


Servidores de réplica en entornos de nube


Las soluciones en forma de nube permiten disponer de entornos de alta fiabilidad, escalabilidad y redundancia a precios muy convenientes. XOne dispone de componentes que pueden ejecutarse en estos entornos aprovechando su conectividad para evitar al cliente final los costes de mantenimiento de hardware y software asociados a las máquinas servidoras.

También le permiten a un cliente beneficiarse del entorno adicional de seguridad que ofrece la nube. Los clientes de réplica no necesitan conocer que están conectándose a un servidor en la nube, por lo que el sistema se puede desarrollar en un entorno local de pruebas y desarrollo y posteriormente publicarse en la nube o contratarse a un proveedor sin necesidad de cambiar nada.

Réplica Documental


Transferencia de ficheros e imágenes. Este mecanismo permite que determinados campos de la base de datos se utilicen como referencias a archivos que se transmitirán entre el cliente y el servidor. Opcionalmente estos archivos se le envían también a los clientes de réplica, en función del diseño que se genere para la aplicación.
Los diferentes frameworks pueden emplear estos ficheros para mostrarlos al cliente o para otras tareas relacionadas con el funcionamiento de las aplicaciones. Para ello se han creado tipos especiales de campos que se muestran de forma diferente a los registros convencionales de datos.
También se pueden emplear estos archivos en scripts.

La transmisión de ficheros prima la integridad de información sobre la velocidad de transferencia, teniendo en cuenta que en muchos casos la transmisión puede verse afectada por la línea, la falta de cobertura o incluso la interrupción del servicio durante un tiempo considerable. Por tanto se prioriza el envío de datos y el envío de ficheros se subordina a la disponibilidad de ancho de banda y procesador en el dispositivo.

Las dimensiones de los bloques se calculan teniendo en cuenta dicha disponibilidad de comunicaciones, de forma que la cantidad de retransmisiones sea mínima y que en caso de caerse la transmisión no se pierda el tiempo y cuota de datos empleado hasta el momento volviendo a comenzar el envío. Es importante recordar que la mayoría de los planes de datos tiene un techo en el volumen de información a transmitir, por lo que cuanto menor sea la cantidad de información retransmitida como consecuencia de las caídas o fallos de enlace, más eficientemente se explotarán los planes de datos de los usuarios finales.

Debido a que se utiliza el mismo canal de réplica de datos para el envío de bloques de ficheros, este se hace empleando los mismos protocolos de seguridad, por lo que se puede transmitir información sensible como documentos anexos a la aplicación (i.e. fotocopias de documentos de identidad, tarjetas sanitarias, etc.).

Resolución de Conflictos


Los conflictos de datos ocurren cuando dos o más terminales diferentes intentan acceder al mismo registro en copias diferentes de la misma base de datos. Este tipo de problema puede ocurrir en cualquier sistema de réplica que mezcle datos (los sistemas de publicación/suscripción no tienen este tipo de dificultad, pero no serían apropiados para muchas aplicaciones de movilidad), pero en el caso de sistemas asincrónicos como el que emplea XOne, es mucho más crítico, porque los conflictos no pueden resolverse en tiempo real o mediante un sistema de transacciones distribuidas.

La réplica de datos XOne emplea un sistema de prioridades y de control de tiempo para resolver los conflictos. Es importante tener en cuenta que cuando las operaciones que son problemáticas no afectan a los mismos campos del mismo registro el sistema no las considera conflictos, por lo que no solo se logra una mayor eficiencia, sino que se evita perder modificaciones debido a conflictos.

A esto contribuye la forma en que la maquinaria XOne genera las actualizaciones de datos, replicando de forma incremental solamente aquellos cambios en aquellos campos en que hayan ocurrido y no mediante el envío de registros completos. A la larga la única forma de evitar que los conflictos afecten el sistema y demoren los procesos de réplica es efectuar un diseño correcto de las aplicaciones.
Este tipo de conocimientos se ofrece en los cursos de formación que ofrece XOne como parte del entrenamiento del personal encargado de diseñar aplicaciones de movilidad.

Registro de Operaciones (log)


Se pueden establecer diferentes niveles de traza de los procesos que genera el servidor de réplica, desde niveles básicos, que registran solo los errores, hasta los más detallados para efectuar estudios de carga, optimizaciones de eficiencia, etc.

Los registros de operaciones se pueden escribir en la localización que el usuario o el administrador decida y se particionan de forma que puedan ser manejables en caso de necesitarse para algún análisis. Los logs son diarios y están separados por base de datos, por lo que para cada aplicación se puede tener un nivel de log diferente, evitando que se afecte el rendimiento de las bases de datos que estén en producción por parte de otras que estén en desarrollo o en pruebas.



La Plataforma dispone de un protocolo propio para el envío y recepción de la información entre los dispositivos móviles y la parte servidora.

Sus características principales son:

CARACTERÍSTICAS
COMUNICACIÓN DESATENDIDA El usuario de la aplicación móvil no tendrá que forzar en ningún momento los mecanismos de sincronización. Este proceso puede llegar a ser totalmente transparente al usuario, de modo que ni siquiera sea consciente de él. Esto no impide que se tenga acceso a los controles del servicio de réplica para comprobar su estado, forzar las comunicaciones o modificar su comportamiento. Estas actividades de administración están sujetas a permisos definidos por los administradores del sistema.
SEGURIDAD EN LAS COMUNICACIONES Aunque el sistema pueda trabajar de forma local, independientemente de que exista conectividad, una vez que se dispone de ella, se gestiona el envío y recepción de información. Los procesos de sincronización están protegidos contra posibles pérdidas de conexión, de modo que se pueda garantizar la integridad de la información. Además, en el caso de que la conexión se interrumpa, al iniciarla nuevamente la transferencia continuará desde el punto en el cual se obtuvo confirmación de transmisión desde el servidor. Por tanto, aunque haya pérdidas de conexión, los mecanismos de sincronización permiten no reiniciar el proceso completo, garantizando la seguridad y eficiencia en los intercambios de información. Tanto el cliente como el servidor están preparados para que estos posibles cortes de comunicación no afecten la integridad de los datos (registros perdidos, duplicados, etc.)El sistema prioriza la integridad de la información ante la velocidad de envío, con lo que cualquier optimización de velocidad está hecha de manera que se subordine a la seguridad de no perder nunca un dato.
TAMAÑOS DE BLOQUE VARIABLES En función del diseño de aplicación, tipo de terminal o incluso el canal de comunicación empleado para el proceso de réplica, es posible modificar los tamaños de bloque que se intercambian entre el cliente y el servidor. Además, es posible establecer valores distintos para los ciclos de envío y recepción de datos. Este factor ha de tenerse en cuenta cuando se trabaja en entornos heterogéneos, ya que es posible optimizar los tiempos empleados para sincronizar cliente y servidor. Este aspecto permite no penalizar a los usuarios que disponen de mejor conectividad, ajustando el proceso con un menor tamaño de bloque, para favorecer a los terminales que dispongan de un modem de menor velocidad o una zona de peor cobertura de datos, ya que se reducen los tamaños únicamente para esos terminales. Así, por ejemplo, los tamaños definidos para un cliente de réplica que conecta mediante red local o ADSL pueden ser sensiblemente mayores que los de un terminal que, aun disponiendo de conectividad 3G, se encuentre en una zona donde el tipo de cobertura no le permita pasar de una conexión GPRS. En las Plataformas que lo permiten, los clientes de réplica pueden optar por cambiar el tamaño del bloque dinámicamente en función de la respuesta del canal de datos. Esto permite enviar una cantidad mayor de información cuando el canal está más desocupado o tiene mejor cobertura y reducir el tamaño de los paquetes cuando hay poca cobertura o la red falla más, de forma que aunque la réplica funcione más lentamente, cuando sea necesario retransmitir, la cantidad de datos comprometida sea menor.
CONMUTACIÓN INTELIGENTE DE REDES Es posible configurar la conmutación entre diferentes redes en función de las necesidades propias de la aplicación. Así, por ejemplo, para una aplicación de logística, en la que se genera un inicio de jornada laboral, desencadenando la petición de ciertos datos al servidor principal, como pueda ser su ruta de trabajo, es posible obligar al cliente de réplica a conectar mediante WIFI, modificando posteriormente este comportamiento para emplear conexión 3G mientras se efectúa el resto del proceso de reparto.
APROVECHAMIENTO MÁXIMO DEL TERMINAL Cuando se escriben los clientes de réplica para cada entorno de movilidad se utiliza el código nativo de nivel más bajo que permita cada entorno. Esto permite que el proceso sea lo más eficiente posible y tenga la menor cantidad posible de abstracción del dispositivo. Cada entorno, incluso cada versión del mismo entorno tiene clientes amoldados exactamente a sus características, por lo que se aprovechan al máximo las características tanto de red como de procesamiento para el trabajo de réplica.