This document describes the operations for preparing an mBS image and deploying it on a specific target device.
Contents:
Basically, the steps to go through when deploying mBS-based applications on a target device platform are:
The framework deployment process introduces two kinds of systems - host and target.
The host system holds the framework installation and the applications (bundles) being developed - this is usually a personal computer with plenty of capabilities and resources.
The target system represents the device to finally launch the framework on together with a configuration of bundles, building up a specific end user solution. Embedded boards are mainly used as target systems for OSGi-based applications.
This chapter provides some considerations related to running the framework on a target system, featuring its hardware, OS and Java runtime.
The operating system, Java runtime and mBS can be saved in the target's local file system (ROM flash, RAM, HDD) or can be downloaded on target startup.
You can optimize the operating system and the Java runtime so as to produce the optimal execution environment regarding the capabilities of the target (CPU, memory, etc). Refer to the corresponding vendor documentation for more details on configuring target's OS and JVM.
You can get complete information on the minumim requirements to the target system in the release notes and datasheets available at the ProSyst Documentation Center (http://dz.prosyst.com/pdoc).
Consider the following optimization tips regarding the target's file system:
Once the system is started, the framework can place its storage on a persistent (flash, HDD) or temporary (RAM) file system. Its Standard Version also supports combined RAM/flash storage through the flash manager. See the "Choose Appropriate Storage Implementation" chapter.
This chapter provides some basic guidelines for developing custom applications in the form of OSGi-compliant bundles, based on the mBS class libraries.
|
The step that naturally comes after development is building a deployable image, which includes the framework and the bundles, building up the relevant functionality. Depending on the target system, the image can also contain the operating system and Java runtime.
Depending on the file system(s), the mBS framework offers several storage implementations:
|
Note: The Standard and Connector Versions have different approach for data files manipulation. Refer to the "Framework Versions" document for more information about the concept of mBS framework versions.
The Memory Model File System (MMFS) library provides a low-level abstraction for a hierarchical file system, on which the storage implementation can be laid. MMFS's best advantages are:
java.io package.By compromising between available resources (image size, consumed memory and CPU) and needed functionality, you can include and use specific framework modules in the image, such as a resource manager, security manager, tracer, framework controller, etc. (see "Framework Architecture" for further details on modules' features and configuration).
In this sense of words, trimming mBS framework by removing some of its modules can be done by recompiling the framework through the JMM preprocessor (bin/compile/jmm.exe). As the framework source files are not publicly accessible, the needed framework configuration can be requested from ProSyst.
Depending on the resources, available on the target system, a configuration of bundles for the target should be prepared. It is appropriate to load minimum number of bundles there. On demand, other bundles can be additionally retrieved from a backend system during initial provisioning.
Additionally, refined startup ordering can be achieved through defining bundle start levels.
The ProSyst base bundle configuration contains basic bundles used by most of the other mBS bundles, including implementations of the major services from the OSGi Service Platform Specifications Release 4. This base bundle configuration can be trimmed to achieve an optimal set of bundles considering the target system characteristics.
The base bundle configuration is included in the default boot INI files (see the "Boot INI and Boot Extension" document) and contains the following bundles:
The optimal bundle configuration contains only the bundles, most crucial for the operation of the image. The optimal bundle configuration of mBS contains the OSGi Library Bundle (bundles/osgilib.jar), ProSyst Util Bundle (bundles/putil.jar) and Console Bundle (bundles/console.jar). In situations where only the output of the target's virtual machine is interesting (e.g. on a board without a display), the Console Bundle may not be activated and the output can be redirected to a remote destination.
It is recommended that the configuration of bundles is modeled in such a way that there are no unresolved dependencies. This will ensure faultless startup and will avoid installing unnecessary bundles.
Depending on the target JVM and the archive options it provides, it is advisable that you convert the original framework JAR and bundle JARs in the appropriate format. Currently, mBS framework supports the JXE, Tao native archive and preverified JAR formats.
Tip: For increasing performance speed, you can use uncompressed JAR files.
To convert the framework and bundle JARs to the desired format, you can call the shell scripts provided in the VM-specific startup directory of mBS's installation.
On a conventional host system, when the framework starts for the first time, it installs the bundles it needs from the bundle base directory and caches them persistently in the framework storage. The next time the framework starts, it takes the cached bundle JARs directly from the storage.
As targeted embedded devices have limited resources, the cost of keeping bundle JARs locally on the device should be estimated. mBS framework allows situating image's bundle configuration on a remote system.
There are two options for remote loading on the target board - the bundle base directory (for the first time loading) and a built storage.
The bundle base directory is defined as the common directory for the original
JARs of most used bundles (for mBS's installation this is bundles).
The bundle base directory is specified with the mbs.bundles.base
system property and can be on the local file system or at a remote location (see the "System Properties" document for more information about the format of the base directory location).
The bundles that are installed at startup are determined by the framework itself, in particular by the framework's Boot module. By default, the Boot module processes a boot INI file with a list of bundle URLs to install and start during framework startup. You can modify this boot INI file to include the bundles you need. For more information on the boot INI, refer to the "Boot INI and Boot Extension" document.
Note: If the framework storage is placed locally in the RAM of the target platform, it will be lost between restarts of the board and the bundles will be loaded from the bundle base directory at every startup. If, however, the storage is placed in the persistent memory or remotely, the bundle base directory will be used only once during the first startup of the system.
Note: Another solution for safer and optimized performance is installing needed bundles "from file" by using a specific install option in the boot INI file. The JAR files of such bundles remain at their original locations and are not copied to the storage. For more information about installing bundles "from file", refer to the "Framework Architecture" document.
Another mechanism for launching bundles at framework startup is by using a ready persistent storage, situated on the device or on a remote location. This approach will save copying bundle JARs from the bundle base directory to the framework storage area. As a result, the framework will start faster, consuming less memory and CPU time at startup.
Note: If you want to have a built flat storage (the entire storage is placed within a single file, without a hierarchy of directories and sub directories), you can have it only on top of MMFS with Connector Support. On the contrary, when using another type of storage, you can have only hierarchical file structure.
Factory Storage. Additionally, if Storage on top of java.io will be used, a ready factory storage can be prepared with bundle JARs placed outside the storage directory (e.g. on ROM). In this case, bundle JARs can remain at their initial location and only data and manifest files from the ready storage need to be copied to the dynamic framework storage on the R/W file system. This will save space on the R/W file system as well as will protect to some extent the framework from accidental crashes.
Tip: As the current release of mBS does not contain a tool for automated building of a factory storage, you should create one by installing the appropriate bundles in the framework and transfer the resulting storage structure to the target bearer.
Remote Storage. The built storage can be placed on a remote system. The framework supports different storage formats depending on the chosen storage implementation. With Storage on top of MMFS with Connector Support, the built storage must be in a storage.mbs file with a specific MMFS format. With the storage on top of java.io and storage on top of java.io with Connector support, the built storage must be in ZIP format.
Storage Configuration. Storage settings can be configured with the system properties, included in the "System Properties" document.
The framework starting script for the target JVM should be appropriately edited to reflect the configuration and properties of the target system, for example in case of a restricted set of shell commands.
Framework system properties can be defined in a text file or in a Config
class, present either in the framework implementation JAR or in the classpath.
By default, default.prs is such a text file with system properties.
An mBS image can have a hierarchical or flat directory structure depending on the target file system.
The following special files and directories are included in the example images:
|
||||||||||||||||||||||||||
|
Finally, the mBS image should be packed in a ZIP file.
Tip: On a PocketPC running Windows CE you can pack the image in a CAB file, and on a Symbian device you can use a .sis installaion file.
Every target system configuration defines its own deployment mechanism. For example, an image can be transferred to the target ROM (flash) over a network file system, FTP, SSH/SCP, Microsoft HyperTerminal, etc., or can be retrieved at target startup and written to a RAM file system.
For more information about deploying images on a particular board or device, refer to its documentation.