XML - Managing Data Exchange/SyncML

XML - Managing Data Exchange

Chapters

Appendices

Exercises

Related Topics

Computer Science Home

Library and Information Science Home

Markup Languages

Get Involved

To do list

Contributors list

Contributing to Wikibooks

Previous Chapter	Next Chapter
← Database and XML	SVG →

Learning objectives

Upon completion of this chapter, you will be able to

Understand SyncML fundamentals and general syntax.
Understand how and why SyncML is implemented.
Quickly locate and use SyncML technical specifications.

Introduction

Mobile devices such as PDAs, pagers, mobile phones and laptops are- by nature- not always connected to a network. Yet these devices contain applications which require information obtained from a network in order to be useful. While most PDAs and mobile phones contain applications such as calendars, task lists, and address books for storing useful information, this information is far less useful when it is static, only available on the device itself. For example, copies of static information will always be dissimilar when changes are made on one copy or the other. Synchronization offers a device the ability to connect to a network in order to update either the information on the device or the information on the network, such that both sets of information are identical and up-to-date.

Given the proliferation of proprietary mobile devices and protocols, as well as the increasing consumer demand for ubiquitous mobile access of information, leading technology companies saw the need to create a standard, universal language for describing the synchronization actions between devices and applications. They formed a consortium to sponsor the SyncML initiative to create this language.

Currently, the SyncML consortium has been adopted and incorporated into the Open Mobile Alliance, a larger group of over 300 companies which sponsors many collaborative technology projects and protocols.

What is SyncML?

SyncML or Synchronization Markup Language is an XML-based, industry-standard protocol for synchronizing mobile data across a variety of multiple networks, platforms and devices. SyncML started as an initiative in mid 2000 by major technology companies such as Ericsson, IBM, Palm Inc., Lotus, Matsushita Ltd. (Panasonic), Motorola, Nokia, Openwave, Starfish Software, Psion and Symbian. Their initiative's goals were to create a universal language from the myriad, proprietary, synchronization protocols used by mobile devices and provide a complete set of synchronization functionality for future devices. The consortium released version 1.0 in December 2000. They then implemented new features and resolved issues with the subsequent version releases, finalizing the protocol with version 1.1 in February 2002.

The SyncML protocol is designed with these goals in mind:

As a common language, any device should be able to synchronize with any SyncML service (a networked data repository).
Any service speaking SyncML should be able to synchronize with any SyncML-capable device.
The protocol must address the limitations of mobile devices, specifically with respect to memory storage.
It must support a variety of transport protocols such as HTTP, SMTP, Bluetooth and others.
It must deliver common synchronization commands to all devices.
It builds upon existing web technologies, specifically XML.
Support asynchronous communication and error-handling, since the Internet has latency.

SyncML consists of client and server commands enclosed within DTD-defined...

SyncML Fundamentals

Vocabulary

Let's begin by defining a vocabulary:

Client - the mobile device, its application and local database.
Server - a remote system communicating to the system database or application.
Modifications - data in fields in a database are changed.
Sync - The client and server exchange SyncML messages with commands.
Package - SyncML DTD conformant XML markup describing requests or actions to be taken by either a SyncML client or server. A package is a collection of actions to be performed
Message - the smallest unit of SyncML markup. Large packages are broken into separate messages.
Mapping - using an intermediate identifier to tie two pieces of information together. example: let's say 'green' is '5', and '5' is nice. What is nice? If you said 'green' you are correct. You've just done mapping!

Abbreviations:

IMEI	International Mobile Equipment Identifier
GUID	Global Unique Identifier
LUID	Local Unique Identifier

Messages and Packages

SyncML messages are requests from either a client or server to perform some action. The action may be to synchronize data, perform some checks on data, update a status, or handle any errors with these actions. Messages are bundled together as packages, as kind of a to-do list. Messages are a laundry list of requests, and they can be pieced together out of order if sufficient mapping information is given to identify to which package the message belongs.

SyncML is designed this way to accommodate for errors and dropped messages. Should one message be dropped, a syncML client or server will know there is a problem because the mapping cannot be completed. It will then issue a request for the information to be resent. Once the data is received, the updates to the information can proceed.

Structure of a SyncML message

