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

Continued from Page 1

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.

Rate This Article Rating: 1 (best) 2 3 4 5 (worst) Comments: Optional e-mail address:

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