devxlogo

Making the Case for Local Database and Synchronization

Making the Case for Local Database and Synchronization

Editor’s Note: Martyn Mallick is a wireless solutions evangelist at iAnywhere Solutions, a vendor of mobile database solutions. Though the article is not impartial, we have sought it for publication because we believe there is educational value in the technical concepts as presented.

hen extending information to mobile workers the first problem that the IT department has to solve is how to give those workers access to enterprise data when and where it is needed. Smart client applications have emerged as the architecture of choice over browser-based wireless Internet applications, as they enable access to data while the mobile user is disconnected from the network?wireless or otherwise. This capability is best implemented by incorporating persistent data storage using a mobile database in your application.

Your choice of mobile data storage will dictate many factors of your mobile application including storage capacity, performance, security, operating systems support, development tool support, and ability to integrate with enterprise data sources via synchronization.

This article will define the components of a smart client architecture, with a focus on the mobile database component. In Figure 1, you can see the main components of a smart client solution: the mobile smart client application, the synchronization server, and the back-end data source. The main difference between a smart client application and a client-server application is the synchronization layer. Synchronization is a key element in delivering the many benefits that smart client applications provide.

Of course, each of the three smart client components is important to the overall success of your mobile application. Your application will require a form of persistent data storage, which, as you will read, is often best accomplished by a small footprint relational database.

Figure 1: Smart Client Architecture. A smart client architecture uses a synchronization server as a middle-tier between the shared data sources and the clients.

Why Use a Mobile Database?
Even though smart client applications have been successfully deployed for several years, many developers are still unfamiliar with the benefits they provide. This is likely because until recently, the focus of mobile applications has concentrated on WAP and other thin client architectures. This is unfortunate because many of the commonly cited pitfalls of wireless computing, such as poor user interface, low bandwidth and unreliable data access could have been avoided if companies developed smart client applications instead of casting their lot with WAP.

The main advantage of using a mobile database in your application is offline access to data?in other words, the ability to read and update data without a network connection. This helps avoid problems such as dropped connections, low bandwidth, and high latency that are typical on wireless networks today. Furthermore, because a modem is not in constant use, this model increases battery life on the device and greatly reduces the length of connection time and higher cost incurred when a constant network connection is required. Because only updated data is synchronized, wireless airtime fees can be reduced with mobile database applications. Depending on your business need, synchronization can also be done using a cradle over a wired network eliminating wireless airtime altogether.

The main advantage of using a mobile database in your application is offline access to data?in other words, the ability to read and update data without a network connection.

As mentioned earlier, synchronization is a critical component of smart client applications. The synchronization layer has to be able to handle not only updates, but also inserts and deletes. And it has to be able to manage all of these changes for each user on the system, in such a way that conflicts are largely avoided, and if they do occur, are resolved in a non-intrusive manner. This may seem like a daunting proposition, but mobile database and synchronization vendors have succeeded in solving these issues through a combination of technology and best practices in application design.

In general, when designing an application that will have multiple users communicating via synchronization to a central database, you want to design your application so that there is minimum overlap between the data for each user. This typically requires the data to be partitioned by user, so each user has a distinct set of data. When this is accomplished, the worry of having ‘stale’ data and of having users overwrite each other’s data is minimized.

When data partitioning is not an option, such as in the case where multiple sales people are selling products from the same inventory supply, one good approach is to use priority synchronization. This is the ability to specify components of your client data that are more time sensitive, and in turn can be synchronized more frequently without having to synchronize the entire data set. In the case of our sales people, they may synchronize orders in a priority manner, allowing for inventory levels to be kept up to date, while at the same time leaving other data such as product catalogues to be synchronized at a later time. In extreme cases where real-time access is required for all of the data, such as stock quotes, then another application architecture, such as wireless Internet may be more appropriate.

