Initial Provisioning Bundle

The Initial Provisioning bundle is a provisioning agent implementing the OSGi Provisioning Service, defined in the OSGi Service Compendium Specification.

Contents:

• Bundle Information
  • Bundle JAR
  • Import
  • Export
• Basic Principles
  • OSGi-Specific Provisioning Features
    • OSGi Provisioning Properties
    • Provisioning Schemes
  • General ProSyst-Specific Provisioning Features
    • Provisioning Scenarios
    • Providing and Storing Provisioning Properties
    • ProSyst Provisioning Info Providers
    • ProSyst Provisioning Storages
    • UDP Multicast Discovery of OSGi Devices
    • Provisioning System Properties
  • mPRM-Related Provisioning Features
    • Provisioning Procedures
    • mPRM-Related Provisioning Properties
• Provisioning Setup
  • Installing URL Handlers to Enable Provisioning Schemes
  • Setting Properties in the CM Provisioning Storage
  • Setting Properties in the File Provisioning Info Provider
  • Setting Properties in the HTTP Provisioning Info Provider
  • Setting Properties in the Environment Info Provider
• Services
  • OSGi Provisioning Service
  • Provisioning Info Providers
  • Provisioning Storage
  • Managed Service
• Provisioning APIs
  • Creating Provisioning Info Providers
    • Implement the Provisioning Info Provider
    • Packing the Provisioning Info Provider Inside the Provisioning Agent
  • Creating Provisioning Storages
    • Implement the Provisioning Storage
    • Packing the Custom Provisioning Storage
• Configuration
  • Configuration Resources
  • Visual Administration
  • System Properties
• References

Bundle Information

Bundle JAR

The JAR file of the Initial Provisioning bundle is prvagent.jar located in the bundles directory.

Import

Export

The Initial Provisioning bundle exports a single package - com.prosyst.mprm.gateway.provisioning. It contains the APIs of provisioning info providers and provisioning storages.

Basic Principles

OSGi-Specific Provisioning Features

The term initial provisioning is specified by OSGi. It describes the procedure for supplying a device with all necessary components for its management through a backend system, such as mPower Remote Manager (mPRM). More specifically, these components are management agent bundles and configuration properties. Without such components, there cannot be unified communication between a backend system and a device. Hence, if an OSGi device will be managed through mPRM or any other system, it must be provisioned with the necessary components first.

The OSGi defines a special service that has the goal to enable the initial provisioning of a device - the Provisioning Service (org.osgi.service.provisioning.ProvisioningService), implemented by a provisioning agent. This service is given a set of provisioning data (also referred to as provisioning properties or provisioning Dictionary) describing the URL of its backend, communication scheme, and any other information. When it receives the URL of its backend, which is the least information necessary, the service starts the provisioning.

The ProSyst implementation of provisioning agent is capable of contacting vendor-independent backend management systems (i.e. not only ProSyst mPower Remote Manager) and performing flexible initial provisioning according to a set of configuration properties.

More information about the OSGi initial provisioning concept is available in the OSGi Service Compendium Specification.

OSGi Provisioning Properties

OSGi defines a set of vendor-independent provisioning properties that can be passed to the Provisioning Service. They are available as constants in the org.osgi.service.provisioning.ProvisioningService interface:

Note: To be able to initiate the provisioning, at least the provisioning.reference property must be available in the provisioning Dictionary!

Provisioning Schemes

To be able to use a particular scheme for the provisioning URL, a URL stream handler for the scheme must be available. The JVM itslef usually provides URL handlers for basic schemes like "http" and "file". Additionally, the set of supported provisioning schemes can be extended with custom ones by implementing URL handlers for them. For instance, providing URL handlers in an OSGi R3/R4 specific way may be achieved by implementing and registering an org.osgi.service.url.URLStreamHandlerService. For details on implementing OSGi URL Handlers see the URL Handlers Service Specification, part of OSGi Core Specification Release 4.

The Provisioning Service implementation supports three provisioning schemes, based on the protocol support in the JVM and on proprietary URL handlers:

