Enterprise Resource Planning

ERP Journal on Ulitzer

Subscribe to ERP Journal on Ulitzer: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get ERP Journal on Ulitzer: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

ERP Journal Authors: Elizabeth White, Progress Blog, Automic Blog, Janakiram MSV, Louis Nauges

Related Topics: Java EE Journal, Java Developer Magazine, ERP Journal on Ulitzer

J2EE Journal: Article

Java Technology for the Wireless Industry

Toys or Tools?

The Java Technology for the Wireless Industry specification (JTWI) encompasses a standard set of J2ME APIs for mobile device development that is being widely adopted by mobile telephone service providers, making it an important platform for Java developers.

Its core component, the Mobile Information Device Profile (MIDP), provides a number of specialized libraries for multimedia and games development; however, its underlying subset of general purpose Java classes is strictly limited. In addition, support for persistence via the Record Management System is relatively poor. This raises an important question: Is JTWI a realistic application development tool or is it only good for games and other software trivia?

In this article, we try to answer this question by exploring the viability of MIDP as a tool for nontrivial application development. An enterprise application that includes mobile components might reasonably expect to devolve some of its business processes and data management to mobile devices. Our chosen example, which considers both of these aspects, is a proposed implementation of the Java Data Objects (JDO) specification. This includes a number of interesting features that highlight the constraints of working with J2ME APIs for limited devices. We describe the issues around the development of such an implementation and the limitations that MIDP imposes, suggest some useful workarounds and architectural options, and finally draw some conclusions about the usefulness of JTWI as a set of APIs for serious application development.

Handheld computers, such as the Pocket PC and the Palm, can support reasonably complete Java Application Programming Interface (API) sets that can be used to develop serious enterprise applications. However, smaller devices, such as mobile telephones, only support Java APIs that have been significantly reduced to work within the confines of limited hardware. There is no support for the types of persistence mechanisms that we have come to expect on larger Java platforms. The question we address in this article is whether the mobile telephone is a viable platform yet for serious business or scientific applications that need to store and process data locally and that expect the services of a reasonably rich set of Java APIs.

To date, we have seen considerable development in areas such as mobile games development, but more serious business and scientific applications will need to be developed if JTWI is to be a useful component of enterprise software systems. Since such systems are likely to require considerable support for persistence, we focus on the JDO specification and examine some potential issues that arise when attempting to implement this specification using MIDP. We extrapolate from this analysis to assess the general usefulness of MIDP as a general purpose application programming platform. We also look at how MIDP devices fit into larger distributed architectures that can mitigate the limitations of mobile telephones as Java application platforms.

The Java 2 Micro Edition (J2ME)
To cater to a wide range of small devices and application requirements, the J2ME architecture (see Figure 1) provides multiple configuration and profile layers that overlay the specialized Java Virtual Machine (JVM) and operating system. Configurations define the minimum set of available JVM features and class libraries for a specific category of device and are hardware focused; profiles define the set of APIs available for a particular market category of devices and are software focused.

J2ME configurations specify the minimum requirements for memory, Java language features, JVM support, and runtime libraries. There are two standard J2ME configurations: the Connected Device Configuration (CDC) and the Connected Limited Device Configuration (CLDC). For the smallest portable devices, such as mobile telephones, the standard configuration is the CLDC. This configuration requires a very small virtual machine, such as Sun's KVM (Kilobyte Virtual Machine) or CLDC HotSpot Implementation, with footprints of only about 50-80K. These virtual machines don't have to comply with the full JVM specification, nor do they have to support the complete Java language specification. API support is limited to a selection of classes from a few packages from the Java 2 Standard Edition (J2SE), plus the Generic Connection Framework (GCF), comprising a hierarchy of connection interfaces (and the Connector factory class) that are intended to provide a generic way of expressing operations on connections regardless of the actual protocol.