Performance and More
Beyond reliable access to corporate data, smart client applications also provide performance benefits. Because the data is local on the device, a roundtrip to a server is not required for data access. This allows you to prevent network performance issues (bandwidth, latency, etc.) from affecting your mobile application’s performance. In addition, native applications typically allow for more sophisticated user interfaces?interfaces that are more desktop-centric?thereby improving application usability.

At a more granular level, the features of the database you select can provide additional benefits. For example, having support for enterprise class functionality, such as indexes, referential integrity, and especially transactions, allows you to create applications that are extensions of your enterprise applications and not mere substitutions.

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 is rolled back.
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 is rolled back. This is an important feature when you are modifying data in more than one table, as you can ensure that internal references remain intact.

Security is another area where smart client applications excel. This is because all aspects of the applications security are controlled by you, meaning you do not have to rely on third party infrastructure, such as WAP gateways, for security. With a mobile database architecture, you control access throughout the application using authentication and data encryption. User authentication, built into the application on the device, prevents unauthorized users from accessing your confidential data and carries through to your back-end data source during synchronization. Encryption can be applied to both the data on the device and the communication stream to the server. This way, confidential data cannot be viewed on a device that is lost or stolen.

The advantages of a smart client architecture with a mobile database are compelling, but to tell the whole story, you need to be aware of the tradeoffs over a wireless Internet architecture.

When Smart Clients Won’t Work
There are three characteristics of wireless Internet applications that are not present in smart client architectures:

1) Immediate deployment of applications. Wireless Internet applications reside on a server and, as long as the user knows the URL of the application, he can access it immediately. The drawback, of course, is that network connectivity is required to access the server-based content. The introduction of mobile application deployment and management software has made deploying smart client applications much easier, so companies rarely decide to create Internet applications for this reason alone.

2) Simplified enterprise integration. If you have existing Web applications that need to be taken mobile, moving to a smart client architecture can be more challenging than using a Web model. A wireless Web application would be able to reuse the majority of the existing application, including Web servers, business logic and enterprise integration, whereas a smart client application may require components to be rewritten since a Web component is not required. For this reason, the ideal fit is often an offline Web application. This solution provides the best of both worlds in that it still takes advantage of existing Web technology while providing offline access to your Web content. In this type of solution, the Web content is still deployed on the Web infrastructure, but is then synchronized to the local device where it can be viewed even after the network is disconnected.

3) Real-time data access. There are situations where the data used by a mobile worker has to be 100 percent up to date at all times. These applications are few and far between, but when they do occur, a smart client solution will not offer the ‘data freshness’ that you require. Areas where real-time data access may be required include securities trading, information services such as sports scores or weather information, and m-commerce applications.

One way to mitigate this for corporate applications is by using server-initiated synchronization. Essentially, this means that any change to specified data in your enterprise database will initiate a synchronization of the local database on all mobile clients. With poorly designed database schema and synchronization logic, this may result in an uncontrollable number of synchronizations. Take time to properly partition your data to avoid such issues.

Local Data Storage Options
When it comes to creating smart client applications, there are a variety of options for persistent data storage. These range from basic formats, such as a text file or flat-file database, to spreadsheets or XML files. While these are all viable options for certain simple applications, they usually run into performance problems for any significant amount of data. Additionally, these solutions are often limited in programming capabilities, forcing developers to use a particular tool. Robust tuning and optimization features, which are typical in relational databases, are absent with these techniques, limiting application performance. These types of data storage implementations are rarely found in enterprise applications because of their lack of synchronization support, poor scalability, limited security features, weak transactional integrity, and lack of support for conflict detection and resolution.

These types of data storage implementations are rarely found in enterprise applications because of their lack of synchronization support, poor scalability, limited security features, weak transactional integrity, and lack of support for conflict detection and resolution.
The leading mobile operating systems are Palm OS, Windows CE, and Symbian OS, each of which comes with a basic form of persistent data storage built into the operating system. While using these databases may seem attractive at first, in most cases, these databases suffer from the same limitations listed in the previous paragraph. They may be sufficient for simple applications but fall short for enterprise applications.

