4 Data Access Choices for Mobile Apps
Data access models now are much more robust than the old model of browsing a WAP page.
by Matthew Carter

Microsoft Mobility Developer Conference, March 20, 2003

Mobile applications are looking more and more like yesterday's business applications: They feature a relatively rich client UI, connectivity to corporate and partner information systems, and bidirectional data synchronization. At a panel discussion on "Choosing the Right Mobile Technologies for Your Application's Needs" at the Microsoft Mobility Developer Conference yesterday, the bulk of the time was spent on how to choose the data access model that best suits your needs. Data access models now are much more robust than the old model of browsing a WAP page. And if you've been developing data-centric Visual Studio .NET apps, the models will look familiar to you. Let's take a look at the four approaches.

1) XML Web Services
Much has been written about XML Web Services since they were unveiled in 2000. XML Web Services support, which is an integral part of .NET on desktop and server systems, is included in the .NET Compact Framework featured on Tablet PCs and Pocket PCs. (The .NET Compact Framework either ships with the device or is available as a distributable component.) XML Web Services support allows you to consume XML Web Services from your mobile applications. This is useful when you want to keep a single set of data and business rules on the server, and use the same information on mobile and desktop devices. Data synchronization is not as robust as in other models, and it lacks some of the flexibility of other models such as SQL Server CE.

2) SQL Server CE Synchronization
SQL Server CE is a subset of SQL Server 2000 that resides on a mobile device. With a dramatically smaller footprint (1.2 MB) than full SQL Server, this database brings a lot of the benefits of SQL Server to the mobile developer—such as data synchronization, said Microsoft's Kevin Collins, a senior program manager on the SQL Server CE team. SQL Server CE handles the overhead of synchronization, so rather than writing code to serve as a "traffic cop," developers can focus on dealing with the data. Collins demonstrated a real estate application in which a 20 MB database was uploaded to a Pocket PC while it was docked at the desktop, and SQL's notification services handled row-by-row updates to meet the criteria for being synchronized.

3) Direct SQL Server Access
In some instances, when wireless connectivity is relatively cheap and reliable, it can make sense to have data connectivity in much the same way as a normal wired client/server system. In this case, direct SQL Server access makes sense for real-time synchronization. To illustrate this, Collins described a scenario with a warehouse worker using a Tablet PC in a completely Wi-Fi structure.

4) ADO.NET Local Data
Storing and manipulating locally stored data using ADO.NET is the fourth model for data access. While less sophisticated and flexible than the SQL approaches, it is a good way to access persistent data from XML files. ADO.NET is built into the .NET Compact Framework and is familiar to many Visual Studio .NET developers, but lacks the ability to do joins and other advanced data handling.

The last scenario for data handling discussed by the panel is a situation in which the database or middleware isn't SQL Server. Mobile developers can access heterogeneous data in one of two ways: through creating or purchasing a native provider, or by using SQL Server 2000 to sit between the back-end database and the mobile user. In Collins' real estate demo, the data was stored in an Oracle database. When the data is sent out to mobile users, it is first sent to a SQL Server database that handles the synchronization tasks for remote users.

About the Author
Matthew Carter is vice president of Internet products for Fawcette Technical Publications.