J2ME: Understanding the Technical Challenges
J2ME can offer synchronization support for limited connected devices, rich user interfaces, and advanced client-server communications. However, making use of such functionality comes only after some understanding of the challenges and limitations.
Persistence/ Synchronization: Persistence is the ability for applications to run without a wireless connection. Synchronization is the ability to keep a local data store on the client side in synch with the server data store once connection is established. By definition, J2ME applications are persistent, but without a local data store, it is practically impossible to produce a compelling application. For example, a J2ME-based email program will be persistent, but without a local database of emails, you cannot read your email offline.
Maintenance: Building a client-side J2ME application with a thin-client data store may require significant development effort since this is, in essence, custom application development.
Maintaining a synchronized solution requires monitoring data integrity after synchronization, a challenging task in multi-user shared environments. Although some commercial synch servers are available, many have their own limitations and proprietary synch conduits. Unless seamless over-the-air incremental synch is provided, synch operations can take too long over low-bandwidth wireless links, and the alternative of lugging around cradles reduces the usability of wireless applications. For example, in a mission-critical enterprise application such as time and attendance and real time scheduling, duplicate data entries may result in incorrect billing and underserved customers. In such cases, it may be necessary to resolve synchronization conflicts manually, a costly proposition. Local databases result in a security issue when the mobile device is lost. Unless password-protected, local databases are easy targets to crack for hackers. Client-side application version control is another issue to consider, but using automatic over-the-air provisioning software can solve much of the problem.
Rich and Adaptive User Interface: J2ME MIDP offers a richer user interface and is not limited by the capabilities of WAP browsers. However, such a UI has to be custom-designed for the mobile application and potentially for different devices, if the low-level API is used. This design development requires skills beyond markup languages. In contrast, to create compelling WAP applications, an enterprise could use an HTML developer to learn WML and leverage its existing Web development process. A Java developer would only need to program the back-end, and the less-costly markup language/HTML developer puts the front-end/presentation layer together. A similar J2ME application would require the full involvement of a more expensive and skilled Java developer during the entire development process.
On the flip side, a J2ME application is built once, and automatically adapts to a device by using the device profile and configuration settings. WAP applications require a robust mobile application server, such as Aligo's M-1 Mobile Application Server, to adapt to multiple devices. Depending on the device, J2ME applications may have pull capabilities and incorporate animated graphics and streaming media, whereas the WAP application will be limited by the capabilities of WAP browsers.
Enhanced Client-Server Communications: MIDP devices can operate at an access protocol level different from WAP. J2ME on a WAP device can provide the ability to operate SSL end-to-end. The MIDP KSSL libraries perform the SSL encoding and decoding, while the WAP gateway only proxies the HTTPS requests. WTLS is not used at the gateway or on the end-device. For non-HTTP based applications, it is possible for certain MIDP devices to have a VPN client and tunnel into the enterprise. Installing and maintaining VPNs is an expensive endeavor for most enterprises, and costs may outweigh the benefits of enhanced functionality and speed.
J2ME in Summary
J2ME has the ability to improve the end-user experience for certain types of applications; that is, applications that demand an improved UI and can benefit from a disconnected mode of operations. Outside of these applications, it is likely that J2ME will enhance browser-based applications by providing off the shelf plug-ins to add to the end-user experience.
If an enterprise chooses to build MIDlets, however, it is likely that they will build server-side applications that will take advantage of the new capabilities provided by the plug-ins of the device. Wireless server-side development is facilitated with a mobile application server, such as Aligo's M-1 server, that allows the enterprise developer to build a server-side application once, and automatically defines a device profile that will tailor the application to fully utilize any capabilities the device may have to offer. In the mobile application server, device profiles may be developed that describe the capabilities of the device. The capabilities may include the type of MIDIets the enterprise has developed or third party plug-ins. In either case, by describing these capabilities for the device using a profile manager, the enterprise developer can build one application that will be customized for each device and its supported plug-ins.
J2ME does offer advances in application development of mobile devices in certain instances. Still, developers need to know the limitations of J2ME, identify the appropriate applications for its use, understand the differences among wireless devices, and ensure access to the appropriate technologies to speed development and deployment of any solution. Only then will J2ME have an appropriate role in mobile-enabling an enterprise.
Not currently available, J2ME will integrate the MIDP 1.0 NG specification, while KSSL has been tested alone with CLDC on the Palm.
Jeffrey M. Capone, Ph.D. is a noted author and frequent speaker on Mobile and Java Technology. He is currently CTO of Aligo, Inc.
Return to ONJava.com.