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.