The Solve Menu

Un elemento central de la especificación SyncML es el protocolo de representación. El protocolo de representación especifica la estructura lógica y el formato de los mensajes SyncML. La estructura y formato de un mensaje es especificado utilizando XML (extensible markup language). El uso de un lenguaje de descripción estructurado es esencial y XML es una opción muy natural dada su aceptación general y grado de utilización en la industria.

Durante la sincronización, las entidades de sincronización de una forma lógica intercambian paquetes, pero físicamente cada paquete puede ser dividido entre múltiples mensajes comunicados. Existen muchas formas en las cuales un paquete puede ser dividido en múltiples mensajes para la comunicación. Una motivación para tal fragmentación de paquetes es la falta de espacio de comunicación en un cliente restringido de recursos. Otra motivación es que los mensajes más pequeños son transmitidos con un mayor grado de éxito sobre conexiones de ancho de banda y confiabilidad baja. En general se debe de asociar a los paquetes con unidades lógicas de comunicación durante la sincronización y a los mensajes con unidades físicas de comunicación durante la sincronización. Cada mensaje SyncML es un documento XML bien formado, lo que quiere decir que es de sintaxis correcta y se adecua a la definición correspondiente en su DTD (Document Type Definition). El mensaje consiste en un encabezado y un cuerpo. El encabezado incluye información tal como la aplicación fuente y objetivo, el ruteo, la sesión y la autentificación. El cuerpo de un mensaje SyncML está formado por un conjunto de comandos. Cada comando identifica a una operación que ha sido realizada o que se solicita en un registro o en un conjunto de registros. Algunos ejemplos de operaciones incluyen agregar, borrar, reemplazar, buscar y estado. Cada comando identifica e

incluye a los datos relevantes dentro de él mismo, por ejemplo, un comando reemplazar

identifica a los datos reemplazados por una aplicación dentro de su repositorio de datos.

Cuando el otro cliente de sincronización recibe el mensaje y procesa el comando reemplazar,

intenta reemplazar los mismos datos en el repositorio de datos correspondiente a la aplicación. Si no existen conflictos o errores, los datos reemplazados son ahora reflejados en ambos repositorios de datos. En otras palabras, los reemplazos han sido sincronizados exitosamente. El protocolo de representación no impone ningún orden implícito o alguna otra restricción en lo que respecta a como se deben procesar múltiples comandos en un solo mensaje, por

ejemplo, si un mensaje contiene varios comandos agregar y reemplazar, el cliente que los

recibe puede procesar esos comandos en cualquier orden. El protocolo de representación, sin embargo, permite que varias operaciones sean agrupadas conjuntamente con una semántica

especial, por ejemplo, el elemento del comando atómico puede contener otros comandos, tales

como agregar y reemplazar, junto con semántica especial que instruye al cliente a procesar

exitosamente todos los comandos dentro del comando atómico, o no procesar ninguno. Este

tipo de capacidades permiten a SyncML poder ser utilizado en aplicaciones comerciales que requieren propiedades transaccionales. El protocolo de representación de SyncML solo especifica el lenguaje hablado por dos computadoras cuando ellas sincronizan. El protocolo de representación define qué deben decirse las computadoras y en qué secuencia. Dos computadoras no pueden sincronizarse si no siguen una secuencia predefinida de intercambio de paquetes, aun si los paquetes individuales son correctos.

– 60 – El protocolo de sincronización define los roles del cliente y del servidor. Típicamente el cliente es un dispositivo móvil, y el servidor es un servidor de red o una computadora personal y en el caso de ésta tesis, el cliente será una aplicación de escritorio. Sin embargo, la distinción entre un cliente y un servidor se hace de forma lógica.

Es posible para dos dispositivos móviles realizar una sincronización entre ellos utilizando SyncML, donde uno asume el rol del cliente y el otro asume el rol del servidor. Usualmente, un cliente realiza una petición de sincronización en su primer mensaje al servidor, en cambio, el servidor puede alertar a algunos clientes a que inicien la sincronización. La forma de sincronización puede ser de dos vías o de una vía. En la sincronización de dos vías, el cliente y el servidor intercambian y reconcilian sus respectivas actualizaciones. La sincronización de una vía puede ser muy útil para clientes que solo necesitan leer los últimos datos de un servidor o actualizar a un servidor con los últimos cambios. Además de los protocolos de representación y sincronización SyncML toma consideraciones adicionales en cuenta para lograr una sincronización de datos práctica que puede ser utilizada comercialmente.

Las consideraciones adicionales pertenecen a los rubros de red, formatos esperados y aceptables de datos, capacidades de los dispositivos y seguridad. Algunas de las consideraciones adicionales están incluidas en las especificaciones de soporte actuales y algunas otras consideraciones, tales como la seguridad, se manifiestan dentro de los protocolos de representación y sincronización.

