Architecture Overview

SyncML Overview

The way data is synchronized varies dramatically from one vendor to the next. Each implementation has its own proprietary way of exchanging data, sometimes making it difficult for device manufacturers, service providers, and application developers to integrate these solutions. Furthermore, each synchronization solution has support for different protocols, devices, and data types, making the task of data integration an even greater challenge. This is particularly the case when you need to synchronize applications from multiple vendors.

In February 2000, a group of companies, including Ericsson, IBM, Lotus, Motorola, Nokia, Palm, Psion, and Starfish Software, joined forces to create a new industry initiative to develop and promote a single, common data synchronization protocol that could be used throughout the industry. This protocol is called SyncML.

To date, the objectives of SyncML have not yet been realized for enterprise data synchronization. The specification is still relatively new and not many vendors have implemented SyncML-compliant products. This is largely because SyncML is not yet proven for corporate applications. Many of the existing synchronization solutions have proven market success, so there is no need for these vendors to rush to implement new SyncML solutions. The one exception is in the PIM space, the first market targeted by SyncML. As you'll learn in Chapter 16, many of the PIM solutions are now SyncML-compliant.

Note 

The information in this section is largely based on the SyncML specifications and related documents from the SyncML Initiative (now a component of the Open Mobile Alliance). Consequently, there is some level of bias in the favor of SyncML. As more vendors implement SyncML solutions, we will be able to take a more objective look at SyncML. For now, we take a preliminary look at target audiences for SyncML and explain how SyncML works.

What Is SyncML?

What exactly is SyncML? The best answer to that question can be found at the SyncML Web site (www.syncml.org) where SyncML is defined as follows:

• SyncML is a specification for a common data synchronization framework and XML-based format, or representation protocol, for synchronizing data on networked devices. SyncML is designed for use between mobile devices that are intermittently connected to the network and network services that are continuously available on the network. SyncML can also be used for peer-to-peer data synchronization. SyncML is specifically designed to handle the case where the network services and the mobile device store the data they are synchronizing in different formats or use different software systems.

As the definition reveals, SyncML is an XML-based specification for synchronizing all forms of data between remote devices and enterprise systems. Its goal is to provide an industry-standard protocol for synchronizing data between all types of devices, such as PDAs, handheld PCs, smart phones, pagers, and cell phones, over any network protocols, to any data store. To achieve this lofty goal, the SyncML initiative decided to start with personal information management (PIM) synchronization, and then move to other forms of enterprise data.

Why Use SyncML?

The overall benefit of SyncML is that it is an industry initiative aimed at bringing together synchronization technology for many devices, networks, and data sources. Many of the current synchronization solutions use proprietary conduits that are often complex and limited in the data sources they can communicate with. As the number of mobile computing devices increases, and the expectations for access to corporate data grows, the SyncML Initiative hopes to provide enough benefits to make it the leading protocol for data synchronization.

SyncML Target Audiences

Four main groups are expected to benefit from the adoption of SyncML as an industry standard, each in its own specific way:

• End users. SyncML promises to provide a single way to synchronize email, calendar, to-do lists, contact lists, as well as corporate application data. This would be a welcome change to the current landscape where different synchronization software is required for each task.

• Device manufacturers. For devices that have built-in synchronization capabilities, SyncML offers a protocol that will allow the device to access a broader range of data sources, over any network and transmission technology. This will enable device manufacturers to provide a wider range of features with reduced overhead.

• Service providers. Companies in the application-hosting field currently have to limit their offerings due to the numerous forms of synchronization technologies on the market. As it stands now, service providers already have a difficult time managing the few technologies they do support because they all have different requirements for devices, networks, and back-end data sources. SyncML should alleviate these issues by providing a single protocol that will be able to work with a broad range of applications, devices, and networks.

• Application developers. Developers want to focus their efforts on technology that is in demand and will result in successful applications. SyncML should provide a single technology that will allow them to build a variety of data-driven applications without having to learn a number of synchronization technologies. This should result in developers being able to build applications that will work on a larger number of devices, over many network protocols.

