| Logically, synchronization between two applications requires the sharing of changes that the applications have made to data common to both applications. Synchronization also involves potential reconciliation of conflicting changes made concurrently. If applications can represent what has changed in a manner that is mutually understood, and are able to communicate those changes in an agreed upon fashion, they can synchronize their data. SyncML is primarily based upon this observation. Naturally, the two fundamental parts of the SyncML data synchronization specification are the SyncML Representation Protocol and the SyncML Synchronization Protocol. The Representation Protocol is essentially the syntax for specifying the changes that an application has made to its data. The Synchronization Protocol is the specification of the sequence of packages that applications must exchange in order to communicate their changes to each other. Figure 2-2 illustrates the scope of the SyncML framework. The framework encompasses the Representation Protocol, the Synchronization Protocol, and the various transport bindings such as Hyper Text Transfer Protocol (HTTP) [RFC2616] and Object Exchange Protocol (OBEX™) [OBEX99]. The framework also includes elements of the SyncML reference implementation, such as the SyncML API and the SyncML adapter. The SyncML framework, however, does not include other synchronization-related programs, such as application, synchronization engine, and synchronization agent, that drive the framework. Instead, the framework assumes their existence. Figure 2-2. The main elements of the SyncML Framework and the entities that support the SyncML framework. 
In the figure, application A on a client device wants to synchronize its data with application B on a server computer. There is a logical entity called the "synchronization engine" on both the client and the server sides. The synchronization engine on the client typically only keeps track of local changes that the application makes to its data. The synchronization engine on the server also keeps track of local changes made by the server application, but in addition, it encapsulates intelligence about the semantics of application data. It stores and manipulates supporting metadata called "version" to account for changes made to data by multiple clients. It has methods to detect and resolve what constitutes a conflict between local changes to data and changes obtained from the synchronizing client. Although the synchronization engine plays a critical role in the synchronization process, it is not part of the SyncML specification. The synchronization engine can sometimes be part of the application itself. It is expected that competing mobile applications and synchronization vendors would want to differentiate themselves by advancing their synchronization engine technology. The synchronization engine is expected to co-ordinate synchronization using a "synchronization agent." The synchronization agent is primarily responsible for generating and processing SyncML Packages in the format and sequence specified by the SyncML Representation and Synchronization Protocols, respectively. The synchronization agent is also not part of the SyncML specification. Thus, although the synchronization agent is functionally defined, the particular ways of implementing the synchronization agent are not specified. The interaction between the synchronization engine and the synchronization agent is also unspecified. In some cases, the application, the synchronization engine, and the synchronization agent may all be combined. SyncML Basics One core element of the SyncML specifications is the Representation Protocol. The Representation Protocol specifies the logical structure and format of various SyncML Messages. The structure and format of a Message is specified using XML (eXtensible Markup Language). The use of a structured description language is essential and XML is a natural choice given its widespread acceptance and use. Figure 2-3 outlines a high-level structure of a SyncML Message. During synchronization, the synchronizing entities logically exchange Packages. Physically, each Package can be partitioned into multiple actual Messages that are communicated. There may be many instances in which a logical Package is broken down into several Messages for communication. One motivation for such Package fragmentation could be the lack of communication buffer space in a resource-constrained client, such as a mobile phone. Another motivation could be that smaller Messages are transmitted with higher degrees of success over a low-reliability and low-bandwidth wireless connection. The reader should associate Packages with logical units of communication during synchronization and Messages with physical units of communication during synchronization. Figure 2-3. The figure shows the logical structure of a SyncML Message 
Each SyncML message is a well-formed[1] XML document. The precise definition of a SyncML message is described in a XML Document Type Definition (DTD). The message consists of a header and a body. The header includes information such as the source and target application, routing, session, and authentication. The body of a SyncML message is a set of SyncML "commands." Each command identifies an operation that has been performed or being requested on a data item or a set of data items. Examples of operations include Add, Delete, Replace, Search, and Status. Each command identifies the relevant data items within itself. For example, the Replace command identifies data items replaced by an application in its datastore. When the synchronizing counterpart receives the message and processes the Replace command, it attempts to replace the same items in the corresponding application datastore. If there are no conflicts or errors, the replaced items are now reflected in both datastores. In other words, the replacements are successfully synchronized. The Representation Protocol does not impose any implicit order or other constraints concerning how multiple commands in a single message may be processed. For example, if a message contains multiple Add and Replace commands, the recipient may process those commands in any order. The Representation Protocol, however, allows sets of operations to be grouped together with special semantics. For example, the Atomic command element can contain other commands, such as Add or Replace, with semantics that require the recipient to either successfully process all commands within an Atomic group or process none at all. These types of capabilities allow SyncML to be used in commercial applications that may require transactional properties. Chapter 6 offers a more in-depth discussion of the SyncML Representation Protocol. [1] A well-formed XML document is one that is syntactically correct and conforms to its definition in a corresponding DTD.
The SyncML Representation Protocol only specifies the language spoken by two computers when they synchronize. The Synchronization Protocol specifies what the computers should say to each other in what sequence. Consider two persons who know the English language well enough to form correct, meaningful sentences. They will still not be able to have a successful conversation if they do not have an implicit understanding of what sentences should follow what sentences. For example, if two persons alternately say "What is your name?" "I live in London." "I asked you for your name." "London is in England."; the dialogue does not represent a successful conversation, even though both formed correct, meaningful sentences. Similarly, two computers cannot synchronize if they do not follow a prescribed sequence of packages, even if the individual packages are correct. This sequence of packages is specified by the SyncML Synchronization Protocol. The Synchronization Protocol defines the roles of the client and the server (Figure 2-4). Typically, the client is a mobile device, and the server is a network server or a personal computer. The distinction between a client and server, however, is logical. It is possible for two mobile devices to synchronize using SyncML where one assumes the role of a client and the other the role of a server. Usually, a client requests synchronization in its first message to the server. The server, however, can alert some clients to begin synchronization. For example, a network server can alert a mobile phone client to begin synchronization. The form of synchronization could be two-way or one-way. In two-way synchronization, the client and the server exchange and reconcile their respective updates. In one-way synchronization, only the client or the server sends its updates and the other receives and reconciles them. Two-way synchronization is useful for applications that update shared data concurrently, such as a family calendar or a store inventory. One-way synchronization can be very useful for clients that only need to read the latest data from a server or update a server with the latest data, such as downloading insurance rate quotes or uploading receipt delivery signatures. Chapter 5 provides an in-depth discussion of the SyncML Synchronization Protocol. Figure 2-4. This figure is a high-level illustration of the SyncML Synchronization Protocol. 
Additional Key Considerations In addition to the Representation and the Synchronization Protocols, SyncML takes additional considerations into account to enable practical, commercial data synchronization. The additional considerations pertain to network binding, acceptable and expected data formats, device capabilities, and security. Some of the additional considerations are embodied in actual supporting specifications, such as device and meta-information specifications. Some other considerations, such as security, manifest themselves inside the Synchronization and Representation Protocols. Two synchronizing entities must communicate over an actual network. Applications typically communicate using network transport protocols, such as HTTP. Although the SyncML Representation and the Synchronization Protocols are transport-independent, during synchronization the SyncML packages must be carried in actual messages over an actual transport protocol. Clearly, for different transports, the form of these messages could be different, even if they carry the same overall package. The form of messages for a particular transport is called a "transport binding." SyncML defines a few popular transport bindings such as HTTP, Wireless Session Protocol (WSP)[2] [WSP01], and OBEX.[3] The bindings are ancillary specifications that can be used by application developers. If one wants to use SyncML over a transport other than the three above, it is possible to define bindings for additional transports. For example, if one wants to synchronize using an email protocol, an additional transport binding such as Simple Mail Transfer Protocol (SMTP) [RFC2821] can easily be defined. Other potential significant transport bindings could include MQSeries®[4] [GS96], for corporate messaging applications that may want to use SyncML, or Remote Method Invocation (RMI)[5] [Gro01], for applications that may want to keep Java objects synchronized using SyncML. [2] WSP is a transport protocol specified as part of the WAP communication standard.
[3] OBEX is a transport protocol implemented on the Infrared and Bluetooth communication media.
[4] MQSeries is an IBM software product that supports messaging between applications running on multiple hosts.
[5] RMI is a Java specification that supports object-level communication between applications running on multiple hosts.
The application data formats are not specified in the Representation or the Synchronization Protocols. Two applications that synchronize must, however, understand the application data type and data format that they use. SyncML specifications cannot include all possible data formats for all possible data that may be synchronized using SyncML. Consequently, SyncML only identifies a few data formats that SyncML Servers must support for specific content types being synchronized to claim SyncML conformance and test interoperability between Clients and Servers.[6] These data formats relate to PIM applications and are adopted from emerging standards in calendar and contact data formats, such as vCard [VCARD21] and vCalendar [VCAL]. It is expected that representation standards will emerge for several classes of business-related data. For example, it is likely that an XML representation for data in Relational Databases will emerge in the near future. It is SyncML's goal to leverage such data standards and incorporate their use into SyncML. It may be useful to think about this process as establishing "data bindings" as such become necessary and appropriate. [6] From this point in the book onwards, the first letters of the words client and server are capitalized to mean a SyncML Client and a SyncML Server.
It is important for synchronizing computers to know about their respective capabilities, such as supported applications, data formats, and memory limitations. For example, before a server computer sends data to a mobile client, it may be important to know about the client's memory limitations so that the data does not cause a memory overflow in the client device. The synchronizing computers may need to know if they recognize and support each other's data types. The computers may need to know each other's version information for incremental synchronization since the last occurrence of synchronization. They may need to know the maximum allowable size of data identifiers. Datastores on clients and servers are rarely homogeneous. Hence, clients and servers typically use different types of identifiers to identify the same data item. Clients typically use a compact form of identifiers and servers use a more elaborate form. SyncML specifies how this type of device information and metainformation should be represented. Device information and other metainformation are exchanged at the beginning of synchronization between a Client and a Server when they are synchronizing for the first time or if there are changes to device information and meta-information since the last time they synchronized. Data security is also of critical importance in synchronization. Accessing and updating data must require appropriate authentication. SyncML allows multiple levels of sophistication of authentication. One may choose simple username-password schemes for personal applications, such as a Web calendar. One may choose Message Digest (MD5) based credentials or X.509 Certificates for corporate applications, such as inventory control. In addition, SyncML relies on secure transport layer mechanisms to ensure data protection for sensitive data when in transit across a network. Another key driving goal of SyncML is the rapid development of mobile applications and prototypes in an interoperable manner. To promote that goal, SyncML also provides a reference implementation of key parts of the SyncML framework on a number of platforms. The reference implementation serves as key enabling code that application writers can readily use to write SyncML applications. It implements the SyncML C-language API and a few transport bindings. The synchronization agent in Figure 2-2 may use the SyncML C API to generate, process, and communicate SyncML Messages. The SyncML C API is not part of the core specification but only a de facto available interface. Applications are free to generate SyncML Messages directly using their own means. The readily available reference implementation has, however, played a key role so far in the acceptance and popularity of the specification. |