Like SOAP, there are two parts to the SyncML message, a Sync Header <SyncHdr> and Sync Body <SyncBody>. The header contains meta-information about the request, such as the target database <Target> and source database <Source> URIs, Authentication information <Cred>, the session ID <SessionID>, the message ID <MsgID>, and SyncML version declaration <VerDTD>. The body contains the actual requests, alerts and data.

Addressing

Addressing is done through the <syntaxhighlight> and <LocURI> tags. A server will have a familiar URI like http://www.chris.syncml.org/sync and a client mobile device will have an IMEI identification number like this 30400495959596904.

Mapping

SyncML is based on the idea that clients and servers can have their own way of mapping information in their databases. Therefore, clients and servers must each have their own set of unique identifiers.

Locally Unique Identifiers (LUID) are numbers assigned by the client to a data object in a local database (like a field or a row). They are non-reusable numbers assigned to these objects by the SyncML client.
Globally Unique Identifiers (GUID) are numbers assigned to a data object for use in a remote database. This identifier is assigned by the server.

LUID and GUID numbers only have to be unique if they are being used in a table between two communicating parties. In other words, these numbers are temporary, used for mapping data to tables and only really exist for the complete duration of transactions between client and server.

The server will create a mapping table to tie the LUID and GUID together.

Client-side data

LUID
----
5

Data
----
Green

Server-side data

GUID
----
5050505

Data
----
Green

Server Mapping

GUID
----
5050505

LUID
----
5

Change Logs

The Server and Client track of changes made to their databases during synchronization through "change logs". SyncML doesn't define the change logs, instead SyncML does require that the changes and corrections be negotiated between client and server through messages. Using change logs, the Client and Server know which fields need to be updated. The implementation of change tracking in the application which will use SyncML is not defined.

Sync Anchors

During Synchronization, the Client and Server need to know which fields to update. If a client/server application is checking the fields prior to updating/modifying them, how then does the client/server keep track of the position of current field in the database? The answer is "by using Sync Anchors".

There are two kinds of Anchors : Last and Next. The 'Last' anchor describes which updates occurred during the last synchronization event. The 'Next' anchor describes the current and future synchronization request. These anchors describe the events from the standpoint of the sending device.

Anchors are sent back and forth from client and server to keep track of what is happening to the database fields and what's going on in overall through the lifetime of the sync operation.

By coordinating Sync Anchors and change logs with the type of Sync that is requested, the server application can determine and track (with change logs) which information is the most up-to-date. For example, it is possible to overwrite 'newer' information- that is information for which there is the most recent time-stamp in the change log- with older information. This could be done by choosing a sync in which the client tells the server to overwrite it's information with client data. This is called a 'refresh sync from client'. The types of syncs are described below.

Syncs

There are seven types of Syncs in the SyncML 1.1 language. The following section describes the types of syncs:

Two-way Sync - The client and server exchange information about modified data. The client sends the modifications first.
Slow sync - a two-way sync in which all fields in the database are checked on a field-to-field basis. This type of sync is used for the first sync, or after a synchronization failure.
One-way sync, client only - the client sends the modified data first. The server accepts and updates the data and does not send its modifications.
Refresh sync from client - the client sends the entire database to the server. The server does not sync. Rather, the server replaces the target database with the client's database.
One-way sync, server only - the server sends the modified data first. The client accepts and updates the data and does not send its modifications.
Refresh sync from server - the server sends all its information from a database to the client, replacing the client's database.
Server alerted sync - the server remotely commands the client to initiate one of the above sync types with the server. In this way, the server is remotely-controlling the client.

Sync Initiation

Sync Initiation is the process the client and server must go through prior to an actual Synchronization. The first step is for the client and server to speak the same language, exchanging and revealing each other's capabilities (as defined by device, as in amount of memory, and protocol as defined by DTD). The second step is identification of the databases to be synchronized. Next the two must decide on the type of synchronization. The third and final step is authentication. Once this step is completed successfully, the synchronization activities can begin.

Authentication

The SyncML server can send the client a message containing the <Chal> tag in order to represent an authentication challenge to the information the client is attempting to access. The client must then respond, giving the username and password within the <Cred> tag.

SyncML uses MD5 digest access authentication. The Client and Server exchange credentials during the authentication process, returning error codes if the process breaks down at some point. The <Cred> tag is used in the <SyncHdr> for holding the credentials to be used for authentication.

Common SyncML implementations