• File - Based on the standard file access.
• HTTP - Based on the HTTP protocol support of the JVM.
• HTTPS - Based on the HTTPS protocol support of the JVM.
• RSH - Defined by OSGi. Based on a shared-secret security mechanism. To be able to use this scheme, you need the mBS Security Package.

See the "Installing URL Handlers to Enable Provisioning Schemes" section for more information about installing the provisioning schemes in the OSGi framework.

General ProSyst-Specific Provisioning Features

ProSyst introduces additional features to the ones defined by the OSGi Alliance providing extra flexibility and integration capabilities with regard to both the device platform and the backend system.

Provisioning Scenarios

The OSGi specification defines that the provisioning is initiated when the Provisioning Service is supplied with enough properties for it, but it doesn't specify the way in which the properties should be set.

The ProSyst implementation enables two ways of passing properties to the Provisioning Service:

• The backend establishes initial connection to the device and pushes a set of properties to it - The idea is that the backend can "urge" the device to initiate the provisioning. The backend can establish initial connection to the device over HTTP or HTTPS, authenticating itself with an administration user account existing on the device (only if the prm.require.auth system property is not set to false on the device, see "System Properties") and/or certificate chain (only for HTTPS initial transport). After the connection is successfully accepted, the backend pushes the initial provisioning properties for the device's further management. This enables the device to begin the execution of the initial provisioning and actual provisioning procedures.

  During the initial connection, the backend actually pushes the provisioning properties through the HTTP Provisioning Info Provider, introduced again by ProSyst.

• The essential provisioning properties are set in on the device - In this scenario the device takes the initiative for the provisioning. The device establishes connection to the provisioning URL on the backend. The connection can be over HTTP, HTTPS, RSH, File (defined in the OSGi Initial Provisioning specification and implemented by the ready-to-use ProSyst URL providers, see "Provisioning Schemes"), or any other scheme provided in some way. If a secure scheme is chosen (e.g. RSH), the device may have to be authenticated through the means used by the scheme (such as shared secret for RSH scheme). After the contact is successful, the device requests a set of provisioning properties from the backend, and continues with the rest of the phases of the provisioning.

The basic difference between the two scenarios is that in the backend-initiated case, the backend establishes connection to the device before it starts the provisioning. Note, however, that the very provisioning always begins on the device.

Providing and Storing Provisioning Properties

The OSGi specification does not define the way in which the provisioning properties should be provided and stored persistently. It is up to the implementation to provide such mechanisms. The ProSyst implementation works with two ProSyst-specific types of components: provisioning info providers and provisioning storage.

• Provisioning info providers - A provisioning info provider supplies provisioning properties to the ProSyst Provisioning Service. There may be zero, one or more provisioning info providers available in the framework. Every provider could load a different set of properties. If a property is set by more than one provider, then the ProSyst Provisioning Service uses the property value set by the provider with highest ranking (the "service.ranking" property of OSGi services with which the provider is registered). The provider ranking is the "weight" of the provider service. It determines the priority with which a given provisioning info provider can set provisioning properties. For providers installed before the Provisioning Service, the rule is this: the values of the properties provided by the provider with the higher ranking override the values of those exported by a provider with lower ranking. After the installation of the Provisioning Agent, the values available in a newly installed provider override the ones available in older ones. Thus, each new provider overrides the property values of the previously installed providers, no matter their ranking.

  The properties may be obtained in various ways, and it is up to the implementation of the provider. For example, one provider could provide the identifier of the service platform by retrieving the serial number of the hardware box, while another provider could provide the provisioning URL obtained from an issued by the operator smart card. See "ProSyst Provisioning Info Providers" for a list of ready-to-use providers.

  Provisioning info providers can be packed inside the provisioning agent bundle (see "Services"), or can be exported as services by other bundles (see "Creating a Provisioning Info Provider").

