| A production SyncML Server is expected to have certain functional abilities that are commonly more than the minimal requirements for compliance and/or interoperability. The expectations include support for the following: Many device types Numerous data types A few different Sync Types Various authentication schemes Diverse types of back-end data sources Multiple transport protocols
Many types of devices may wish to synchronize with a SyncML Server. Devices vary in capabilities such as communication bandwidth and memory size. A SyncML Server needs to be aware of device capabilities and adjust its behavior accordingly. For example, depending on Client memory conditions, the Server may decide to partition SyncML Packages into multiple Messages. A Server also needs to share its capabilities with certain devices (e.g., supported applications and data types) for devices to make better decisions about synchronization. Servers use the Initialization phase in the Synchronization Protocol to discover device capabilities and store these capabilities in an internal table. With diversity of devices comes diversity of applications and diversity of data that the applications use. For compliance and interoperability, the SyncML Server already needs to support multiple common PIM data types. Other desirable data types include relational data, XML and HTML data, and binary data, such as music and pictures. An important issue in supporting multiple data types is the ability to support conversion of the data types to and from their external "standard" representations to "internal" or "back-end" representations. For example, there are many commercial calendar systems that do not export APIs that use the vCalendar format. If the Server wishes to allow mobile Clients to synchronize with such systems, it has to provide appropriate converters. As mentioned earlier, Servers may be required to perform filtering and field mapping for various data types and Clients. Sometimes, the display capabilities of mobile devices are limited. Certain forms of data (e.g., pictures) may need to be transcoded (e.g., from color to black-and-white) before they can be sent to the device. To enable end-to-end solutions acceptable to users, Servers must implement such transcoding functions or leverage existing transcoding libraries. SyncML Servers may need to support all the Sync Types in the specification. The types include One-way synchronization with only Client updates communicated to the Server, One-way synchronization with only Server updates communicated to the Client, and Two-way synchronization. Moreover, the Servers need to support all of the types where the Server is initiating the synchronization using a Server Alert message to a Client that is connected (by a mobile phone, for example). They also need to handle cases where some devices may choose not to respond to Server alerts. The Servers also need to support "slow synchronization" upon detecting certain failures, where the contents of entire datastores are exchanged instead of only updates. Applications require varying levels of authentication. Some applications only require basic username-password authentication, while other applications require more elaborate authentication using message digests or Certificates. In some scenarios, authenticating the user with the SyncML Server is enough. In other scenarios, the user needs to be authenticated to individual datastores. In yet other scenarios, the user may need to be authenticated for individual object access in a given datastore. The SyncML Server should be able to support most (if not all) of these authentication levels. A SyncML Server, especially an Enterprise Server, should be able to support multiple back-end datastores. This requirement not only includes supporting back-end specific formats but supporting access to back-ends using the specific APIs offered by the back-end datastores. If a Server stores some data in a Relational Database, it would need to use the standard JDBC or Open Database Connectivity (ODBC) [San98] APIs. If the Server chooses to store data in the file system, it needs to use the file-access APIs of the underlying platform. In some cases, the back-end datastore may actually be an application that exposes its own API, such as Lotus Notes[7] or Microsoft Exchange. In such cases, the SyncML Server needs to use the APIs provided by these applications. As observed in the previous section, in single-path synchronization, it is a relatively straightforward matter of invoking the correct back-end APIs for data access. In multiple-path synchronization, supporting diverse back-end stores is more complex, as specific Datastore Adapters may need to be implemented that need more complex function than only data access. [7] Lotus Notes is the name for the end-to-end application. The Notes Server is actually called Lotus Domino. At many points in this chapter, we implicitly refer to the Lotus Notes Server and hence actually to Lotus Domino.
SyncML Servers also need to support multiple transport protocols. It will be common for SyncML Servers to be accessed by HTTP Clients or by WAP™ (Wireless Application Protocol) Clients coming through a WAP gateway. Although one can argue that the WAP gateway hides the fact that the Client is a WAP Client and converts the WAP messages into HTTP messages, the Server can still benefit by knowing the eventual communication protocol that the Client uses. For example, WAP gateways have message size limitations that may compel the SyncML Server to partition Packages into multiple Messages that it otherwise would not have to for an HTTP Client. |
