| SyncML can be designed in multiple ways in different mobile device platforms. Figure 11-1 presents a possible logical architecture, which outlines the key components enabling SyncML Client functionality in a wireless device. It shows components of two types. The common platform components are indicated using italic text. The components belonging to the SyncML Client software (Client software) are indicated using boldface text. In the figure, several application programming interfaces (APIs) are also depicted to elaborate which types of APIs could be used between the components. This architecture may not be suitable to SyncML Server functionality. Figure 11-1. Logical architecture of SyncML Client software in a mobile device 
Datastores (DS in the figure), containing the data to be synchronized, are obviously necessary components for the SyncML functionality. For instance, a datastore can contain calendar data, to-do lists, and contact information. In addition to the Client software, there are native applications, such as calendar applications, that present this data to an end-user in the device. The Client software must be able to send and receive SyncML Messages when communicating with a data synchronization Server. For that purpose, the device platform provides one or more transport interfaces (Transport IF in the figure). The transport interfaces offer a data connection over a transport protocol (e.g. HTTP) and a physical transport medium (e.g. GSM/GPRS). The transport components have their own settings for enabling data communication, and these are commonly independent of settings needed for SyncML based synchronization. As Figure 11-1 depicts, the Client software in a device consists of the following components: The synchronization application component provides the user interface (UI) and the application logic for starting a synchronization session and for manipulating the synchronization settings. Commonly, this component is dependent on the device platform, the UI style, and the common UI components provided by the device platform. The design of the components can vary appreciably, depending how many different applications, transport protocols, and synchronization Servers the Client software needs to support. The synchronization configuration datastore in Figure 11-1 contains static configuration information for enabling data synchronization with a Server. These settings are commonly visible to an end-user. The end-user can modify these settings if necessary. Typical settings found in this datastore are the synchronization Server address (e.g. URL), the addresses of the datastores in the Servers, the usernames, and the passwords. There can be other settings depending on the device platform and desired features (e.g. data filtering). The SyncML Client functionality is implemented into the SyncML Client engine component. In other words, this component executes all the synchronization logic related to the SyncML Client. The logical functions found in the Client engine component are the following: Administrating synchronization information related to Servers and datastores Managing all synchronized data to and from datastores Implementing the needed SyncML handshake procedures for synchronization sessions Handling basic conflict resolution when needed
In general, the SyncML Client engine component glues other components together as it interfaces with all the other SyncML related components. The synchronization application component uses the Client engine to execute the synchronization process through the engine API. The Server info datastore utilized by the SyncML Client engine includes the dynamic information related to synchronization Servers and synchronization events. The information to be stored depends on whether the implementation supports synchronization with multiple Servers or only with one Server. An example of data stored in this datastore is the previous times of synchronization (also called sync anchors) associated with different datastores. SyncML messages convey information between the SyncML Client and Server. The SyncML Client engine component is responsible for understanding the conveyed information inside these messages. For creating and parsing SyncML messages, the Client engine uses the SyncML parser component. This component can support XML, WBXML, or both. The SyncML Initiative has created an open source parser called the SyncML Reference Toolkit. The toolkit supports both XML-based and WBXML-based Messages. Commonly, the XML or WBXML parser is used through a Parser API. When implementing the SyncML Reference Toolkit, the SyncML Initiative defined an API based on the C programming language. For details on the SyncML Reference Toolkit, see Chapter 10. The SyncML Client engine attaches to datastores via the datastore adapter. These adapters enable the usage of different datastores. In other words, the Client engine inserts, modifies, and retrieves data through these adapters. Typically, there is a need for multiple datastore adapters if multiple application types are synchronized. The adapters also hide the differences of datastores from the Client engine. Thus, the Client engine can use one API towards the adapters. In Figure 11-1, this API is called the Adapter API. The last component related to the SyncML Client software is the transport manager. The purpose of this component is to enable the usage of different transport protocols and physical communication media. For instance, HTTP, WSP, or OBEX can be used as a transport protocol. Beneath them, there are various physical media such as GSM/CSD, GSM/GPRS, TDMA/CSD, BluetoothTM, and WLAN. The supported transport protocols and physical media are dependent on the device platform at which the Client software is targeted. Main Technical Requirements The SyncML Initiative designed the specification in such a way that it can be used in mobile and wireless devices. A few important aspects related to the Client software in a wireless device are listed below. This list excludes some items like interoperability, supported applications, and transports. Footprint needed RAM usage Performance Usability
The footprint refers to how much space is required for the binary files of a Client implementation. This includes the files added during installation and also the files that may be created by the Client software itself. The acceptable amount of kilobytes that can be reserved for these files is dependent on the specific device platform. For some platforms, only tens of kilobytes are needed, while some other platforms may allow hundreds of kilobytes. For embedded wireless devices, footprint may be more crucial than RAM usage. This does not have to be the case if the platform enables the execution of multiple applications simultaneously. In any case, the required RAM size of the Client software is very much dependent on the amount of data to be sent or received at a given time. In other words, a large part of the dynamic RAM needed is used to keep a SyncML Message in memory. Poor performance of Client software applications can lead to two different kinds of results. First, an end-user may be frustrated if a synchronization session takes too long. Second, using the Client software can be too expensive for the end-user if a data connection needs to be maintained for a long synchronization session. The amount of data sent over the air critically affects the performance of the Client software and must be carefully optimized. This is a responsibility of the Client software but also of the SyncML Server with which the synchronization is done. For instance, the slow sync type should not be initiated if not absolutely necessary, and the unsupported properties of application content should not be sent. One aspect of Client software performance is related to internal processes in the device. The internal processes can be related to operations accessing the datastores or the functions establishing the connections. The usability of the Client software can be primarily divided into three different aspects. The first one is convenient out-of-the-box experience. For an end-user, this means that the first use of the Client software is very easy and trouble-free. This task may not be trivial, as there are settings related to the Client software that must somehow be configured. Different mechanisms (e.g., application wizards, settings sent via a SMS message) can be used for addressing this problem. After the first usability challenge is addressed properly, the continuous usage of the Client software should also be taken into account. Sequential synchronization sessions with a Server must be easy to start. In practice, this means that a synchronization session is initiated without any awkward and time-consuming effort from the end-user. The third area related to the usability of the Client software is the UI functionality during synchronization. The synchronization process and the data connection must be visible to the end-user, as the user may need to cancel or suspend the process in some cases. As mentioned, there can be charges associated with the connection. Thus, these progress- and status-related UI aspects need to be carefully considered. Minimal SyncML Client Implementation In a product enabling SyncML data synchronization, the desired functionality in the product generally sets the bounds for the supported features of the SyncML protocols. Nevertheless, when implementing a Client, one may choose to support only the minimal set of SyncML features. In practice, this means that only the mandatory SyncML features are implemented. Those requirements do not define which application types or transport protocols need to be implemented. Table 11-1 lists the main mandatory features for implementations, or the minimal set of SyncML features. In addition to these, there are many other detailed mandatory features, which can be found in the specifications. It is important to note that the minimal set of SyncML features still offers enough functionality to enable a full Two-way synchronization between a Client and a Server. Table 11-1. The Main Mandatory SyncML Features for ClientFeature/Function | Special Note |
|---|
Representation Protocol [SDS02] | XML/WBXML format | Either one must be supported. | Add command | Only receiving is required, it is not required to send. | Alert command | | Delete command | | Get command | Only support for device information is required. | Map command | Sending is required as a response to an Add command. | Put command | Only support for device information is required. | Replace command | | Results command | Sending is required as a response to a Get command. | Status command | | Sync command | | RespURI element type | Only receiving is required. | Synchronization Protocol [SSP02] | Two-way Sync Type | | Slow Sync Type | | Change log for data items | Minimally, the support for one Server is required. | Sync anchors | | Identifier mapping | This requires the support of the Map command. | Exchange of device info | Sending is required. | Multiple messages/package | | MD5 digest and Basic authentication | The Client is required to respond to the authentication challenge. |
In cases where the Client only supports the mandatory SyncML features, the Server may support some optional features. The Client implementation must tolerate the usage of the optional features, even if it is not able to utilize them. Mobile Software Platforms The SyncML Client functionality can be implemented on several different mobile platforms or mobile operating systems. These can also be called mobile software platforms. A mobile software platform with associated device hardware forms a device platform. Some mobile software platforms provide APIs for entities other than the platform vendor itself. For instance, Symbian OS® and Mobile LinuxTM are of this type. Some platforms are completely embedded in a vendor's specific device hardware, and only the vendor or its partners can use these platforms to develop applications. Typically, mobile phones and pagers are based on embedded platforms on which it is not possible to install applications after the manufacturing process. Nevertheless, this is also changing, as these platforms are more frequently adopting technologies such as JavaTM MIDP (Mobile Information Device Profile). Java-based applications can thus be introduced in these platforms as well. There is no single answer for how to select a correct mobile software platform for SyncML. The answer depends on many issues, such as what kind of device is desired, what applications are to be supported, what is the region where the application is used, and what are the supported use cases. There are also technical aspects to be taken into account. For instance, an application development company may be specialized in producing software in a specific programming language (PL). Thus, this may be a factor when selecting a mobile software platform for the SyncML application. Table 11-2 presents a set of major mobile software platforms in alphabetical order. Also, it lists some common characteristics related to them and the devices supporting them. Table 11-2. Mobile Software PlatformsSW Platform | Primary PL | Multithread support | Native PIMSupport | Primary Device Type(s) |
|---|
Java MIDP | Java | Yes | No | Mobile phone, Smartphone[1] | Microsoft® Pocket PC | C++, C | Yes | Yes | PDA | Mobile Linux | C | Yes | No | PDA | Palm OS® | C | No | Yes | PDA | Symbian OS | C++ | Yes | Yes | Smartphone |
[1] The term smartphone can include all kinds of communicators, PDA-type phones, and imaging/media phones.
In addition to these platforms, there are many proprietary embedded mobile software platforms, as discussed earlier in this chapter. The characteristics of these are diverse and are vendor-specific. | 