• ProSyst provisioning storages - These components take care for the persistent storing of the properties so that the properties and their values can be retrieved even after restart of the device. Only one storage at a time can be used for persistent storage of the properties. The ProSyst Provisioning Service uses the first storage it finds inside its JAR or exported as service by other bundles in the framework. First it searches for storages inside its JAR and, if it doesn't find any, searches for storage services in the framework.

ProSyst provides ready-to-use provisioning info providers and storage wrapped in the Provisioning Agent but the system integrator is free to develop and install customized implementations suitable for the specifics of the business model and hardware configuration of the service platform.

ProSyst Provisioning Info Providers

There are four ready-to-use providers wrapped in the Initial Provisioning bundle:

• CM Provisioning Storage – This storage saves provisioning properties in the OSGi Configuration Admin service. It can act as an info provider as well though not a provisioning info provider in the meaning of the ProSyst providers but it can still be used to provide provisioning properties as a configuration in the OSGi Configuration Admin. See "Setting the Properties in the CM Provisioning Storage" for information about how to set properties in this provider.
• Environment Info Provider – This provider retrieves the provisioning properties from the system properties of the JVM, specified prior to provider's startup. It also retrieves properties available in its BundleContext, such as framework vendor, framework version, etc. See "Setting Properties in the Environment Provisioning Info Provider" for details about providing provisioning properties in the form of JVM system properties.
• HTTP Provisioning Info Provider – This provider loads properties sent as parameters of POST and GET requests to its servlet, available under the /rminit alias. See "Setting the Properties in the HTTP Provisioning Info Provider" for more information about specifying provisioning properties over HTTP.

  Note: To be able to use the HTTP Provisioning Info Provider, you must have an HTTP(s) server running in the OSGi device's framework.

• File Provisioning Info Provider – This provider loads its properties in the form of a file named props.txt, available in the main directory of the bundle’s JAR file. The syntax of the props.txt file is described in the "Setting the Properties in the File Provisioning Info Provider" part of this document.

ProSyst Provisioning Storages

The Initial Provisioning bundle has only one provisioning storage - CM Provisioning Storage. It uses the OSGi Configuration Admin Service as a means for persistent storage of the provisioning properties. It registers a configuration with PID prm.provisioning.pid. All provisioning properties passed to it are stored in this configuration (see "Configuration Resources").

Apart from provisioning storage, it serves for a provisioning info provider, i.e. changing the configuration in the Configuration Admin propagates it to the Provisioning Service.

Note: The provisioning storage requires the OSGi Configuration Admin service to be available on the target OSGi device.

UDP Multicast Discovery of OSGi Devices

The ProSyst Provisioning Service supports a convenience feature allowing the backend to discover devices joined to a specified multicast host and port. The advantage of using this utility is that, first, it allows easy discovery of available devices in the network, and, second, it allows you to register multiple discovered devices simultaneously.

The adjustment of the multicast host and port is done by using a couple of system properties on the device: mbs.multicast.host for the host (default value: 225.0.0.0), and mbs.multicast.port for the port (default value: 7777).

Provisioning System Properties

The Provisioning Service accepts a set of system properties for tuning the behavior of ProSyst's ready provisioning info providers, UDP multicast discovery agent or the general specifics of the provisioning process. Refer to the "System Properties" section for more information.

mPRM-Related Provisioning Features

This section describes the provisioning functionality added to the Provisioning Service specially for registering the OSGi-enabled device in ProSyst's mPRM backend system. For more information about mPRM, refer to its product documentation.

Provisioning Reference URL

For initial provisioning with mPRM, the provisioning.reference property should have the following value:

http://<mprm_host>[:<http_port]/prvsetup

where <mprm_host> is the address of the management server (MS) responsible for the device, <http_port> is the MS port reserved for communication over HTTP.

Provisioning Procedures

The process of initial provisioning, according to the OSGi Specification, involves contacting the backend management system and downloading the appropriate Management Agent (the bundle that enables remote management) from it. The mPRM support of the provisioning, however, is separated into two procedures: initial provisioning and actual provisioning.

