Profile Sets (Informal)
This chapter gives an overview about possible combinations of optional
components when implementing MEEP-1.0. The necessity to take dependencies
into account makes it non-trivial to find the best combination for the
own purpose.
Of course the combinations shown here are jsut samples and not part of the
normative specification. The number of possible combinations is much higher
and by far not limited to the combinations below. But those combinations
are good examples for popular use cases, and many implementors may find
here what they have in mind.
Java ME Embedded Profile 8 "Minimal Profile Set"
Use case: Single-Function Device
This profile set supports a single application model and is defined to cover
use cases of small edge-node devices with a limited and focused set of
functionality and where footprint must be minimized.
Example: Smart sensors.
These devices are typically connected directly to peripheral I/O and/or have
limited networking capabilities, limited remote management capabilities, and
are focused on the specific use case requirements.
The intent of this profile set is to describe the smallest possible memory
footprint for very resource-constrained or low-cost embedded devices. Embedded
systems based on this profile set are good targets for stripping on deployment.
Typical hardware parameters are:
- Single-function device category
- Integrated peripheral I/O, such as serial, GPIO, SPI, I2C, DAC/ADC
- Limited connectivity (may be local or intermittent) or no connectivity
These devices run a single application dedicated to a specific function. The
application can be pre-installed or installed in a limited use-case-specific
manner. The function may change over time, but is principally limited in
scope and flexibility.
The following requirements apply to the single-function device application
model:
- It is assumed the device is controlled by a trusted entity
- There is only one application installed and running on the device at any
time
- The application uses the MIDlet or no provisioning model
- The application 'owns' the device (controls the operation of the device,
is assigned maximum permissions, need not share any resources)
- The application is automatically started by the runtime when the runtime
starts and executes until the runtime is terminated
The above requirements allows simplifying assumptions to be made. These are
- The application provisioning (if any) and management can be reduced to a
minimum needed to support the requirements
- No application-level SWM API (
javax.microedition.swm
) is
required
- Removal of features and optional packages designed to support a
multi-application application model (MVM, concurrency, inter-application
events, IMC, shared libraries, etc)
Simplified application installation:
Since only one application can be present on the device and the device is
controlled by a single trusted entity, application installation can be
simplified. One of two ways is possible:
- The application may be pre-installed (bundled with the runtime), in which
case no post-deployment installation or update mechanism is necessary.
This model is a prerequisite for stripping on deployment.
- The application is installed separately from the runtime through some
limited and implementations-specific installation method and channel
(e.g. serial port, LAN, WAN, etc)
The MEEP-1.0 "Minimal Profile Set" includes the following
APIs/functionality:
- MEEP-1.0 application lifecycle based on the underlying CLDC-8 implementation
with single application execution (SVM)
- MEEP-1.0
javax.microedition.midlet
- No, or a small number of, MEEP-1.0 optional packages depending on the use
case.
A typical use case solution would include:
- MEEP-1.0 Minimal Profile Set
- Peripheral I/O API
- Few, if any, optional JSRs
- A single application of low to moderate complexity
Java ME Embedded Profile 8 "IMP-NG Profile Set"
Use case: Device with IMP-NG compliant implementation
The intent of this profile set is to describe a runtime which is IMP-NG
compliant and which allows execution of IMP-NG-based applications without
modifications.
Typical hardware parameters are:
- Full multi-function device category
- Set of peripheral I/O, such as serial, GPIO, SPI, I2C, DAC/ADC
- Networking and connectivity as required by IMP-NG
The MEEP-1.0 "IMP-NG Profile Set" includes the following APIs/
functionality:
- MEEP-1.0 application lifecycle based on the underlying CLDC-8 implementation
(the execution capabilites - SVM or MVM - are irrelevant with respect to
IMP-NG)
- MEEP-1.0
javax.microedition.midlet
- All MEEP-1.0 capabilities and optional packages required for IMP-NG
compliance (including deprecated functionality as necessary for
compatibility), with or without audio media support (being optional to
IMP-NG) depending on the use case
A typical use case solution would include:
- MEEP-1.0 IMP-NG Profile Set
- Zero or more optional JSRs
- One or more (possibly concurrent) applications of moderate to high
complexity
Java ME Embedded Profile 8 "Standard Profile Set"
Use case: Multi-Function Device
The multi-function model covers use cases where devices are more powerful,
address more general use cases, and there can be one or more applications
installed and running at any time.
These devices typically are capable of running multiple applications,
implement a wider and more flexible set of functionality, are connected to a
variety of peripheral I/O, have full networking capabilities, and can be
managed remotely (e.g. application provisioning and lifecycle control).
The intent of this profile set is to describe the base of a runtime which is
applicable to a wide range of use cases.
Typical hardware parameters are:
- Standard multi-function device category
- Rich set of peripheral I/O, full networking
The MEEP-1.0 "Standard Profile Set" includes the following APIs/
functionality:
- MEEP-1.0 application lifecycle based on the underlying CLDC-8
implementation with multi-application execution (MVM)
- MEEP-1.0 javax.microedition.midlet
- Appropriate MEEP-1.0 capabilities (such as multi-application support,
application management, shared libraries, security model, communication,
events, etc) as required by the chosen optional packages and dependencies.
A typical use case solution would include:
- MEEP-1.0 Standard Profile Set
- Likely several MEEP-1.0 optional packages, as required by the use
case
- Peripheral I/O API
- Zero or more optional JSRs
- Multiple (likely concurrent) applications, modules, services, or shared
libraries of varying complexity providing a combined set of
functionality
- Note: It is also possible that the implementation contains support for
a bitmap-oriented display and user interface, both of which are outside
the scope of MEEP-1.0
Java ME Embedded Profile 8 "Full Profile Set"
Use case: Complete MEEP-1.0 functionality for Multi-Function Device
The intent of the MEEP-1.0 Full Profile Set is to describe a runtime which
includes all MEEP-1.0 APIs/functionality, including all optional functionality
(as long as the packages are not mutually exclusive). Such a Profile Set is
useful for defining the maximum functionality that can be implemented
by a MEEP-1.0 implementation, for example for reference purposes or to
describe a full MEEP-1.0 development platform.
Typical hardware parameters are:
- Full multi-function device category
- Rich set of peripheral I/O, full networking
The MEEP-1.0 "Full Profile Set" includes the following APIs/
functionality:
- MEEP-1.0 application lifecycle based on the underlying CLDC-8
implementation with multi-application execution (MVM)
- MEEP-1.0
javax.microedition.midlet
- All ME-EP optional packages and MEEP-1.0 capabilities (such as
multi-application support, application management, shared libraries,
security model, communication, events, etc)
- Note: It is also possible that the implementation contains support for a
bitmap-oriented display and user interface, both of which are outside
the scope of ME-EP 8