Synchronization. Kari Pihkala HUT, Telecommunications Software and Multimedia Laboratory. Abstract

Transcription

1 Synchronization Kari Pihkala HUT, Telecommunications Software and Multimedia Laboratory Abstract This paper discusses various synchronization methods for mobile devices. It gives an overview of today s standards, IrDA and SyncML, and presents some existing synchronization systems. Legacy synchronization methods use incompatible proprietary protocols. Recently, a standardization effort was initiated to create SyncML, an open standard for data synchronization. However, there is still a long way before every device can be synchronized with any database, in any location, at any time. 1 INTRODUCTION Nowadays, different kinds of mobile devices are available for consumers. These devices are currently discrete entities, such as mobile phones or Personal Digital Assistants (PDA). The rapid development of technology will enable production of smaller and more powerful devices. According to Moore s Law, the quantity of elements in microchips will double every 18 months. In the future, the mobile devices around us will be more powerful and less noticeable, integrating into the surrounding environment. These devices will also be embedded in, for instance, clothes, cars, and home appliances. Thus, the use of these devices is called pervasive computing, or ubiquitous computing, as the devices will be all around and accessible everywhere. Mobile devices typically store some personal information for its user, e.g., phone numbers, addresses, and preferences. As the number of devices around us increases, it will be useful to have all the devices communicating with each other. The personal information will be entered only into one device, and will automatically propagate into other devices. To share data, the devices require a mechanism to transfer it. This has been the rationale for synchronization. This paper describes most common methods for synchronization and has been organized as follows. In section 2, the background for data synchronization is given. Then, the standards for data synchronization are presented. In section four, few of current data synchronization implementations are described. Section five discusses problems and future of data synchronization, while the last section draws conclusions. 1

2 2 BACKGROUND Usually, computers contain some personal information, e.g., personal calendar, address book, or memos. This information is commonly also on one or more central servers. This way, information can be updated easily on the central server and then copied down to the client computer. Manually copying is a tedious task, and therefore copying is usually made automatically. However, if information is changed on a client computer, it should also be uploaded to the central server. This works fine until the client loses network connection and information is changed simultaneously on the server and the client. Then, when the network connection is re-established, and the automatic copying happens, there will be a conflict. Which updated information should have priority? There are several ways to cope with these kinds of conflicts. The most recently made changes could be kept, or the user could be prompted to help in the process. This kind of copying, keeping two sets of data identical, even during conflicts, is called data synchronization (Hansmann, 2001, pp ). 3 STANDARDS This section presents standards for data synchronization. Infrared Data Association has defined a set of standards defining a hardware level synchronization over an infrared channel, while SyncML is a more complete system defining a data synchronization protocol. 3.1 Infrared Data Association The Infrared Data Association (IrDA) has defined several protocols to handle infrared data transfer. These are (Infrared Data Association, 2001) IrDA Data for high speed short range, line of sight, point-to-point cordless data transfer - suitable for Handheld Personal Computers (HPC), digital cameras, handheld data collection devices, etc., IrDA Control for lower speed, full cross range, point-to-point or to-multipoint cordless controller - suitable for keyboards (1way), joysticks (2 way & low latency) etc., IrCOMM provides COM (serial and parallel) port emulation for legacy COM applications, printing and modem devices, IrOBEX provides object exchange services similar to HTTP, IrDA Lite provides methods of reducing the size of IrDA code while maintaining compatibility with full implementations, IrTran-P provides image exchange protocol used in Digital Image capture devices/cameras, 2