SyncML Advantages

In addition to the advantages for the specific groups just listed, SyncML provides seven other advantages that should prove to be beneficial in a synchronization solution. Many of the existing synchronization solutions already include many of these advantages, but again, SyncML is attempting to provide them in an industry standardized way:

• Designed for wireless and wireline networks. SyncML works over all networks used by mobile devices, including both wireline and wireless networks. Some of the challenges in this effort come from the characteristics of today's wireless networks: high latency, low bandwidth, low reliability, and high costs. To address these issues, SyncML has implemented a robust protocol that uses WBXML, to reduce the data being transferred; uses a single request-response model, to minimize network traffic; and has support for dropped connections during synchronization.

• Support for multiple transport protocols. SyncML works over the following leading network protocols: TCP/IP, HTTP, Wireless Session Protocol (WSP), and OBEX (Bluetooth, IrDA). It can also be deployed over SMTP, POP3, IMAP, and proprietary wireless communication protocols. SyncML does not require any additional capabilities that are not addressed by these protocols.

• Support for arbitrary data. The capability to support various forms of data is a requirement for any general-purpose synchronization solution. Since SyncML is targeted at providing synchronization for all forms of enterprise data, it has built-in support for the following data formats, and can add new formats if the need arises:

  • Personal data formats, such as calendars, to-do lists, and contact lists

  • Collaborative formats, such as email and network news

  • XML and HTML documents

  • Relational data

  • Binary data formats, binary large objects (BLOBS)

• Data access for multiple applications. To work effectively with the largest number of possible applications, SyncML is not tied to any specific programming language. It does not make any assumptions about the programming language being used, and will work effectively when a different language is used on the client and the server parts of the application.

• Optimized for constrained devices. Since many of today's mobile devices have limited memory and processor capacities, SyncML is designed to work in very constrained environments. By keeping the footprint and processor requirements to a minimum, SyncML-based application should be able to operate on a broad range of devices with varying processors, memory capacities, and operating systems. In addition, the data exchanged using SyncML is in a binary format, reducing memory requirements for storage.

• Takes advantage of existing Internet technologies. Since many of today's corporate applications are Web-based, it is important for a synchronization protocol to be able to work with Web technologies. XML has emerged as the preferred way to represent structured data on the Web, so SyncML is XML-based, ensuring easy implementation and quick interoperability testing.

• High level of interoperability. SyncML has been designed to work over any network, with any device and any data source. Even though this goal has yet to be realized, SyncML does work very well with highly constrained devices, allowing them to communicate with synchronization servers that are capable of executing complex synchronization logic.

Note 

Again, keep in mind that these are the proposed advantages of the SyncML protocol, which are just starting to be realized with commercial applications.

How SyncML Works

As we take a look at how SyncML works, we are going to focus on the guidelines that have been laid out in the specifications, not individual vendor products. Once you have an understanding of the underlying SyncML protocols, you will be able to quickly evaluate vendor offerings to determine if they meet your specific requirements.

Specifically, we will examine the following components of the SyncML specification:

• SyncML Representation Protocol

• SyncML Synchronization Protocol

• SyncML Transport Bindings

The SyncML Representation Protocol specifies a common synchronization frame-work and format that can be used to create different data synchronization models. This protocol is defined by a set of well-defined messages (either XML documents or MIME content type) that are transported between the devices participating in a synchronization procedure. It supports both the request/response and the blind push command structures as data synchronization models.

SyncML synchronization is an exchange of packages; each package contains one or more messages. The SyncML representation protocol specifies the expected result of various synchronization operations, based upon the SyncML synchronization frame-work and associated data synchronization models. In this way, the SyncML representation protocol defines the structure of a SyncML message. Each message within a package contains a single data synchronization operation.

