 | |
The Java 2 Platform Micro Edition (J2ME) has enjoyed an impressive response from the wireless industry since its introduction in 1999. Major software vendors, equipment manufacturers, and carriers have committed themselves to the J2ME platform, and J2ME-enabled wireless devices are readily available. As with any technology, though, vendors and carriers realized that the APIs lacked some useful features, and started adding proprietary APIs. For example, MIDP 1.0 implementers were required to support only the HTTP protocol, but Motorola added its own extensions to support TCP sockets and UDP datagrams. Such support is now part of the MIDP 2.0 specification. Through the Java Community Process (JCP), other major players have been standardizing a number of optional packages, which specific vendors may or may not implement in their devices. In the past two years, expert groups from all parts of the wireless communication industry have initiated Java Specification Requests (JSRs) to add new packages to J2ME. It's not clear which of these packages will become part of the J2ME core platform and which will be optional. This article provides an overview of the JSRs related to the Connected Limited Device Configuration (CLDC) and the Mobile Information Device Profile (MIDP) now under way, and provides an eye-opener to wireless Java developers who want to know what the future of wireless Java technology holds. This article:
The Java Community Process The Java Community Process defines itself as "...the way the Java platform evolves. It's an open organization of international Java developers and licensees whose charter is to develop and revise Java technology specifications, reference implementations, and technology compatibility kits. Both Java technology and the JCP were originally created by Sun Microsystems, however, the JCP has evolved from the informal process that Sun used beginning in 1995, to a formalized process overseen by representatives from many organizations across the Java community." JCP members include commercial entities, non-profit organizations, Java licensees, and individual experts. Members incur annual fees depending on the membership category; for example, $5000 for a commercial organization and $100 for an individual. To become a member of the JCP, you must sign the Java Specification Participation Agreement (JSPA), which sets out your rights and obligations when participating in the development of Java technology specifications in the JCP. For more information, see Becoming a Member, or an Individual Expert. The Process Management Office (PMO) is the group within Sun that oversees the Java Community Process and manages the daily running of the program. The actual development of each specification occurs within an expert group, a committee formed to draft and refine it. A specification begins as a Java Specification Request (JSR), a document submitted to the PMO by one or more members to propose the development of a new specification, or a significant revision to an existing specification. The JCP currently includes more than 200 JSRs (concerning the Standard and Enterprise editions of the Java platform as well as J2ME). CLDC 1.1 (JSR 139) The Connected Limited Device Configuration is the foundation for the Mobile Information Device Profile and other profiles. Its main goal is to standardize a highly portable, minimum-footprint Java runtime environment for resource-limited, network-connected devices. The devices targeted by CLDC have the following characteristics:
Cell phones, two-way pagers, organizers, and PDAs are some of the devices targeted by CLDC. CLDC 1.1 (JSR 139) is an incremental release based on the CLDC 1.0 specification (JSR 30). CLDC 1.1 is intended to be fully backward-compatible with CLDC 1.0 so it doesn't include any radical changes. The main new functionality in CLDC 1.1 is the support for floating-point numbers. The new features and improvements are:
MIDP 2.0 (JSR-118) The aim of the Mobile Information Device Profile is to establish an open, third-party application development environment for Mobile Information Devices (MIDs). In MIDP 2.0, a MID is a device with the following minimum characteristics:
The Mobile Information Device Profile v2.0 specification (JSR 118) is based on the MIDP 1.0 specification and is backward compatible with it, so MIDlets written for MIDP 1.0 will continue to run in MIDP 2.0 environments. The features of MIDP 2.0 include:
MIDP 2.0 has added four new packages:
Mobile Media API (JSR 135) The Mobile Media API (MMAPI) specification (JSR 135) defines a multimedia API that allows easy and simple access to and control of basic sound and multimedia resources. An implementation of the Mobile Media API is already available, and an emulator you can add to the J2ME Wireless Toolkit is available as well. You can download the reference implementation and install it on top of the J2ME Wireless Toolkit 1.4. Once installed, open the project mmademo and make sure you run it using the MMEmulator, which comes with the Mobile Media API reference implementation. Figures 1 and 2 show sample screenshots of the Mobile Media API player.
The J2ME Wireless Toolkit 2.0 will support the Mobile Media API. Wireless Messaging API (JSR 120) The purpose of the Wireless Messaging API (WMA) optional package (JSR 120) is to provide APIs for standard access to wireless communication resources, and thus enable developers to build intelligent network-connected Java applications. The wireless communication technologies addressed by this package are:
The Wireless Messaging API is based on the Generic Connection Framework defined in CLDC 1.0 -- a framework that supports input/output and networking functionality in J2ME profiles such as MIDP. A reference implementation of WMA is available for download. J2ME Web Services Specification (JSR 172) Whatever you do in the IT industry, it is very likely that you've heard of web services and the promise they bring. Web services are computing services offered over the World Wide Web, accessible from any web-service-enabled machine with Internet access. Web services provide platform-independent interoperability through a set of XML-based open standards. Organizations use the XML-based Web Services Description Language (WSDL) to describe their web services and list them on the Internet in an XML-based registry such as Universal Description, Discovery, and Integration (UDDI). The registry enables client applications like MIDlets to find publicly available web services as shown in Figure 3. A client sends a service request to the registry, which informs the client about the registered services that meet the criteria of the request. Client and provider, typically running on different platforms, then use the Simple Object Access Protocol (SOAP) to communicate, using HTTP and XML as the exchange mechanism.
The Java community is keenly interested in the potential for web services to provide a common infrastructure and programming model for next-generation enterprise services, and extending these services to J2ME-based clients. The J2ME Web Services Specification (JSR 172) aims to provide two optional packages for J2ME that will:
The technologies addressed by this JSR include:
The final release of this JSR is scheduled for Summer 2003. Security and Trust Services API for J2ME (JSR177) The objective of the Security and Trust Services API (JSR 177) is to define a set of APIs that provide security services to J2ME-enabled devices. Such services will rely on interaction with a security element in the device, which is responsible for:
A security element can be implemented in a variety of ways. Use of smart cards is common. For example, in GSM networks, the network operator puts the network authentication data on a SIM card. When this card is inserted into a mobile handset, it enables the handset to use the operator's network. This JSR will provide an access-model API to enable your applications to communicate with a smart card. Location API for J2ME (JSR 179) The goal of the Location API (JSR 179) is to define an optional package to enable developers to write location-based wireless Java applications. It will define a generic interface for positioning, and therefore should work with most positioning methods such as Global Positioning System (GPS) and Enhanced Observer Time Difference positioning (E-OTD). The API is intended to be extensible to fulfill special purposes. This API, however, raises a security concern. Users may be reluctant to allow discovery of their location by determining the position of their handset. Therefore, not all applications may have permission to use this API. The expert group for this JSR may rely on security features defined in MIDP 2.0 to enforce access control. This API will be of great benefit, however. Imagine you're in New York City for the first time, and you wish to use your cell phone to find a restaurant close to Times Square. You don't want to locate all the restaurants in the city, just the ones close by. This JSR will provide APIs that allow wireless application developers to build such location-based applications. SIP API for J2ME (JSR 180) The Session Initiated Protocol (SIP) API for J2ME was designed for establishing and controlling multimedia sessions on telecommunication networks based on the Internet Protocol (IP). It is also a signaling protocol for all IP-based wireless networks, Internet conferencing, telephony, events notification, and instant messaging. I expect that SIP will become an important protocol in IP-based mobile communications, and that SIP-based applications will be the essential enablers. The SIP API for J2ME (JSR 180) aims to define a general SIP API for J2ME clients, so that SIP applications can operate in memory-limited devices. Mobile 3D Graphics API for J2ME (JSR 184) The aim of the Mobile 3D Graphics API (JSR 184) is to define a lightweight interactive 3D API for use on J2ME-enabled devices. The API will be generic enough to be used for games, animated messages, screen savers, customer user interface, and product visualization. Event Tracking API for J2ME (JSR 190) The objective of the Event Tracking API (JSR 190) is to define an optional package that standardizes the tracking of application events on a mobile device and the submission of event records to an event-tracking server using a standard protocol (such as HTTP or HTTPS in MIDP2.0). The events will be used for purposes such as billing, usage tracking, application revocation, update notification, reviews, and ratings. The security issue raised by this JSR is how to authenticate the specific application, device, and user so that the server is able to validate the source of the event. The expert group for this JSR plans to take advantage of the security model of the underlying environment. The final release of this specification is expected to be in Spring 2003. Java Technology for the Wireless Industry (JSR 185) All the JSRs described here propose optional packages for CLDC/MIDP. What is really needed now is a set of guidelines describing how the various JSRs could work together to form a complete handset solution for the wireless industry. That is the purpose of JSR 185, Java Technology for the Wireless Industry. Its objective is to provide an overall architecture that would include which optional packages fit, and how an end-to-end solution for interoperable Java applications could work. The output of this JSR will be a collection of documents describing architecture and guidelines, and a reference implementation and technology compatibility kit (TCK) bundle for the JSRs. The documents will describe an architecture specification, a technology road map, and a user's guide. Note, however, that these documents may not address all JSRs proposed for J2ME. Status of JSRs Not all of the JSRs I've described have evolved to the same stage in the Java Community Process. Table 1 indicates the status of each, as of this writing. Before a JSR is finalized, it goes through a Community Review, followed by a Public Review several months later. Table 1: Status of JSRs
Conclusion J2ME technology has been very successful in the wireless industry. J2ME-enabled devices are already available from Motorola, Nokia, Ericsson, and others. This article provided an overview of complementary efforts that are currently under way to enhance the functionality of CLDC/MIDP devices. CLDC 1.1 and MIDP 2.0 will soon make their way into devices. MIDP 2.0 provides lots of interesting features that enable you to develop feature-rich end-to-end secure wireless Java applications. In addition, while all of the JSRs described above are interesting, I believe that the ones that will soon make their way into actual devices are the Mobile Media API (JSR 135) and the Wireless Messaging API (JSR 120). For more information
- J2ME Wireless Toolkit
Acknowledgments Special thanks to Nicolas Lorain of Sun Microsystems whose feedback helped improve the article.
Back To Top | |||||||||||||||||||||||||||||||||||||||||||||||
| | ||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||
Print-friendly Version
