directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Göktürk Gezer <gokturk.ge...@gmail.com>
Subject Re: [ADS 2.0] OSGi
Date Thu, 06 Oct 2011 10:29:22 GMT
Hi Emmanuel,

I would like to elaborate the things about OSGI those we've talked with you
and Alex here. So that we can have some road map.

With respect to OSGI's 3 layer (modularity, lifecycle and services), we can
divide our future efforts into 3 main step. Actually the first and second
steps can be merged in one.

*Step1 (Implementing Modularity and Lifecycle)*

This step will contain mostly configuration changes on POM files.

* As you've told, conflict packages problem must be solved or at least down
to a minimum degree. For the situations those are impossible to completely
solve that issue, we may look into the "fragments" feature that is designed
for practically one bundle backing the other with extra content. However
this is not an elegant solution. We must ensure the separation as much as we
can.
* After dividing the modules's packages properly, we're gonna introduce OSGI
specific instructions into each modules POM, making them an OSGI bundle. And
at that point we must introduce ApacheDS's 3th party dependencies as bundle
imports into corresponding modules.
* Modify the existing apacheds-service module (or add a new one) for
embedding the felix, deploying the core and dependency bundles into it, and
then starting the ApacheDS on top of Felix.
* Create a Karaf feature description xml file for deploying ApacheDS into
Karaf easilly with all of its dependencies.

This first step is going to be mostly a configuration job. If we are lucky,
there won't be much code changes at that step. Considering the fact that
ApacheDS's code is designed to be embeddable, we are lucky. It already works
as megabundle on all frameworks without modification.

*Step2 (Implementing Services)*
*
*
Using services layer in ApacheDS will give you the runtime extendibility you
want. But interacting with service layer may not be the wise choice. To deal
with the wildly dynamic nature of the OSGI, we must use some component model
on top of services. Considering two mainly used component frameworks,
blueprint and IPojo, it seems IPojo is the correct choice. To list my
reasons of this choice:

* IPojo lets you describe the component model with annotations. It also
accepts xml and also gives you the API to create your own way other than
these two.
* Its highly extendable, letting you implement your custom needs without
need to change the core IPojo code.
* Field injection feature of it is the perfect way for making existing code
to use services with minimum modification.

List goes long...

Listing the things we must do for implementing service layer depends on what
we want to do with it. For example we can provide partition implementations
as services, so changing the code to see those arriving implementations in
the form of implementing bundles and start to use them immediately.

The ability to configure the arriving component's(service's) configuration
data inside ApacheDS DIT will be an ease for us, the 3th party component
writers and the users. I implemented that feature as test research. It has
some issues but not unsolvable, we just have to set the slider between speed
and code clarity.

Actual substeps needed for implementing service layer will come out clearly
after we decided what aspects needs to be extendable.


Regards,
Gokturk

Mime
View raw message