3 IrMC specifies how mobile telephony and communication devices can exchange information. This includes phonebook, calendar, and message data. Also how call control and real-time voice are handled, IrLAN describes a protocol used to support IR wireless access to local area networks. Especially Specification for Infrared Mobile Communications (IrMC) specifies information exchange for mobile devices. The specification is quite limited, concentrating on few application areas, and working only in local area. Thus, it lacks the ability to control a large set of data in a wide area networks. 3.2 SyncML SyncML is a next generation standard for data synchronization. It includes the following characteristics: operate over wireless and wired networks, support a variety of transport protocols, support arbitrary networked data, enable data access from a variety of applications, and address the resource limitations of the mobile devices. Also, it has been build on existing Internet and Web technologies. SyncML defines the data format and the protocol for data synchronization, and thus is a complete system for data synchronization. Figure 1 depicts the SyncML protocol architecture. It is possible to run SyncML over HTTP, WSP, or OBEX protocol. Similarly, the network or link between the server and client can be Internet, WAP, or IrDA based. The SyncML layer defines the data format and protocol for synchronization, and these can be used via an SyncML interface. The Sync Client Agent and Sync Server Agent are used to access the network and to communicate the data synchronization operations via the SyncML interface. On the server side, the data is merged and possible conflicts are solved by the Sync Server Engine. The Sync Server Engine usually resides on the server side, but it can also be on the client side. On top of the stacks are the actual applications requesting synchronization. (SyncML, 2001) Sync Client App Sync Client Agent Sync Server App Sync Server Engine SyncML http WSP obex Internet WAP IrDA Sync Server Agent SyncML Transport Physical Medium SyncML interface Client Figure 1: SyncML Protocol Architecture. Server 3

4 The SyncML protocol describes the order of messages and responses to them. Messages are written in XML based language and consist of two parts, the header and body. A simple example is depicted in Figure 2. The header contains metadata, while the body carries the data. In the example, the source element is used to identify the Sync server. The target element specifies the Sync client. The other header elements specify the version of the protocol and Ids. In this example, the body part only tells the client that the server cannot handle the synchronization request because it is busy. (Martin, 2000). <SyncML> <SyncHdr> <VerDTD>1.0</VerDTD> <VerProto>SyncML/1.0</VerProto> <SessionID>1</SessionID> <MsgID>2</MsgID> <Target><LocURI>IMEI: </LocURI></Target> <Source><LocURI> </SyncHdr> <SyncBody> <Status> <MsgRef>2</MsgRef><CmdRef>0</CmdRef><Cmd>SyncHdr</Cmd> <TargetRef> <SourceRef>IMEI: </SourceRef> <Data>101</Data> <!--Status code for Busy--> </Status> </SyncBody> </SyncML> Figure 2: Snippet of SyncML message. The client and server can exchange other kind of messages, too. These include <Add> to add data, <Alert> to notify the target, <Atomic> to inform the originator that a set of commands should be performed with all or nothing semantics, <Copy> to copy some data to the target, <Delete> to delete some data on the target agent, <Exec> to invoke an executable on the target agent, <Get> to get some data from the target agent, <Map> to allow the originator to ask the recipient to update the identifier mapping between two data collections, <Put> to put some data on the target agent's storage, <Replace> to replace some data, <Search> to perform a query on the target agent, 4

5 <Sequence> to indicate that the commands are to be executed in sequence, and <Sync> to indicate that the included commands should be treated as part of the Synchronization of two data collections. Figure 3 gives an example of adding a vcard (IMC, 2001) on the target agent database. Of course, this <add> command will be contained in a <syncbody> element. The example has the vcard inside the <data> element, but it is also possible to just mention the relative URI of the data source. In that case, the recipient has to retrieve the data from the specified network location. <Add> <CmdID>12345</CmdID> <Cred> <Meta> <Type xmlns="syncml:metinf">syncml:auth-md5</type> <Format xmlns="syncml:metinf">b64</format> </Meta> <Data>OGNkNDI1ZTZjNjgwMTNiYWZkOWEyN2JjMjNlZDM4YzENCg==</Data> </Cred> <Meta> <Format xmlns="syncml:metinf">chr</format> <Type xmlns="syncml:metinf">text/x-vcard</type> </Meta> <Item> <Source> <LocURI>./2</LocURI> </Source> <Data>BEGIN:VCARD VERSION:2.1 FN:Bruce Smith N:Smith;Bruce TEL;WORK;VOICE: TEL;WORK;FAX: ;INTERNET:bruce1@host.com END:VCARD </Data> </Item> </Add> Figure 3: Adding a vcard to the target agent database. SyncML messages are encoded in XML, and can be identified with a MIME content type of application/vnd.syncml+xml. To save sparse mobile network bandwidth, SyncML messages can also be encoded in WAP Binary XML (WBXML), which is identified with a MIME content type of application/vnd.syncml+wbxml (Stemberger, 2001). 4 TODAY S SOLUTIONS There are several synchronization systems provided by the current handheld and mobile device manufacturers. This section concentrates on some of these. 5

