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.

MEDIUM-CLIENT ARCHITECTURE AND J2ME

To address the aforementioned issues, a medium-client architecture has evolved. A common desktop example of this architecture is a Java applet hosted on the client. Most, if not all, of the business logic still resides on the server, where you can most easily deploy bug fixes and enhancements. However, the client is no longer a simple data display. It can present an application-specific interface to the user, perform basic data validation, cache data, and so on. The million-dollar question is: how do you partition your architecture? Although you may have no shortage of opinions, actually designing the system requires some experience.

Generally speaking, the client-neutral interface exposed by your server offers the business services your application provides. You can choose from several technologies, including generic XML, DCOM, EJB, and simple object access protocol (SOAP). By removing the knowledge of the client from the server, adding a new client is simply a matter of developing the application to use the same interface. You don't need to modify the server components. Because the client implementation is irrelevant to the server, you can optimize different clients based on the context of where they will execute. For example, if bandwidth is not a problem but your computation power is limited, the client would not perform user input validation on the device. Nevertheless, if bandwidth is a driving force, the client could validate user input locally before transmitting anything to the server.

By using a medium-client architecture for your wireless application, you have substantially more control over interaction with both the server and the user. Unfortunately, developing an application for mobile devices has traditionally meant a custom application for each device with very little reuse. Sun Microsystems has attempted to address this problem by moving its promise of "write once, run anywhere" Java solutions to limited-capability devices. J2ME is a subset of the Java 2 Standard Edition (J2SE) for handheld devices.

With J2ME, Sun has defined a set of configurations that describe families of devices. These configurations provide the minimum set of capabilities a device must support and offer foundation classes to develop an application. Profiles sit on top of these configurations and define a higher-level set of functionality offered by a particular device. For example, cell phones and personal digital assistants each have different profiles. A device uses only one configuration, but may support many profiles. Applications - built on top of the profiles - can determine at run time which profiles the device offers and use them appropriately.

Although J2ME restricts some of the J2SE features you can use in your application, the possibility for reuse from desktop applications and server-side components is huge if properly designed. Not only can you reuse Java code, you can share fully compiled class files across devices. J2ME supports language features such as threading, garbage collection, network I/O, and persistent storage in a way that's familiar to any Java developer rather than specific to a device. J2ME also helps address client distribution through the Java Application Manager (JAM). JAM lets devices download applications through whatever means the device can support (such as synchronization or wireless download). Users can upgrade their client applications remotely whenever a new version is released.

DESKTOP AND WIRELESS SUPPORT

You can easily imagine an application that uses a medium-client architecture to accomplish tasks that would be difficult or impossible with earlier wireless application solutions. Let's discuss a mobile sales force application from which sales personnel retrieve client information, enter orders, and get current product information. Your company would like to support both desktop and wireless users because the staff filling the orders and maintaining customer information works in the office, but your sales staff spends most of the time on the road.

Then you may make the architectural decision to use a multitier application, hosting business functionality on the server, and providing a medium-client application for remote use. This application requires defining an interface between the client and server. If you choose a standard interface solution such as SOAP, you can implement the client and server any way you want. Then you can use DCOM, EJB, or even Perl to implement your back end. Again, each of these choices has trade-offs, but that is beyond the scope of this article. (However, as an aside, if you were to implement your back end in Java, you would increase the possibility for reuse even more.) At this point, all you should care about is your SOAP interface to the server.

You must now consider your client implementation. If you build a thin, browser-based client for your wireless users, the application is only useful in areas with coverage. Also, you have no way of caching any information on the device; if the user wants to look at an old purchase order while entering new purchase information, you need to push current data to the server, request the new information, and then retrieve the old information to continue.

In addition, you definitely don't want to restrict your home office users to a browser solution, so you need to develop two independent applications. If you beef up your wireless client slightly, you could cache relevant sales information on the device, protecting your users from loss of coverage and allowing them to look at old information while temporarily holding new data before submitting the request to the server. Once you have decided that a medium client makes the most sense for your wireless users, you must address how to build it.

BUILD ONCE FOR ALL

If you would like to support multiple devices, building custom applications for each one is enough to make even the most highly skilled development team squeamish. By building a J2ME client, you can write one application that would work across all devices in a given configuration. In addition, if you design your application for reuse, you could write your desktop application in Java (either as a stand-alone application or an applet) and share code, classes, and even whole components between clients. For example, wireless-specific code has no place in classes such as order, customer, item, and so on.

Obviously, we have simplified this example. Nevertheless, J2ME is not a silver bullet, and implementation decisions often involve far more extensive factors than the ones we discussed here. However, one of the founding principles of software architecture is leveraging common, proven solutions to well-established problems. J2ME is the first real opportunity to achieve solutions such as medium clients, device independence, and reusability when building wireless applications. Regardless of the technology used to implement medium-client architectures, wireless applications have a lot to gain from moving away from the browser-based solutions currently used today. J2ME is causing a commotion in the wireless world and companies ignoring it for quick and dirty browser solutions are doing so at their own peril.

CHRISTIAN NELSON [cnelson@blueprinttech.com] & DAN PILONE [dpilone@blueprinttech.com] are component framework engineers with Blueprint Technologies Inc. (www.blueprinttech.com), a software architecture company located in the Washington, D.C. metropolitan area. They spend their time performing object-oriented design, implementation, and mentoring for a variety of clients.

Java 2 Platform Micro Edition:

Related Articles on IntelligentEnterprise.com:

"IT and the Now Economy," January 30, 2001

"Untangling the Web," March 27, 2001

"Shaking off the Wires," July 17, 2000