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 Tue, 15 Oct 2013 20:33:01 GMT
Hello David,

On Oct 15, 2013, at 19:51 PM, David Jencks <david_jencks@yahoo.com> wrote:

> After seeing a lot of commit activity on DependencyManager I decided to try to understand
what it's for, and after looking at the documentation I'm still not sure.  It looks to me
like the main feature is a fluent api that provides something like DS, although less declaratively,
and then there are some special cases that might be slightly simpler than just declaring a
service that does the same thing (aspects, temporal)

DependencyManager has its roots long time ago, when there was no Declarative Services specification
yet. It started when I was working on my first big OSGi project (about 10 years ago) and we
needed a library to help us declare and manage dependencies.

The only library at that time was "servicebinder", which was somewhat similar to what became
DS. We evaluated that library for our project, but it did not fulfill all our use cases.

Most importantly, we had use cases that required us to declare dependencies at runtime, for
example based on configuration data or some hardware aspects we discovered at runtime. Furthermore,
I did not like the XML configuration, which did not automatically update when refactoring
your code and did not have code completion or syntax checking.

That last bit has been improved now that DS supports annotations to generate XML.

> So as a DS partisan :-) I'm wondering what the big advantages of DependencyManager are.

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).

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.

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 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).

The other way round would be easier: creating an extender bundle that reads the XML descriptors
that DS uses and using DM to create the appropriate components.

For the record, DM currently also has an annotation based API, contributed a while ago by
Pierre and Arjun.

Greetings, Marcel


Mime
View raw message