Nokia was the first company to make a SyncML-enabled phone. It synchronized the calendar database on the phone. SyncML can synchronize to-do lists, calendars, address books, phone-books, pretty much anything an organizer can do. SyncML is capable of much more. It would be appropriate to use SyncML any time there are two disparate, remote applications which need to share the same data.

SyncML Syntax

SyncML Example

Abbreviated SyncML example

<SyncML>
<SyncHdr>
<VerDTD>1.1</VerDTD>
<VerProto>SyncML/1.1</VerProto>
<SessionID>104050403</SessionID>
<MsgID>5</MsgID>
<Cred>...</Cred>
</SyncHdr>
<SyncBody>
<Status>...</Status>
<Sync>
<Target>target database URI</Target>
<Source>source database URI</Source>
<Add>datafield and data</Add>
<Replace>an existing data field with some data</Replace>
</Sync>
</SyncBody>
</SyncML>

Notice lines {1} and {18} start the SyncML file with the root tags. Next, the SyncHdr is defined by lines {2} and {8}. Further, lines {3,4} define the versioning information, line {5} defines the sessionID to distinguish which unique dialogue is occurring between client and server applications, line {6} shows the MsgID to uniquely identify this set of requests (this entire markup) to be performed by the requested application. Also in the syncHeader are credentials, on line {7}.

The SyncBody begins on line {9}. In this part of the syncML message, device/application status {10}, target/source URIs {12,13}, and requested actions such as the sync itself between lines {11,16}, Add and Replace {14,15} commands are given.

WBXML and SyncML

WAP Binary XML (WBXML) is a form of XML whereby the XML tags are abbreviated in order to shorten the markup for transmission to mobile devices, which commonly have bandwidth and memory limitations. The XML tags are encoded into a binary shorthand to save space. Let's take a look at an example so that this will make more sense.

The following is WBXML binary code depicting a SyncML message. Notice in the first line there is a the document type definition, represented here in hexadecimal tokens. Can you see what happens to the following string? "//SYNCML//DTD SYNCML 1.1//EN"

wbxml

Immediately following this string are the characters '6D 6C 71'. Each of these represent a SyncML tag.

wbxml abbreviations

6D
6C
71

= "<SyncML>"
= "<SyncHdr>"
= "<VerDTD>"

wbxml abbreviations (cont.)

C3
03
"1" "." "1"
01

 = represents the beginning of opaque (xml) data
= this represents the length of this opaque data
= The characters "1" followed by "." and "1"
= represents "</VerDTD>"

tells the SyncML processor that this is the beginning of opaque (xml) data this represents the length of this opaque data The characters "1" followed by "." and "1" represents "</VerDTD>"

All together this WBXML code snippet, 6D6C71C303"1.1"01 represents:

SyncML header snippet

1
2
3

<SyncML>
<SyncHdr>
<VerDTD>1.1</VerDTD>

So you can see how using WBXML shorthand would be a more compact means of representing XML, saving bandwidth for mobile devices.

For more information please refer to Ed Dumbill's articles on syncML with WBXML:

SyncML specifications

The best source of information on SyncML is the protocol itself. Visit the Open Mobile Alliance for the SyncML specifications.

Open Mobile Alliance

Download OMA SyncML Specifications and white papers at the Open Mobile Alliance. Or check out the SyncML Articles at the Open Mobile Alliance.

SyncML Implementations

Although the SyncML specifications are useful, you still have to implement the protocol in your application. There are a few toolkits and implementations out there that you can use to get a head start.

SyncML Reference Toolkit

The Open Mobile Alliance has released a toolkit written in C to demonstrate SyncML. You can get it here. If you can read German, you can get a sample application using the toolkit here.

Funambol

Interested in developing SyncML for Java? Check out the open source project Funambol. It offers a Java and C++ SDK that implements the SyncML data synchronization protocol, a Java-based application framework for building SyncML server applications, and a standalone SyncML server.

Summary

Mobile Device Technology is improving and changing at a rapid pace. As US telecommunication companies implement Third generation (3G) WCDMA technology (wide-band code-division multiple access), or wireless broadband, we will begin to see powerful devices emerge on the market. These devices will be able to deliver full color, video, streaming multimedia and a variety of data services such as Multimedia Messaging Service (MMS) through WAP. In that infrastructure is becoming cheaper, these telecommunication companies are starting to shift towards being service providers and media vendors as opposed to communications utilities. Cingular wireless, multimedia messaging and ringtones services are a good example of the shift of their company towards being a media platform. The companies that will survive will be the ones that listen to customers needs and make easy-to-use services.

