Enterprise Everywhere

A "medium-client" approach may be your best strategy for extending the information supply chain to mobile users

By Christian Nelson and Dan Pilone

To leapfrog ahead of your competitors, your best people have been working day and night to extend your business into the wireless domain. Your company has invested blood, sweat, and a small fortune in this secret project. And your wireless users have been waiting for the coveted ability to plug directly into your enterprise applications.

Finally, the big day arrives and you unveil your project to the world. But instead of accolades and applause, you are inundated with emails and questions from sophisticated users, or worse, savvy shareholders: "What about my new cell phone?" "Why doesn't this application work on the Appalachian Trail?" "Why does [insert your competitor here]'s application have more features?" "Why does everyone else have a different approach?"

Is this nightmare business scenario the result of poor market research? Probably not. Technology moves more or less independently of business. While the online brokers of the world race to be part of the wireless trading craze, the technology has moved two generations beyond and users are tiring of punching in ticker symbols such as 4-4-4-2-2-6. If your organization wants you to develop a wireless application, you need to be fully aware of the available options and weigh the benefits and risks of each very carefully. In this article, we will discuss the current problems facing businesses entering the wireless domain, and how medium-client architectures such as Java 2 Micro Edition (J2ME) may offer the competitive edge that you are seeking.

BROWSER ORIGINS OF XML MESSAGING

Just like any other technology, wireless computing has gone through many phases to arrive where it is today. Some of the original efforts attempted to implement some type of text browser on the device. If your corporation wanted to have a serious network presence, it needed to support cell phones, Palm Inc. handheld devices, and desktop computers. As separate pages became a maintenance problem, you needed more sophisticated solutions. When Web servers became more advanced, device details were abstracted away, creating a "device-agnostic" architecture.

The typical solution used a device-independent layer, such as XML, to send data between the application-specific code and the device-specific generators, called transcoders. Adding support for a new device was simply a matter of adding a new transcoder. You could apply this type of solution in any number of ways using Java Server Pages, Personal Home Page Hypertext Preprocessor, Enterprise Java Beans (EJBs), Active Server Pages, and so forth. Several commercial products, such as NetMorf Inc.'s SiteMorfer (now defunct) and IBM's WebSphere Transcoding Publisher, were released in 2000.

Although this solution was a substantial leap forward, it shared some of the same problems faced by static pages and introduced some new issues as well. First, transcoding applications often required the definition of the intermediate XML. Second, some applications using this approach required the developer to design the mapping between the XML and the device-specific markup, leading to duplication of the mapping code because of the overlap between devices. Third, this method relegates the handheld device to simple browser status. Finally, the load on the server is substantial because it must render pages for every device it supports and validate any received data.

More powerful devices let developers host full-blown applications on the handheld devices. These applications were almost always written using a custom API and were tied to a specific device. The advantage of this approach was that the applications could make full use of the device features. If you couple a custom application with the wireless capabilities of handheld devices, you can enhance the user experience tremendously. Unfortunately, developing for one device commits your corporation to a particular vendor.

COMMON BARRIERS

If you take a step back and look at wireless application development as a whole, you'll see several common hurdles, regardless of the device you target or the development solution you use. The variety of wireless devices - each boasting a set of capabilities that varies wildly from one to the next - leads to an interesting set of architectural drivers that are not typically found in desktop computing:

• Limited bandwidth to the wireless device
• Inconsistent network coverage
• Lack of common display, computing, and input capabilities.

Any application that performs a semicomplex function must be customized to some degree for each device category that you target. Applications on wireless devices must be easy to use, concise, and aware of the data they present; and they must make the best use of the input features available on a device. A hard-to-use wireless application is absolutely unacceptable. In comparison, the desktop is very forgiving. After all, how often do you use desktop applications that are not very intuitive, or barrage you with unrelated information? Now imagine doing the same functions on your mobile phone during the commute to work.

Therefore, you must dedicate a component of your wireless application architecture to addressing the differences in presentation and interactivity between devices. In other words, because wireless devices vary in their capabilities, for many applications you can't implement a single presentation solution for all devices. Herein lies one of the greatest differences between desktop and wireless application architectures. Desktop computers generally have similar types of input devices, display capabilities, and computational horsepower.

You also face issues associated with the server side of the architecture. The bottleneck with respect to scalability and reliability is typically on the server side. The process of generating presentation code and data for a multitude of devices on the server side is not only computationally expensive, but also increases the complexity of the server. Removing these activities from the server allows for more effective scaling and may also reduce server downtime.