The first part, the initial provisioning, follows the OSGi specification. However, the initial provisioning in terms of mPower Remote Manager involves downloading an MA Loader Agent bundle (maloader.jar), which is a "fake" management agent. Its task is only to select the very best for the specifics of the OSGi device real management agent among those available on the backend.

The download of the real management agent plus the transport provider bundles is called Actual Provisioning. It is handled by the MA Loader Agent. This procedure is ProSyst-specific, it is out of the scope of the OSGi Initial Provisioning specification.

mPRM-Related Provisioning Properties

The mPRM-specific properties, are not used only during the initial provisioning process. Some of them are used during the subsequent management sessions between the device and the mPRM backend to provide information about the URL of the backend MS, communication transport, ports, etc.

The available mPRM-specific provisioning properties are:

Tip: You can decrease the network traffic by directly connecting to mPRM without getting initial provisioning data over the network. In this case, you have to set the prm.maloader.url provisioning property explicitly. As a result, the appropriate management agent, communication service and transports will be installed on the OSGi platform.

Provisioning Setup

To perform the initial provisioning of the device, the following sequence of steps must be taken:

1. Install and start the appropriate URL handler (if such is necessary) for the scheme you intend to use.
2. Make sure the appropriate Initial Provisioning bundle is running in device's OSGi framework.
3. Set the initial provisioning properties in the suitable way for the provisioning info provider(s) you intend to use.

Installing URL Handlers to Enable Provisioning Schemes

• For File scheme - You can use the URL handler available in the JVM itself.
• For HTTP scheme - You need not install any URL handler bundle as this scheme is considered to be supported by all JVMs.
• For HTTPS scheme - You need not install any URL handler bundle as this scheme is considered to be supported by most JVMs.
• For RSH scheme – Install and start the RSH URL Handler bundle whose JAR file is bundles/rshhdlr.jar. Before starting this bundle, you need to provide the following prerequisites:
  1. The ProSyst Crypt Bundle from the mBS Security Package (crypt.jar from the bundles directory) must be activated in the framework as the RSH URL Handler depends on it.
  2. The value of the provisioning.rsh.secret property must be set in the provisioning Dictionary. It should contain the shared secret between the OSGi platform and the backend system.
  3. The shared secret should be available on the backend system as well.

Setting Properties in the CM Provisioning Storage

These properties can be conveniently set in the prm.provisioning.pid configuration dictionary by using the mBS runtime console or through the mConsole. See the "Configuration Resources" and "Visual Administration" sections for details on the configurable provisioning properties through the CM storage.

Setting Properties in the File Provisioning Info Provider

By default, the File Provisioning Info Provider provides saved data to the Provisioning Service only when the provider is started for the first time (i.e. the Initial Provisioning bundle is started for the first time). The next time when the provider is started, it considers that provisioning data has been already delivered and is no longer needed, and the File Provisioning Info Provider is disabled. To have the File Provisioning Info Provider always available, set the prm.file.load.once system property to false.

Setting properties in the file provisioning info providers means modifying the props.txt file within the Initial Provisioning bundle JAR file.

The props.txt file consists of two parts:

• Text properties – These properties are available directly in the props.txt, and must have the <key>=<value> syntax. They are listed after the [TEXT] line of the txt file.
• Binary properties – These are not available in the props.txt but are to be loaded additionally from a ZIP file included in the bundle's JAR file. The format of lines is: <key>=<jar_entry_where_value_is_stored_as_byte_array>. These properties are listed after the [BINARY] line.

The lines started with “#” are comments. By default, all contents of the props.txt file are commented. To add text properties, uncomment the [TEXT] line. To add binary properties, uncomment the [BINARY] line.

For example, the content of the props.txt file can be:

# TEXT section contains properties that are to be load directly at load phase

# The format of lines is :

# <key>=<value>

[TEXT]

provisioning.spid=testdevice

provisioning.reference=http://localhost:80/prvsetup

# BINARY section contains properties that are to be load indirectly

# The format of lines is :

# <key>=<jar_entry>

[BINARY]

provisioning.rsh.secret=testbinaryprops

Setting Properties in the HTTP Provisioning Info Provider

