Getting Started With the Information Module Profile

Print-friendly Version

Hundreds of millions of mobile devices now support the Mobile Information Device Profile (MIDP), the most popular profile in the Micro Edition of the Java platform (Java ME). The most common mobile devices comfortably meet or exceed MIDP's requirements for interactive use: a minimum graphical display of 96x64x1, and a simple keyboard or touch screen. There are many kinds of devices, however, that have only a very simple user interface, or none at all: vending machines, alarm systems, routers, elevators, automobile engines, industrial utility meters, and others.

These devices, called information modules (IMs), are designed for stand-alone operations. They're becoming intelligent and connected. Imagine a vending machine that can talk to its suppliers and order restocking as needed.

Although such devices don't need the display and input mechanisms to support a sophisticated GUI, they do need many of MIDP's other capabilities. To address these requirements, a separate profile has been developed and enhanced within the Java Community Process (JCP). JSR 195, the Information Module Profile (IMP), supports features found in MIDP 1.0, and JSR 228, Information Module Profile - Next Generation (IMP-NG) adds support for features added to MIDP in its 2.0 release. IMP defines the architecture and the associated APIs needed to provide a Java environment for developing IMlets – applications intended to run on networked embedded devices that lack rich interaction capabilities, or whose resources are limited in other ways.

This article provides a technical introduction to IMP, describes the profile's architecture and programming model, and provides sample code. In addition, the article identifies kinds of applications that depend on information modules, and discusses some of the wireless modules that support IMP.

JSR 195 defines a profile that's a strict subset of MIDP 1.0. Like MIDP, it's based on the Connected Limited Device Configuration (CLDC). JSR 195's expert group based IMP's original capabilities on MIDP 1.0 rather than MIDP 2.0 because the latter had not yet been finalized when work on IMP began, in October 2002. IMP has inherited key features from MIDP 1.0:

• The execution environment: multi-threaded, identical application life-cycle, and the javax.microedition.midlet package, unchanged
  
  
• The RMS, Timer, and Connector APIs

IMP-NG, released in November 2005, was a response to the growing needs of embedded networked devices for the advanced features added to MIDP in release 2.0, principally security enhancements and additional communication protocols. JSR 228 is a strict subset of MIDP 2.0, tailored to the requirements of information modules. The stated goals of IMP-NG were to:

• Enforce backward compatibility with JSR 195
  
  
• Maintain tight footprint objectives to limit growth in the core APIs
  
  
• Support all functional areas of MIDP 2.0 that are useful for embedded networked devices, such as:
  • The domain security model, including signing of applications and verification of certificates
  • HTTPS and secure networking
  • Network connectivity using datagrams and sockets, including secure sockets
  • Over-the-airprovisioning
  • Push architecture: external events and messages routed to appropriate IMlets

To help ensure that IMP can address the needs of modems, alarm systems, routers, and other devices with primitive user interaction or none, the IMP expert group has clarified and quantified the definition of "information module," specifying these characteristics:

• Memory
  • 128 kilobytes of non-volatile memory for the IMP components
  • 8 kilobytes of non-volatile memory for application-created persistent data
  • 32 kilobytes of volatile memory for the Java runtime's heap
  
  
• Networking
  • Two-way wireless communication, possibly intermittent, within limited bandwidth
  
  
• Display
  • UI capabilities, if any, that do not allow the use of MIDP UI
  
  
• Sound
  • In IMP-NG, the optional ability to play tones, using either dedicated hardware or software algorithms

Even within these specifications, there is a broad range of possible software capabilities. IMP makes minimal assumptions about the information module's system software:

• A minimal kernel to manage the underlying hardware, including handling interrupts, exceptions, and scheduling
• The kernel must provide a schedulable entity to run the Java virtual machine¹, but the kernel need not support multiple processes or make guarantees about real-time scheduling or latency behavior.