One final area to investigate is native XML data sources, which have started to gain attention and maturity. There are typically two types of XML databases. The first type implements XML capabilities on top of another database format; the second uses XML itself as the storage mechanism. Most enterprise mobile database vendors have added some form of XML capabilities to their offerings, ranging from the capability to store XML documents in text fields to the capability to interact with the database using XML datagrams.

Native XML data stores range widely in their complexity. Some simply keep an XML text file on the device; more complex schemes maintain XML content in a specialized server. The main drawback of this approach is a performance penalty that results from the overhead required to parse the XML itself, as well as the lack of indexes in most systems. Furthermore, if the enterprise database is not XML based, the advantages of having a mobile XML database is reduced since the data will have to be transformed and then stored in a relational format on the server.

Choosing Wisely
When developing a smart client application, many factors come into play, not the least of which are concerns about operating system support, development tools support, and standards. Each of these should be evaluated when choosing which device, operating system, and database vendor is right for your project.

Operating System/Device Support
At a minimum, the database you choose should be capable of running on the leading mobile operating systems and devices, both during development and deployment. These include Windows CE, Palm OS, and Symbian OS. Moreover, because the mobile operating system and device market is changing constantly, you need a solution that can adapt quickly to those changes.

Standards Support
Developers in your organization have likely 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. While most commercial database systems are SQL based, many of the alternatives such as those included with the OS, and flat file systems are not.

Low Resource Requirements
Because mobile devices have constrained resources, the database should be capable of running on slow processors and have a small footprint that doesn’t hog local memory. Choosing a solution that is modular, so you can deploy only the features you require, will minimize resource usage.

Tools Support
Developers need tools for the development, testing, administration, and deployment of mobile applications and the more familiar those tools are, the more productive developers will be. 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.

Enterprise Integration
Because synchronization is critical to the smart client architecture, the solution you choose should be able to synchronize to a variety of relational databases as well as other enterprise applications. Most of the commercial mobile database solutions do offer some form of data synchronization, although it is often limited to that particular company’s enterprise database offering. The other file-based or operating system mechanisms typically offer no synchronization support, further limiting their suitability for enterprise applications.

Zero Client Administration
You can’t deploy technical staff to troubleshoot and resolve problems wherever mobile clients are. At the same time, it is unrealistic to expect the end user to do IT tasks. This means that you need to choose a solution that is easy to install, configure, and manage. When support is required, mobile device management solutions let you remotely troubleshoot and repair a device as well as perform software upgrades.

Choosing a vendor with no track record or a technology platform that only works with a narrow set of standards may leave you with an application that is obsolete only a short time after it is deployed.
The mobile application you deploy today may not be the same application you will need tomorrow. Because you expect your business to grow and new technologies to emerge, your mobile application should be built on a platform that is likely to incorporate new technologies and functionality. If you decide to go with a commercial solution, don’t be afraid to ask vendors for references from deployed solutions to see how well they understand the market. Choosing a vendor with no track record or a technology platform that only works with a narrow set of standards may leave you with an application that is obsolete only a short time after it is deployed.

The Bottom Line
While many organizations will start small with pilot applications, the benefits of mobile and wireless applications on worker productivity, customer service and operational efficiency can be significant?and can scale up dramatically as more workers and applications are mobilized. Leveraging a smart client architecture offers many advantages for helping ensure that your workers have “always available” access to key data anywhere, anytime. Whether your plan is to mobilize five users or thousands, the key point is not to let the mobile application revolution pass you by.

devxblackblue

About Our Editorial Process

At DevX, we’re dedicated to tech entrepreneurship. Our team closely follows industry shifts, new products, AI breakthroughs, technology trends, and funding announcements. Articles undergo thorough editing to ensure accuracy and clarity, reflecting DevX’s style and supporting entrepreneurs in the tech sphere.

See our full editorial policy.

About Our Journalist