This service loads properties sent as parameters of POST and GET requests to the /rminit servlet. This service uses a system property which must be set in advance (or left with default value): the prm.require.auth. If its value is false, no user authentication is done. If true, “user” and “pass” parameters must also be included as parameters of the request.

Example: This is an exemplary POST request that the HTTP Provisioning Info Provider can read.

POST /rminit HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 51
user=admin&pass=admin&provisioning.spid=testOSGiDevice

In some cases, a GET request will not result in setting provisioning properties. If a GET request contains the Get-Id header, no provisioning properties will be set and the response will contain the device ID in the Gw-Id header.

Setting Properties in the Environment Provisioning Info Provider

This provider maps the provisioning properties to system properties set in the JVM prior to the provider's startup (otherwise restart the Initial Provisioning bundle). The system properties should have the same keys as the provisioning ones. See the "System Properties" document for more information about setting system properties in the framework's JVM.

Note, however, that the Environment Info Provider does not immediately add the retrieved system properties to the provisioning Dictionary. It waits for the Provisioning Service to query about the value of a particular property in order to pass it. Only the properties defined as value to the prm.env.provider.push.starting.with system property (see "System Properties") are immediately passed to the provisioning dictionary.

Services

OSGi Provisioning Service

The OSGi Provisioning Service allows initial provisioning of OSGi-enabled devices for control by backend management systems. The OSGi Provisioning Service is capable of getting provisioning properties from a specific URL as well as exporting these properties to management agents and other applications. The Provisioning Service from ProSyst contains additional features, not included in the OSGi specification, for optimized service behavior and for management by ProSyst's mPRM backend system. The interface of the service is org.osgi.service.provisioning.ProvisioningService.

For more information about the Provisioning Service, refer to the "Basic Principles" section.

Provisioning Info Providers

Provisioning info providers deliver convenient ways for passing provisioning properties to the Provisioning Service. The info provider services are published under the com.prosyst.mprm.gateway.provisioning.ProvisioningInfoProvider interface.

The Initial Provisioning bundle offers several ready info provider, described in the "ProSyst Provisioning Info Providers" section. Depending on the requirements to the OSGi platform, you can implement your own info providers as described in the "Creating Provisioning Info Providers" section.

Note: By default, the File Provisioning Info Provider is available as a service in the OSGi framework only when the Initial Provisioning bundle is started for the first time. To have the provider registered on every bundle start, set the prm.file.load.once system property to false.

Provisioning Storage

A provisioning storage stores persistently provisioning properties, handled by the Provisioning Service. Only one provisioning storage is used at a time. The interface of the provisioning storage is com.prosyst.mprm.gateway.provisioning.ProvisioningStorage.

The default storage of the Initial Provisioning bundle is the CM storage, keeping provisioning information in the OSGi Configuration Admin (see "ProSyst Provisioning Storages"). You can develop your own storage depending on the requirements to the system, as described in the "Creating Provisioning Storages" section.

Managed Service

The Initial Provisioning bundle registers an org.osgi.service.cm.ManagedService for the CM Provisioning Storage. The PID of the provisioning configuration is prm.provisioning.pid. Refer to "Configuration Resources" for the full list of provisioning properties.

Provisioning APIs

The OSGi Device Provisioning API is hold in the com.prosyst.mprm.gateway.provisioning package. It allows creating two ProSyst-specific OSGi device components: provisioning info providers and provisioning storages. Their goal is to provide provisioning information to ProSyst's Provisioning Service on the device.

Creating Provisioning Info Providers

A provisioning info provider must implement the com.prosyst.mprm.gateway.provisioning.ProvisioningInfoProvider interface. Then, the info provider can be deployed as a service in the OSGi framework in two ways:

• In a bundle other than the provisioning agent (i.e. other than the Initial Provisioning bundle) - The bundle should explicitly register the provider implementation as a service in the OSGi framework by calling the registerService method of the bundle's org.osgi.framework.BundleContext.
• In the Initial Provisioning bundle JAR itself - The info provider should be available in the Prv-Providers manifest header as described in the "Packing the Provisioning Info Provider Inside the Provisioning Agent" section.

