Provides Information about the Execution Environment Management capabilities of the RM.
RM is capable of validating that a vendor's runtime environment implementation supports the methods and fields, required by a bundle. This RM feature is built upon the execution environment concept, defined by the OSGi Service Platform Service Compendium Specification, Release 4.

What Is an Execution Environment

According to the OSGi Service Platform Service Compendium Specification, an execution environment (abbreviated as EE) represents a set of public classes and interfaces with their public and protected methods and fields, which a bundle needs to operate properly within an OSGi framework. An EE can contain not only Java classes but OSGi classes and interfaces, "javax" packages, etc., which must be available in the runtime environment prior to bundle deployment and execution.
The execution environments that the OSGi Alliance introduces are OSGi/Minimum-1.0 (defines minimal environment for support of the OSGi framework and implementations of basic OSGi services) and CDC-1.0/Foundation-1.0 (comprises the APIs in J2ME CDC version 1.0.). Of course, there can be arbitrary execution environments defined as long as the needs of bundles are satisfied.
A bundle can indicate its required EE through the Bundle-RequiredExecutionEnvironment manifest header which, as described in the OSGi Framework Specification, should contain a comma-separated list of required execution environments .
An OSGi device can indicate the execution environments it implements through the org.osgi.framework.executionenvironment system property, which should again contain a comma-separated list of supported execution environments.

Execution Environment Relations

RM defines a special relation between execution environments: an execution environment (EE1) is a subset of another execution environment (EE2) if:

• EE2 contains all EE1's classes and interfaces including their methods and fields.
• The access qualifiers of EE1's classes, interfaces, methods and fields are identical with those of EE2.

This "inclusion" relation can be applied to bundle requirements and device capabilities in the following way: If a bundle (i.e. some of its editions) requires EE1 and a device offers EE2, and EE2 "includes" EE1, the bundle will be successfully installed from the RM backend and resolved on this device.
RM automatically determines which stored EEs are subsets of other stored EEs (see the "Execution Environment Storage" section below for more information on how RM stores EEs). The device operator can also specify extra relations between EEs as 100% value relations of the SoftwarePlatform.EE platform property, as described in the next section, "Execution Environment Platform Property".

Execution Environment Platform Property

RM uses a platform property (refer to the "Device Platform Capabilities" document from the Conceptual Guide of the Software Repository package documentation), named SoftwarePlatform.EE, to handle the device execution environment as client bundle requirement and as device capability. A special property matcher, com.prosyst.mprm.backend.impl.ee.ExecutionEnvironmentMatcher, is assigned to the property, which executes refined matching between a bundle requirement and a device capability as described in the "Execution Environment Matching" section below.
For the SoftwarePlatform.EE property the device operator can define additional value relations and transform rules, therefore establishing compatibility links between different EEs.

How RM Determines the Required EE of a Client Bundle

RM automatically determines the EE that a client bundle requires on adding the bundle to the Software Repository and sets is as SoftwarePlatform.EE client bundle requirement. The EE client bundle requirement can include one or more comma-separated lists of required EEs. Each list is treated as a conjunction of its component environments, i.e. the device must implement all EEs from the list.
If the edition's manifest contains the Bundle-RequiredExecutionEnvironment manifest header, RM directly retrieves the value of the header and sets is as client bundle requirement.
If the manifest of the client bundle variant does not have the Bundle-RequiredExecutionEnvironment manifest header, the system inspects the classes within the variant's JAR for references to fields and methods of other classes and interfaces, not scoped by the Import-Package manifest header value. Referenced classes may belong to different EEs so as a result the generated client bundle requirement is possible to contain several EEs.
If needed, the device operator or service provider can additionally modify the SoftwarePlatform.EE client bundle requirement.

How RM Determines the EE of a Device

When a device is registered in the system, RM automatically sets its SoftwarePlatform.EE capability. The EE device capability can contain one or more EEs, implemented by the OSGi device, each defined as a separate capability value.
On registering a device, RM checks it for the org.osgi.framework.executionenvironment OSGi-defined system property, which indicates the device's EE. If this property is present, the EEs it defines are set as values of the SoftwarePlatform.EE capability. If the property is missing, RM applies the transform rules defined for the SoftwarePlatform.EE platform property. By default, RM recognizes three execution environments – OSGi/Minimum-1.0, CDC-1.0/Foundation-1.0 and JDK1.1.8.

Execution Environment Matching

When a bundle is to be installed on a device, RM calls the com.prosyst.mprm.backend.impl.ee.ExecutionEnvironmentMatcher to match the EE platform requirements of the client bundles against the EE capability of the device. If one of the EEs, defined as capability values, includes all EEs, defined as one of the requirement values, the matcher will indicate success and the edition will be installed on the device.

Execution Environment Storage

An EE can be represented as a JAR file, which contains a collection of .class files, describing the public/protected classes and interfaces and their public/protected methods and fields. RM maintains a storage of execution environments, represented as such JAR files. The EE storage is handled by a special Database Service, called EE Database.
When a new EE is added to the storage, RM automatically determines the "inclusion" relation between the new EE and each of the other stored EEs, as well as re-calculates appropriately the EE platform requirements of the client bundles in the Software Repository.

Types of Execution Environments

RM's EE storage defines two types of EEs – JVM and library. JVM EEs represent the runtime environments of miscellaneous Java virtual machines. Library EEs represent specific class libraries required in addition to the JVM ones. RM qualifies an EE as JVM if the EE JAR file contains a .class file for the java.lang.Object generic class.

Access Rights

RM restricts access to the operations that can be performed on execution environments:

• View execution environments – The right to view execution environments without changing is provided to the users, members of the Permission – Execution Environment - View group. By default, users with "process" permission for execution environments can view them.
• Process execution environments – The right to have the execution environment requirements of added client bundle processed (see "How RM Determines the Required EE of a Client Bundle ") is granted only to members of the Permission – Execution Environment – Process group. By default, users with "modify" permission for EEs own "process" permission as well.
• Modify execution environments – The right to modify EEs (add/remove/convert EEs, etc.) is provided to the users participating in the Permission - Execution Environment - Modify group. By default, users from the administration group (i.e. device operators) have the "modify" right for execution environments.

Installation and Setup

The execution environment management functionality is implemented by:

• genericosgi.ee.api.jar
• genericosgi.ee.be.api.jar
• genericosgi.ee.be.jar
• genericosgi.ee.db.jar
• genericosgi.ee.init.be.cc.jar
• genericosgi.ee.mc.jar

It is included in the package descriptor of the OSGi Device Management package, and is automatically loaded and started at host startup.
Being an optional bundle the Execution Environment Manager bundle can be easily disabled at runtime if not needed.

EE Management API

RM offers an API for management of stored execution environments, which is described in Programmer's Guide: Managing Execution Environment. Additionally, you can use the Profiles Manager API described in the "Platform Properties Management" Programmer's Guide from the Software Repository package documentation to configure the execution environment property as a platform property.