SyncML is an important enabler for mobile applications, as a number of different applications need data synchronization capabilities in wireless devices. When creating synchronization services for SyncML enabled wireless devices, it is important to understand which applications are usually supported and how they are supported in these devices.
There are several usage models in which mobile data synchronization is utilized. Four models are addressed below. More synchronization usage models and use cases are introduced in Chapter 3, SyncML Applications.
Mobile data synchronization can be used to share information among multiple entities. For instance, calendar data is simultaneously used by an employee and by his/her secretary. Or a group calendar can be stored in a Server with that information shared among many people.
The same person as in the first usage model might want data to be available in multiple locations due to usability concerns. When the person is at the office, he wants to access data by using a desktop computer. On the other hand, when he is out of the office, he may only carry a handheld mobile device with him.
Backup and restore functionality can easily be provided by a synchronization application. That is, a user may want to back up his data to a network every now and then to ensure that data is not lost.
Data synchronization can also be associated with public data distribution. If frequently updated data is distributed into a large number of devices, mobile data synchronization can offer huge benefits in time and bandwidth saved.
The usage models listed above can be applied differently, depending on the application requiring data synchronization. Some of them may not be even suitable or desirable for some applications, while having a high priority for other applications. The usage model is also affected by the target market segment, such as consumer or enterprise.
Companies implementing SyncML have started from a limited set of application types and enabled SyncML based synchronization of these applications. For instance, contacts and calendars are supported by most public SyncML Client implementations. Fortunately, the next application types beyond PIM data are already being addressed, as end-users perceive the benefits of SyncML and new applications built on top of SyncML.
Different Client implementations in mobile devices can add support for different application types, but there are a few questions that need to be answered. First, the business case for synchronizing the content of a specific application type needs to be ascertained. Second, it needs to be ensured that there is an interoperable way to synchronize the content type. Without mutually agreed upon data formats (if not standard data formats), it is impossible to achieve interoperability between diverse Client and Servers.
The content format question introduced above has been answered for a set of application types that are commonly used in mobile devices. Those application types are enumerated in Table 11-3. Formats or MIME types associated with these application types are also described. The format describes how the content of an application is transferred in an interoperable way. The timeframe in Table 11-3 represents when it is expected that this application type is or will likely be widely supported by mobile devices. "Now" means that the application type is commonly supported already in 2002. "Near" indicates that the type will be supported within the next 2 3 years. "Far" stands for the distant future or indicates that it is impossible to evaluate when the application support will be enabled.
Table 11-3. Application Types for SyncML in Mobile Devices
vCard 2.1, vCard 3.0
vCard 2.1 is more widely supported by mobile devices.
vCalendar 1.0, iCalendar 2.0
vCalendar 1.0 is more widely supported in mobile devices.
vCalendar 1.0, iCalendar 2.0
Application type can be integrated into the Calendar application.
vNote 1.0, Plain Text
Plain Text is more widely supported.
MIME Message (RFC2045, RFC2822)
RFC2045 describes the attachments.
HTML, WML, XHTML
WML is used for the WAP 1.x pages.
This can mean any kind of files, such as pictures and documents.
Proprietary data formats need to be used here, as requirements vary.
The contacts application type is found in most mobile terminals. In mobile phones, it is also called the phonebook application. This application is traditionally used to contain information about personal contacts. In the future, as more contacts are included in mobile devices, the contacts application can be used to handle a wider range of information, like corporate phonebooks or yellow pages. Large datastores of these kinds naturally contain massive amounts of contact information, all of which is changing all the time and must be kept up to date in the device.
Electronic calendars and to-do lists are appearing in more places than just traditional business environments. People utilize them in desktop computers, PDAs, and mobile phones. Data synchronization enables this type of multi-device usage. Electronic calendars have also been introduced in different Web services for both private and public usage. Through these services, all content related to scheduling could also be enabled for mobile phone users. For instance, music concert events or football matches could be synchronized to mobile devices.
In the near future, more application types will be seen in mobile terminals. Some of them are already there, but data synchronization has not yet been utilized for them. Notes, browser, messaging, and file manager are such applications. Using data synchronization with them offers new possibilities to provide additional and different kinds of content to end-users.
As mobile devices evolve, more sophisticated applications will emerge. The emerging applications will likely be more customized for specific purposes, as has happened in PC and Server environments. As this happens, more specific enterprise application types and Relational Databases will be seen in mobile devices. At that time, data synchronization will be essential in order to enable the usage of these applications.
SyncML Requirements of Applications and Datastores
SyncML is content-type agnostic. Nevertheless, there are some requirements for the content to be synchronized using SyncML. In other words, SyncML impacts the application or the datastore of the application residing on a wireless device. By taking this into account in the early phase of design, adding SyncML support for the application is convenient and straightforward.
At a minimum, the application and the datastore implementation of the application desiring the synchronization support are required to provide the following services for the Client software:
Data items in a datastore of the application are accessible.
Data items are uniquely identifiable in a datastore.
Changes of data items and types of changes are detectable.
Data items can be converted from a native datastore format to a transferable and interoperable content format and vice versa.
The first required service is very obvious. Data items need to be read, modified, and inserted into a datastore. In the Client software architecture presented earlier, this means that the DS adapter operates the datastore as depicted in Figure 11-2.
Figure 11-2. The DS adapter accessing a datastore
SyncML technology is designed in such a way that data items are addressed by using local unique identifiers (LUIDs) within a datastore. As a consequence, this is also a requirement for a datastore. All data items in the datastore must be accessible through these LUIDs. Also, when inserting a new data item, a datastore needs to assign a LUID for the item. In practice, the DS adapter uses the LUID as a parameter for operations on the data items in a datastore.
The third requirement for the datastore of the application is that changed data items must be detectable. This is needed so all data items modified since a previous synchronization session are sent to a Server. There are multiple ways to detect modifications. For instance, the time when a modification has happened can be stored in a datastore. Alternatively, datastores might maintain sequence numbers or dirty bits for the items in the datastore. In addition to the modification detection, the type of modification also needs to be visible. In general, the modification can be an addition, an update, or a deletion. SyncML Clients are only required to indicate whether the modification is an update or a deletion.
It is important to transfer the application content in an interoperable manner. To achieve this, a standard or widely adopted content format is used (e.g. vCard [VCARD21]). This is not necessarily the format in which the applications store the data in their datastores. Conversion to and from the content format is needed when transferring the application content. The conversion can happen in the datastore interface, but it can also happen in the Client software, especially in the DS adapter (see Figure 11-3). If the application uses the same content format for other communication purposes, then this conversion should definitely be offered by the datastore interface.
Figure 11-3. Format conversion for data transfer
In wireless devices, there are possibly more requirements for the applications and their datastores to enable the SyncML synchronization. The requirements can be quite application-specific and dependent on the features provided by different application implementations. These types of requirements should be evaluated on an application-by-application or a "mobile software platform"-by-"mobile software platform" basis before the design and implementation of the application is started.