Java Technology for the Wireless Industry
The key goal of the JTWI specification is "to minimize API fragmentation in the mobile phone device market, and to deliver a predictable, clear specification for device manufacturers, operators, and application developers" (http://jcp.org/aboutJava/communityprocess/final/jsr185/index.html).

Thus, we can reasonably expect the next generation of Java-enabled telephones to support these technologies. The specifications included within JTWI are:

  • Mandatory specifications:
    -Mobile Information Device Protocol (MIDP) 2.0
    -Wireless Messaging API (WMA) 1.1
  • Optional specification:
    -Mobile Media API (MMAPI) 1.1
  • Minimum configuration on which JTWI is built:
    -Connected Limited Device Configuration (CLDC) 1.0
From an application development perspective, the most important API is MIDP (and by implication the CLDC upon which it builds), since these are the APIs that provide a subset of the standard Java packages found in the Java 2 Standard Edition, along with additional APIs specifically tailored for mobile development. One important issue with JTWI is that it mandates only CLDC 1.0, not CLDC 1.1, which, as we will see, introduced some important new features.

The Mobile Information Device Profile
The MIDP is one of two profiles (the other being the Information Module Profile) that works on top of the CLDC. It provides graphical interfaces for interactive applications and is the standard Java profile for mobile telephone development under the JTWI specification.

There are seven packages containing the additional classes and interfaces of the MIDP, providing user interface features at two levels of portability, sound support, certificate-based authentication, persistence, and the MIDlet framework for deploying classes into a MIDP environment. There are also extra classes in the javax.microedition.io and java.util packages.

The sum of APIs available to a MIDP developer will be the combined set of classes in the CLDC and MIDP. Figure 1 summarizes the relationships between the relevant configuration and profile APIs and the underlying J2ME JVM.

What Is Missing from MIDP?
To consider how viable MIDP is as a general-purpose programming framework, it's useful to explore which packages and classes are excluded from it when compared with the standard edition. Of course, MIDP provides its own classes for graphics and sound, so there are no AWT, Swing, or sound-related packages from the standard edition. Similarly, MIDP has its own (limited) security classes, so there are no javax.security packages either. Since the Generic Connection Framework covers connectivity, packages relating to CORBA and network connections are also excluded. RMI likewise is not part of MIDP; although there is a separate J2ME RMI profile, it can only be used with the CDC configuration, not with CLDC. Other missing packages are those that relate to JavaBeans, reflection, XML, printing, and JNDI.

Although MIDP excludes many packages that are present in the standard edition, many of these have equivalents in the MIDP packages or, like printing, are not particularly important for mobile devices. However, it is in those packages that are included in MIDP that we find the most constraining factors, since these packages have far fewer classes in MIDP than in the standard edition. For example, MIDP includes only one interface and nine classes from java.util, as opposed to 14 interfaces and 41 classes in the standard edition (version 1.4), principally due to the absence of the Java 2 Collections Framework.

More Stories By David Parsons

David Parsons is a senior lecturer in information systems at Massey University, Auckland, and a knowledge engineer for Software Education Associates, Wellington. Until last year he was the director of emerging technologies at Valtech, London, and prior to that principal technologist at BEA Systems.

More Stories By Ilan Kirsh

Ilan Kirsh is a lecturer in Computer Science at the Academic College of Tel-Aviv-Yaffo, and the author of ObjectDB (www.objectdb.com), a pure JDO object database for J2EE, J2SE and J2ME.

More Stories By Mark Cranshaw

Mark Cranshaw is a senior lecturer in the Faculty of Technology at Southampton Institute. He has extensive experience of delivering education using Java technologies, including JDO tools. His current research interests include mobile Java and HCI.

Comments (2) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

Most Recent Comments
Ajay D. Desai 01/24/05 06:19:32 AM EST

Mobile phone's software development has to take place within the limits of that device. For this reason, it is necessary to expand limits of mobile phone. Mobile phones should be equipped with full english keyboard and other special characters like PC keyboard of 101 keys. This will enable computer like usage of mobile phone. Particularly, it may be difficult to use Asian languages on mobile phones. Having bigger key board will make it possible to use all languages on mobile phone.

C. Enrique Ortiz 01/22/05 11:01:36 PM EST

The articles title is "Java Technology for the Wireless Industry", but most of it concentrates on JDO. The title is misleading - it should have been called "JDO and J2ME" or something like that.

The article is misleading, for one because it concludes "MIDP specification is an interim set of APIs"... because of the difficulties the authors encountered while implementing JDO on MIDP; JDO this is not a typical application, and not a good example for JTWI.

I do agree with the authors comment "At present, mobile phone developers must work within the constraints of current devices and work around the constraints of the platform as best they can."; But the authors must understand that writing wireless mobility software is NOT the same as writing desktop or enterprise software.

The authors say "developing software for mobilized architectures requires us to consider a range of aspects of design and implementation in order to identify the optimum configuration"; yes, that is what makes writing software for mobile, constraint devices so specialized.

JDO on MIDP (on top of RMS) is too heavy. Instead of JDO to access a server DB, data synchronization should probably be used.

C. Enrique Ortiz, J2MEDeveloper.com