Telecommunications companies can add value to their services by creating custom applications and services that use SyncML for synchronization.

Exercises

Visit the Open Mobile Alliance Website, download the pdf of the SyncML v. 1.1 protocol and review it. Reading this reference is a valuable exercise in learning.
Answer these questions:
- What is WBXML and why is it used?
- How do you foresee SyncML being used in the future?
- Name a problematic situation whereby SyncML is the best 'tool' for the job.

Answers: 2a) WBXML is Wap Binary XML, it is a form of XML whereby the XML tags are abbreviated in order to shorten the markup for transmission to mobile devices, which commonly have bandwidth and memory limitations. 2b) SyncML will likely be used as a general, standard syncing mechanism for synchronizing data sets between systems, not just for mobile devices. 2c) A ticket-tracking system called TNT helpdesk is a web-based open work request management system. The staff running this system would like to have live data from this system on their PDAs, listing open requests. Currently, the PDA database is synced via a docking sync station attached to the staff members' PCs. Staff members have to download the request list as a CSV file, convert it into a usable PDA database and upload it to the PDA, making it this process cumbersome, prone to error, and always out-of-date. Recommendation: Create a custom app to push live updates to the PDAs using SyncML over Bluetooth/Wireless

References

Dumbill, E.(2002, January 1). XML Watch: Have data, will travel. IBM.com. Retrieved April 6, 2004 from
http://www-106.ibm.com/developerworks/xml/library/x-synchml/index.html

Dumbill, E.(2003, March 1). XML Watch: WBXML and basic SyncML server requirements. IBM.com. Retrieved April 6, 2004 from
http://www-106.ibm.com/developerworks/xml/library/x-syncml2.html

How [SyncML] works(n.a). Nokia.com. Retrieved April 6, 2004 from
http://www.nokia.com/nokia/0,8764,2559,00.html

The New SyncML Standard. . Cellular Dot Co Dot Za Website. Retrieved April 6, 2004 from
http://www.cellular.co.za/syncml.htm

Open Mobile Alliance (2002, April 2). SyncML version 1.0, 1.1 specification, white paper, errata. Retrieved April 6, 2004 from
http://www.openmobilealliance.org/tech/affiliates/syncml/syncmlindex.html

Pabla, C(2002, April 1). SyncML Intensive: A beginner's look at the SyncML protocol and procedures. IBM.com. Retrieved April 6, 2004 from
http://www-106.ibm.com/developerworks/xml/library/wi-syncml2/

SyncML Initiative, Ltd.(2000, December 7). SyncML Specification Protocol version 1.0. The Open Mobile Alliance. Retrieved April 6, 2004 from
http://www.openmobilealliance.org/tech/affiliates/syncml/syncml_represent_v10_20001207.pdf

SyncML Initiative, Ltd.(2002, February 15). SyncML Device Information DTD version 1.1. . Retrieved April 6, 2004 from
http://www.openmobilealliance.org/tech/affiliates/syncml/syncml_devinf_v11_20020215.pdf

Saarilahti, A, Group SyncML, et al.(2001, April 23). Tik-76.115 Short introduction to SyncML. . Retrieved April 6, 2004 from
http://www.hut.fi/u/asaarila/syncml/syncml_intro.html

Stemberger, S.(2002, October). Syncing Data: An introduction to SyncML. IBM.com. Retrieved April 6, 2004 from
http://www-106.ibm.com/developerworks/wireless/library/wi-syncml/

Synchronica Software GmbH(n.d.). SyncML for Microsoft Exchange. Synchronica Software Website. Retrieved May 24, 2004 from
http://www.synchronica.com/products/syncml/corporate_syncml.html

Weblicon Technologies AG (n.d.). SyncML for SunOne. Weblicon Technologies AG Website. Retrieved April 6, 2004 from
http://www.weblicon.net/html/products_syncml.html

XML Cover Pages (n.a., 2003, April 29). The SyncML Initiative. XML Cover Pages Dot Org Website. Retrieved April 6, 2004 from
http://xml.coverpages.org/syncML.html