Implement the Provisioning Info Provider

The init(ProvisioningService prvServ) method of the ProvisioningInfoProvider interface is invoked by the Provisioning Service when this provider is registered. It should return a Dictionary object holding all properties defined by this provider.

If you intend to pack the info provider within the Initial Provisioning bundle, the class implementing ProvisioningInfoProvider should implement org.osgi.framework.BundleActivator as well, as the provisioning agent will call the start and stop methods inherited from BundleActivator.

Listing 1 shows the implementation of the init method, reading provisioning properties from a smart card. It provides provisioning properties only when the smart card is inserted (i.e. when the File Access Card service is registered), and reads them from the smart card. If no smart card is available, no properties are pushed.

import java.util.*;
import import java.io.ByteArrayInputStream;
 
import org.osgi.framework.*;
 
import com.prosyst.mprm.gateway.provisioning.ProvisioningInfoProvider;
 
import com.prosyst.mprm.gateway.provisioning.ProvisioningInfoProvider;
 
import opencard.opt.iso.fs.FileAccessCardService;
import opencard.opt.iso.fs.CardFilePath;
import opencard.opt.iso.fs.CardFile;
  
 . . .

  private CardFilePath configFilePath = new CardFilePath( ":3f00:0815:0817");


  /**
   * If there are read properties they are returned to the provisioning service 
   * (who is the one that invokes this method) and provisioning service adds
   * the properties into Provisioning Data dictionary.
   */
  public Dictionary init(ProvisioningService prvService) throws Exception {
    Dictionary props = cardServiceRegistered();
    print("FlashCard data:\n" + props);
    return props;
  }
  
  . . .
  
  private Dictionary cardServiceRegistered() {
    try {
      ServiceReference ref = bc.getServiceReference(FileAccessCardService.class.getName());
      if (ref != null) {
        FileAccessCardService card = (FileAccessCardService)bc.getService(ref);
        CardFile file = new CardFile(card, configFilePath);
        byte[] data = card.read(configFilePath, 0, file.getLength());
        Properties config = new Properties();
        config.load(new ByteArrayInputStream(data));      

        try {
          bc.ungetService(ref);
        } catch (Exception e) {
          print(e);
        }
        
        return config;
      }
    } catch (Exception e) {
      print(e);
    }
   
    return null;
  }

. . .

The get(Object propertyKey) method is invoked by the Provisioning Service if someone has queried about the value of a property that is not stored in the provisioning Dictionary.

Packing the Provisioning Info Provider Inside the Provisioning Agent

If you want to add new internal provisioning info providers wrapped in the Provisioning Agent, you must edit the PrvInfo-Providers header in the Provisioning Agent bundle's manifest. As a result, the provisioning agent will register the providers from the headers as services in the OSGi framework.

The PrvInfo-Providers header determines the provider ranking in case more than one provider service is available in the framework. The default priority of the provisioning info provider could be changed by editing the value of this header.

The syntax of the PrvInfo-Providers header is as follows:

PrvInfo-Providers: <info_provider_impl>;<provider_ranking>[,<info_provider_impl>;<provider_ranking>]

where:

• <info_provider_impl> is the Java class name of the ProvisioningInfoProvider implementation. The same class must also implement org.osgi.framework.BundleActivator.
• <provider_ranking> is the ranking (weight) of the provider service. The <provider_ranking> part reflects the "service.ranking" property of OSGi services with which the provider is registered. It determines the way in which the values of provisioning properties will be defined if two or more providers declare different values. For providers installed before the Provisioning Agent, the rule is this: the values of the properties provided by the provider with the higher ranking override the values of those exported by a provider with lower ranking. After the installation of the Provisioning Agent, the values available in a newly installed provider override the ones available in older ones. Thus, each new provider overrides the property values of the previously installed providers, no matter their ranking.

Creating Provisioning Storages

