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.
What Role Does J2ME Have in Wireless Application Development?
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.