Implementing Data Synchronization on Mobile Wireless Agents

ADRIAN SERGIU DARABANT, HOREA TODORAN Dept. of Computer Science Babes-Bolyai University

1, Kogalniceanu street, Cluj-Napoca ROMANIA

http://www.cs.ubbcluj.ro Abstract: - Mobile salesmen out in the wild and the entire commercial store with them? A while ago this would have seemed atypical. Nowadays, it has become a must have asset for any salesmen-based commercial enterprise. In the past, the Web brought the virtual store to the client’s premises. While this is still enough for certain types of commerce, negotiation is a pre-requisite for selling most of industrial items in large quantities. Having a salesman carrying all the necessary information to conduct a win-win negotiation with the clients is a difficult task. What about being able to consult and provide accurate, updated information about stocks, client credit and statistical data? All this could be easily implemented in a mobile solution. We present in this paper a pilot implementation of a mobile store solution with dynamic and efficient data synchronization using wireless technologies. Key-Words: mobile applications, wireless data synchronization, personal digital assistants, mobile virtual stores.

1 Introduction Personal Digital Assistants (PDAs), also known as ‘palmtops’ or ‘handheld PCs’, have been initially conceived as simple electronic organizers for address books and diaries. They eventually evolved into mini computers designed for carrying out more complex, but still common activities like word processing, spreadsheet editing, or even multimedia presentation authoring. The utility of current models have been enhanced by incorporating digital cameras, multimedia players, GPS devices for the location of destinations, or by combining the function of a mobile phone and a PDA in one single unit. Moreover, most of the latest devices offer wireless connectivity (WiFi, Bluetooth, infrared beam), thus facilitating data transfer across networks and other useful services, including web browsing, email, messaging. Therefore, PDAs are able to accomplish virtually the whole range of tasks that a desktop computer or a laptop could perform.

The advantages of palmtops over other mobile devices accomplishing the same tasks include a higher degree of portability and mobility (they are about 10 times lighter than laptops or TabletPCs, fit into the jacket’s pocket, can be hold into one hand and operated with the other, can run on the move), and lower power consumption (the battery life lasts roughly two times longer than for laptops). Additionally, PDAs are cheaper that their counterparts

and very easy to use, thus being called “equity computers” by some authors (e.g. Andrew Trotter quoted in [1]). These are the main reasons for us to believe that handheld computers have the potential to become more and more exploited in various fields in the near future, including business, education, medicine, and leisure.

Nonetheless, there are also disadvantages when using PDAs. The most significant are related to the small size of the screen, which confines the amount of information displayed or requires the intensive use of navigation bars. The keyboard and the mouse are very small (if at all present), thus making data input more difficult than in the case of desktop computers or laptops. The stylus pens are quite narrow, therefore requiring accurate operation on the screen pad. Palmtops have rather limited storage capabilities, are difficult to upgrade and much less robust than TabletPCs, laptops, and desktop computers (see [2] for a detailed comparison). Having these limitations in mind, software producers must design applications running on PDAs more carefully than those for the other types of PCs. As a good practice example, the Windows Mobile for PocketPC family includes scale down versions of the Microsoft Windows operating systems, very similar to the desktop versions, though adapted in terms of minimal requirements (memory, processor speed) and visual elements (windows,

Proceedings of the 10th WSEAS International Conference on COMPUTERS, Vouliagmeni, Athens, Greece, July 13-15, 2006 (pp57-62)

menus, lists, buttons) to the characteristics of PocketPCs. 2 Problem Formulation The goal of the present paper is to present the architecture and the functionality of a software product that we designed and implemented for the mobile agents of a sales company. The application not only facilitates the management of various sets of information (customers, products, orders, and so on) using the PDA, but also synchronizes the data between the mobile device and the company’s database server. We will also discuss usability aspects, in the final part of the current paper.

Acquiring and keeping new clients in salesmen-based commerce industry often requires salesmen bringing the entire store with them, in order to be able to show the client all the features of a product set, to negotiate the prices and handle the delivery time slots. This is possible in two ways:

• Highly qualified sales personnel capable of memorizing characteristics of thousands of products, prices and their availability, or some mixed cocktail of memorized data and catalogues for presentation.

• Using a computer-based solution, with hardware that is small enough to fit easily into the jacket’s pocket, and with enough computing and communication power to rapidly bring data on demand from the virtual store onto the device.

