Apache

OSGi Design Patterns

This section lists a couple of design patterns as they can be applied in an OSGi context.

(Singleton) Service

Provides a service as long as its dependencies are resolved.

Motivation

In a dynamic framework, services can come and go. Components that publish a service are often themselves dependent on other services to perform their task. In such cases, they have a dependency on those services and it makes sense to only publish their own services when these dependencies are available. Being able to declare such dependencies in code ensures consistent life cycle behavior.

Structure

Full Size | Edit Diagram | Remove Diagram
A Gliffy Diagram named: singleton

Code Example

public class Activator extends DependencyActivatorBase {
    public void init(BundleContext context, DependencyManager manager) throws Exception {
        manager.add(createComponent()
            .setInterface(UserStore.class, new Properties() {{ put("store.id", "users"); }})
            .setImplementation(UserStoreImpl.class)
            .add(createServiceDependency()
                .setService(Store.class)
                .setRequired(true)
            )
            .add(createServiceDependency()
                .setService(LogService.class)
                .setRequired(false)
            )
        );
    }
    
    public void destroy(BundleContext context, DependencyManager manager) throws Exception {}
}

Aspect Service

Provides an aspect on top of a specific type of service.

Motivation

In aspect oriented programming, supporting functions are isolated from the main application's business logic. This increases modularity at the source level by allowing the separation of cross-cutting concerns. In OSGi we want to extend this modularity to the runtime, therefore we implement aspects to work on certain services, where the aspect itself publishes that same service but (usually) with a higher priority. This allows you to dynamically add and remove aspects.

Structure

Full Size | Edit Diagram | Remove Diagram
A Gliffy Diagram named: aspect

Code Example

public class Activator extends DependencyActivatorBase {
    public void init(BundleContext context, DependencyManager manager) throws Exception {
        manager.add(createAspectService(Manageable.class, "(monitor=true)", 50)
            .setImplementation(ManageableMonitor.class)
        );
    }
    
    public void destroy(BundleContext context, DependencyManager manager) throws Exception {}
}

public interface Manageable {
    public void setProperty(String key, String value);
}

public class ManageableMonitor implements Manageable {
    private volatile Manageable m_manageable;

    public void setProperty(String key, String value) {
        System.out.println("Someone set " + key + " to " + value);
        m_manageable.setProperty(key, value);
    }
}

Adapter Service

Provides an adapter for a specific type of service.

Motivation

Like with aspects, sometimes you want to create adapters for certain services, which add certain behavior that results in the publication of (in this case) a different service. Adapters can dynamically be added and removed and allow you to keep your basic services implementations clean and simple, adding extra features on top of them in a modular way.

Structure

Full Size | Edit Diagram | Remove Diagram
A Gliffy Diagram named: adapter

Code Example

public class Activator extends DependencyActivatorBase {
    public void init(BundleContext context, DependencyManager manager) throws Exception {
        manager.add(createAdapterService(Manageable.class, "(publish=servlet)")
            .setInterface(HttpServlet.class.getName(), null)
            .setImplementation(ManageableServlet.class)
        );
    }
    
    public void destroy(BundleContext context, DependencyManager manager) throws Exception {}
}

public interface Manageable {
    public void setProperty(String key, String value);
}

public class ManageableServlet implements HttpServlet {
    private volatile Manageable m_manageable;

    public void doPost(HttpRequest req, HttpResponse response) {
        String key = req.getProperty("key");
        String value = req.getProperty("value");
        m_manageable.setProperty(key, value);
    }
}

Resource Adapter Service

Provides an adapter for a specific type of resource.

Motivation

Resource adapters are similar to normal adapters, but instead of requiring a service, they require a resource and provide a service on top of it. Resources are an abstraction that is introduced by the dependency manager, represented as a URL. They can be implemented to serve resources embedded in bundles, somewhere on a file system or in a content repository or database.

Structure

Full Size | Edit Diagram | Remove Diagram
A Gliffy Diagram named: resource-adapter

Temporal Dependency

Provides a proxy that hides the service dynamics of a dependency, even if it disappears for a short time.

Motivation

As a service consumer, you sometimes do not want to deal with the dynamics of services and the fact that they tend to go away for short periods of time whilst their hosting bundle gets updated. A temporal dependency provides you with a proxy that hides these dynamics and blocks your calls if you try to invoke a method on a service that is currently "updating". The maximum time to wait is configurable and you will get an exception if no new service becomes available before that time.

Structure

Null Object

Provides an implementation of an object that does nothing and can be used in the absence of the real object.

Motivation

When a component depends on a service, but the dependency is optional, it means that it will use this service when available, but it can still operate if it's not. Constantly checking in your code if a service is actually available tends to lead to code with a lot of "if (service != null) service.invoke();" constructions which do not help with code readability. Instead, the dependency manager offers you a mechanism where it will inject null objects for services that are currently not available so you can simply invoke methods on them that "do nothing".

Structure

Whiteboard

Handles listeners by leveraging the OSGi service registry to publish and look them up.

Motivation

The traditional model for dealing with listeners in Java needlessly complicates things in an OSGi context. Instead of having listeners registering themselves with the component that will invoke them on any change, a listener simply registers itself in the service registry and the component will do a lookup of all relevant services. This is explained in more detail on the OSGi.org wiki in the "Listeners considered harmful: the 'whiteboard' pattern" article.

Structure

Last modified by marrs on Wed Jun 08 15:49:27 EDT 2011
Apache Felix, Felix, Apache, the Apache feather logo, and the Apache Felix project logo are trademarks of The Apache Software Foundation. All other marks mentioned may be trademarks or registered trademarks of their respective owners.