Implementing the Ideal Architecture

So, what makes for an ideal SyncML implementation? Generally, the lead on the project will follow these best practices for device management, data synchronization and client provisioning architecture:

•    The User Agent initiates the management or data synchronization session by initializing the Client Agent and the transports.  It also manages the exchange of packet data between the Client Agent and the Transport Adapter.

•    The Data Synchronization, Device Management & Provisioning Agents manage the message
exchange process, including the flow of commands and responses between the remote server and the Data Store or Managed Object Tree.

•    The Object Manager Interface forms the conduit between the Management Agent and the Managed Object Framework.  The Managed Object Framework is responsible for maintaining the properties and values of all managed objects. This includes maintaining and enforcing the server access control lists.

•    The Database Adapter Interfaces the Data Synchronization Agent to the data store. Translation of data store records between native and MIME formats is also performed here.

•    The Command Processors handle SyncML specific command building and parsing.

•    The WBXML Processor handles encoding and decoding generic commands in WBXML format.

Synching Up

Not every implementation based on the SyncML protocols is the same; of course, that is one of the great inherent values of the standards — that they can be used to satisfy varying carrier and end-user requirements.  Yet, there is one main question administrators should ask before moving forward with a SyncML implementation:  “Who should drive the synchronization process — the client or the server?”

With SyncML, a device behaves as either the client or the server.  Typically though, the embedded mobile device is the client, and as a result, the more difficult processing is pushed onto the (more powerful) server platform.  Likewise, within the device itself, the transport may be implemented as a client or server or both, enabling either device to initiate the synchronization or management session. 

Over time, there has been a shift in the structure of the initiation process — historically the client initiated the synchronization session, but more and more the server initiates the session. It’s a simple workaround bringing more control to the management server.  The server sends a message to the client requesting that the client initiate a session back to the server.

With Server-Initiated Synchronization (SIS), the OMA-DS specification defines how a server can request a client start a synchronization session.  Because the client is responsible for initiating synchronization in SyncML, this message from the server to the client is unique, and is used only as a trigger.

During implementation of OMA-DS, developers identified many problems in the SIS specification, some of which were very complex and required drastic changes.  As a result, when it came time for the device management group to address server-initiated management, they chose a different path, called “Server Alerted Notification” (SAN).

The SAN is used to instruct a client to establish a management session back to the initiating server.  The format of the SAN message is unique in that it is not based on XML, and thus, results in a much smaller message size that is easier to send in push messages, such as Short Message Service (SMS).  This means that the OMA-DM client device must include two parsers, one for the standard XML or WBXML messages and one for the SAN message.  The SAN message format addressed many of the problems with SIS and has since been adopted on the data synchronization side by OMA, as well.

In the current environment, devices that are developed to support SIS must be considered proprietary solutions.  While the general format and use of the SIS message is similar on most devices, some amount of client or server customization is typically required to tailor support of SIS for each device.