6 4.1 Palm Pilot The Palm Pilot handheld comes with a proprietary synchronization mechanism designed for Palm OS, working between a Palm Pilot handheld and Palm s desktop portal. The desktop portal runs on either Microsoft s Windows or MacOS. The desktop portal includes a basic Personal Information Manager (PIM), designed to handle Palm Pilot information. It has a calendar, an address book, a to do list, and a memo. All of these can be modified on the desktop portal or Palm Pilot itself. The desktop portal can be used to send and receive data to other programs, such as Microsoft Outlook. Other PIM vendors can also develop customized conduits to enable data synchronization to their products. There are several ways Palm can be synchronized. Figure 4 depicts the four different methods. The simplest way is a direct Serial to PC link (a), which operates over a physical serial cable. It is also possible to synchronize over a modem (b), thus allowing remote synchronization to the desktop. Another way to perform a remote synchronization is over a LAN or WAN. The Palm Pilot handheld can be connected with any computer in the network and the synchronization will be performed over the network with the user s computer. This is similar to the Serial to PC link, except the desktop client is physically elsewhere in the network. Because Palm Pilot has an infrared (IR) port, it is also possible to synchronize using it. Palm supports the IrCOMM implementation of the IrDA standards. If the desktop computer also supports it, it is possible to perform an IrComm to PC synchronization (c). Also, the modem can be operated in this fashion. Some mobile phones equipped with an IR port may also be used as a modem (d). modem modem modem phone (a) (b) (c) (d) Figure 4: Connection methods for Palm Pilot synchronization. Palm is capable of synchronizing any kind of data and applications. Thus, all data on the handheld can be backed up on the desktop portal. In case of data synchronization conflicts, the client and server will have both copies of conflicted files, the client and server version. Thus, it is the responsibility of the user to solve any conflicts (Palm Computing, Inc., 1999). 6

7 The Palm synchronization follows the IrDA standards mentioned in section 3.1 and thus provides hardware level compatibility with other devices. However, it currently doesn t use open data format, which makes it impossible to synchronize it to anything else than the Palm s desktop portal, or another Palm Pilot. 4.2 Pocket PC Microsoft s Pocket PC (former Windows CE) uses Microsoft s ActiveSync, which is also a proprietary synchronization system. It is possible to use the same synchronization methods as with the Palm Pilot, using a direct serial link, a modem, an IR port, or a mobile phone. It is also possible to make data conversions during synchronization. (Compaq, 2000) Similarly to Palm Pilot, Pocket PC is IrDA compliant, making it hardware level compatible with other devices. Pocket PC operating system can be run on Compaq ipaq, HP Jornada and Casio Cassiopeia, thus enabling synchronization between these machines. However, synchronization cannot happen with other devices without Pocket PC and ActiveSync software. 4.3 DB2 Everyplace IBM has developed a widely working platform for data synchronization and application management. DB2 Everyplace relies on client server architecture. The client software can be run on several devices, such as Palm OS devices, Symbian EPOC devices, QNX Neutrino devices, embedded Linux devices, Windows CE and Pocket PC devices and Win32 platform. On the client, a proprietary database is used to save data. It can then be accessed using a subset of SQL99, some ODBC, or JDBC. JDBC enables Java applications to access the local client database. The server software can access several databases. This includes DB2, Oracle, Microsoft SQL server, Domino and Exchange. Thus, the system gives a lot of flexibility, as depicted in Figure 5. As the synchronizer engine, DB2 Everyplace uses the SyncML framework (IBM, 2001a). DB2 family Local data Local data adapters SyncML SyncML Database adapters Oracle MSSQL Server Domino Exchange Figure 5: DB2 Everyplace Sync Server design overview. 7

