The OSGi Complete - Pavlin Dobrev

© 2008 by ProSyst Software GmbH; made available under the EPL v1.0 | 17 March 2008
The OSGi Complete
Dr. Pavlin Dobrev
Research and Development Manager, ProSyst Labs EOOD
Eclipse Equinox Committer
p.dobrev@prosyst.com
Stoyan Boshev
Department Manager Development Tools, ProSyst Labs EOOD
Eclipse Equinox Committer
s.boshev@prosyst.com

The OSGi Complete | © 2008 by ProSyst Software GmbH; made available under the EPL v1.0
Contents
• Introduction and Services Overview
• OSGi Wire Admin Service Specification
• OSGi Declarative Services Specification
• OSGi IO Connector Service Specification
• OSGi Initial Provisioning
• Conclusions and Future Work

Introduction
• The aim of the tutorial is to present several not well
known OSGi services and to promote them to the
Eclipse community.
• Special attention will be given to the code snippets and
programming examples.
• The applications presented here are based on
Equinox.

Donated Services from ProSyst
• Implementations of:
 OSGi Wire Admin Service Specification
 OSGi Declarative Services Specification
 OSGi IO Connector Service Specification
 OSGi Initial Provisioning
• Quality of the implementations:
 Production ready code used in many projects
 All services successfully pass the corresponding OSGi test
cases.

Donation History
• EclipseCon 2007 – ProSyst declares the intention for
donation of missing OSGi Services implementations.
• July 2007 – Service code is contributed to Equinox
Incubator.
• September 2007 – All IP logs are resolved.
• February 2008 – after successfully passed
Graduation Review all components will be included in
the Ganymede Simultaneous Release started from
Milestone 6. The components can be downloaded
from Eclipse Equinox web site.
• Pavlin Dobrev and Stoyan Boshev will support them as
committers.

OSGi Service Implementations Overview 1/2
• OSGi Wire Admin Service Specification
 An administrative service that is used to control a wiring topology
 Used to wire components that produce data to components which
consume data.
• OSGi IO Connector Service Specification
 Adopts the javax.microedition.io package as a basic communication
infrastructure.
 In J2ME, the Connector framework can be extended by the vendor
of the Virtual Machine, but cannot be extended at run-time by bundle
code.
 This specification defines a service that adopts the flexible model of
the Connector framework, but allows bundles to extend it.

OSGi Service Implementations Overview 2/2
• OSGi Declarative Services Specification
 Uses a declarative model for publishing, finding and binding to OSGi
services.
 Simplifies the task of authoring OSGi services by performing the
work of registering the service and handling service dependencies.
• OSGi Initial Provisioning Specification
 Defines how the Management Agent can make its way to the Service
Platform, and gives a structured view of the problems and their
corresponding resolution methods.
 Enables the management of a Service Platform by an Operator, and
(optionally) to hand over the management of the Service Platform
later to another Operator.

OSGi Wire Admin Service Specification - Theory
• The Wire Admin service is an administrative service that
is used to control a wiring topology in the OSGi Service
Platform
• Bundles participate in this wiring process by registering
services that produce or consume data. The Wire Admin
service wires the services that produce data to services
which consume data
• The Wire Admin service is designed to cooperate
closely with the Configuration Admin service.

OSGi Wire Admin – Problems to be Solved
• When a bundle wants to use a service and there are
several implementations available, the bundle will
receive one at random.
• After a bundle has started using a service, the
framework is no longer in control of the volume or type
of data that is transferred.
• If an administrator wants to make a bundle stop using
a service, the only way is either to stop the producer or
the consumer of the service.

OSGi Wire Admin Service Specification - Solution
• Wire Admin Service is between the producer and the
consumer of the service
• The Wire Admin Service controls the connection and
the data
• Typical data-producing service can be, for example,
one that represents some physical device.
It produces information about
its current status.
• Typical data-consumers
can be detectors, gauges,
user interfaces, etc.

