According to the MIDP 2.0 (Mobile Information Device Profile) specification, the term Application Management Software (AMS) refers to the device software that manages the downloading and life cycle of MIDlets. An MIDP-compliant device, which is capable of browsing or locating MIDlet suites available in a network, requires AMS to facilitate any MIDlet suite installation. AMS is also used for upgrading the MIDlet suite by checking for later versions, launching it, and then removing it from the device. This article explains the AMS implementation for Palm OS-powered devices, which is delivered as a part of the IBM WebSphere Micro Environment Toolkit that currently supports downloading MIDlets from the Web using the HTTP 1.1 protocol.
Traditionally, transferring MIDlets onto Palm devices has required the JAR or JAD (Java Application Descriptor) files to be downloaded to your desktop and converted to their Palm-equivalent Palm Resource (PRC) application by being run through some tools. The PRC file then needs to be hot-synced or beamed to the device, which is indeed tedious. AMS performs all these functions and also allows you to change the set of permissions associated with the downloaded MIDlet.
AMS is bundled with the WebSphere Micro Environment Toolkit, which contains CLDC1.1/MIDP2.0, along with the J9 Java Virtual Machine (JVM). AMS installs a MIDlet HQ application on the Palm device and can be launched from the Application Launcher.
MIDlet suite discovery and installation
You have two options for installing a MIDlet suite on the Palm device. You can browse for available MIDlets on the network using a Web browser (Web Pro, for example, is available for Tungsten series and Zire 71 handhelds). You can also pass on the actual MIDlet suite JAR or JAD URL to AMS to start the installation. (However, this is a bit cumbersome because the exact case-sensitive URL must be provided.) If you choose to use Web Pro, click on the JAR URL for any available MIDlet on the Web to ensure that the MIDlet gets downloaded and the control passes to AMS to start the MIDlet installation.
Figure 1 shows a Palm-simulated depiction of a Web Pro MIDlet installation while browsing the http://midlet.org repository:
Figure 1: Browse http://midlet.org site using Web Pro

Click the necessary MIDlet JAR file to download it onto the device while AMS starts up to install it.
Figure 2: Download the required JAR file

To install this untrusted MIDlet, click Yes.
Figure 3: Untrusted dialogue from AMS during installation

A list of all AMS-installed MIDlets on the device informs you of the successful installation of the MIDlet; the latest install shows up at the bottom.
Figure 4: List of MIDlets installed on the device

AMS provides a fairly good user interface with which you can type in the MIDlet URL details and make the choice to install it. Click the MIDlet HQ icon and then click Install to invoke the MIDlet installation through AMS, as Figure 5 shows.
Figure 5: AMS MIDlet Install screen

Type in the complete URL (JAD or JAR file location) and click Install to trigger the MIDlet download and its subsequent installation.
Figure 6: MIDlet install in progress

The installation process at this point is similar to the previous one. After you agree to install this untrusted MIDlet, AMS installs it and informs you that it has been done.
AMS checks to ensure the MIDlet suite being downloaded is correct before it tries to install it. It alerts you with appropriate messages if it finds any inconsistency that would cause the installation to fail. Following are some of the factors that could cause installation failure:
- Size of the downloaded JAR file is not the same as given in the Application descriptor.
- The mandatory attributes MIDlet-Name, MIDlet-Version, and MIDlet-Vendor in the descriptor do not match those present in the manifest of the downloaded JAR file.
- Extraction of any file present in the downloaded JAR file fails.
- The MIDlet-JAR-URL attribute present in the descriptor points to a wrong location.
- Any attribute value present in the JAR file manifest gets overridden by that present in the descriptor, in the case of signed MIDlet suites.
- The MIDlet-Permissions attribute defined in the descriptor is not valid or admissible for the domain to which the downloaded MIDlet belongs.
Checking the X.509 Public Key Infrastructure (PKI) certificates that accompany the signed JAR file authenticates the MIDlet suites. Any of the protection domain root certificates present on the device validate the MIDlet suites. If the MIDlet suite being downloaded is signed, AMS verifies its signature and authenticates its certificate by using the protection domain root certificate to determine whether it belongs to a trusted domain. If not, AMS alerts you about this, but still allows you to install this MIDlet, binding it to the untrusted domain (which usually has very limited permissions).
The MIDlet installation completes with AMS extracting the contents of the JAR or JAD file and creating its equivalent PRC application database, after which the former files are discarded. The PRC database represents the downloaded MIDlet suite on the Palm device and is named with the MIDlet-Name attribute present in the application descriptor.
Attempting to install two MIDlets with the same name, but from different vendors results in AMS asking you to rename the second MIDlet before it can successfully perform the install. Palm does not allow the creation of two PRC databases with the same name, thus restricting AMS from creating the PRC for the second MIDlet with the same name. Figure 7 and Figure 8 illustrate this scenario:
Figure 7: AMS prompt for re-naming the second MIDlet

Figure 8: Provision for you to specify a different name

The second Solitaire MIDlet can only be installed after you specify a different name for it.
AMS maintains a history of previous MIDlet installs, which can be very helpful given that it lets you avoid the tedious typing of URLs. By selecting History in the Install screen, AMS displays a list of URLs visited earlier for MIDlet installs, with the most recent install URL at the top.
Figure 9: List of previous MIDlet installs through AMS

An implicit list displays all the installed MIDlets, along with their names and version numbers. To launch any MIDlet, choose the one you want from the list and click Launch from the Menu; AMS launches the MIDlet. If multiple MIDlets are contained in a suite, a list appears showing the names of those MIDlets, allowing you to choose the one you want to launch. Exiting the MIDlet takes you back to the AMS screen. If AMS encounters any problems launching the MIDlet, appropriate error messages are displayed.
You can regularly check for updates to any of the installed MIDlets by choosing one from the MIDlet list and selecting Update from the Menu. AMS refers to the URL used to install the present MIDlet, checks for newer available versions, and prompts you for an update. To check for updated MIDlets installed using Web Pro, AMS refers to the MIDlet-JAR-URL attribute. If the MIDlet being updated created any Record Management System (RMS) data during its life cycle, AMS ensures that it gets retained.
AMS provides an option that lets you modify permissions for the installed MIDlets separate from what their MIDlet-Permissions attribute specifies. To do this, select the MIDlet from the list and select Permissions. This displays a list of all permissions defined for the protection domain to which the chosen MIDlet belongs. Figure 10 shows a list of permissions defined for the untrusted domain on the device:
Figure 10: Permission list for the MIDlet chosen

Select the Permission to be modified by highlighting it in the list. This opens a Permission interaction dialogue mode with a default value for the Permission chosen. Figure 11 shows the Permission interaction for the HTTPMIDlet to use for the HTTPS connection:
Figure 11: Provision to change permissions

You can choose any of the following four modes for granting permission:
- Blanket: Permission is allowed for all invocations of the MIDlet until it gets uninstalled or you change it.
- Session: You are prompted when the MIDlet first launches. If permission is granted, it is retained until the MIDlet terminates. This process repeats for every invocation of the MIDlet.
- Oneshot: Prompts you each time to gain permission.
- Not allowed: The MIDlet is blocked and AMS throws a SecurityException if the MIDlet tries to gain entry again.
Choosing any of the modes and clicking Save ensures that AMS updates the MIDlet permissions accordingly. These permissions are considered during the next MIDlet invocation.
To delete any MIDlet from AMS, select it from the list and click Delete; this prompts you for a confirmation, after which the MIDlet, along with any RMS data, is removed from the device.
At this time, AMS recognizes only MIDlets that it has installed itself, and not those transferred onto the device by other means (that is, HotSynced or beamed). Future releases, however, promise to include those, too. In the meantime, with all its other features, AMS does prove very useful in managing the life cycle of MIDlets on the Palm or, for that matter, any device, and is aptly named MIDlet HQ. Keep in mind, too, that some of the AMS features here are to be included with WebSphere Micro Environment Version 5.7, which will soon be available for download.
Author note: Thanks goes to Michael Brung and Rajan Raman for their help and advice, and to Anjali, who was a source of inspiration for this article.
- Read the complete MIDP 2.0 specification.
- Find good information on the subject of MIDP 2.0 security architecture.
- Download free MIDlets from the repository at midlet.org.
- Learn how to build Palm OS applications with Software designer Frank Abelson's four-part series of free tutorials.
- Get the specification on the WebSphere Micro Environment.
- Read through the info on the Web Services Toolkit for Mobile Devices.