The Use of OSGi in Aperture

Both Aduna and DFKI are in favour of using OSGi as a way to bundle these components. It seems to be a good platform for running and maintaining applications with a large set of plugin-like components.

Furthermore, the use of bundle-local classpaths may provide befeficiary. Consider for example the ​TextMining library for Word extraction which bundles a partial and unknown version of the ​POI libraries.

At Aduna we have followed a specific way of modeling services, using a factory for every implementation of a service, and a separate registry that registers all implementations of a specific service. It is the responsibility of the bundle activator of a service to register an instance of a service implementation's factory with the service registry.

This has two benefits:

• It allows for a very light-weight initialization of the system, provided that creation of a factory instance is very light-weight.

• All bundle activation code is kept outside of the factory, meaning that the code/bundle jar file is also usable in a non-OSGi application.

For Aperture, this means that the project is divided into several bundles:

• one bundle with the core engine including the registries and all interfaces

• for each ApertureDataSource implementation and crawlers that are related one bundle

• for each ApertureExtractor (or several for convenience, like "extractor pack") one bundle

Chris> I think the DataSource API, a DataSource implementation, the DataCrawler API and the DataCrawler implementation should all be separate bundles. This is the only way to ensure that you can use different crawlers for the same DataSource.

Currenly, Aduna and DFKI think that we should base our code only on pure OSGi code (i.e. org.osgi.*) and not use any other utilities such as the DependencyManager that's currently used in the Aduna code. Perhaps Herko can tell us more about what we're in for, because we both have hardly any experience with OSGi yet.

Comments by Herko:

Ideally, libraries like this should contain no OSGi-specifics whatsoever. I think of OSGi as just one of many possible runtime environments. However, it is beneficial to design the software with OSGi in mind, as the programming model of OSGi (or SOA in general) enforces a clean separation of interface and implementation and loose coupling between modules (bundles).

Having said that, I see no reason NOT to use the DependencyManager when using the library in an OSGi context. The DependencyManager provides support for a number of common scenarios when dealing with interdependent services, in addition to the syntactic dependency managment of the OSGi framework itself.