OSGi Wire Admin Service – Objects 1/4
• Producer - A service object that generates information
to be used by a Consumer service
• Consumer - A service object that receives information
generated by a Producer service
• Wire - An object created by the Wire Admin service
that defines an association between a Producer
service and a Consumer service. Multiple Wire objects
can exist between the same Producer and Consumer
pair
• WireAdmin - The service that provides methods to
create, update, remove, and list Wire objects.

• WireAdminListener -A service that receives events
from the Wire Admin service when the Wire object is
manipulated or used.
• WireAdminEvent - The event that is sent to a
WireAdminListener object, describing the details of
what happened.
• Configuration Properties - Properties that are
associated with a Wire object and that contain identity
and configuration information set by the administrator
of the Wire Admin service.
• PID - The Persistent Identity as defined in the
Configuration Admin specification.

• Flavors - The different data types that can be used to
exchange information between Producer and
Consumer services.
• Composite Producer/Consumer - A Producer/
Consumer service that can generate/accept different
kinds of values.
• Envelope - An interface for objects that can identify a
value that is transferred over the wire. Envelope
objects contain also a scope name that is used to
verify access permissions.
• Scope - A set of names that categorizes the kind of
values contained in Envelope objects for security and
selection purposes.

• Basic Envelope - A concrete implementation of the
Envelope interface.
• WirePermission - A Permission sub-class that is used
to verify if a Consumer service or Producer service has
permission for specific scope names.
• Composite Identity - A name that is agreed between
a composite Consumer and Producer service to
identify the kind of objects that they can exchange.

org.osgi.service.wiring package:
Source: OSGi Specification

Creating a Producer Service 1/2
• A producer service must implement and register the
org.osgi.service.wireadmin.Producer interface. Its
polled(Wire) method should return the data output
sent across the wires.
• The consumersConnected(Wire[]) method actualizes
the list of connected wires.

Creating a Producer Service 2/2
• Each producer may be registered with the following properties:
 org.osgi.framework.Constants.SERVICE_PID - the service PID of
the producer (mandatory)
 WireConstants.WIREADMIN_PRODUCER_FLAVORS - the object
classes created by the producer. It takes Class[] values.
 WireConstants.WIREADMIN_PRODUCER_FILTERS - (if the
producer will handle the filtering) the data filters.
 WireConstants.WIREADMIN_PRODUCER_COMPOSITE - (for
composite producers only) the service PIDs of the composite
consumers it will communicate with.
 WireConstants.WIREADMIN_PRODUCER_SCOPE - (for
composite producers only) the data types the producer will create.

Example Producer 1/2
• The following example creates a producer for String output. This
is indicated by the value of the
org.osgi.service.wireadmin.WireConstants.WIREADMIN_PRODU
CER_FLAVORS registration property. The service is also
registered with the producer.all PID. The only output it sends is a
single String. It will be received by consumers connected with
wires to this producer.
...
public void start (BundleContext bc) throws BundleException {
Hashtable props = new Hashtable();
//the producer will be sending String data (flavors)
Class[] flavors = new Class[] {String.class};
props.put(WireConstants.WIREADMIN_PRODUCER_FLAVORS, flavors);
//the producer PID property
props.put("service.pid", "producer.all");
reg = bc.registerService(Producer.class.getName(), this, props);
}

Example Producer 2/2
/** If there are connected wires, updates them with the produced
values */
public void consumersConnected(Wire[] wires) {
if (wires != null) {
for (int i = 0; i < wires.length; i++) {
wires[i].update(polled(wires[i]));
}
}
}
/** This method is responsible for creating the output */
public Object polled(Wire wire) {
String output = "Hello there! This is the producer speaking!";
return output;
}
}

Filtering the Data Output
• By the producer - The producer can be implemented so as to
filter the data for sending (its polled method should be
implemented so as to produce only values corresponding to the
necessary filter). In this case, it must be registered with the
WireConstants.WIREADMIN_PRODUCER_FILTERS property.
• By the connecting wire - In this case, the Wire Admin will create
the Wire with the WireConstants.WIREADMIN_FILTER property;
the producer must NOT have the
WireConstants.WIREADMIN_PRODUCER_FILTERS property
simultaneously!

