Mobile technologies are only at the cusp of software innovation. We have seen similar inflection points of innovation in other segments of technology whenever the gap between network connectivity and device capabilities has widened. In the not so distant past, when direct-connection bandwidth exceeded the processing capabilities of mainframe dumb terminals, server-side mainframe applications ruled.
More recently, when the PCs came to being, with superior processing capabilities, and Intranet and Internet network connectivity performance lagged, client application development gained traction. As a result, client-side operating systems and application-development and -deployment software became critical. Such software filled the gap between processing capabilities of client devices and network connectivity by offering synchronization, better user interfaces, and advanced server-side communications. Enterprises became the first buyers of such software, to maximize the benefits of their centralized data stores and decentralized processing power residing on the client devices.
Currently, over forty percent of enterprise employees use mobile devices. Reflecting past technological gaps, continuous advances in hardware technologies have pushed mobile device capabilities to exceed their networks' performance. With the lags involved in migrating the networks to 3G connectivity, enterprises look to software solutions for synchronization, server-side communications, and better user interfaces. In this article, we will discuss the role of J2ME technology, and discover not only its strengths to fill in the software gaps, but also the associated development, maturity, and maintenance cost for the enterprise. In the conclusion, you will be provided a map that can explain where and how J2ME applications can meet enterprise needs.
How will J2ME impact wireless application development? To answer this question, we need to understand what a wireless application is, and more generally, what an application is. In summary, an end-user application (as opposed to an embedded application) consists of the following components:
An application can then be classified as a distributed or local application. Distributed applications typically involve a client component and a server component of the application, whereas a local application resides on a single device.
Wireless devices and networks pose additional challenges for client-server application development. Some of the challenges include:
Wireless applications are, therefore, client-server applications that operate over unreliable low-bandwidth links on devices with limited capabilities. Some technologies exist to attempt to alleviate the problems associated with building such applications. They include:
WAP (Wireless Application Protocol) was designed to allow wireless devices running on high-latency, low-bandwidth networks to access Internet and Intranet applications despite restrictions such as small screens and limited keyboards. Since the foundation of the Wireless Application Protocol Forum in June 1997, WAP has gained a substantial amount of industry support, and WML (Wireless Markup Language) and WMLScript have been the standard choices for delivering and presenting wireless Internet content to ultra-thin mobile devices, particularly mobile phones. For wireless application development, WAP provides WML for preparing the user interface. With the introduction of WAP 1.2, some of the application logic, in addition to the user interface, may reside on the client through the use of WMLScript. WAP contains a transaction protocol (i.e., Wireless Session Protocol) similar to HTTP; it is actually WML that lets you build browser-based, thin-client applications optimized for wireless delivery.
Will J2ME indeed bridge the wireless technology gap?
In addition to WAP, there are iMode- and Palm-based technologies that offer services similar to WAP over wireless networks. The technologies use compact and clipped HTML to display data, but they have no provisions for scripting.
Java 2 Platform, Micro Edition (J2ME) is a Java-based programming language that lets you build client-side applications optimized for mobile devices that have limited resources. These devices are also referred to as connected limited device configuration (CLDC) devices. A Java application that conforms to the specifications set out by the CLDC spec and the Mobile Information Device Profile (MIDP) is called a MIDlet. While MIDlets may have an improved user-interface, contain more client-side application logic, and use local data stores (e.g., thin client databases) to give them the ability to run in offline mode, they still require some level of network connectivity. CLDC specifies a networking library, so that MIDlets do not necessarily need to employ browsers.
J2ME (MIDP) may be installed on Palm, WAP, and iMode devices to provide these advanced functionalities, as long as limitations of the device are taken into account.
The key technologies that J2ME MIDP has to offer for wireless application development are:
J2ME is not a replacement for WML, but may be viewed as a complementary technology to expand the usefulness, capabilities, and look and feel of WAP applications. Since WML relies on a browser to interpret content, its UI is limited by the capabilities of WML browsers. WAP application user interfaces are limited by the markup language interpretation capabilities of the browsers. Moreover, there is incompatibility between micro browsers and gateways from different vendors, making user-friendly UI design quite difficult. However, when coupled with J2ME, users can download J2ME applications via their standard WAP browser. Then they can enjoy full-color graphics and applications that have some potential to improve navigation.
Once a Java application (MIDlet) has been stored on a handset using the Java Application Manager (JAM), it is persistent and does not consume airtime. As necessary, it can then exchange data with backend systems using the existing WAP gateways and infrastructure. Moreover, it can support other Internet protocols beyond WAP. For example, you might download an IMAP-based J2ME email application and communicate directly with your backend mail server, not only providing faster data exchange, but also providing offline email capabilities.
J2ME applications can utilize a local database to store, replicate, and process information, only synchronizing with the server when connected and thus enhancing its usability offline.
J2ME can offer additional security beyond WAP. WAP currently uses the WTLS (Wireless Transport Layer Security) specification, which has some well-known limitations. WTLS has a lot in common with standard SSL (Secure Sockets Layer), but it is specifically designed to conduct secure transactions over a low-bandwidth, high-latency transmission environment without requiring extensive processing power or memory. It utilizes a WAP gateway that acts as a translator between WTLS encryption and the Web's standard, more robust SSL security protocol. The problem (called the WAP-Gap) occurs when the data is handed over from WTLS to SSL, where the data is decrypted and then re-encrypted. This implies that for a few microseconds, the data is left unencrypted. Using MIDP libraries, the developer can use the kilo SSL (KSSL) libraries to have an end-to-end secured socket layer. With the KSSL libraries, the Java application is performing the SSL encryption and decryption; WTLS is avoided and there is no decryption and encryption preformed at the gateway. However, the gateway must still proxy the HTTP requests and response and forward client and server certificates.
J2ME has the potential to improve the end-user experience for certain applications. For example, a data collection application such as a time and expense application can be improved by offering off-line operation and periodic synchronization of the data with the back-end system. Using synchronization, the application is not required to be connected to enter the data that is collected throughout the day. Other applications that are time-critical, such as stock trading, require the application to always be connected to conduct the transactions. Since these transactions are time-critical, it is imperative that the transaction be processed by the back-end system and a confirmation returned in real-time. The ability to benefit from the storage library and synchronization capabilities of J2ME will heavily depend on the time-scale of the application.
The UI libraries of J2ME have the ability to improve the usability of the application over a browser-based solution. The UI libraries offer a low-level and a high-level application programming interface (API). The high-level API is portable across all MIDP devices; however, there is no direct access to native device features such as device key events and drawing primitives. The low-level API allows access to native features, but at the cost of portability. The ability to improve this experience is limited by the capabilities of the device and the need for portability.
Certain applications can take advantage of the UI features that J2ME has to offer. For example, a mapping application or a calendaring application could significantly benefit from the improved UI, as seen in Fig 2. These applications could use features of the J2ME UI API to display data in a manner that is not supported in WML.
Other applications do not require the improved UI functionality. Consider many banking applications similar in functionality to your average automatic teller machine (ATM) application. Since most of these applications are menu-driven, the MIDP UI does not have much ability to improve the data presentation over WML.
The challenge is to understand the application requirements and decide the best technologies to apply to solve the problem without over-engineering.
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 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.
Copyright © 2009 O'Reilly Media, Inc.