Dos entidades de sincronización se deben comunicar mediante una red actual. Las aplicaciones típicamente se comunican utilizando protocolos de transporte de red, tales como el HTTP. Aunque los protocolos de representación y sincronización de SyncML son independientes del transporte, durante la sincronización los paquetes SyncML deben ser enviados en mensajes actuales sobre un protocolo de transporte actual. Claramente, para diferentes transportes, la forma de los mensajes podría ser diferente. La forma de los mensajes para un transporte en particular es llamada “liga de transporte”. SyncML define unas cuantas ligas populares de transporte tales como: HTTP, Wireless Session Protocol (WSP) y OBEX. Las ligas son especificaciones adicionales que pueden ser utilizadas por los desarrolladores de aplicaciones.

Si se requiere utilizar SyncML sobre un transporte diferente a los antes mencionados, es posible definir ligas de trasporte adicionales, por ejemplo, si se requiere sincronizar utilizando un protocolo de correo electrónico, una liga de transporte adicional tal como SMTP (Simple Mail Transfer Protocol) puede ser fácilmente definida. Otra liga potencial de transporte adicional puede incluir RMI (Remote Method Invocation) para aplicaciones que requieren mantener objetos Java sincronizados utilizando SyncML.

– 61 – Los formatos de datos de las aplicaciones no son especificados en los protocolos de representación o sincronización. Sin embargo, dos aplicaciones que sincronizan deben entender el tipo de datos de la aplicación y el formato que utilizan. Sería imposible para la especificación incluir todos los posibles formatos de datos que pueden ser sincronizados utilizando SyncML. En la especificación solo se identifican unos cuantos formatos de datos que los servidores SyncML deben soportar para la sincronización de tipos de contenido específicos que claman ser compatibles entre clientes y servidores SyncML.

Dichos formatos de datos se relacionan a las aplicaciones PIM y son adoptados de estándares emergentes en formatos de datos de calendarios y contactos, tales como vCard y vCalendar. Se espera que en futuro estándares de representación emerjan para muchas clases de datos relacionadas a los negocios, es muy probable que una representación XML para los datos en las bases de datos relacionales emerja en un futuro cercano. Uno de los objetivos de SyncML es apoyar dichos estándares e incorporar su uso en la especificación.

Es importante para las computadoras que se sincronizan conocer sus respectivas capacidades, tales como las aplicaciones soportadas, formatos de datos y limitaciones de memoria. Por ejemplo, antes de que una computadora servidor envíe datos a un cliente móvil, es importante conocer las limitaciones de memoria del cliente para que los datos no causen un sobre flujo de memoria en el dispositivo cliente. Las computadoras que se sincronizan necesitan conocer si ambas reconocen y soportan los tipos de datos de cada una. Las computadoras necesitaran saber las versiones de la información de ambas para una sincronización incremental desde la última ocurrencia de la sincronización. Ellas necesitaran saber el tamaño máximo permitido de los identificadores de datos. Los repositorios de datos en los clientes y en los servidores son raramente homogéneos, entonces los clientes y los servidores típicamente utilizan diferentes tipos de identificadores para identificar los mismos datos. Los clientes típicamente utilizan una forma compacta de identificación y los servidores utilizan una forma más elaborada.

SyncML especifica como este tipo de información de los dispositivos y meta información debe ser representada. La información de los dispositivos y otra información son intercambiadas en el inicio de la sincronización entre un cliente y un servidor cuando están sincronizando por primera vez o si existen cambios a la información del dispositivo o a la meta información desde la última vez que se sincronizaron.

La seguridad de los datos es también de importancia crítica en la sincronización. Acceder y actualizar los datos debe requerir una apropiada autentificación. SyncML permite múltiples niveles de sofisticación de la autentificación. Se puede escoger entre los esquemas de usuario y clave de acceso para las aplicaciones personales, tales como los calendarios a través del Web. Se puede escoger entre el algoritmo MD5 (Message Digest) basado en credenciales o los certificados X.509 para aplicaciones corporativas, tales como el control de inventarios. Además, SyncML confía en una capa segura de transporte para asegurar la protección de los datos sensibles cuando se encuentran en tránsito a través de una red.

– 62 – La intención de SyncML es permitir la sincronización de datos entre una diversa gama de dispositivos de computación, incluyendo, dispositivos móviles, teléfonos, computadoras personales y servidores de red. SyncML está diseñado para ser independiente del tipo de transporte y extensible de tal manera que pueda trabajar con una gran variedad de transportes de red. Uno de los elementos clave de SyncML es que es una especificación basada en mensajes. Las especificaciones basadas en mensajes han sido exitosas en sistemas cliente servidor y distribuidos. Estándares y tecnologías como CORBA (Component Object Request Broker), RMI (Remote Method Invocation) y DCOM (Distributed Component Object Model), que dependen en la aceptación de una interfase particular de programación no han sido ampliamente adoptados más allá de dominios limitados. Ya que SyncML está basado en mensajes le permite a las plataformas como los teléfonos móviles mantener su naturaleza propietaria y aún así inter operar con diversas computadoras servidor y diversas aplicaciones. Otro elemento clave es que SyncML no intenta estandarizar las funciones de las máquinas de sincronización que capturan diversas semánticas de la aplicación, ya que es peligroso para el crecimiento de las aplicaciones.

El precio de la interoperabilidad es a menudo el rendimiento. El estándar SyncML tomo algunas decisiones en su diseño para generar una forma sencilla, práctica y utilizable para lograr la sincronización de datos.