Database technology is the foundation of many enterprise applications. This is true in the world of e-business, and it is becoming more true in the world of m-business. As corporations continue to develop mobile business applications, the requirement for persistent data on the mobile device becomes increasingly prevalent. Just as databases made the client/server era of computing possible, databases are changing the way companies look at mobile computing. As articulated earlier in this book, one of the main goals of mobile computing is to extend enterprise data beyond the confines of the enterprise. In doing so, many lessons have been learned, demonstrating how mobile data access for e-business (or m-business) differs from client/server data access. The following are some of the key differences between the two means of data access:
The mobile-device landscape is much more complex. Compared to the choices in the desktop world, there are many different devices, which use a broad range of hardware, operating systems, and user interfaces.
The number of devices and applications that need to be managed in the mobile landscape is increasing. As mobile computing grows, users may use more than one device, and will definitely use many mobile applications. Desktop computers are a known entity. There are not many new hardware systems or radical new applications coming to market.
Mobile users often need to use applications when not connected to a network. One reason is the unreliable nature of the wireless networks, but it can also be credited to the performance and depth that offline applications can provide. Desktop computers typically have reliable, continuous network connectivity, allowing data access to occur over a network without worrying about prolonged downtime.
All of these points lead the conclusion that mobile data storage is an important aspect of mobile applications.
Now that we have looked at the types of databases available, as well as some of the key differences of mobile computing, we are in a better position to evaluate the key features that are important in a mobile environment.
The database engine and the technique used for data storage will play a significant role in the database's storage capacity, performance, and scalability. You want to choose a solution that can store a large amount of data, being limited only by the memory available on the device. At the same time, the solution should have fast data access, to ensure that the database does not cause a performance bottleneck. There is often a trade-off between data capacity and performance; in some products, as the data set grows, the performance decreases.
Another important consideration is the support for enterprise class functionality, such as indexes, referential integrity, and, especially, transactions. Choosing a product that has these features will enable you to produce a robust, high-performance solution. The importance of transaction integrity cannot be overemphasized for mission-critical applications. Transaction integrity means that clients can perform database actions within transactions, so if something goes wrong in any part of the transaction, the entire transaction can be undone. This is an important feature when you are modifying data in more than one table, as you can ensure that internal references remain intact. Since your mobile application will not contain the entire schema of your enterprise data source, the database system should provide an easy way to define the required subset of data. Once defined, the synchronization layer should be able to automatically take care of the data mappings. This leaves you with a minimum amount of data on the device and a means of direct synchronization.
Having tools for the development, testing, administration, and deployment of your mobile application will make the development process more efficient. Support for leading development tools and programming languages enables developers to use products that they know. Ideally, for maximum flexibility, the database system will support development of both native and Java applications. Being able to leverage existing tools and programming language skills will dramatically reduce the amount of training required. When it comes to administration and deployment, the database vendor should provide tools that support all of your target operating systems.
The database solution should provide an integrated synchronization layer. The synchronization must be bidirectional, so that both the client and server data can be updated. At the same time, the amount of data being transferred has to be kept to a minimum. One way to accomplish this is by synchronizing only the net changes. Imagine the case where a data field changes several times between synchronizations. When synchronizing net changes, the only information sent to the enterprise server would be the final value, rather than all of the intermediate values, which could add considerable overhead to the data being transferred. For most applications, receiving only the final value from the synchronization should be sufficient, but for others a complete transaction history might be required. A solution that offers a choice between the net changes and complete transaction history would be ideal.
Mobile applications run on many devices, using many communication protocols. The synchronization capabilities should be able to run over a variety of both wireline and wireless protocols. The system should also support access to enterprise data being stored in the leading enterprise database products.
In most mobile environments, technical staff to troubleshoot and resolve problems is not readily available. At the same time, it is unrealistic to expect the end user to take care of troubleshooting tasks. This means that you need to choose a solution that requires zero client administration. To accommodate this requirement, the database must be easy to install, configure, and manage.
When support is required, having remote device support capabilities can be very helpful. Such support may include the ability to remotely control a mobile device and to remotely deploy application updates to the device. The mobile device management products discussed in Chapter 16, "Mobile Information Management," will be useful to accomplish this task.
Because mobile devices have constrained resources, the solution has to be able to run efficiently on handheld devices. The database should be capable of being run on slow processors and provide a small footprint reducing memory usage. Choosing a solution that is modular, giving you only the features required for your application will minimize resource usage. Also note that native applications are often more efficient than Java-based solutions, so native support for your target operating systems can be important.
At a minimum, the database you choose should be capable of running on the leading operating systems and devices, both during development and deployment. Moreover, because the mobile operating system and device market is changing constantly, you need a solution that can adapt quickly to those changes. At a minimum, the operating systems it supports should include Windows CE, Palm OS, and possibly Symbian OS. You are also advised to choose a database that can run in the emulation environments that you have selected. If it does not, the development process will be much more difficult, because physical devices will be required for all stages of the development cycle.
Probably the developers in your organization have done some database development, meaning they have SQL skills as well as knowledge of ODBC or JDBC. Because these standards are used widely and have a broad level of industry support, the database system you choose would ideally support these standards. Even if you do not have previous database experience, choosing a solution that is standards-based will help you to learn the system faster and gain skills that are transferable to other platforms. In addition, technical resources are more readily available for standard systems than for proprietary ones.
Having a SQL relational database on the client can also ease the integration process with enterprise databases, which are commonly SQL relational as well.
The database system should support security throughout all parts of your application. This includes both authentication and data encryption. To prevent unauthorized users from accessing your confidential data, having built-in authentication is important. This authentication should also carry through to your back-end data source during synchronization.
Two levels of data encryption are required: encryption of the communication stream, and of the data stores themselves. The encryption of the data stream will prevent others from listening in when data is transmitted from the data store to the enterprise database. The encryption of the client data store will ensure that confidential data cannot be viewed on a device that is lost, misplaced, or stolen.
An argument can be made that direct real-time access to enterprise data is better suited for enterprise applications than persistent client data storage. This solution would involve having a communication layer within the client application that would go over a wireless network to retrieve data from the enterprise server. In the same way, the business logic could reside on the server as well, removing the need for client-side logic. This would leave the presentation layer on the device, along with a communication layer, allowing for enterprise integration, making the result very similar to wireless Internet applications. In this case, the real-time data access solutions would suffer from some of the limitations that real-time browser-based applications do, namely:
Unavailable or unreliable wireless networks. In many cases, mobile tasks such as sales force and field service applications take place in remote locations, where wireless coverage is either unavailable or unreliable. This is also true of workers for whom physical barriers, such as office buildings, cause interference issues.
Insufficient bandwidth. A significant amount of data is being recorded with data capture applications. With the low bandwidth of today's networks, constantly transmitting data is impractical and costly.
Static data. Much of the data retrieved in mobile applications is relatively static, requiring only periodic updates. Examples include customer contact information or product catalogues. In these cases, it does not make sense to be downloading the information over a wireless network when it can be stored persistently on the device.
Battery life. Communicating over a wireless network requires significantly more battery power than accessing data locally. This is a concern for workers who do not have the ability or time to charge their devices throughout the workday.
For all of these cases, developing a smart client application with persistent data storage and enterprise synchronization is a more practical and cost-efficient solution. In many cases, the data can be synchronized via a wireline network, avoiding the wireless network limitations.
And when real-time data is required, wireless Internet applications appear to be a better choice than creating custom client applications with real-time access. Wireless Internet applications do not require a client to be deployed to the device, plus they can communicate over standard protocols such as WAP and HTTP. Another option is hybrid applications that use local data storage for most of the data access, and wireless Internet access for content that is the most critical or time-sensitive.