Enable a mobilized application to provide virtually the same user experience, regardless of connection status. Today, we can connect mobile notebooks to the Internet at tens of thousands of hotspots all over the world. Even this large number of public networks, however, cannot provide coverage at most locations. Truly ubiquitous wireless network connectivity may never come to pass, and even blanket coverage in many urban areas is years away. In the meantime, users will continue to find themselves often without a consistent network connection. In these cases, Web and client-server applications that require static connections provide no value. This dilemma translates into an opportunity for businesses to develop new applications and to evolve existing products to work in a mobile environment.

Mobilized software applications must work reliably and consistently, with or without a consistent network connection. For too many applications, the lack of a network connection results in work stoppages. When working offline, we keep mental “to-do” lists to complete when we are online. When online, we struggle to prioritize our work and those to-do lists, and try to remember to manually collect all the documents we need to carry us through our next offline episode. At best, this workflow scheme is a grand nuisance; at worst, it severely impairs our ability to work. Productivity aside, this approach also consumes larger amounts of bandwidth, placing greater demands on internal networks and driving up costs of cellular connections.

Provide local client interfaces and interact with local databases, which are automatically synchronized with enterprise data when network connections become available. Specifically, one can achieve offline functionality by using application synchronization or a publish-subscribe model. For example, using an enterprise database engine such as Microsoft SQL Server*, one can set up a data publication.

On the client computer, one might install SQL Server* Personal Edition, or in the case of a Pocket PC*, SQL Server* CE. The first time one synchronizes a device, all the data in the publication downloads to the device. On subsequent synchronizations, however, only modified data uploads from the client, and only the merged updates from all clients will download, reducing network-bandwidth requirements.

This kind of functionality is relatively simple to implement. The device holds the data that an application needs (after the initial synchronization), so the application runs successfully whether or not a network connection is available. Depending on the requirements of the application, an application may only occasionally need to resynchronize with the back-end database. This reduces the complexity of the solution, albeit at the estimable risk of working with outdated data in the client application.

There are also several techniques for extending Web applications to better serve mobile users who often need to work offline:

• Content caching: This technique involves offline caching of the content provided by a portal in response to a request for a Uniform Resource Identifier (URI), such as a Web page address. The code that gen erated the content is not cached. For example, a hyperlink may refer to a Java* Server Page (JSP) or Active Server Page (ASP). When the user follows the link, the application server runs the script that generates the content of the page, which streams HTML back to the client. It is the HTML that is cached, not the JSP or ASP.
• Code replication: This technique allows portal content to be more dynamic. The portal can execute code, such as Java servlets, JSPs, ASPs, and server controls, in the process of serving content, interacting with the user, and collecting and manipulating data and data stores. This technique replicates code from the portal to clients only.
• Data replication: Replicating data on the client side enables more transaction-like interactions and ad-hoc queries. Using this technique, an application may replicate data from the portal to client, client to portal, or in both directions. Any new and updated data is exchanged and applied to the copies. If the data is writeable only at the client or only at the server, implementation can be simple; on the other hand, the implementation of schemes where multiple copies of the data can be updated independently can be very difficult.
• Emulation: When a user selects a URI in a browser, either by entering a Uniform Resource Locator (URL) in the address box or by clicking on a hyperlink, the browser attempts to contact the server specified in the URI and to request the resource using Hypertext Transfer Protocol (HTTP). If the browser is unable to contact the server, the browser will return an error.

Normally, the local Web browser attempts to contact the presentation server over the network. When the system is offline, the Web browser should be redirected to the local presentation server (residing on the client) that is serving the cached content. Developers can easily implement this functionality using the autoproxy mechanism supported by most browsers. A JavaScript function can be created for the autoproxy mechanism that dynamically rewrites requested URLs before a request is submitted over the network. This function could, based on network state, modify the URL to redirect the browser to a presentation server running locally.

This item is part of a series that is introduced in the item “How to Mobilize Software Applications.”

Discovering Mobilized Software

Comments (0)

Trackbacks (0)

Leave a comment