In order to host quality mobile applications, smart devices require characteristics that include being small and portable, having a decent battery life, displaying information with richness and quality, having memory to hold plenty of information and applications, and the ability to access remote data. In this column, we'll introduce the topic of accessing remote data using the .NET Compact Framework by focusing on just one of the several ways in which remote information can be manipulated.

Data in a Connected World
Everyone opens up their first PDA like it's Christmas morning. It's easy to enjoy the coolness of being able to carry around a device that contains a considerable amount of information and to use an application that will access that data. But we soon discover that visiting the cradle periodically is required for the device to be updated with current information. This type of synchronization requires tethering to a PC and is therefore unwieldy in many situations. In today's business world, being successful requires that companies become increasingly more agile. This includes being sensitive to changing market factors and understanding changing customer needs. The companies that are quicker to change usually live longer and wealthier. Therefore, all sorts of company information has to be available and accessible anytime and anywhere. Consequently, it is not just a stand-alone PDA environment anymore. Corporate applications need to get on mobile or smart devices, and the devices absolutely require the ability to communicate to enterprise back ends in an easy fashion.

The integration of mobile devices, the Internet, and wireless connectivity provides a way for companies to extend their reach to employees, partners, and clients. The potential impact of this convergence is unlimited. Possible results for each of the groups include improved productivity, reduced operational costs, and increased satisfaction for all involved. The geographic expansion of wireless connectivity over the past few years has created a situation in which a device can retrieve information from anywhere in the world.

It turns out that the Compact Framework provides a great deal of assistance in accessing data remotely, including high-level communication mechanisms for accessing SQL Server and XML Web services. Furthermore, a Compact Framework-based application can work at different levels of the network stack, including TCP/IP, Sockets and Infrared, Streams, and HTTP. In this column we'll focus only on accessing a remote SQL Server, but we cover this entire group and other communication issues in our upcoming book.

ADO.NET and the Compact Framework
One way to remotely access data is to use classes from the System.Data.SqlClient namespace for working with SQL Server.

SQL Server is one of the leading database servers today and is therefore familiar to most desktop and server programmers who work with the .NET Framework. SQL Server is also well known to those who worked in the ADO environments (VB 6.0 and ASP) of yesterday. Moreover, many developers interested in the Compact Framework are in offices that use Microsoft technologies and therefore probably have SQL Server databases implemented in important applications. So, a normal transition to smart device architectures will be to access these already-established data sources.

As many developers will already be aware, ADO.NET is the technology that .NET developers use for accessing data in data sources like database servers. Rooted in the System.Data namespace, ADO.NET provides a model that does several things for the developer, including the combination of relational and object-oriented paradigms, integration with XML, and the abstraction of database server protocols.

There are several benefits to the way ADO.NET defines data providers. These benefits emanate from the fact that the class model or architecture used (the base classes and interfaces) in the .NET Framework is the same as for the Compact Framework. Therefore, the knowledge of providers in the .NET Framework will be mostly reused, except for the actual database implementation differences and smart device constraint considerations. The main benefit that flows from this architecture is that Compact Framework SqlClient is identical to the .NET Framework implementation of SqlClient. A second benefit is that other data providers can be built in the Compact Framework that are more easily understood since they are based on a common architecture. In the case of the Compact Framework, the SQL Server 2000 Windows CE Edition (SQLCE) team provided a rich data access mechanism in System.Data.SqlServerCe, a data provider for SQLCE that is a great database residing on Windows CE devices.

Because ADO.NET Data Providers are based on a common architecture, they are required to implement certain interfaces. Therefore, all providers will have managed classes for Connection, Commands, Parameters, Data Adapter, Command Builder, Data Reader, Transaction, Exceptions, and more. Missing from this is the DataSet, as DataSets are provider independent.

Enter the SqlClient Provider
The easiest way to exchange data with SQL Server is to use the SqlClient provider, whether on a PC or on a smart device. As stated earlier, the usage of SqlClient on a smart device is the same as the usage on the .NET Framework.

OleDb and Odbc are "broad" data providers in the .NET Framework, and as mentioned in last month's column, they do not exist in the Compact Framework. They are considered "broad providers" because they serve as an interface for multiple database vendors and cannot take advantage of any certain database capability. Thus, broad providers cannot create a performance gain based on the strength of the database. As SqlClient is a narrow provider (i.e., it is only intended to work with SQL Server databases), it has no excess layers of communication code and is therefore the fastest way to interact with SQL Server.

Most developers who develop applications that use SqlClient do not realize what is happening behind the scenes when a client machine talks to another SQL Server database machine. This is due in part to ADO.NET acting as an abstraction layer so developers can focus on their application. It turns out that SqlClient is using the Tabular Data Stream (TDS) wire protocol that is specific to SQL Server. TDS is provided through a SQL Server client Net-Library that is installed as a part of MDAC for PCs, and for smart devices is automatically added to the smart device project deployment in Visual Studio .NET. The classes in SqlClient take care of converting the query or command to the database into the TDS packets and shipping to the server. They also take care of the response.

Figure 1 is a diagram of the SqlClient namespace. Because of the ADO.NET data provider architecture, certain interfaces and base classes are required to be implemented and this illustration depicts that fact through the set of classes prefixed with "Sql". Again, this is the same SqlClient model for the .NET Framework and the Compact Framework. Since information on the programming details of ADO.NET and SqlClient is widespread and can be applied to the usage in the Compact Framework, we will not cover every class in the figure.

 

SqlClient on a Smart Device
There are several issues to consider when deciding whether to use SqlClient on a smart device.

The first issue to address is to contrast the usage of SqlClient and SQLCE. Although SQLCE has many advantages, especially for disconnected and occasionally connected scenarios, it is important to understand that there are times when using SQL Server remotely is a good choice.

For example, consider the following scenario. The device is capturing data in a manufacturing environment and the back-end application is exposed by a SQL Server 2000 database. The business requires the captured data to be placed in the SQL Server database as soon as possible. In most cases, this database exists due to an existing Windows application. If the device can maintain a full-time high-speed connection to the local network, this scenario works great. And we see this in data-collection environments, like manufacturing, warehousing, and hospitality, in which the devices are typically used within a circumscribed environment like a shop floor or warehouse.

A second scenario is where the data is too large for the smart device, but complex queries can be made. This still allows for sending requests to a rich query system provided by SQL Server, and also allows for the device to maintain a low memory footprint. Again, this is for special environments in which the device maintains a reliable connection to the network especially in times of communication with the database.

Even though there are benefits in the SqlClient, there are some limitations to consider if using the Compact Framework implementation of SqlClient:

• Figure 1