Synchronization Development Options

Synchronization Development Options

Your synchronization options often will be dictated by the choice you make for your persistent data store. Many of the relational database vendors have synchronization solutions as part of their offerings. These solutions are usually integrated extremely well with the mobile database, making them an obvious choice. On the other hand, many of these synchronization solutions integrate only with the vendor's enterprise database, possibly imposing a limitation that is not suitable for your environment. If this is the case, you can either build your own synchronization solution or find a vendor that offers generic synchronization for many client and server databases.

If you use the database built into the operating system, you may also be able to use the OS's synchronization conduit; but more often than not, you will have to create your own synchronization layer. The built-in synchronization software is usually not targeted at accessing enterprise data, and is more suitable for deploying applications and related files to the device.

Mobile OS Synchronization Conduits

Most of the mobile operating systems on the market come with proprietary conduit software for synchronizing data and applications between the mobile device and a companion PC. We will take a look at the leading operating system synchronization conduit software here, focusing on the capabilities for enterprise data synchronization.

Windows CE ActiveSync

Microsoft ActiveSync gives you an easy way to synchronize files and applications between your desktop and Windows CE device. You can connect to your PC through the device's cradle or wirelessly over a wireless LAN or infrared. ActiveSync provides built-in support for synchronizing email, contacts, calendar, tasks, and notes with Microsoft Outlook. In addition, you can browse the Internet directly on your device using the Internet connection on your desktop computer.

ActiveSync is based on a client/server architecture. It consists of a service manager and a service provider. The service manager coordinates the synchronization process between the desktop and the device. It provides connectivity, detects changes, resolves conflicts, and transfers data.

If you are looking for more advanced features, such as synchronizing enterprise data to a client application, you will have to either build or purchase a custom ActiveSync service provider. A service provider is a custom conduit used in conjunction with the ActiveSync application to execute data synchronization. By creating or purchasing an ActiveSync service provider, the users of your application will be able to synchronize their enterprise data using the same method they use to synchronize applications and PIM data.

Building a custom service provider requires the creation of two modules, one for the client device and another for the desktop PC. Both modules are implemented as inprocess COM objects, which have exposed interfaces allowing the service manager and other service provider modules to request the tasks for which the service provider has been designed. (Note: Describing the development of these components is beyond the scope of this book. Consult the Microsoft Web site,, or a Windows CE programming book for more detailed information.)

Palm OS HotSync

Similar to ActiveSync, Palm OS HotSync provides an out-of-the-box solution for synchronizing files and applications between your desktop and a Palm OS device. You can establish the connection using a cradle or wirelessly using infrared. Additionally, the Palm OS desktop software allows you to synchronize various forms of PIM data, including email, calendar entries, contact lists, and to-do lists. It's important to point out here that the Palm OS HotSync Manager is not a synchronization conduit; rather, conduits are plug-ins that can be managed by the HotSync software, and are executed when you press the HotSync button on a cradle or modem. In general, you are required to develop or purchase custom conduits that you require for your applications. The exception is the basic backup and installation conduit that comes with the Palm OS HotSync software. Anything beyond this basic level of functionality has to be developed as a custom conduit. For example, if you want to transfer data from the handheld to your company database, a conduit must be developed to perform the translation, access the appropriate database record, write to it, and save to the database.

Conduits for the Palm OS are usually written using Visual C++, Visual Basic, or Java, using the Palm Conduit Development Kit (CDK). The CDK provides access to the HotSync Manager APIs, and comes with complete samples and documentation. The most useful sample in the CDK is a generic conduit that includes a portion of the required synchronization logic that can be customized for your use.

Symbian OS Connect

