J2ME connects corporate data to wireless devices

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