While there are situations where it is feasible for salesmen to take catalogues with them, these do not always provide the most up-to-date information when handling negotiation. They usually cover only the products’ characteristics, but there is neither live data about the current stocks, nor client specific information that would help the salesman to properly negotiate each new order (e.g. the current credit allocated to the client, payment delays, other statistical data).

In this paper, we propose a novel software architecture on mobile devices with communication capacities, solution that can be linked with any exiting store management software. We implemented the proposed framework on mobile assistants (PDAs) with cellular phone and/or wireless 802.11 capabilities [3, 4] in a pilot project that has been experimentally linked with the management system of a commercial

enterprise [4]. With the aid of the new framework the enterprise is able to keep its salesmen out on the field for an average of 98% of the time. Whenever they need sensitive or live information, they can get it on their mobile devices. Whether we talk about sensitive data (prices, client status and its current debt, client credibility when it comes to payment delays, sales turnover) or marketing data (statistics about best-sellers and worst-sellers among products, most selected product provider, and so on) the salesman can have it almost instantly on his/her device. Comparing the acquisition prices with the publicly displayed prices (for selling items) helps the sales agent negotiate orders from clients on a win-win basis.

2.1 Data flow Usually, any commercial enterprise has a central or a set of central warehouses and premises where the administrative staff is located. Clients frequently send online and phone orders or estimates to the central facility, which afterwards dispatches them to the salesmen. Sales agents usually cover a well- determined geographical area and have a portfolio of clients that they are handling on a regular basis. This policy helps building on confidence and a trusty long time relationship, as the same salesman is handling orders and estimates from the same client. The typical data flow within the business architecture we are trying to model is represented in Fig. 1

Fig.1 Business information flow

The client typically asks for an estimate or has a

direct order that is passed to the central facility of the commerce enterprise. Then the estimate is allocated to the correspondent salesman, usually with a fixed date

Proceedings of the 10th WSEAS International Conference on COMPUTERS, Vouliagmeni, Athens, Greece, July 13-15, 2006 (pp57-62)

appointment with the client. The assignment is either pushed by the system to the salesman’s device or automatically collected by the sales agent himself when synchronizing his data with the central store. Upon receiving the order/estimate demand, the salesman confirms the appointment in his own schedule and heads to the client offices at the specified date. At the client’s premises, the sales agents already have all the necessary information to conduct the negotiation on their devices: products public prices, product offer prices, customized previous prices for a given product and the given client, requested quantities, client status and payment history, client debts and ongoing transactions, and so on. They might also receive promotions with products sold at a lower rate than usual. The salesman builds the order for the estimation requirement sent by the client into a caddy-like structure, where each product is presented with its own code, description, unit price, price rebates, and further relevant information.

When the entire order has been successfully mediated, it is added to the list of completed orders on the salesman device – it is now ready to be sent to the central office for delivery. The commercial enterprise

will deliver the products to the client and will request the payment in order to complete the sale.

3 System Architecture and Services In the following paragraphs we present the proposed system architecture that has been already implemented in the pilot project (MobSel). One of our major requirements was to build a system that is as least intrusive as possible in the existing client’s management software (EMS). With this goal in mind, we need to link the mobile system facilities to an existing software solution in such way that there are no modifications required for the already implemented solution.

We used the following model to implement the mobile architecture on the top of the existing AS400 management software, which runs on the IBM AS400 hardware architecture with dedicated software. We present this particular architectural model here, as opposed to a more common known data management system, in order to show the degree of independence between the mobile system and the existing management solution.

GPRS/ UMTS/ 802.11/ HUB

Internet Wireless Communication

GSM/GPRS/UMTS/802.11

Mobile Salesman running MobSel

Enterprise

AS400 System

Data Exchange

MobSel GATEWAY (MGW)

Apache PHP WebServer

Fig. 2 – The MobSel System Architecture and Integration with the Existing Management Software

Proceedings of the 10th WSEAS International Conference on COMPUTERS, Vouliagmeni, Athens, Greece, July 13-15, 2006 (pp57-62)

Even if it is a challenging task, the integration between any existing management software (EMS) and MobSel is always possible with little or no intrusion at all in the EMS. In order to implement the MobSel solution we suppose that the commerce enterprise already has an Internet connection. We further suppose that, in most of the cases, the internal network of the enterprise is protected by a firewall that separates the Intranet from the Internet.

