Enterprise J2ME Developing Mobile Java Applications [Electronic resources] نسخه متنی

4.1 Container-Managed Applications

In the field of software engineering, the term container refers to specialized software that runs other software. For example,

The MIDP Application Management Software (AMS) is a container that installs, starts, pauses, stops, updates, and deletes MIDlet applications. In the CDC Personal Basis Profile, the Xlet programming model also features container-managed life-cycle methods.

A Java servlet engine is a container that invokes servlets and provides access to the HTTP context.

The Java Virtual Machine (JVM) itself is a container. It monitors Java applications for proper memory usage (garbage collector) and security.

In the next two sections, we will discuss the features and benefits of mobile containers.

4.1.1 Container Features

As mobile enterprise applications become mainstream, the complexity of smart clients grows. For example, fully commercial applications often require features such as user login, logging, transaction, and transparent data access. Without proper tools for code and service reuse, mobile developers have to duplicate those functionalities for every smart client. Wasting time reinventing the wheel is not only inefficient but also causes error-prone code.

Hence, it makes sense to make those common features available as services in software containers that run on mobile devices. An advanced container usually provides the following functionalities.

Self-contained applications: Applications run inside the container are self-contained with portable code and necessary configuration files. The interdependence of applications and library components could be managed by the container. Examples are the WAR files for servlet containers and EAR files for EJB containers.

Life-cycle management: By calling the life-cycle methods defined in the container framework and implemented by all applications, the container can install, start, stop, update, and delete any application programmatically or through an interactive console.

Application services: The container provides services that are common to all applications. For example, an authentication module in the container could allow all applications to authenticate against a single password database.

Custom services: The container should also allow its applications to offer services to each other. That encourages code reuse and prompts architectures for layered and modularized applications.

In this book, we use the term container rather loosely. Our containers do not impose arbitrary boundaries for API usages. Applications installed inside the container can transparently access any Java or native API available on the device. These containers are often known as frameworks. The container architecture on J2ME mobile devices is illustrated in Figure 4.1.

4.1.2 Benefits of Containers

The above container features translate to real benefits in mobile development projects:

Reduced code redundancy: Since the common services are not repeatedly implemented, we can reduce overall footprint and potential number of errors while improving the developer productivity.

Managed update: When we fix a bug or add a new feature in a service, all applications that use it automatically get the update. Some containers support service versioning for more refined controls.

Support for multitiered application models: Services in a container offer natural separations between application tiers (e.g., the presentation and business layers).

Simplified application provisioning: Self-contained applications can be easily deployed to any container. That enhances Java's value proposition of "write once, run anywhere."

Given these benefits, containers or frameworks are widely used in mobile Java application development. In the next section, we introduce a standard container specification for lightweight mobile devices: the OSGi specification.

Note

Every MIDP device comes with the AMS container for provisioning, security, and life-cycle management. However, the MIDP platform is too resource-constrained to run any more advanced containers. As a result, the containers we discuss in this chapter require at least J2ME/CDC or PersonalJava runtimes.