CIOs and IT managers are always struggling to improve the availability of corporate data to those who need it to run the business. In the case of salespeople and mobile executives, that's a tall order. Ideally, you would use the very gear that these people already carry — such as PDAs or cell phones — to act as messaging systems and data terminals that can fetch customer information or place an order.
Unfortunately, the vast differences among these devices — Pocket PCs running Windows CE, PDAs running Palm OS or Linux, cell phones running the Symbian OS — pose significant problems for developers. Even the cell phones from a single vendor such as Motorola (the company I work for) can vary widely in processor type, memory amount, and LCD screen dimensions. Worse, new handsets sporting new features, such as built-in cameras and Bluetooth networking, are released every six months to nine months.
For IT managers whose chief concern is that applications running on device A today also run on device B tomorrow, the best choice among development platforms is J2ME, a slimmed-down version of Java tailored for use on embedded and mobile devices. Most handset vendors implement their own Java VM, and third-party VMs provide Java support in Palm and Pocket PC devices. For a broad range of devices, past, present, and future, J2ME provides a high degree of security and application portability — but not without drawbacks.
As were all editions of Java technology, J2ME was built to provide controlled access to program resources. The run-time architecture uses a “sandbox” mechanism that contains the executing program in a separate, protected memory space. This prevents code malfunctions from damaging other critical components of the run-time environment. Also, the program doesn’t have unfettered access to any low-level hardware or resources outside of the sandbox. Instead, all device operations are conducted via J2ME API calls.
There are good reasons to isolate a program from many of the phone’s functions. Unlike a desktop PC in which a program crash might clobber a word processing session, a cell phone is essentially a two-way radio. The Federal Communications Commission frowns on the improper use of radio transmitters regardless of the culprit — a cell phone’s owner or a malfunctioning program. And you wouldn’t want a Trojan program “phoning home” and transmitting personal information to a cracker. Because over-the-air provisioning allows users to download new applications, this makes the Java security sandbox more important than ever.
However, this protection scheme has its downside. Stated simply, if an API isn’t defined for a specific hardware feature, a developer can’t use that feature. For example, the Sony Ericsson T610 handset comes with an army of features: Bluetooth networking, infrared and serial connectivity, and a built-in digital camera. However, the current APIs in the T610’s J2ME implementation don’t utilize these features. Instead, you must use C++ and the Symbian OS (which lies under the J2ME abstraction layers) to access them.
Most vendors sidestep this issue by providing special Java APIs designed to access proprietary features. Unfortunately, each vendor devises its own unique set of APIs to use similar services. These incompatible APIs defeat J2ME’s prime directive to provide an abstract platform with a consistent interface that accesses all available features across all devices. Using such vendor-specific APIs also ties the application to a particular mobile device, which reduces an IT manager’s options to deploy the application as far as possible across the enterprise.
The Profile’s the Thing
J2ME limits support for vendor-specific hardware features to accommodate variations among devices. J2ME tackles hardware variations in two ways. First, J2ME defines an abstraction layer known as a configuration, which describes the minimum hardware required to implement Java on an embedded device. The J2ME configuration that addresses resource-constrained devices such as mobile phones and low-end PDAs is the CLDC (Connected Limited Device Configuration).
Second, J2ME defines a second abstraction layer, termed a profile, that describes the device’s hardware features and defines the APIs that access them. Put another way, profiles extend a configuration to address a device’s specific hardware characteristics.
J2ME currently defines one profile for CLDC devices: the MIDP (Mobile Information Device Profile). In addition to stipulating the basic hardware requirements, the MIDP implements the APIs used to access the hardware.
It’s important to understand that a J2ME device can have only one configuration that describes the core hardware. However, multiple profiles are allowed, including the MIDP and vendor profiles that support device-specific features. A vendor can therefore quickly adapt J2ME for a new device by writing profiles for it.
Besides interfaces, the MIDP describes the characteristics of a J2ME application, known as a midlet. Midlets are taxonomically similar to Java applets, the major difference being that a midlet can download data but not additional code through the connection. The end result is that a midlet has the potential to run unaltered on any J2ME-enabled device. Furthermore, because J2ME profiles define the interface, the appearance and behavior of the midlet on different devices is nearly identical. J2ME thus holds out the promise of becoming a universal front-end for client applications that can run on any mobile device.
The astute reader will have no doubt noticed the words “potential” and “nearly” in that last paragraph. Let’s face it: A few limitations in J2ME can hamper application portability. To begin with, subtle variations in each vendor’s J2ME implementation can cause incompatibilities.
Another issue is that if an API doesn’t exist for a specific device feature, you can’t use that feature at all. J2ME does specify optional standards, such as the MMAPI Mobile Media API, which provides support for audio playback and streamed video. Unfortunately, a developer can’t rely on an optional standard being available on every device.
However, J2ME is constantly evolving to address these concerns. In November 2002, the Java Community Process (JCP) released a significant revision to the MIDP specification. Called MIDP 2.0, it adds mission-critical APIs that support secure network connections (via HTTPS) and implements permissions with digital signatures to support trusted code. The specification also provides improved UI elements that offer enhanced form layout for business applications.
Unlike optional standards, a device that uses MIDP 2.0 must implement all the APIs that it describes, thus ensuring their availability to a program. Handsets that support the MIDP 2.0 specification should appear on the market later this year.
Down the road, the JCP proposes a new JTWI (Java Technology for the Wireless Industry) specification. In JTWI, a number of optional J2ME APIs — such as MMAPI and WMA (Wireless Messaging APIs) — become required services.
Even in its current state, J2ME offers developers the ability to write once and deploy a business application across the wide range of wireless gear currently available. J2ME’s abstraction layers also provide a hedge against vendor lock-in, and they help cope with the rapid changes in today’s wireless devices. Developers may have to craft the midlet’s interface to address the lowest-common-denominator display, but that’s a small price to pay compared with writing a custom client application for each device the corporation owns.