8 DB2 Everyplace is intended to be a whole organization solution. The users on clientside can request for synchronization at any time, but the server can also be commanded to synchronize devices. As both, data and applications, can be transferred, the system can be used to control and update the client device applications. This makes maintenance of mobile devices easy for users, as it can be done remotely from a central server. (IBM, 2001b). 4.4 IntelliSync PumaTech has synchronization software called IntelliSync. It runs on Palm OS, Pocket PC, Windows CE, and Symbian devices. It is a client server architecture. The server can replicate data from the client to Microsoft Exchange, Lotus Domino, or Lotus Domino R5. It allows the user to synchronize data simultaneously to several applications, e.g., Microsoft Outlook, Schedule+, Lotus Notes, Novell GroupWise, and ACT!. (Puma Technology, 2001) 4.5 TrueSync Starfish Software has TrueSync, which is a platform to create synchronization infrastructure. It has a server software, able to access several PC applications, such as Microsoft Outlook, Schedule+, ACT!, and Lotus Notes. The client software currently runs on Palm OS, Windows CE, Pocket PC, Motorola pagers, and SyncML-enabled devices, with some restrictions. TrueSync is built on top of SyncML framework, thus ready for any SyncML enabled device. (Starfish Software, 2001) 4.6 SyncML devices There are some other SyncML based devices on the market. Nokia s 9210 Communicator is one of the first mobile devices supporting SyncML. Also, Ericsson has released a SyncML based mobile phone T39. Motorola has incorporated TrueSync with some of their pagers and phones. (Stemberger, 2001) 5 PROBLEMS AND THE FUTURE The proprietary systems described in the last section, e.g., Palm and ActiveSync, have severe problems. They only work with the designed devices. Thus, it is rare that a Linux or Unix box could be run as a synchronization server. Also, larger scale synchronization, from central database to various mobile devices may be unachievable. SyncML is certainly the protocol of the future, as interoperability between devices and network databases becomes a bigger priority for businesses and consumers. SyncML promises to connect all devices together with a common protocol and it is also likely that this will happen to some extent. Nokia, Ericsson, IBM, Motorola, and Starfish Software have already implemented SyncML compliance into their devices and systems. 8

9 Palm has promised that the next version of their desktop portal (HotSync server) will be SyncML compliant. Symbian has made SyncML a core component of the Symbian OS. However, there is still a long way to a perfect world, where every device could be synchronized with any database, in any location, at any time. One of the problems is that not all vendors are yet supporting the new standard. For instance, Microsoft has remained outside the SyncML initiative. It has a large marketshare in mobile devices (PocketPC) and server databases (SQL Server), but instead of supporting SyncML, it markets its proprietary ActiveSync software, which is optimized for retrieving data from Microsoft s SQL Server database. This will undoubtedly slow down the spread of SyncML. Another problem is the partial implementation of the standard by vendors. Many vendors have claimed full support of SyncML, but haven t yet implemented the standard into their products in full. This increases the possibility that different devices use the same protocol, but still cannot communicate with each others (Stemberger, 2001). 6 CONCLUSIONS In the future, the world will be full of small-scale computers. These can be mobile phones, PDAs, and laptop computers, but also embedded computers in cars, clothes, and home appliances. These devices are able to store personal information, e.g., addresses, and phone numbers. Entering such data to every device would be a frustrating task, and an automated method is preferred. Data synchronization provides a method for transferring data between various devices, at the same time converting the file formats and resolving any conflicts in the data exchange. As mobile devices started to appear on the market, they needed a way to synchronize themselves with a desktop computer, to create a backup, or to share data. Device vendors started to implement their own proprietary synchronization systems, optimized for their devices. This has led us into a world with incompatible devices, each using its own system. As the number of mobile devices increases around us, there will be a demand for a common standard, otherwise the users will find the new mobile devices cumbersome and will not adopt them. As the problem with proprietary systems was recognized, an initiative for a common standard, SyncML, was made. It is an open standard designed by major mobile device manufacturers. The goal of the new standard is to allow any device to be able to synchronize itself with any other device. However, it will take some time before this will be reality, as the standard hasn t yet been implemented widely. REFERENCES Compaq Ipaq H3000 Pocket PC Reference Guide. Hansmann, U. et al., Pervasive Computing Handbook. Berlin, Springer. pp

10 IBM. 2001a. Have your database Everyplace. [ref ] <URL: ibm.com/developerworks/library/wi-everyplace/?dwzone=wireless> IBM. 2001b. IBM DB2 Everyplace. [ref ] <URL: IMC vcard - The electronic business card - Version 2.1. [ref ] <URL: Infrared Data Association Infrared Mobile Communications. [ref ] <URL: Martin, D Staying in Sync. [ref ] <URL: Palm Computing, Inc Handbook for the Palm V Organizer. Puma Technology Intellisync. [ref ] <URL: Starfish Software TrueSync. [ref ] <URL: Stemberger, S Syncing data. [ref ] <URL: ibm.com/developerworks/wireless/library/wi-syncml/>. SyncML [ref ] <URL: 10