In Fig. 2 the salesmen are running MobSel on Pocket PC devices with incorporated GSM phones or wireless radio cards (WiFi). The choice of GPRS/UMTS or wireless is conditioned by the necessary connection persistence. If connection is desired at any particular moment, the best choice is GPRS/UMTS, both requiring a GSM line. For connections only in high urban areas with Wifi hotspots, the 802.11 might be a useful variant.

As there is no defined interface between an AS400 architecture and mobile devices, and because we want to keep the independence between the EMS and MobSel, we have built MobSel around a gateway server (MGW) that will handle all mobile device communication and execute the requested operations on the EMS. The MGW is running an Apache PHP server. It acts as a middleware between the AS400 system and the mobile users. We used an over HTTP communication protocol in order to ensure that the system keeps functioning in the most restrictive configurations. All that is needed is a TCP link transporting HTTP. All requests from mobile devices are sent over HTTP to the MGW, which handles them and sends back the answers. In the case of GPRS/UMTS protocols, all requests from mobile devices are transported over GPRS/UMTS to the GSM service provider and transferred over Internet to the MGW server as an HTTP request. In our current model, the mobile device is always the dialog initiator. This way, the GPRS connection does not need to be permanently connected.

3.1 Availability and failure handling We can identify three major components in the system architecture that ensure application isolation and impendence in the case of temporary failure:

1. The mobile device. 2. The MobSel Gateway server 3. The AS400 system (EMS system)

The EMS system (AS400 in this case) is completely isolated from any failure of the MobSel system. In

situations of MobSel failure the fact that the system is non-intrusive allows the EMS to run normally as it wouldn’t be connected at all to MobSel. Nevertheless, in these cases the mobile devices won’t be able to send and receive data from the system anymore. The EMS is the central point of data storage and the most important one. Data backups need only be performed at this level.

The MobSel Gateway server runs a HTPP server and also stores a highly updated copy (snapshot) of the sensitive data from the EMS. The snapshot usually contains complete information about products, orders, frequently used providers, and statistical data. In the event of EMS failure, the MGW is still capable to provide recent product information, statistic data, recent orders and provider data, and so on. However, it is not capable to handle finalized orders sent for invoicing and delivery, as they should be handled by the EMS. Any requests to finalize an order in the event of EMS failure will temporary fail.

The mobile devices (Pocket PCs) run the MobSel application and a smaller local data repository. The local data repository stores data specific to the current salesman profile: data about salesman and his clients, specific orders and estimates, statistical data about current clients, partial information on products, etc. As it features a local repository, the mobile device is capable of running disconnected to present and evaluate orders and estimates for a client, and use the network connection only when requesting or and sending live data (stocks, finalized orders, and so on). Failure of other components of the system (EMD and MGW) will still allow the mobile device to operate at a certain extent: analyze orders and estimates, consult product prices, features and promotions, build orders, etc. Then again, it won’t have the capability to request stock information and finalize orders. They will be temporarily stored onto the device until the other components of the system are restored. Once the communication with the MGW is restored, the temporarily stored information will be synchronized with the MGW and then with the EMS.

3.2 Security Issues An important aspect in almost all data exchanging applications is security. We identify two main requirements concerning security: authentication and privacy. The authentication is implemented in the MobSel framework using a login/password technique. The salesmen accounts are created and managed on

Proceedings of the 10th WSEAS International Conference on COMPUTERS, Vouliagmeni, Athens, Greece, July 13-15, 2006 (pp57-62)

the MGW server using a web server component. An authentication token is created on the mobile device for each pair: mobile device/user. The token is then used and revalidated at each request in order to avoid spoofing. The data privacy aspect is handled by encryption. A simple SSL tunneling ensures data confidentiality as it passes trough Internet. 4 Data Exchange and Synchronization As already mentioned we use HTTP as transport protocol. We chose HTTP because of its high implementation availability on all platforms and because it allows easier through firewall communication. 4.1 Data exchange and synchronization The MobSel framework exchanges data as business objects units. Each data exchange unit (products, customers, providers, statistical data, orders, estimates, appointments, etc) is a separate synchronization unit. The storage on the mobile device is implemented using the Pocket PC SQLCeEngine [5] that provides a simple yet efficient relational storage. For all synchronization units (products, customers, providers, etc) we implemented an incremental synchronization mechanism based on timestamps. Each device keeps the date and time of the last successful synchronization per entity type and brings in only newly modified data from the MGW server.

Fig. 3 The one-way synchronization process using

