SQL Anywhere Studio Mobilink One

Brief introduction

The North Carolina Department of Transportation (NC DOT) has faced many of the challenges of data synchronization in today's typical mobile computing. This article provides an overview of the NC DOT Mobile Inspector application, the need for timely exchange of information within the Bridge Technology Inspection Unit and the central Office, and the SQL Anywhere Studio Mobilink technology that implements database synchronization in this application.

Introduction to NC DOT application

In the spring of 2004, I came to the Raleigh of North Carolina State. Before that, I had never spent too much time on bridges and viaducts. I do not know the need to regularly check the safety of bridges, of course, the role of "bridge Inspector" is very little known. As I know, the job of those with helmets and safety vests is to clean up the dead animals on the road.

These perceptions quickly changed when I started working on the Mobile Check (Inspector) application synchronization components. North Carolina State about 19 000 bridges and culverts need to be inspected regularly, with about 60 on-site inspectors in charge of inspections, including 4 underwater working groups. These inspectors are very busy and need to be recorded and photographed on the spot before returning to the office to prepare for the inspection report, which is used to determine which bridges are in good condition for some time to come and which bridges need to be repaired immediately.

Photo 2– Field Inspector Shane Dunlow is using a flat-panel notebook (tablet PC) mobile Inspector application to record the dimensions of the flange.

The Mobile inspector is used to collect the measurements and observations of the Inspectors, as well as to store digital photographs. The Mobile inspector is designed to transfer data entry from the office to the site, while saving costs while satisfying the federal government's requirement to obtain bridge inspection data electronically. For this reason, voice control, handwriting recognition and custom shorthand tools have become a major feature of mobile Inspector applications.

On site, each inspector uses a tablet computer running the Windows 2000 operating system. If it is a traditional two-tier structure-client/server layout-or even a two-tiered distributed hierarchy, all tablets will have to communicate or sync directly with the central database. However, for security reasons, a tablet computer can only be connected to a central database in an office. That is, before each on-site inspection, the data is copied to the panel owner's tablet computer and replicated back to the central database after the inspection report has been completed. It is also necessary to replicate data back and forth between the Panel's tablet computer and the Panel's tablet computer, often on a wireless connection when checking for large bridges.

Figure 1 shows how to deploy a mobile Inspector application to a three-tiered computer, where the central database is placed at the top, the team leader tablet is placed in the middle tier, and the panel's Tablet PC is placed on the bottom. The team leader communicates with the central database through the wired local area network, communicates with the group members through the wireless local area network. The synchronization server software is also run on the central database computer and the group owner's tablet computer, which communicates with the group leader and the team member's computer on the synchronous client software.

Figure 1. Level Three distributed hierarchy:

The application itself uses a relational database management system (RDBMS) to store data on a tablet computer-including digital photos. There are good reasons to use an RDBMS: it guarantees data integrity and provides the ability to restore, powerful and easy-to-use. This is the advantage of it. The disadvantage is that moving data from a central database to a three-tier distributed hierarchy containing multiple remote databases is a daunting task. In particular, it is not possible to send a database administrator (DBA) to each inspection team, so whatever the weather is on the banks outside of North Carolina, make sure that the synchronization process is stable and reliable even when the wireless connection is unstable.

NC Dot uses Oracle 9i as a central database, adaptive Server Anywhere (ASA) as a remote database on a tablet computer, The Mobilink synchronization software is used to handle transmission between Oracle and ASA, and between ASA and ASA. Both ASA and Mobilink are part of Ianywhere Solutions's SQL Anywhere Studio 9, which is released together.

Basic concepts of synchronization

The Mobilink software is comprised of client components and server components. The remote client initiates the synchronization session by first connecting to the local database, collecting all the rows that have changed since the previous synchronization, and uploading the rows to the Mobilink server. The server then applies the uploaded changes to the central database, selects the rows to be downloaded, and sends the rows to the client. Finally, the Mobilink client applies the downloaded changes to the local database and returns confirmation information to the server.

In any environment, fault handling is an important part of synchronization, especially in a mobile environment where connections are frequently lost or accidentally disconnected. When using Mobilink, failures are handled at the level of uploading and downloading database transactions. If the upload fails, all uploaded changes are rolled back and the whole process stops. The restore includes rerun of the synchronization process, rebuilding the upload stream from scratch and repeating the entire process-as if the process had never been interrupted.

Troubleshooting during download takes a similar approach: Download the rollback and apply the same restore technology: "Try Again". However, only the download is repeated at this time, because the previous upload was successful and submitted. All of this is done automatically by Mobilink.