SyncML
SyncML is an abbreviation for Synchronization Mark-up Language and is actually a specification for data synchronization .
The specification mainly consists of an XML -based representation protocol and a synchronization protocol as well as its exemplary connections to HTTP , OBEX and WSP .
The data can be in any format as long as they are registered or representable in MIME .
SyncML was first published in December 2000 by the SyncML Initiative , which was formed as a non- profit making joint venture in February 2000 with original sponsors including Ericsson , IBM , Lotus , Matsushita , Motorola , Nokia , Palm and Psion , and in November 2002 in the Open Mobile Alliance rose.
A special form of SyncML is SyncML-DM ( SyncML for Device Management ), which defines remote maintenance functions for mobile devices, with which a server can manage configurations and software updates.
Platform independence
Any device with a SyncML-compliant client can synchronize data with a SyncML-capable server, regardless of the operating system and manufacturer. Typical end devices between which data can be compared are PCs , cell phones and handheld computers .
Data synchronization
Data synchronization is basically the process in which two different end devices (regardless of whether, for example, cell phones, handhelds or laptops or PCs) synchronize data. It is recognized which terminal device has which data, and it is also checked whether the respective other terminal device wants to have this data in addition to its own. In the event that both terminals have the same data content, only in different versions (for example if an address has been changed on one side), it can be defined which change is retained.
Using SyncML messages, clients exchange data for synchronization with a server. Typically, the client always initiates the start of a synchronization. Only a future version 1.3 should enable a real push from the server to the client. SyncML messages are very similar in structure to normal e-mail messages. There is a header with receiver and sender information and synchronization IDs that are unique for the server. The head is followed by the synchronization commands for adding, deleting and replacing data.
example
Alice and Bob each have a mobile phone and are employed as field workers from the same company. This company manages all customer data centrally on a server.
Alice now gets to know a customer Dave, and saves his phone number and name in her cell phone. Alice's mobile phone automatically transmits the new entry to the central company server, which now stores the new contact centrally. Now the server sends the entry to Bob's mobile phone immediately after Alice's mobile phone has announced the entry to the server. The server has thus synchronized the data content between Alice and Bob. This also works with more than two participants.
If Dave's number changes, Alice changes it on her mobile phone and, when synchronizing, it is also changed on the central company server, and is then also transferred to Bob's device during subsequent synchronizations.
Challenges
There are some problems with the way SyncML works:
- How does the central server really know 100% which contact it has to update when Alice changes the number of a contact on her cell phone?
- How can the server be sure that a change has taken place? That is, which data should be compared?
- What if Alice and Bob make a change to Dave's phone number within a short period of time? Whose number is then considered to be the "correct" one and is synchronized among all other employees?
- What should happen if a new employee enters various private numbers in his phone - should these really be loaded onto the central server and thus be accessible to all others?
- In summary: Whose data should be synchronized when and between whom?
To be able to solve these problems, there are some advanced concepts for the synchronization process.
Concepts
The following concepts must be implemented for the purpose of functional data synchronization:
- ID handling : Serves for the unique identification of a data record (e.g. contact entry). This is implemented using a unique ID (identification data - usually a number). In this way, servers and end devices (cell phones and so on) can recognize whether, for example, two contacts on two devices are the same or not.
- Change detection : When is a data record considered changed? Is it enough if the first name is spelled differently, or does the whole phone number have to be a new one? This defines the change detection, which usually also works with a timestamp (specific point in time - date including time) in order to define the point in time of the change.
- Modification exchange : How is a change made? Should be deleted, replaced or recreated? All of this is defined here.
- Conflict detection : This concept takes care of the detection of the cases described above, such as simultaneous changing of various data or whose data should be synchronized.
- Conflict resolution : Here it is decided how the conflict identified above is to be resolved, freely according to the principle: "First come, first served", or "Last wins" - that is, whose data set should serve as a reference for the update.
- Slow and fast synchronization : Should only the data be compared that has changed since the last full synchronization process, or all of them?
This is just an overview of the concepts - it is included for the sake of completeness.
Scheme
With SyncML, the devices receive a uniform exchange protocol. This works independently of the device type and the transmission path: So that such different types of devices as PDAs, handhelds, cell phones, cameras and PCs can exchange their data with the synchronization protocol, SyncML supports established protocols such as HTTP, WSP (Wireless Session Protocol, part of the WAP protocol ) and OBEX for Bluetooth and IrDA connections.
communication
The following graphic is intended to show the synchronization process between a server and a client. You can clearly see that both the server and the client have a SyncML interface, which enables smooth data exchange.
The SyncML-converted data is transmitted from the server to the client and vice versa via any protocol - this can be HTTP (TCP / IP), WSP (WAP) or OBEX (Bluetooth, infrared).
The Sync Client Agent initiates a synchronization process based on the SyncML protocol and manages the transmission processes on the client side. On the other side of the client, the Sync Server Agent waits for a synchronization request.
The Sync Engine carries out an analysis and checks which data needs to be changed. To do this, she opens and modifies databases, reacts to changes in the appointment calendar or updates the folders in the e-mail program.
Use
On the client side, that basically means the end user side - and thus the mobile part - SyncML masters the data types that occur in e-mail, calendar entries, address directories and documents. At the same time, SyncML is so flexible that new formats can be integrated with little effort. In detail, the protocol does the following:
- It enables data communication via wired networks, radio networks and infrared connections.
- It supports a wide variety of transport protocols and data formats.
- It allows data to be accessed from many different devices.
- It takes into account the limited resources of mobile systems in terms of memory and processing power.
- It is based on proven network technologies.
- It supports those synchronization functions that as many systems as possible use.
In practice
SyncML (OMA DS) has established itself as the standard for the comparison of appointment, contact and other PIM data, but there are still challenges in practice:
- In contrast to IMAP implementations for e-mails, relatively few desktop applications have so far supported SyncML. Microsoft Outlook or Mozilla Thunderbird , for example, need additional plug-ins in order to synchronize calendar or contact data with a server in this way. Most cell phones of current mobile devices support this standard; on smartphones with the Android, Windows Mobile, Blackberry or Apple iOS operating systems, it must be retrofitted using an additional application.
- Existing server and client programs, especially from different developers, do not always communicate smoothly with each other, which is partly due to poorly developed implementations. With some constellations, the synchronization does not work at all, only after complex configuration or incorrectly (among other things, duplicates are formed ).
There are now solutions that are capable of intelligent data comparison with duplicate and conflict resolution and which relieve the user of most of the work.
- In Germany, all of the major mobile network providers and internet providers are now relying on services for data backup and synchronization based on SyncML, especially T-Mobile with MyPhonebook, Vodafone with MeinAdressbuch, o2 with the Communication Center, Mobilcom with the MSync service, or T-Home ( T-Online) with the Data Sync Service. Such services are already established in other countries too, for example with the A1 address book at Mobilkom Austria or Orange address book in Austria, as well as the online messaging address book synchronization at O2 Ireland.
Individual evidence
- ↑ a b Enabler Release Definition for SyncML Common Specifications. (PDF; 91 KB) Open Mobile Alliance, July 24, 2009, accessed February 11, 2018 .
- ↑ SyncML WSP Binding, Version 1.1. (PDF; 97 KB) Open Mobile Alliance, February 15, 2002, accessed on February 11, 2018 .
- ↑ a b OMA DS Standards Change History. (PDF; 111 KB) Open Mobile Alliance, March 31, 2008, accessed on February 11, 2018 .
Web links
- Current SyncML specifications (v1.2.2) of the OMA (English)
- SyncML Reference Toolkit (English)