• A mechanism to read and write from non-volatile memory, to support the Record Management System (RMS) APIs
  
  
• Read and write access to the device's wireless networking, to support the networking APIs
  
  
• A mechanism to provide a time base for use in time-stamping the records written to persistent storage, and to provide the basis of the Timer APIs
  
  
• A mechanism for managing the application life-cycle

To give you a general idea how IMP fits into a device, Figure 1 provides a high-level view of the architecture. Note that not all devices that implement IMP will have all the components you see here, and devices are not required to layer the software as shown.

Figure 1: IMP Architecture"

In this figure, the lowest-level block represents the information module's hardware. On top of that resides the native system software, including the operating system and libraries the device uses. The next layer is CLDC, which comprises the Java virtual machine and associated libraries defined by the CLDC specification. On top of CLDC are two categories of APIs: IMP and OEM-specific. Given the diversity among information module devices, it's impossible for a platform-independent profile like IMP to address all device capabilities fully. To access functionality specific to a given device, developers may need to use APIs provided by the OEM, reducing portability.

As a result, there are three types of applications:

• Native: built directly on the IM's existing native system software, with no reliance on Java technology
  
  
• OEM-specific: written in the Java programming language but dependent on classes not included in the IMP specification, and as a result not portable across IMs
  
  
• IMlet: developed using the IMP APIs; likely to be the most common type of application on information modules

IMP 1.0 inherits five packages from MIDP 1.0:

• javax.microedition.midlet: the application life-cycle package
  
  
• javax.microedition.rms: the persistence package
  
  
• javax.microedition.io: the networking package
  
  
• java.lang and java.util: the MIDP language and utility classes

IMP-NG inherits some additional functionality for networking, in the javax.microedition.io package, and for security:

• javax.microedition.pki: the public key package; certificates are used to authenticate information for secure connections
  
  
• javax.microedition.media: the optional sound and tone media APIs
  
  
• javax.microedition.media.control: the optional package that defines specific control types that can be used with a player

An IMlet's life-cycle is similar to that of a MIDlet. You even implement it by extending the javax.microedition.midlet.MIDlet class. Remember, though, that an IMlet cannot use classes that are defined in MIDP but not in IMP.

IMP defines two additional property values that the application must be available to retrieve using the java.lang.System.getProperty() method:

• microedition.locale, the current locale of the device, which is null by defaullt
  
  
• microedition.profiles, which must contain at least IMP-1.0

Just as you package MIDlets in a MIDlet suite, you can package one or more IMlets in an IMlet suite, a single Java ARchive (JAR) file that includes a manifest file describing the contents, a Java Application Descriptor (JAD) file, Java classes for the IMlets, and any resource files used. You'll see a sample manifest and an application descriptor later.

Once you've developed some IMlets, you need to deploy them. The IMlet management software handles the retrieval, installation, launching, version management, and removal of IMlets and IMlet suites. A device may support retrieval of IMlets by way of a serial cable, an IRDA port, or a wireless network. Once an IMlet has been retrieved, it will be verified and installed. Then the user can launch it.

Because IMP is based on MIDP, developers find that their knowledge of MIDP transfers to the IMP sphere easily, and they soon feel at home. An IMP application's starting point is the IMlet class itself, inherited from javax.microedition.midlet.MIDlet. It must define the following methods:

• public void startApp() throws MIDletStateChangeException is the IMlet's entry point, called by the Java application manager after the IMlet is loaded into memory. The method can be called multiple times: when the IMlet is first started, and every time it's resumed from the paused state
  
  
• public void pauseApp() is called by the Java application manager to notify the IMlet that it will be set to the paused state
  
  
• public void destoryApp(boolean unconditional) throws MIDletStateChangeException: is called when the IMlet is to be destroyed. Setting the flag to false prevents completion of the destroy request by throwing an exception. If the IMlet calls notifyDestroyed(), the Java application manager does not call destroyApp(). The IMlet can stop execution by calling the notifyDestroyed() method of the MIDlet superclass.

The IMlet development cycle too is similar to that of a MIDlet:

1. Write the application.
2. Compile it.
3. Preverify the classes.
4. Package the classes and other files in a JAR file.
5. Create a Java application descriptor (JAD) file.

Machine-to-machine (M2M) refers to systems that enable machines such as home devices, vending machines, or utility meters to communicate automatically, without human intervention. In such systems intelligence is embedded in the communicating devices, heralding an equivalent of the industrial revolution for connectivity. IMP provides the core application functionality needed by M2M applications, including network connectivity, local data storage, and application life-cycle management.

M2M promises to be a challenging and profitable sphere of business. Solutions are developed by combining contributions of several kinds of players, including system integrators, service providers, mobile operators, and application developers. Example opportunities include:

• Sales and payments: vending machines and point-of-sale (POS) terminals
  
  
• Remote metering and monitoring: utility meters, parking meters, vending machine control
  
  
• Fleet management: vehicle and cargo tracking
  
  
• Security and surveillance: access and mobility control, surveillance cameras, and asset monitoring

Wireless modules are the key to the communication that's at the heart of M2M. Not only do they improve existing products, but they increase effectiveness. They help users of M2M systems lower costs by deploying personnel more efficiently, and save time by identifying problems early and reacting immediately.

M2M products relying on IMP are on the rise. For example, Siemens offers M2M solutions that include a range of wireless modules that support voice, fax, and SMS transmission based on IMP. These are commonly used for security systems or for remote reading of electricity meters, but can also be found in M2M applications such as fleet management and tracking systems, vending machines, POS terminals, and GSM gateways.

Nokia developed the Nokia 12 GSM module to support IMP, along with Serial, I/O, wireless messaging, HTTP, Socket, Whatchdog, and ORB APIs. Nokia has since spun off this product to another Finland-based company, Aplicom. Nokia continues to offer the Nokia 12 IMP 1.0 Concept Simulator, which lets a developer do the initial verification of an application in a simulation environment, before acquiring the actual GSM module. In the next two sections I'll show you how to integrate this simulator into a popular integrated development environment, and how to build an application and test it in the simulator.

You can integrate Nokia's simulator into development environments like JBuilder, Sun One Studio, and the Sun Java Wireless Toolkit, which you can download freely. I tested the simulator in version 1.0.4 of this toolkit.

Integration is straightforward:

1. Download and install the Sun Java Wireless Toolkit, if you haven't already, in any directory you like. In this article, I'll refer to the installation directory as <toolkit>.
   
   
2. Configure the toolkit environment. Ensure that the text file <toolkit>/wtklib/runtime.properties includes kvem.otherVM: true. If the file doesn't exist, create it.
   
   
3. Install the Nokia simulator in <toolkit>/wtklib/devices.
   
   
4. When compiling IMlets in the Sun Java Wireless Toolkit you should use the classes in the classes.zip that comes with the simulator. One way to ensure you do is to combine these classes and the toolkit's classes in a single .zip file when you install the simulator.
   
   
5. Start the Wireless toolkit; the simulator should appear in the toolkit's device list, as shown in the figure.

Figure 2: The Nokia 12 IMP 1.0 Simulator Integrated Into a Popular IDE

In this section, you'll use the Nokia simulator from the command line to simulate execution of an IMlet. Instructions assume you have downloaded the simulator and installed it in <toolkit>/wtklib/devices/Nokia-Simulator.

1. In <toolkit>/wtklib/devices/Nokia-Simulator create three subdirectories:
   test, to contain manifest.mf, .java, .jar, and .jad files
   classes, to contain .class files
   preverified, to contain preverified .class files
   
   
2. The next step is to write an IMlet. The following sample uses Nokia's I/O APIs to set the output pin 7 on and off. Save it as Blinker.java in the test directory.
   
   

   /** * Sets output pin 7 on and off. */ import javax.microedition.midlet.MIDlet; import javax.microedition.midlet.MIDletStateChangeException; import com.nokia.m2m.imp.iocontrol.IOControl; public class Blinker extends MIDlet { private static final int OUTPUT_PORT = 7; protected void startApp() throws MIDletStateChangeException { boolean on = true; try { if (on) { on = false; IOControl.getInstance().setDigitalOutputPin (OUTPUT_PORT, true); } else { on = true; IOControl.getInstance().setDigitalOutputPin (OUTPUT_PORT, false); } Thread.sleep(500); } catch (Exception ignored) { } } protected void pauseApp() { // Not needed. } protected void destroyApp(boolean unconditional) throws MIDletStateChangeException { // Not needed. } }

    
   
3. Compile Blinker.java, using the classes.zip that comes with the simulator, and directing Blinker.class to the classes subdirectory. Here's the command:
   

   javac -bootclasspath ../lib/classes.zip -d classes Blinker.java 

4. Preverify Blinker.class and write the output to the preverified subdirectory, thus:
   

   preverify -classpath ../lib/classes.zip -d preverified classes 

5. Before you can package the pre-verified class in a JAR file, you must create a manifest, which specifies the IMlet name and other important information the Java application manager will need when you start the IMlet. Here's a sample manifest file, manifest.mf:
   
   

   MIDlet-1: Blinker, , Blinker MIDlet-Name: Blinker MIDlet-Vendor: Nokia Corporation MIDlet-Version: 1.0 MicroEdition-Configuration: CLDC-1.0 MicroEdition-Profile: IMP-1.0

    
   Note the specification of the IMP 1.0 profile where the manifest for a MIDlet suite would specify a version of MIDP.
   
   
6. Now you can create the JAR file:

   jar cmf manifest.mf blinker.jar -C preverified Blinker.class 

7. Create a JAD like this one, calling it blinker.jad:
   
   

   MIDlet-1: Blinker, , Blinker MIDlet-Jar-Size: 100 MIDlet-Jar-URL: blinker.jar MIDlet-Name: Blinker MIDlet-Vendor: Nokia Corporation MIDlet-Version: 1.0

    
   
8. Before you can run the IMlet you need to set some environment variables:

   set EMULATOR_HOME=/wtklib/devices/Nokia-Simulator
   set DESCRIPTOR_FILE=/wtklib/devices/Nokia-Simulator/test/blinker.jad
   

9. Now run the IMlet using the simulator:
   

   java
   -classpath %EMULATOR_HOME%/bin/emulator.jar;%EMULATOR_HOME%/externalapp/classes;%EMULATOR_HOME%/bin
   -Demulator.home=%EMULATOR_HOME% com.nokia.phone.sdk.Emulator
   -Xdescriptor %DESCRIPTOR_FILE%
   

If all goes well, you will see a dialog similar to Figure 3. Note that the box for output pin 7 is checked.

Figure 3: The Nokia 12 IMP 1.0 Concept Simulator at Work (Click image for larger view.)

Machine-to-machine systems will compose a significant sector in the mobility industry as information modules join mobile phones and pagers in the fast-growing world of mobile connectivity and Internet access. Given the tens of billions of machines in the world, the potential for the M2M market is vast, but the only way to remove the barriers to this market is through standardized solutions. The Information Module Profile (IMP) is a major step towards standardization. IMP provides a Java application environment for networked embedded devices with limited capabilities for user interaction, or none. This article provided a quick tutorial on IMP 1.0 and IMP-NG, the IMP programming model, and using the Nokia 12 IMP 1.0 Concept Simulator for IMlet development.

• Information Module Profile product description
  
  
• JSR 195: Information Module Profile 1.0 specification
  
  
• JSR 228: Information Module Profile - Next Generation specification
  
  
• Siemens M2M Solutions
  
  
• M2M Magazine

Qusay H. Mahmoud provides Java consulting and training services. He has published dozens of articles on Java technology, and is the author of Distributed Programming with Java (Manning Publications, 1999) and Learning Wireless Java (O'Reilly, 2002).

¹ As used in this document, the term "Java virtual machine" or "JVM" means a virtual machine for the Java platform.