The goal of a provisioning storage, as its name suggests, is to store persistently the provisioning properties so that they will be available even after restart of the device. The Provisioning Service can use only one storage at a time. First, it searches for built-in storages and, if there aren't such, searches for external ones in the framework. It picks up the first one it finds and uses it until it is unregistered. So, if you want the Provisioning Service to use your custom storage, make sure all other concurrent storages are eliminated.

To create a custom storage, implement the com.prosyst.mprm.gateway.provisioning.ProvisioningStorage interface, and deploy it in one of the following ways:

• In a bundle other than the Initial Provisioning Bundle - The bundle should register the provisioning storage as a service in the OSGi framework by using the registerService method of the bundle's org.osgi.framework.BundleContext.
• Inside the Initial Provisioning bundle - The provisioning storage should be available as a value to the Prv-Storage manifest header of the bundle.

See "Packing the Custom Provisioning Storage" for more information.

Implement the Provisioning Storage

The getStoredInfo() method is invoked by the Provisioning Service to collect all stored properties. This is done the first time it starts using this storage and each time the Provisioning Service starts up.

The store(Dictionary provisioningData) method is invoked when new provisioning data is to be stored by the Provisioning Service.

If you are going to pack the storage inside the Initial Provisioning bundle, the class implementing ProvisioningStorage must also implement org.osgi.framework.BundleActivator. The provisioning agent will call the start and stop methods inherited from BundleActivator to activate and deactivate the operation of the storage.

Packing the Custom Provisioning Storage

If you want to change the provisioning storage wrapped in the Provisioning Agent, change the value of the Prv-Storage header in its manifest. The format of the header is as follows:

Prv-Storage: <storage_implementation>

Where <storage_implementation> must point to the Java class name of the desired ProvisioningStorage implementation.

If you want to provide custom storage implementation that is not packed in the Provisioning Agent bundle, you do NOT need to include the Prv-Storage header. It is enough to export a service that publishes the ProvisioningStorage interface.

Configuration

Configuration Resources

The prm.provisioning.pid configuration of the Initial Provisioning bundle provides the interface to the CM Provisioning Storage, exporting provisioning properties and storing them at the same time. In particular, you can use the configuration properties to specify the provisioning properties defined in the OSGi specification or used for communication with mPRM. The configuration properties have the same key and meaning as the provisioning ones (see "OSGi Provisioning Properties" and "mPRM-Related Provisioning Properties").

Visual Administration

The visual administration of the Initial Provisioning bundle through the mConsole consists of viewing and configuring the provisioning properties, described in the preceding section and exported by the CM Provisioning Storage.

As the properties are exported as a dictionary compliant with the OSGi Configuration Admin service, for their management mConsole shows its general property editor.

To activate initial provisioning editor:

1. Start ProSyst mBS if it is on the same machine, or if it is residing in a distant computer, make sure the mBS is on.
2. Start mConsole and log in to the mBS.
3. In the bundle tree, locate the Initial Provisioning R4 node within the osgi category and unfold it.
4. Go to bundle's Provisioning Configuration.

   The properties show on the right.

Figure 1: Visual configuration of the Initial Provisioning bundle.

Basically, the configurable properties include specifying the provisioning URL of the backend system, the management agent configuration, the X509 root certificate for the HTTPS provisioning scheme, the shared secret for the RSH provisioning scheme and the platform ID. For binary data such as the X509 root certificate, the shared secret and the management agent configuration, you can save information to a file and use the button to specify its location.

The Set button saves the changes. The Refresh button updates the displayed information in case another administrator has altered some of the communication parameters. The Defaults button loads the default property values as defined in the configuration metadata.

System Properties

The following list of system properties can be provided to the Initial Provisioning bundle for tuning the behavior of ProSyst's ready provisioning info providers, UDP multicast discovery agent or the general specifics of the provisioning process:

References

• OSGi Service Compendium Specification
• OSGi Provisioning Service API Documentation
• API Documentation for Provisioning Info Providers and Provisioning Storages
• mPRM Product Documentation

OSGi Bundles