A SyncML message is a well-formed XML document consisting of a header and a body. The header contains metadata, which conveys information about the SyncML message. This metadata may include versioning, session, routing, and security information. The body of the SyncML message contains a list of commands, which allow for inserts, updates, deletes, and other actions to be executed to make the two datasets the same.

Figure 10.7 shows an example of the SyncML framework; notice the dotted line that defines its boundaries. It is in this framework that the SyncML Representation Protocol is applied. When you look at the overall interactions between the SyncML client and the SyncML server, the SyncML Sync Protocol is used. This protocol is essential for achieving interoperable data synchronization. It defines the protocol for various synchronization procedures, which occur between the SyncML client and the SyncML server in the form of message sequence charts. The SyncML Sync Protocol allows for both one-way and two-way data transfer in a variety of modes. One-way synchronization is an important feature because it allows clients to save time by sending only their changes to the server; clients do not have to receive the server changes at the same time. It also is appropriate where only one set of data has changed, in which case two-way synchronization is not required; by default, only the changed records are synchronized between the client and the server. If the full set of data has to be synchronized, there is a slow-sync mode that will allow this.

Figure 10.7: SyncML framework.

Within the SyncML Sync Protocol, two roles are defined: a client and a server. Most of the time, synchronization is initiated by the client application, although some of the always-on networks allow the server to initiate the transfer. Do not be fooled into thinking that the server role within the protocol has to be performed by a powerful server-class machine: Both the client and the server may be mobile devices.

When it comes to the transport layer, SyncML defines a set of transport bindings. These bindings are required to ensure that there will not be any problems using the underlying protocols. The three transport bindings currently supported are HTTP, WSP, and OBEX. Each of these is supported for a reason. HTTP is widely used, and usually is able to pass through corporate firewalls; WSP is a part of WAP, allowing WAP phones to support SyncML; finally, OBEX provides support for short-range connectivity, possibly using Bluetooth, IrDA, or USB.

Now let's see how this works. Figure 10.7 shows how two applications communicate with each other using SyncML. Application A represents a server application that can synchronize with multiple client applications, such as Application B. The communication between these two applications can occur over any network transport, such as HTTP, WSP, or OBEX. The client application (Application B) uses the Sync Client Agent to access the network and send messages to the server. For this to happen, the client agent communicates with the SyncML Interface (SyncML I/F), which in turn uses the SyncML adapter to send the XML message object. The server (Application A), then receives the message through the Sync Server Agent and manages the entire process using the Sync Engine. All of the Sync Engine's network access and data synchronization operations to and from the client application go through the Sync Client Agent.

This example is at a conceptual level. As vendors bring commercial products to market, these products may not contain all of these concrete components. However, the functionality that is contained in these components will have to be incorporated into their solution in some fashion.

Note 

If you are interested in learning more about SyncML, you can download the SyncML specification from www.syncml.org or www.openmobilealliance.org. It will give you in-depth information about the SyncML architecture and protocols.

Future of SyncML

The first products to support the SyncML initiative have focused on the synchronization of PIM data such as email, to-do lists, contact lists, and calendar information. Companies like Starfish Software, Pumatech, Synchrologic, and FusionOne have added support for SyncML at this level. There has been some adoption by other SyncML sponsors, including Palm, Symbian, and Nokia; all of which have added SyncML support to their latest device offerings.

In contrast, SyncML has not been widely adopted for enterprise data synchronization. To date, only IBM (a founder of the SyncML initiative) has released SyncML-compliant products. Oracle, Sybase, and Microsoft have all decided to stay with their own synchronization solutions, which are not based on SyncML. These products have been on the market for some time, and it is unlikely that they will support SyncML anytime soon.

It is still too early to tell whether SyncML will become an industry standard. SyncML is currently in a prestandards phase, where it will remain until it gains sufficient momentum and market acceptance to justify its adoption by an international standards body. At this time, more than 700 companies are supporting the SyncML initiative, although many of them are taking a wait-and-see approach. If these companies start to release SyncML-compliant products, we could very well see plug-and-play integration between any device, on any network, and be able to synchronize with any data source.