Among the standard features included in Symbian OS Connect are file management, backup and restore, remote printing, document conversion, contacts and agenda synchronization, email synchronization, clipboard transfer, machine management, and application installation. This is indeed an impressive list of features, but notice that it does not cover bidirectional enterprise data synchronization. If you want to use Symbian OS Connect for this type of synchronization, you will have to develop it yourself using the converter APIs provided in the Symbian OS SDK. (More information on using Symbian OS Connect can be found on the Symbian Developer Network at

Synchronization Conduit Considerations

The synchronization conduits included with mobile operating systems have advanced application and PIM synchronization capabilities, but they do not include any functionality for enterprise data synchronization. Hence, in all cases, you will be required to develop a custom conduit or service provider to have these capabilities.

Since most device users take advantage of these conduits for application and PIM synchronization, it is often requested that data be synchronized using these conduits as well. Doing this gives users a seamless way to synchronize their applications and data using the same process. If you are developing your own data synchronization conduit, integration with the operating system synchronization software may be a good feature to include. Many of the commercial data synchronization solutions have support for ActiveSync and HotSync synchronization.

One final point to keep in mind about OS conduit software: It is very specific to the operating system. A conduit written for ActiveSync will have to be rewritten to work with HotSync, and vice versa. If you are going to build a custom synchronization layer, you may want to take a more generic approach.

Custom-Coded Synchronization Solution

Now that you know that the synchronization software that comes with an operating system will not provide any level of database synchronization, you are left with two choices for your synchronization solution: build it in-house or purchase a commercial solution.

Let's take a look at some of the issues that you will have to resolve in a custom-coded synchronization solution. Many of these topics/features have been discussed earlier in the chapter, but are readdressed here to refresh your memory.

In addition to having the knowledge to write your own C/C++ or, possibly, Java-based server application, you will also have to know some specifics about data synchronization requirements:

  • Database issues. You will have to understand the structure of your database and know how to extract the required information so it can be synchronized to the mobile device. You will have to be concerned with transactional and referential integrity during the data transfer process. Once you understand the enterprise data structure, you have to define a layer to map this data to your client side data source, possibly requiring a transformation layer. And, of course, you will require a data access layer. This may be ODBC, JDBC, or a custom adapter for nonrelational data sources.

  • Mobile operating systems. Which mobile operating system do you have to support? Each operating system has its own I/O layer with which you will need to integrate. In addition, you may end up having to develop separate applications for each client since each has its own SDK.

  • Network protocols. Which protocols are required for the data transfer? Is supporting TCP/IP enough, or do you need support for other non-IP wireless protocols? This may require knowledge of how to communicate using the wireless modems that are available for the devices to which you are deploying.

  • Handling conflicts. Once you are at the point where data can be synchronized, what do you do when a conflict arises? You will have to develop a methodology for resolving conflicts in an acceptable way. This most likely will require a mechanism for custom resolution logic.

  • Security. What level of security is required for your application? You may need to implement encryption of the communication stream, as well as authentication support for remote users.

  • Support for SyncML. Do you want this solution to adhere to the SyncML specification? If you are reselling the solution, this may provide a good selling point. Even if you are not reselling this solution, SyncML can offer you a standardized way to handle the most common synchronization tasks that you will encounter. Information on SyncML is provided later in this chapter in the section entitled SyncML Overview.

In addition, if you want your synchronization layer to work in conjunction with the synchronization software provided with the operating system, you will need to build specific conduits for each operating system to which you are deploying. To aid with the conduit development, each operating system has a development kit that provides integration APIs.

On top of the development efforts, you also have to address ongoing maintenance of the solution. Each time an operating system is updated or a new network protocol is required, you will have to perform additional maintenance work. In our current mobile environment, where new devices and networks are constantly emerging, maintenance alone could require significant resources.

If you think this sounds like a lot of issues to consider, you are right. Developing a robust, enterprise class synchronization solution in-house is not an easy task. It requires in-depth knowledge about databases, mobile operating systems, network communications, and security. In general, if there is a commercial solution available that meets your requirements, most likely you will end up ahead in the long run if you use it. On the other hand, if you have decided to implement the mobile database inhouse, then building the synchronization layer may make sense. It may also be your only option, as many of the commercial synchronization solutions are tied to a specific mobile database offering.

Commercial Synchronization Solutions

The commercial synchronization solutions can be broken into two categories: those offered by mobile database vendors, and general-purpose synchronization solutions. In both cases, the commercial synchronization solution should address many of the key synchronization requirements listed earlier in the chapter. As you learn more about the available products, you will quickly be able to determine whether a solution meets your needs.

Database Synchronization Vendors

The synchronization products in this section are from vendors who also sell mobile databases. In all cases, the synchronization software is only available for each vendor's client database offering, although often it can integrate with other databases on the server side.

Sybase/iAnywhere Solutions


MobiLink and SQL Remote

Mobile OS support

Windows CE, Palm OS, Symbian OS, Linux, Java

Server OS support

32-bit Windows, Solaris, Linux, AIX, HP-UX, Novell Netware, Mac OS X


Sybase/iAnywhere Solutions has two offerings in the synchronization area: MobiLink and SQL Remote. Both are implemented as proprietary servers that sit between the client and sever databases, providing flexible synchronization solutions. Let us take a look at where each technology is best suited.

MobiLink synchronization works with both Sybase Adaptive Server Anywhere and UltraLite as the client databases. It provides session-based bidirectional synchronization to all of the leading enterprise databases, including Sybase Adaptive Server Enterprise (ASE), Oracle, IBM DB2, Microsoft SQL Server, and Sybase Adaptive Server Anywhere (ASA). The integration with these databases is provided in a direct manner using ODBC, without requiring any intermediate data storage. MobiLink uses the publish/subscribe synchronization model, storing all of its synchronization logic in the enterprise database. The conflict resolution logic is stored in the same manner. This gives the developers a flexible way to modify the synchronization logic using the SQL variant implemented by the enterprise database vendor. Additionally, the synchronization logic can be programmed using Java or any .NET language.

MobiLink synchronization is designed to support a large number of remote databases; it can support thousands of remote databases with a single installation. Both wireless and wireline protocols are supported, including HTTP and TCP/IP, as well as common operating system conduits such as HotSync and ActiveSync. For security, MobiLink offers the option of encrypting the data stream to prevent unwanted parties from viewing the data.

The SQL Remote synchronization technology is somewhat different. Though it, too, has support for thousands of remote users in a single installation, it is suitable only for Sybase databases, supporting Sybase ASE and Sybase ASA. SQL Remote is a message-based synchronization layer, permitting asynchronous communication between the client and the server. For each update made on the database, an entry is made into a transaction log. When synchronizing, the changes in the transaction log are sent to the server, using one of many available protocols, including email, FTP, or any other file transfer mechanism. The messages can be processed whenever they are received, allowing replication to occur incrementally.

Overall, the two iAnywhere Solutions offerings are very capable for data synchronization, providing flexible options for the server database. They do, however, require a Sybase client database (either Adaptive Server Anywhere or UltraLite). By providing both session-based and message-based synchronization, iAnywhere Solutions should have a solution that is suitable for your environment.



DB2 Everyplace Sync Server

OS support

Windows CE, Palm OS, Symbian OS

Server OS support

Windows NT, AIX, Linux, and Solaris


The IBM DB2 Everyplace Sync Server is a relatively new technology. At the end of 2001, it supported only the Palm OS client and Windows NT server. In 2002, IBM released the Sync client for Windows CE and Symbian OS, and the Sync server for AIX, Linux, and Solaris. Compared to the other commercial solutions, this product has not been on the market for very long.

The synchronization server is implemented as a Java servlet. This allows it to run within any servlet engine, although it works best in IBM WebSphere. The client components are native for each client operating system. The architecture is based on the SyncML protocol. In accordance with this protocol, the synchronization messages are WAP binary-encoded XML (WBXML). This provides a compact way to send and retrieve data over wireless networks.

User data is defined using the publish/subscribe model. IBM provides a tool to define the server publications and the subscriptions for the mobile users.

Data synchronization can either be one-way or two-way, using HTTP as the transport protocol. When synchronization occurs, the data is sent from the client to the Sync server using SyncML. Once it reaches the Sync servlet, it is temporarily placed in an IBM DB2 Universal database. From there, custom JDBC adapters can transfer the data to the enterprise database of choice. There is currently support for Oracle, Sybase, and Microsoft databases. Once the server has received the client data, the server sends its changes back to the client using the same process.

The IBM synchronization solution is obviously a great choice for those companies using the DB2 Everyplace database. It provides tightly integrated synchronization options for the DB2 Universal database and adapters for other relational databases. The fact that the DB2 UDB is required for temporary storage may be seen as a limitation for some organizations, as it may require additional hardware and maintenance resources.



Oracle9i Lite

Mobile OS support

Windows CE, Palm OS, Symbian OS

Server OS support

32-bit Windows


Oracle provides a bidirectional synchronization solution between the Oracle9i Lite client database and the Oracle9i enterprise database. There are two components to Oracle Lite's synchronization solution: the Mobile Server and the Mobile Sync client. The Mobile Server sits on top of the Oracle9i AS application server and provides integration to the Oracle enterprise database. The Mobile Sync client works with Oracle Lite on all of its supported platforms.

The Sync Server automatically generates the synchronization logic. This provides a quick way to get an application going. However, if you require custom logic (which you often do), you will have to control the synchronization programmatically, meaning that the database administrator also has to be a developer. There is a similar limitation for conflict resolution logic. The Mobile Server will automatically detect a conflict; but from there, only basic conflict resolution is offered. If these are not sufficient, the conflict data is put on a queue where an administrator can perform manual reconciliation of the data.

For security, Oracle offers data encryption directly from the synchronization client to the synchronization server, thereby prohibiting any access by malicious parties.

The Oracle synchronization solution is targeted only at corporations using both the Oracle9i Lite and Oracle9i server databases. If this does not describe the technology being used in your organization, then you will want to look at other solutions with more extensive enterprise support.



SQL Server CE

OS support

Windows CE

Server OS support

32-bit Windows


Microsoft SQL Server CE provides bidirectional synchronization between the SQL Server CE client database and the SQL Server enterprise database. There are two means of data synchronization: Remote Data Access (RDA) and merge replication. Both provide two-way data synchronization. Merge replication, though it is more complex, has some benefits over RDA for mobile scenarios. For example, merge replication allows data to be updated autonomously on mobile devices and the server. The data is then merged when the device is reconnected to SQL Server. Microsoft SQL Server CE uses the publish/subscribe synchronization model.

Synchronization is provided over HTTP to Microsoft SQL Server back-end databases via Microsoft Internet Information Server (IIS). Replication can be performed over wired and wireless local area networks (LANs) and wide area networks (WANs). Using IIS as the synchronization server provides several benefits, one of them integrated security. IIS provides authentication, authorization, and encryption to the synchronization process. These are tied to the IIS security layer and do not have to be visible to the mobile user.

Microsoft's synchronization layer does have some limitations. Besides working only on Microsoft platforms with Microsoft products, another weakness is the product's support for conflict detection and resolution: Most conflict resolution work has to be done programmatically by the application developer. In addition, the overall synchronization architecture is rather complex, and will take significant effort to set up properly, especially if you do not have experience with SQL Server or IIS.



PointBase UniSync

OS support

Java clients

Server OS support

Platforms with a Java Virtual Machine


Synchronization between the PointBase Embedded database and other enterprise databases is accomplished using PointBase UniSync. UniSync is a middleware server that provides bidirectional data synchronization. If you are using the PointBase Server or Oracle databases, you can synchronize the net changes. If you are using other enterprise relational databases from Sybase, Microsoft, or IBM, only snapshot synchronization is supported.

PointBase UniSync uses the publish/subscribe synchronization model. It allows data subsetting at the user level. It also has built-in conflict detection with standard resolution schemes, and enables users to implement custom schemes in Java.

PointBase UniSync offers a capable synchronization solution for companies using the PointBase embedded database on the client, and the PointBase Server or Oracle databases on the server. If you are using other enterprise databases, being limited to only snapshot synchronization may prove to be problematic. And note that PointBase Micro version, discussed in Chapter 9, "Persistent Data on the Client," is not currently supported by PointBase UniSync.

Other Synchronization Vendors

The enterprise data synchronization market currently is dominated by companies that offer a corresponding mobile database product. Most of the other synchronization offerings do not focus on the enterprise database market, with one notable exception: Synchrologic.

Unlike the other vendors listed in Table 10.1, Synchrologic also has adapters that allow bidirectional data synchronization between a variety of client and server databases. For mobile client databases, Synchrologic does not currently support IBM DB2 Everyplace or Sybase UltraLite. It does, however, support Sybase Adaptive Server Anywhere, Microsoft SQL Server CE, and Oracle Lite. On the server is support for all the leading enterprise data sources. In terms of features, the Synchrologic synchronization server supports data subsetting, conflict detection and resolution, multiple network support, and security.

Table 10.1: Additional Synchronization Vendors




Extended Systems XTNDConnect

PIM, file



PumaTech Intellisync

PIM, file

Starfish TrueSync


Synchrologic iMobile Suite

PIM, file, data

Table 10.1 lists other leading synchronization technology vendors. Notice that many of their solutions focus on PIM synchronization, which is discussed in more depth in Chapter 16, "Mobile Information Management."


All of the synchronization vendors covered in Table 10.1 support the SyncML initiative and have SyncML-compliant products.

Commercial Solution Conclusions

You have two options for enterprise data synchronization: building it in-house or purchasing a commercial solution. In most cases, building a custom solution will require significant resources for development and maintenance, ultimately making it more costly than licensing a commercial product. If, however, you are using a database that comes with the mobile operating system or a custom-built database, building your own synchronization layer may be the only available option.

All of the leading mobile database vendors offer synchronization to their corresponding enterprise databases. In the case of Sybase and IBM, you also can synchronize to other enterprise databases from their mobile clients. These commercial solutions have rich, flexible synchronization features, making them well suited for large-scale enterprise-wide deployments.


Rather than choosing a synchronization solution based on the mobile database, you might find it easier to choose the mobile database based on the synchronization solution. Since many of the commercial synchronization solutions are more limited than the commercial mobile databases, making the decisions in this order will result in a solution that will directly integrate with your enterprise databases, while still maintaining persistent data storage on the client device.