timestamps

On the other side, the MGW server keeps the modification timestamps for every separate entity. For example, each product has its own modification timestamp. This ensures conflict-free one-way synchronization for all entity types. In fig. 3 we present the synchronization process using timestamps, as implemented by MobSel.

An important aspect in data synchronization with multiple data sources is conflict resolution. Devices might update the same entity locally with different data and then upload changes to the MGW server in a random order. The problem is choosing the correct final value/state of the entity. Automated conflict resolution is usually tightly dependent on the business rules that govern the conflicting entity’s type. In the proposed framework we have solved the conflicts by sending updated entities directly to the EMS in a transaction context. Thus, the EMS handles updates in its own regular way. The only sensitive entities from this point of view are orders, but they never generate conflicts as an order is always uniquely assigned to or generated by a mobile agent. The downlink (server to device) and uplink synchronization (device to server) are depicted in Fig. 4 below.

Fig. 4 The data synchronization process

MGW

PDA OnDemand uplink sync PDA O

downlink syndemand

nc

Product TSTP-B

Product TSTP-A

AS400 EMS

uplink syncScheduled (out of sync) downlink EMS MGW synchronization

Product TSTP-C

MGW

Proceedings of the 10th WSEAS International Conference on COMPUTERS, Vouliagmeni, Athens, Greece, July 13-15, 2006 (pp57-62)

Please note that the on demand downlink synchronization on the Pocket PCs is served by the MGW from its local store. The data synchronization between the MGW and EMS is done asynchronously at established intervals or when triggered on the local system. The updates from Pocket PC are pushed directly to EMS through MGW without any in the middle caching.

The downlink data synchronization is user controlled. As each of the entity types supports synchronization, a mobile agent might choose to synchronize only the products or clients at a given moment in time. At the mobile application level, this can be controlled in the synchronization window, as presented in the Fig. 5 below. The individual checks are incremental synchronization procedures, while the “Force reload” check does a full-scaled synchronization.

Fig 5 Controlling the synchronized data.

4.2 Data Compression An important aspect when dealing with GSM transports is the cost of the data transfer. As the GPRS/UMTS solutions are still costly, we have implemented a simple Lempel/Ziv compression algorithm using the zlib libraries. As we transfer data using HTTP, thus mostly text, the compression ratios are usually high – 5:1. This saves costly GPRS bandwidth, but adds a small processing burden on the PDA application.

5 Conclusions and future work The current paper proposes a novel 3-tier system to enhance the mobility of sales agents, thus bringing an important competitive advantage to the enterprises implementing it. The main functional characteristics of our proposal are related to salesmen having access to up-to-date, complex information on their Pocket PCs, virtually wherever and whenever they need it. This is provided by on demand secure and fast synchronization of the local database from the mobile device with the central data warehouse of the enterprise. The application running on the mobile device is designed according with the general requirements described in [6].

As far as the system architecture is concerned, our model ensures application isolation and impendence in the case of temporary failure between the three tiers: the mobile device, the gateway server, and the EMS. Moreover, Mobsel successfully deals with important aspects related to data synchronization, like conflict resolution and data compression.

Future work is intended to building a general framework allowing the smooth integration with any EMS. It should also improve the security of data exchange and the control of mobile agents’ navigation from the handheld devices. 6 References [1] B.B. Ray, A. McFadden, S. Patterson, V. Wright, Personal Digital Assistants in the Middle School Classroom: Lessons in Hand, Meridian Palm Journal, NC State University, Raleigh, Vol. 4, Issue 2, 2001, [http://www.ncsu.edu/meridian/sum2001/palm/palm.pdf], visited March 2006. [2] K. Wood, Introduction to Mobile Learning, Ferl, BECTa, March 2003. [3] M. Mallick, Mobile and Wireless Design Essentials, Wiley Publishers, 2003. [4] W. Wheeler, Integrating Wireless Technology in the Enterprise, First Edition: PDAs, Blackberries, and Mobile Devices, Elsevier Digital Press, 2003. [5] R. Laberge, S. Vujosevic, Building PDA Databases for Wireless and Mobile Development, Wiley Publishers, 2002. [6] ***, Designed for Windows Mobile™ Software Application Handbook for Pocket PCs, Microsoft Corporation, May 2004.

Proceedings of the 10th WSEAS International Conference on COMPUTERS, Vouliagmeni, Athens, Greece, July 13-15, 2006 (pp57-62)