How To Retrofit Your Organization's Apps for the Wireless Internet
How To Retrofit Your Organization's Apps for the Wireless Internet
By: Derek Ferguson
Mar. 16, 2001 12:01 PM
By 2003, more Internet connections will be made by wireless devices than by standard PCs. This revolution in data connectivity will facilitate the creation of entirely new kinds of software applications, providing myriad new opportunities for start-ups and established software vendors alike. But what does it mean for the corporate IS department?
Unless you work for an accounting firm that's so conservative that they still haven't given up their abacuses, the chances are strong that you've got a lot of homegrown applications in use at your organization. Under these circumstances, the wireless Internet can easily seem like the sort of thing that will only apply to other people. Don't bet on it!
Sooner or later, someone is going to ask you to retrofit one of your existing applications for wireless use. In this article, I will share with you several tips and tricks I have discovered in helping organizations do exactly this. The main obstacles can be divided into two main groups: back-end barriers and front-end limitations.
Adapting the Back End
One of the most common back-end causes of wireless application failure is a single operation that takes too long to execute. An example of this might be a poorly designed query that fails to take advantage of existing indexes. An obvious solution to this, when available, is to improve upon the design of such activities so that they'll respond in a more reasonable amount of time.
Sometimes, however, an operation can't be optimized beyond its current state. Listing 1 shows a SQL statement that might represent such a case. We must assume here that all of this data is, indeed, needed by our application and that the customer's ID number is also the best criteria to use in our search.
In this event, we're left with two ways in which to restore our application to functionality. First, we may decompose this single, long-running query into several, smaller (hopefully shorter-running) queries. Listing 2 exemplifies this approach.
Developing "Server Push"
Sometimes the delay on the server is completely unrelated to data. Certain complex calculations and highly iterative logic structures can take a very long time to execute. In situations such as these, it may be possible to relocate some or all of the time-consuming calculations from the server onto the client itself. This depends, among other things, on the level of support for client-side scripting offered by the target device in question.
On WAP-compliant devices, for example, you might consider implementing lengthy calculations as WMLScript. Listing 3 shows a simple WML page that does exactly this. When the user clicks the "Go Figure" link, the script contained in the file, server.wmls, will be downloaded to the client. The function named Compute will then be executed. This function will then perform whatever lengthy computations are required, place its response in the variable named Answer, and finish by refreshing the display.
The final back-end barrier to wireless implementations is when legacy applications have coupled their client software too closely with the database. For example, many database servers support authentication methods besides simply entering a username and password. These additional options, such as SQL Server's ability to use Windows integrated security, can prove highly beneficial, both in terms of reduced administration burdens and increased security.
Notice that, in Listing 4, no username or password is needed in order for the code to access the database. It's assumed that the database server will authenticate the code through some other means. This might be as simple as comparing the IP of the machine executing the script to a list of IPs stored within the database's Access Control List (ACL).
This might prove a very secure approach when designing for client PCs with statically assigned IPs. Most wireless devices, on the other hand, have dynamically assigned IPs at best. At worst, they have no IPs of their own at all but, instead, share the IP of their proxy server with many other wireless devices on the same network.
In this worst-case scenario you could, of course, simply elect to add the IP of the proxy server to your database server's ACL. There are two problems with this approach. The first is that these proxy servers' IPs are completely beyond your control and are typically quite unstable. If you choose this route, you should be prepared to spend a lot of time in the future keeping your database servers' ACLs up-to-date.
The second, potentially much worse, problem with this approach is that, by adding a proxy server's IP to your database server's Access Control List, you "let in" all of the wireless devices that connect to that proxy, not just the ones that you want. This means that anyone who knows about your database server can gain access to it simply by connecting to the right proxy server.
A much safer approach would be to encapsulate all access to your database server within a tier of so-called "business logic" objects. You can then host these objects in an application server on a machine that is completely separated from the one running your database server. Access to this application server machine is open to any remote device.
You can ensure that no unauthorized clients will access your application server by establishing your own username and password authentication scheme. Listing 5 shows an example of just such an approach.
In Listing 5, we've adapted the code from Listing 4 to access the database via a business object named DB.Account. This object has a method named Authorized which determines whether or not a specific login/password combination is valid. This guarantees the security of our back end.
Adapting the Front End
Perhaps the most obvious front-end obstacles would be screens that are too big for display on wireless devices. A Web page that attempts to display the complete text of Beowulf, for example, will require the ability to scroll horizontally at a bare minimum. Even with the ability to scroll, however, trying to fit this volume of text onto a single page could easily consume all available memory on many of the smaller wireless devices.
In order to make this quantity of text available on most wireless devices, a solution will be required that is capable of breaking the text up over the course of several pages. This process, called pagination, may either be custom-coded by the developer or (using tools such as Microsoft's Mobile Controls) left to the application server's runtime environment.
Listing 6 shows an example that uses Microsoft's mobile list control to present a list of items on the screen. This control can (usually) determine the length of a target device's display. If the control senses there are more rows than can fit onto a single screen, it will automatically divide the text into multiple pages. Appropriate navigational controls for paging forwards and backwards through the list are automatically provided.
Pages that are too wide, rather than too long, present a unique challenge to developers. The best solution to this that I have seen is the one used by a product called PocketDBA (www.pocketdba.com), a tool that allows Oracle DBAs to monitor their databases remotely from wireless PalmPilots.
It's common for database tables to have more columns than could ever be easily displayed on a PalmPilot's narrow screen. PocketDBA's solution to this is to "wrap" the header row as needed, and then to wrap the detail lines to match this header. Listing 7 shows HTML that formats a 4-column table for 2-column display using this approach.
Because bandwidth for mobile devices is particularly limited, the use of large graphics is another front-end issue that can cause headaches when trying to retrofit for wireless use. Fortunately, most mobile Internet devices have already come up with their own approaches to dealing with this particular nightmare. On WAP devices, for example, converting your images to the prescribed WBMP format will go a long ways toward reducing bandwidth loss. Other devices, such as those using the PalmOS, provide ways to pre-package your graphics as part of the client-side software installation, thus eliminating the need to download them across the network at all!
It's always a good idea to give your users the option to refuse graphical content altogether if they desire (or if their clients can't accept them). Listing 8 demonstrates how you might use the ability of Active Server Pages to mix in-line HTML with dynamic code to achieve this purpose. The Boolean variable "GraphicsUser" is assumed to have been set previously according to the user's preferences.
In this article, I've set forth just a few of the most common issues that I see in helping organizations to bring their existing applications into the new millennium of wireless Internet access.
Reader Feedback: Page 1 of 1
Latest Cloud Developer Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week