Implementing the ManagedServiceFactory Interface

When a bundle needs to create objects based on varying runtime configuration data, the OSGi specification states that a Managed Service Factory should be used.

The term Managed Service Factory is a misnomer: If you were to visit a chocolate factory you would expect to see a factory that makes chocolate, not a factory made out of chocolate.
- A Managed Service Factory is not a factory that makes Managed Service objects, but rather an object factory that is also a Managed Service.
- For this reason, the name Factory Managed Service would have been a better choice, but it was not to be.
By registering a Managed Service Factory a bundle will receive its configuration data from OSGi's Configuration Admin bundle, just like any other Managed Service.
See the OSGi Configuration Admin Service Specification for more information on ManagedServiceFactory objects and the ConfigurationAdmin service.

OSGi defines the ManagedServiceFactory interface as follows:

  public interface ManagedServiceFactory {
    String getName();
    void updated(String, Dictionary) throws ConfigurationException;
    void deleted(String);
  }

A bundle would implement this interface and register the ManagedServiceFactory object with the OSGi framework. The factory will be notified by the ConfigurationAdmin bundle when a configuration is created, updated or deleted.

The getName() method simply returns a descriptive name for the factory.
- A reasonable implementation of this method would be to return the fully qualified class name of the factory.
- Returning a name that uniquely identifies the factory is desirable but not required.
- The name is used for debugging and tool support.
The updated(String, Dictionary) method is called whenever a configuration is created and updated. The first parameter is the unique persistent ID, often referred to as simply the pid, for the configuration, and the second parameter is the configuration's properties.
- It is the responsibility of the factory to manage the object it creates for each configuration, which is typically done using a Map, using the persistent ID as a key and the object created for the configuration as the value.
- If the persistent ID does not exist as a key in the Map then the configuration is clearly new, meaning that the factory must create an object using the properties, and store it in the Map.
- Sometimes the object created needs to acquire one or more services from the OSGi framework.
- Sometimes the object created will be registered as a service with the OSGi framework.
- If the persistent ID exists as a key in the Map then the configuration is clearly not new, meaning that the factory must update the associated object in the Map using the properties. This might mean simply updating the object, or it might mean creating a brand new object that replaces the existing one.
The deleted(String) method is called whenever one of the factory's configurations is deleted by ConfigurationAdmin. The parameter is the unique persistent ID for the deleted configuration.
- The factory is responsible for destroying the object associated with the persistent ID. How the object is destroyed is dependent upon the type of object. Many objects need no custom destruction.
- If the object was registered as a service with the OSGi framework, it must be unregistered.
- Once the object is destroyed the persistent ID is removed from the Map.

Creating a ManagedServiceFactory as described above is only really feasible for the simplest cases. In fact, even simple cases can be complicated to implement. Consider the following problems that must be addressed:

What if the application requires many bundles to implement a Managed Service Factory? Implementing the code to manage the objects created for each configuration is complicated, repetitive and error prone.
What if an object created by the factory needs to acquire one or more imported service?
What if the imported services for each object vary based on the configuration's properties?
What if an imported service needs to be acquired based on an LDAP filter that varies based on the configuration's properties?
How are you going to handle the case where one of the acquired imported services needs to be released because it has been unregistered or has changed it registered properties?

These problems are not new to users of OSGi. Users of SAT already have support for working appropriately with imported services, exported services and LDAP filters, but none of these benefits are available to implementers of the ManagedServiceFactory interface.

These are serious problems that cannot be easily addressed. SAT provides support for implementing a Managed Service Factory and addresses all the problems described above.
SAT's support for implementing a Managed Service Factory is more complicated than building regular bundles, but hopefully it can be seen as necessarily complicated to provide the desired behavior.