Synchronization Architecture

Let’s take a quick look at all the components that are involved in a typical data synchronization architecture.

If you look at the bottom of Diagram 1 you will see a range of different mobile devices all with their own relational database, which will either be a SQL Anywhere Server or Ultralite Server database. Both of these databases are full relational database management systems (RDBMS) that are contained within SQL Anywhere Studio.

At this point, the user has a number of options as to how they can synchronize their data changes to the Mobilink Server.

One option is to dock the device into a cradle, such as a Pocket PC or Palm device making use of either ActiveSync or HotSync, whilst you are connected to the corporate network.

The other option is to utilise some form of Wireless connection allowing you to sync over either TCPIP, or if you have an existing corporate web server in place, mobile users can synchronize through the internet via HTTP or HTTPS, thus connecting to your Apache or IIS web server. The HTTP or HTTPS requests of those users will then be redirected to the Mobilink Server, which would normally be sitting behind the firewall in your corporate network. Once those requests are received by the Mobilink Server, they would be redirected to the backend consolidated database which can be Oracle, Microsoft, Sybase or any other major heterogeneous database.

The Synchronization Process

There are two main streams in the synchronization process… the Upload and the Download stream

The Upload stream takes care of uploading any changes that have occurred on the remote SQL Anywhere Server or UltraLite database.

The way that Mobilink Server keeps track of what has changed, is to monitor the transaction log on the remote to see what has changed since the last time the user synchronized.

This process is very efficient; we can simply look at the log, package up all the changes and quickly upload all of the changes to the Mobilink Server.

The Download stream: Since we don’t necessarily have access to the transaction log of the consolidated database which might be Oracle, Microsoft or IBM, we need a different method of keeping track of what has changed in order to send down the changes to the remote database, and the way that we do that is through a set of select statements that you as the administrator either write or generate with the help of the MobiLink Server.

The Acknowledge Download is an optional stream and will be discussed at a later stage.

We will be going through a step by step walkthrough of exactly how these scripts are generated, edited and maintained by you as the developer or administrator.

The automatically generated scripts are created in the SQL language by default.

However, if you have a requirement to synchronize your data to systems like SAP or Siebel, you may want to add some more custom business logic, so in this scenario SQL might not give you all the functionality you need to interrogate or evaluate the data, prior to it being applied to the central consolidated database.

For that reason, we allow developers to embed their own custom business logic, which you can write in either Java or .NET e.g. as the inserts, updates and deletes are coming from your remote databases, you can embed some Java or .NET logic, that takes a look at the uploaded changes, review them, modify them if need to, prior to applying the changes to the consolidated database.

Another characteristic of the Mobilink synchronization scripts are the concept of -‘script versioning’.

For each set of scripts that is generated, we give the collections of scripts a name.

This allows your remote users either the ability to upload data to multiple back ends, or it gives you as the administrator flexibility to subset your data even further by creating a set of scripts that allows different people in different projects to have access to different sets of data.

A good idea for implementation of synchronization versions is to split functional levels in the organisation, such as the executives from other managers or employees.