Filtering the Data Output by the Producer
...
Hashtable props = new Hashtable(3);
Class[] flavors = new Class[] {Double.class};
//the producer registers for Double data output
props.put(WireConstants.SERVICE_PID, "producer.that.filters");
// set this registration property with some value
//to indicate that filtering is performed by the producer
props.put(WireConstants.WIREADMIN_PRODUCER_FILTERS, "some.value");
bc.registerService(Producer.class.getName(), this, props);
...
//the data is sent only if it is no smaller than 25
return (currentTemperature >= 25.d) ? new Double(currentTemperature) : null;
}

Value Based Filters
• WireConstants.WIREVALUE_CURRENT ("wirevalue.current") -
Indicates the current value available on the wire
• WireConstants.WIREVALUE_PREVIOUS ("wirevalue.previous")
- Indicates the previous value passed across the wire
• WireConstants.WIREVALUE_DELTA_ABSOLUTE
("wirevalue.delta.absolute") - The absolute (always positive)
difference between the last update and the current value
• WireConstants.WIREVALUE_DELTA_RELATIVE
("wirevalue.delta.relative") - The relative difference is
(current_value - previous_value ) / current.
• WireConstants.WIREVALUE_ELAPSED ("wirevalue.elapsed") -
for constructing time-based filters. It represents the elapsed time
in milliseconds between the current value and the previous value
sent by the producer.

Creating a Consumer Service
• A consumer service must implement and register the
org.osgi.service.wireadmin.Consumer interface. It may have the
following list of registration properties:
 org.osgi.framework.Constants.SERVICE_PID - the service PID of
the consumer (mandatory)
 WireConstants.WIREADMIN_CONSUMER_FLAVORS - the
consumed data object classes (flavors).
 WireConstants.WIREADMIN_CONSUMER_COMPOSITE - (only
for composite consumers) the service PIDs of the producers this
service will communicate with
 WireConstants.WIREADMIN_CONSUMER_SCOPE - (only for
composite consumers) the list of descriptive data types consumed by
the service.

Example Consumer
...
public void start(BundleContext bc) throws
BundleException {
Hashtable prop = new Hashtable();
//this property shows that the consumer will accept
any data types
prop.put(WireConstants.WIREADMIN_CONSUMER_FLAVORS,
new Class[] {Object.class});
//the identifier property of the consumer
prop.put("service.pid", "consumer.all");
//registering the service on the framework
reg = bc.registerService(Consumer.class.getName(),
this, prop);
}

Example Consumer
/** Watches the list of wires*/
public void producersConnected(Wire[] wires) {
if (wires == null) {
System.out.println("Not connected to any wires");
} else {
System.out.println("Connected to " + wires.length
+ " wires");
}
}
/** Receives the new data whenever such are available
*/
public void updated(Wire wire, Object value) {
System.out.println("Updated " + wire + " with value
" + value);
}

Creating Wire using Wireadmin
// getting a WireAdmin service reference
waRef =
bc.getServiceReference(WireAdmin.class.getName());
// getting the WireAdmin Service Implementation
wa = (WireAdmin) bc.getService(waRef);
// create wire
wire = wa.createWire("producer.all", "consumer.all", new
Hashtable());

Creating Wire
// getting a Configuration Admin service reference
saRef = bc.getServiceReference(ConfigurationAdmin.class.getName());
ca = (ConfigurationAdmin) bc.getService(saRef);
try {
// Create Factory Configuration
c=ca.createFactoryConfiguration("equinox.wireadmin.fpid",
"initial@reference:file:plugins/org.eclipse.equinox.wireadmin_0.1.0.jar/")
;
props.put("wireadmin.consumer.pid", "consumer.all");
props.put("wireadmin.producer.pid", "producer.all");
c.update(props);
} catch (IOException e) {
throw new BundleException("Configuration Admin Exception!"
+ e.getMessage());
}

Creating Composite Producers/Consumers 1/2
• Composite consumers and producers have additional
registration properties besides those for ordinary
producers and consumers. See the corresponding
descriptions for details.
• Such composite services exchange data in the form of
org.osgi.service.wireadmin.Envelope objects (flavors).
An Envelope wraps a number of data types, for
example: "front left door status", "rear left door status"
and "airbag status".

Creating Composite Producers/Consumers 2/2
• The org.osgi.service.wireadmin package provides the
following class implementing the Envelope interface:
 BasicEnvelope - this class can be used as a basic
implementation of the Envelope interface.

Example – Implementing Composite Producer
. . .
private String[] scope = new String[] {"current.date","hello","bye"};
private Class[] flavors = new Class[] {Envelope.class};
. . .
/** Registering the service with the necessary props */
java.util.Hashtable props = new java.util.Hashtable();
//the data types transmitted by this producer
props.put(WireConstants.WIREADMIN_PRODUCER_SCOPE,scope);
props.put(org.osgi.framework.Constants.SERVICE_PID,"test.producer");
//this property indicates the PIDs of the consumers that the producer will
communicate with
props.put(WireConstants.WIREADMIN_PRODUCER_COMPOSITE, new String[]
{"test.consumer"});
//for composite services, the value of this property must be Envelope
bc.registerService(Producer.class.getName(),this,props);
. . .
String date = new java.util.Date().toString();
BasicEnvelope envelope = new
BasicEnvelope(date,"test.producer","current.date");
System.out.println("Message from the producer: My current date is
"+envelope.getValue());
return envelope;
}

Creating a WireAdmin Listener
• The WireAdminListener interface allows you to receive
WireAdminEvent-s notifying of changes in the state of the wire.
The WireAdminEvent class provides the following types of events
and their correspondent class fields:
 creating a new Wire object - WIRE_CREATED
 connecting an existing Wire object - WIRE_CONNECTED
 updating an existing Wire object with new properties -
WIRE_UPDATED
 transferring a new value over the Wire object - WIRE_TRACE
 disconnecting an existing Wire object - WIRE_DISCONNECTED
 deleting an existing wire - WIRE_DELETED
 a Producer service method has thrown an exception -
PRODUCER_EXCEPTION
 a Consumer service method has thrown an exception -
CONSUMER_EXCEPTION

Creating a WireAdmin Listener - Code Example
public void start(BundleContext bc) {
//bitwise OR of the event types
Integer bitmask = new Integer(WireAdminEvent.PRODUCER_EXCEPTION |
WireAdminEvent.CONSUMER_EXCEPTION);
props.put(WireConstants.WIREADMIN_EVENTS, bitmask);
reg = bc.registerService(WireAdminListener.class.getName(), this,
props);
}
// WireAdminListener implementation
public void wireAdminEvent(WireAdminEvent e) {
switch (e.getType()) {
case WireAdminEvent.PRODUCER_EXCEPTION:
// do some work
break;
case WireAdminEvent.CONSUMER_EXCEPTION:
// do some work
break;
}
}
}

OSGi WireAdmin Summary
• Used to wire components that produce data to
components which consume data
• Data can be:
 Simple
 Composite
• Data can be filtered:
 By the producer
 By the Wire itself
• Additionally you can listen for WireAdmin Events

OSGi Declarative Services Specification
• What are Declarative Services?
 Service component model
 Represent components and their dependencies to services
 A component may provide a service and/or may consume a service
 Declarative representation in XMLs
 Service component runtime (SCR)
 Processes the components of the activated bundles
 Manages the lifecycle of the components based on changes in:
dependent services
configurations (Configuration Admin Service Specification)
bundles state

Service Component Runtime relations

Component Life Cycle 1/2
• Enabled state
 It is bound to its bundle life cycle
 Can be initially controlled by the component description
(attribute “enabled”)
 Can be controlled programatically by using the
ComponentContext methods enableComponent(String) and
disableComponent(String)
• Satisfied state
 A component is satisfied when:
 It is enabled
 All of its references are satisfied

Component Life Cycle 2/2
• Activation
 Activating a component consists of the following steps performed by
SCR:
 Load the component implementation class
 Create the component instance and component context
 Bind the target services
 Call the activate method, if present
• Deactivation
 Deactivating a component consists of the following steps performed
by SCR:
 Call the deactivate method, if present
 Unbind any bound services
 Release all references to the component instance and component
context

First steps using Declarative services
• Steps required to create a component that provides a
service:
 Create the service interface
 Create the implementation of the interface
 Write the component description XML
 Add the component description to the “Service-Component”
manifest header

Declarative Services – Step By Step 1,2/4
1. Write the service interface:
package simple.service;
public interface HelloService {
public void hello();
}
2. Write the service implementation:
package simple.service.impl;
import simple.service.HelloService;
public class HelloServiceImpl implements
HelloService {
public void hello() {
System.out.println("Hello components!");
}
}

Provide an XML with the component description 3/4
<?xml version="1.0" encoding="UTF-8"?>
<scr:component name="HelloServiceComponent"
xmlns:scr="http://www.osgi.org/xmlns/scr/v1.0.0">

<implementation class="simple.service.impl.HelloServiceImpl"/>
<service>

<provide interface="simple.service.HelloService"/>
</service>
</scr:component>

Header in Bundle Manifest 4/4
• Use Service-Component header in the manifest
to declare the XML description:
Service-Component: <path to the XML document's location>
• For example
Service-Component: OSGI-INF/Hello.xml

References to services 1/4
• Accessing services
 Lookup strategy
 Component implementations must have
activate(ComponentContext) and deactivate(ComponentContext)
methods
 use ComponentContext to locate services
 Event strategy (binder methods)
 The component defines bind and unbind methods for each
reference
 These methods can have as parameter ServiceReference or the
type specified by the reference’s interface attribute

• Reference cardinality
 “cardinality” is an optional attribute of the “reference” element
 It defines the reference’s multiplicity and optionality
 Possible cardinality values:
0..1 – Optional and unary
1..1 – Mandatory and unary (Default)
0..n – Optional and multiple
1..n – Mandatory and multiple

• Reference policy
 Static
 The default policy of a reference
 Components are reactivated on each change of its reference
 Simple but expensive
 Not suitable for references with cardinality 0..n or 1..n
 Dynamic
 More complex to handle
 SCR updates the bound service of a component without
reactivating it

• Selecting target services
 Use the “target” attribute to define a filter to constrain the
services that match the reference
 The “target” is an LDAP filter
Example:
<reference name=“AppFactory"
interface="org.osgi.service.component.ComponentFactory"
target="(component.factory=my.application)"
/>

Lookup Strategy for Getting Services 1/3
1. Write a reference element in the component's
description XML to declare the referenced service(s)
2. Get the component's ComponentContext object
passed as an argument to the component's
activate() method
3. Call the locateService or locateServices method
of the ComponentContext

<scr:component name="HelloServiceLookup"
<implementation
class="simple.service.reference.HelloServiceLookup
"/>
<reference name="helloService"
interface="simple.service.HelloService"
/>
</scr:component>

public class HelloServiceLookup {
ComponentContext cc;
protected void activate(ComponentContext ctxt){
this.cc = ctxt;
}
public void useService() {
HelloService helloService =
(HelloService) cc.locateService("helloService");
helloService.hello();
}
protected void deactivate(ComponentContext ctxt){
this.cc = null;
}
}

Event Strategy for Getting Services 1/3
1. Write binding and unbinding methods
2. Declare them in the reference element of the
component description
3. SCR passes the referenced service as an argument
of the bind and unbind methods

...
public class HelloServiceBind {
HelloService helloService;
public void setHelloService(HelloService helloService){
this.helloService = helloService;
}
public void unsetHelloService(HelloService helloService){
this.helloService = null;
}
protected void activate(ComponentContext ctxt){
//note that lookupService() is not called
helloService.hello();
}
...

<scr:component name="HelloServiceBind"
<implementation
class="simple.service.reference.HelloServiceBind"/>
<reference name="helloService"
interface="simple.service.HelloService"
bind="setHelloService"
unbind="unsetHelloService"
/>
</scr:component>

Delayed / Immediate Components
•Delayed components are lazily instantiated
•A component is delayed in case:
It provides a service
It does not have the attribute immediate=“true” in
its XML description
•Immediate components are instantiated as
soon as they become satisfied

Factory Components
• Factory component creates component configurations on
demand
• Factory component is specified by using the “factory”
attribute in the component’s element
• org.osgi.service.component.ComponentFactory service is
registered for each factory component
• ComponentFactory.newInstance(Dictionary) can be used
for creating new component instances

Component Properties
• Component properties are put as service properties when
SCR registers a component service
• They can be used in the “target” attribute of a reference
for constraining the set of services that match
• SCR always adds the property “component.name”
• Properties can be set/overriden by:
 The argument of ComponentFactory.newInstance(Dictionary)
 Configuration object (retrieved by Configuration Admin)
 The component description

Component Factory Example
<scr:component name="HelloServiceComponentFactory"
factory="hello.component.factory"

<implementation
class="simple.service.impl.HelloServiceImpl"/>
<service>

<provide interface="simple.service.HelloService"/>
</service>
<property name="SomeProperty" value="initial value"/>
<property name="instanceID" type="Integer" value="0"/>
</scr:component>

Advantages of Declarative Services
• Solves crucial problems of large systems like
 Startup time
 Memory footprint
• Deals with the complexity of handling the dynamism of
services
 Code simplification
 Error preventive
• Can support components which are not OSGi aware

Available tools for DS
• There are no available tools for DS at this moment
• DS support will become part of PDE (not in Eclipse 3.4)
• ProSyst will provide DS Editor plugin for Eclipse 3.4

OSGi IO Connector Service Specification
• OSGi IO Connector Service specification adopts the Java 2
Micro Edition (J2ME) javax.microedition.io packages as a basic
communications infrastructure. In J2ME, this API is also called
the Connector framework.
• ConnectorService – The service that performs the same
function - creating connections from different providers - as the
static methods in the Connector framework of
javax.microediton.io.
• ConnectionFactory – A service that extends the Connector
service with more schemes.
• Scheme – A protocol or device that is supported in the Connector
framework.

OSGi IO Connector Service Specification - URI
• Examples:
 sms://+46705950899;expiry=24h;reply=yes;type=9
 datagram://:53
 socket: //www.acme.com:5302
 comm://COM1;baudrate=9600;databits=9
 file:c:/autoexec.bat
• The same interfaces can be used for communication
via TCP/IP, UDP, SMS, USB/COMM, Bluetooth

How IO Connector Works

How the IO Connector Service Creates Connections

Connection Types (javax.microedition.io package)

OSGi IO Connector Service – Example
• Server
server = (StreamConnectionNotifier)connService.open(
"socket://:3333", ConnectorService.READ);
connection = server.acceptAndOpen();
DataInputStream inputStream = connection.openDataInputStream();
• Client
connection = (StreamConnection)connService.open(
"socket://localhost:3333");
DataOutputStream outputStream =
connection.openDataOutputStream();
//the simple String data sent to the server
outputStream.writeUTF("Hello there from the client!");
• Socket Factory Implementation

OSGi IO Connector Service – Summary
• In J2ME, the Connector framework can be extended
by the vendor of the Virtual Machine, but cannot be
extended at run-time by bundle code. The defined IO
Connector service goes behind this restriction and
allows bundles to add new connection factories
dynamically.
• The same interfaces can be used for communication
via TCP/IP, UDP, SMS, USB/COMM, Bluetooth

OSGi Initial Provisioning - terminology
• Management Agent – A set of one or more bundles
that run on the OSGi framework and communicate
with the Remote Management System to provide
management of the Service Platform
• Initial Provisioning - The process in which an OSGi
Framework is provisioned with a Management Agent

OSGi Initial Provisioning - entities
• Provisioning Service - A service registered with the
OSGi Framework that supports supplying of the initial
configuration needed to trigger the initial provisioning
process and provides information about the initial
provisioning to the Management Agent
• Provisioning Dictionary - A Dictionary object holding
the initial provisioning configuration. This dictionary is
filled through the Provisioning Service methods and
with information from a ZIP files that are loaded during
initial setup

org.osgi.service.provisioning package:

Initial Provisioning Sequence (ProSyst mPRM)
mPRM OSGi Device
Initial
Provisioning
Service
Initial
Provisioning
Server
OSGi DM Adapter
Set Provisioning URL
Get Provisioning Data by URL
Install mPRM MA Loader
Platform info about device
Initiate Management Session
Install Optional Agent bundles
Read
Config
Optional Management Agents
Install
MA Loader
Bundle
InstallList of bundles &
config. settings
Core Management
Agent
Core Management
Agent
Install
Set config

Initial Provisioning Procedure 1/2
1. The Initial Provisioning Service is supplied with an
initial request URL
2. The Initial Provisioning Service sends request to the
Management System using the initial request URL
3. Management System returns a ZIP file containing
entries that are placed in the Provisioning Dictionary
object and stored persistently.

Initial Provisioning Procedure 2/2
4. The Provisioning Service installs (but does not start)
all entries in the ZIP file that are typed as a bundle or
bundle-url.
5. If the ZIP file contains
PROVISIONING_START_BUNDLE entry the
Provisioning Service starts the previously installed
bundle under the location which is the value of that
entry.
6. If the ZIP file contains
PROVISIONING_REFERENCE entry then the entire
procedure is repeated using the value of this entry
as a new initial request URL.

What is covered by the OSGi Specification
• The Initial Provisioning Assignment algorithm
• The format of the ZIP file and the allowed types of the entries -
String, byte[], bundle and bundle-url
• A set of predefined entry names with special meaning -
PROVISIONING_REFERENCE, PROVISIONING_SPID,
PROVISIONING_START_BUNDLE,
PROVISIONING_ROOTX509
• The API of the Provisioning Service for reading and modifying the
properties of the Provisioning Dictionary by the Management
Agent.
• Optional protocol mappings over HTTP, HTTPS and RSH

What is not standardized by the OSGi
• The way for providing the Provisioning Service with the initial
request URL. Possible variants are: staged by the manufacturer,
input by the user or obtained from a SIM-card.
• The protocol used in the Provisioning Assignment. The protocol is
specified by the schema of the initial URL and can be any public
or proprietary protocol as far as it is supported by the Framework.
Examples - http(s)://, file://, smart-card://
• The number and names of properties which could be assigned to
the Provisioning Dictionary. Thus different Management Agents
may be configured with a different set of properties.

OSGi Initial Provisioning - avdantages
• Policy Free - The Initial Provisioning Service provides
business model agnostic solution for Remote
Management. None of the affected parties (Operators,
SPS Manufacturers, etc.) is forced into any particular
business model.
• Interoperability - The Initial Provisioning permit
arbitrary interoperability between management
systems and OSGi enabled devices.
• Flexible - The initial provisioning model is open as
possible, while still achieving interoperability.

Conclusion, Resources and Future Work
• Eclipse Equinox Web Site
http://www.eclise.org/equinox
• ProSyst Developer’s Zone
http://dz.prosyst.com
• Pavlin Dobrev and Stoyan Boshev will support the
donated services as committers

Contacts
Thank you! For further information please contact us!
ProSyst Software GmbH
Dürener Straße 405
D-50858 Cologne, Germany
Tel. +49 221 6604-0
Fax +49 221 6604-660
info@prosyst.com
www.prosyst.com

Thank you!

Legal Notices
• mPRM is trademark or registered trademark of
ProSyst Software GmbH in Germany and other
countries
• Java and all Java-based trademarks are trademarks of
Sun Microsystems, Inc. in the United States, other
countries, or both
• Other company, product, or service names may be
trademarks or service marks of others

The OSGi Complete - Pavlin Dobrev

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à The OSGi Complete - Pavlin Dobrev

Similaire à The OSGi Complete - Pavlin Dobrev (20)

Plus de mfrancis

Plus de mfrancis (20)

Dernier

Dernier (20)

The OSGi Complete - Pavlin Dobrev

Notes de l'éditeur