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:

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:

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

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

Las características de esta arquitectura son:

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

Las ventajas de este sistema son varias:

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.

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

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.

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:

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:

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.

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.

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.

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.

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.

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.).

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.

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: