Java ME Subsystem Architecture : Application Management Software, MIDP Push

1. Application Management Software

Application Management Software (AMS) is a generic term used by the MIDP specification to describe the software component that manages the downloading and lifecycle of MIDlets and listens for inbound notification requests on connections that are registered in the Push Registry.

The AMS implementation in the Java ME subsystem is called SystemAMS.^[] SystemAMS provides the functionality described in the MIDP specification but also acts as a façade layer between Symbian OS and the Java ME subsystem as a whole. Internally, SystemAMS is decoupled into separate SystemAMS components (see Figure 1), each responsible for a specific area of functionality. Below is a non-exhaustive list of some of the SystemAMS components:

^[] SystemAMS sources are under \src\common\generic\j2me\systemams in the Symbian OS source repository.

• Core: responsible for the management and ownership of the other components, including the servers that are used by Symbian OS to access the SystemAMS; it runs in the main SystemAMS thread

• Connection: responsible for all connection functionality, including Push connections

• Installer: responsible for all installation functionality; it runs in its own thread

• Launcher: responsible for the launching of MIDlet suites

• Lifecycle: responsible for managing the lifecycle of MIDlet suites

• Security: responsible for providing security-related functionality

As we discussed previously, the AMS runs in its own separate process, independently from the MIDP run-time process. There are two scenarios in which the AMS can be launched: at Symbian OS boot time or when the user launches or installs an application (and the AMS is not already started). At Symbian OS boot time, the SystemAMS is started in order to check if there are any connections registered in the Push Registry. If a preinstalled MIDlet has registered a connection, then the SystemAMS initializes the connection and waits for an inbound notification request. If there are no registered connections, then the AMS has no reason to remain active and can exit gracefully. Later, if the user launches an installed MIDlet or starts a new installation, then the Symbian OS Recognizer or the Installer connects to the SystemAMS IPC server which starts the SystemAMS.

Figure 1. SystemAMS

In a similar way, after a running MIDlet has finished its execution, the SystemAMS checks if it is still needed to manage any resource and if not, it can exit gracefully.

By now you've probably noticed that the key areas of installation and launching involve entities from outside the Java ME subsystem. The MIDP installation process is the joint responsibility of the Symbian OS Software Installer within the Symbian OS Security Component and the SystemAMS Installer Component. SystemAMS must be involved in the installation process which implies maintaining an IPC interface to the Symbian OS Software Installer. The same applies to launching MIDlets, which also implies maintaining an IPC interface to the Symbian OS Recognizer.

2. MIDP Push

As defined by the MIDP 2.0 specification, there are two types of Push connection: static and dynamic. Static connections are specified by a MIDlet suite upon installation in the JAD file and are created at installation time. During suite installation by the Symbian OS MIDP Installer, SystemAMS attempts to open the specified Push connections. If this fails, the suite installation is rejected. Dynamic connections are set up programmatically when the MIDlet is already running.

From the point that a Push connection is registered, both types of connections are handled identically by SystemAMS. Upon reception of an incoming connection, the associated MIDlet is started if it is not already running and accessing the Java connection results in IPC calls to the SystemAMS Connection component to perform the actual operation. For each Generic Connection Framework (GCF) protocol that supports Push, SystemAMS manages a connection plug-in that is loaded and initialized at SystemAMS boot time to recreate a static or dynamically defined server connection outside the context of a running MIDlet.

As a consequence of MIDP Push, all connections that can be registered to the Push Registry always live in the SystemAMS process. That remains true even if they are not registered as a Push connection, in order to prevent duplicate functionality between the MIDP run-time process and the AMS. Additionally, in the case of listening connections that can spawn a new connection when an incoming request is received, the newly created connection cannot be transferred to any other process. The new connection lives in the same process in which it was created (the SystemAMS process). The MIDP run-time process enables MIDlets to access those connections through IPC.