felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Offermans <marcel.offerm...@luminis.nl>
Subject Re: Why DependencyManager rather than DS?
Date Wed, 16 Oct 2013 20:37:13 GMT
Hello David,

Sit down first, this is a long mail. :)

On Oct 16, 2013, at 1:06 AM, David Jencks <david_jencks@yahoo.com> wrote:
> On Oct 15, 2013, at 1:33 PM, Marcel Offermans <marcel.offermans@luminis.nl> wrote:
>> On Oct 15, 2013, at 19:51 PM, David Jencks <david_jencks@yahoo.com> wrote:

>> DS still can't do dynamic dependencies, nor is it extensible to support new types
of dependencies (DM comes with dependencies to track services, configuration, bundles and
"resources". To give an example, DM can declare a component that requires service A and configuration
B. As soon as it has both, the component can evaluate configuration B and depending on its
contents add another service dependency C (or something like that).
> Do you have an example?  The "requires service A and configuration B" sounds like in
DS a 1..1 reference to A and ConfigurationPolicy.REQUIRE.

This part is the same as DS, and it would look somewhat like this in DM:

public class Activator extends DependencyActivatorBase {
	public void init(BundleContext c, DependencyManager dm) throws Exception {

	public void destroy(BundleContext c, DependencyManager dm) throws Exception {

So we end up with a component that will be instantiated lazily by creating an instance of
ComponentWithDynamicDependencies as soon as the EventAdmin service is available and a configuration
called "org.foo.pid". For that configuration we can also do very specific checks in code to
determine if it contains all the information we want. If not, DM will not consider the requirement
as "satisfied" and the component will wait until a good configuration comes along (see updated
method below).

> What adds the dependency on C?  How does this differ from including the C.target property
in the configuration?

The component does, programmatically, as soon as the two requirements above have been satisfied.
Let's continue with our example:

public class ComponentWithDynamicDependencies implements ManagedService {
	private volatile EventAdmin m_eventAdmin;
	private String m_filter;
	private boolean m_isRequired;
	public void init(Component c) {
		DependencyManager dm = c.getDependencyManager();
			.setService(Storage.class, m_filter)

	public void updated(Dictionary properties) throws ConfigurationException {
		m_filter = (String) getNotNull(properties, "filter");
		m_isRequired = (Boolean) getNotNull(properties, "required");
	private Object getNotNull(Dictionary properties, String key) throws ConfigurationException
		Object result = properties.get(key);
		if (result == null) {
			throw new ConfigurationException(key, "must be specified");
		return result;

So the "updated" method checks the incoming properties and checks if the two ones we need
are really there. Here you could (and maybe should) do more consistency checks, such as make
sure you got a valid filter, etc. but I left that out to keep the example simple).

Then, the "init" method is automatically invoked as part of the life cycle of the component,
as soon as the two dependencies are present. It takes the "Component", as previously declared
in the Activator, as an optional argument and in this case we use that to add an extra service
dependency on a "Storage" class with the filter condition that was in the configuration data.
Also, a second condition determines if the dependency is optional or required.

>> DM also has concepts like aspects and adapters, that allow you to declare factories
that automatically generate components that attach to other services. In the case of aspects
creating a whole "chain" of services, allowing you to easily intercept existing services and
add behaviour such as adding a cache to a store. In the case of adapters allowing you to add
for example management capabilities to services.. Just to name a few examples. This really
deserves a longer description, but this gives you a general idea.
> From my quick look at the docs it looked like these examples basically registered another
service exposing the same interface and with a dependency on the original service, something
that is easy to do with DS as well.  I didn't see the factory aspect described….. again,
is there a more sophisticated example?

Ok, let's take an example using the whiteboard pattern to create a component that can execute
all Task services that have been published in the framework. For the sake of simplicity I'm
going to publish that component and two Task implementations from the same bundle, but in
the real world you'd probably create different bundles for them:

public class Activator extends DependencyActivatorBase {
	public void init(BundleContext c, DependencyManager dm) throws Exception {
				.setCallbacks("add", "remove")));
			.setInterface(Task.class.getName(), null)
			.setInterface(Task.class.getName(), null)

We'll continue the activator a bit further down. The other classes used are:

public class TaskExecutor {
	public void add(Task task) {
		// store our task for later execution
	public void remove(Task task) {
		// remove our task from the internal list

public interface Task {
	public void execute();

public class TaskOne implements Task {
	public void execute() {
		System.out.println("Task One");

public class TaskTwo implements Task {
	public void execute() {
		System.out.println("Task Two");

Nothing "special" so far. Two Task services come up and are "collected" by the TaskExecutor.

Now let's add an aspect. Aspects are factories that create another service on top of the service
that they're an aspect for. In this example, let's create an aspect on top of Task services
that counts the number of invocations for that specific task. We continue our activator like

		dm.add(createAspectService(Task.class, null, 10)

So this creates two instances of a Task service that bind to each underlying Task (TaskOne
and TaskTwo). DM automatically injects the original service in the aspect, and in this case,
the aspect is created with a service ranking of 10. You can create multiple aspects and create
a whole chain if you want. The order is determined by the ranking you supply.

DM also takes care that the TaskExecutor will now see only the two aspects on top of the original
tasks (in other words, it will always only see the top of the chain).

The implementation of the aspect is something like this:

public class TaskCounter implements Task {
	private volatile Task m_task;
	private long m_counter = 0;

	public void execute() {
		System.out.println("Invoked " + m_task + " " + m_counter + " times.");

Now, let's also add an adapter. Adapters also bind to services, but don't create a "chain"
like aspects do. Assume we would like to create a servlet for each task so we can trigger
it with an HTTP GET call to that servlet. Going back to the activator we declare our adapter,
making sure it also has a service dependency on HttpService:

		dm.add(createAdapterService(Task.class, null)

What happens now is that we will end up with an instance of TaskServlet that is linked to
the Task and that also has HttpService injected. So in that implementation, we can simply
do our magic in the start() method (which is one of the life cycle methods that will be invoked
on a component, if present):

public class TaskServlet {
	private volatile HttpService m_service;
	private volatile Task m_task;
	public void start() {
		// register as a servlet here and invoke the task from its HTTP GET method

I did not actually include the code to register the servlet, but you can see where it would

There are still a few other features that I did not discuss in this mail, but aspects and
adapters have proven to be very valuable when building modular systems to allow you to really
build components that do one thing well. Just as an other example, by adding aspects to certain
services, it's easy to deploy all kinds of monitoring capabilities into an existing application,
without ever having to touch the original code. Just deploy an extra bundle with an aspect,
and you're done.

>> A third feature that might be interesting is that DM also has support for "indices"
that dramatically speed up the OSGi service registry when you're dealing with applications
that consist of lots of services (1k-10k or even more). It uses a technique similar to what
relational databases use to speed up lookups. Xander did a lot of work on this, they have
a huge application that used to take about 30 minutes to start up and now does so in more
like 30 seconds (so orders of magnitude speedup).
> I'd like to look at this, can you point me to the code?

Sure, there is a static {} initializer block in:


That sets up the indices based on a system property that needs to be set. That currently means
that, like with databases, you need to think about what indices you want to use to speed up
your application, which obviously depends on the types of services and dependencies that you
have. If you then look at the folder:


You will see the indices for which we currently have implementations. Most of those can be
configured. Some are for specific scenarios (such as when you use a lot of adapters or aspects
as mentioned above).

Mind you, it's probably not the easiest piece of code to read.

>>> I also wonder if it would be useful to add to DS a fluent api for adding components
at runtime.  I think this would be pretty easy, just construct ComponentMetadata and add it
to the appropriate BundleComponentActivator.
>> Creating the fluent API would not be too hard, but DS is not dynamic, you need to
package the XML with the bundle for it to work, so that part would be harder to fix (unless
you resort to generating bundles on the fly or something like that).
> I was thinking of creating a non-xml way to add the same kind of information as in the
xml, I think you might describe this as making DS dynamic.

So how would you do that at build time? Build the code that uses the fluent API, run it and
have it output XML that can then be put in the bundle? That could definitely work.

Greetings, Marcel

View raw message