Introducing Arkadiko, a bridge between Spring and OSGi

Spring's dependency injection framework is the picture of ubiquity in the java world. As such it aims to drive developers toward declarative, component driven design and lose coupling. But, it is largely a static container. The class space is flat and once started there is little means for dynamic change.

OSGi is "the" modularity framework for java. It supports dynamic change via strict classloader isolation and packaging metadata. It also aims to drive developers toward modular design. But although it is very powerfull it is also complex and learning it's intricacies can be daunting.

These two paradigms have recently undergone a merge or sorts in such that within OSGi frameworks one can use the declarative nature of Spring (via Spring DM and more recently standardised as Blueprint) to configure and wire together the interdependencies of components as they come and go from the OSGi framework.

So how does this project, Arkadiko come into play?

First allow me to explain briefly the current state of the world as I understand it (this is my personal assessment).

Given the vast number of Spring based projects and the most recent up-surge in the desire to benefit from OSGi's dynamic modularity it has become clear that there is a understandable difficulty in moving projects of any complexity to OSGi from a pure Spring architecture. The issue is that there are some design changes that must be made in moving traditional java applications, including Spring based ones, to OSGi. OSGi has a puritanical solution to a vast number of problems caused by the traditional architectures, but in order to gain from those solutions a considerable amount of redesign has to be done.

What to do?

There are several well known projects and individuals promoting methodologies and best practices to help undertake the considerable amount of work that such a migration could potentially involve.

A recent presentation by BJ Hargrave (IBM) and Peter Kriens (aQute) ( http://www.slideshare.net/bjhargrave/servicesfirst-migration-to-osgi) defines the concept of "services first" migration methodology. This methodology suggests that the first steps in the migration is to re-design the existing architecture such that it's based on a services oriented design. They offer some insight into how that is accomplished paraphrased over several different articles about μservices (micro-services) and I won't go into detail here about all that. Suffice it to say that once this has been accomplished it becomes far simpler to

isolate portions/groupings of code that form logical components into modules which use or publish services in well defined manner to subsequently be turned into OSGi bundles.

Also, a core developer of the Apache Felix project, Karl Pauls, has recently released a library called PojoSR ( http://code.google.com/p/pojosr/) based on some of the Apache Felix project code that itself does not implement a full OSGi framework container, but essentially provides an active registry which scans the class space for recognizable "services" and effectively tries to wire those together or a the very least provide a central access point for those services.

I have no in-depth knowledge on either of those two topics but I highly suggest taking some time to review both because they present options for anyone entertaining the notion for undertaking such a migration to OSGi, and several

options are always welcome.

Finally we come to Arkadiko!

Arkadiko is a small bridge between Spring and OSGi.

Arkadiko is an attempt to provide an new migration option, and borrows ideas from both of the above and tries to marry into those the concept of "quick wins" (such as immediate access to OSGi features) and "time to evolve".

Quick Wins: Often the light at the end of the tunnel seems awfully far away. When reviewing the scope of the migration, it may seem like an eternity before the benefits will pay off. So, Arkadiko gives you OSGi right now! How does it do

that? It simply provides a means to wire an OSGi framework into your current spring container. But that in itself doesn't help and so it also dynamically registers all your beans as services and at the same time registers a OSGi ServiceTracker for each one. It does this so that if matching services are published into the OSGi framework they are automatically wired in place of those original beans. You get OSGi right away! It also means that the OSGi framework has access to all your beans and can use those as regular services.

Time to Evolve: The other benefit is that you now have time to evolve your platform into OSGi as you see fit, and as time allows, moving components slowly from outside the OSGi framework, into the OSGi framework as re-design is completed by component. This way you gain the benefit where you can get to it quickly. Also, those nasty libraries which have yet to be ported or are still known to not live happily inside of OSGi framework can remain outside thr framework, consumed and wired in from within the container, until such a time as they evolve their own OSGi solutions.

Arkadiko is very small and very simple! It only comprises 5 classes in total (one is an exception, one is constants, one is a util class, the real work is done by two classes).

Adding Arkadiko to your existing spring configurations is as simple as adding a single bean:

<bean class="com.liferay.arkadiko.BridgeBeanPostProcessor">
    <property name="framework">
        <!-- some factory to get an instance of org.osgi.framework.launch.Framework -->
    </property>
</bean>

For more details and to see the code please go to https://github.com/rotty3000/arkadiko.

Feedback is very appreciated!

5 Comments

Please sign in to comment.

Interesting. Did you try to use PojoSR as a framework for Arkadiko (0.1.6 provides a Framework Factory)? The benefit would be that you don't have to worry about classloaders but can just put your bundles together with your jars on the classpath.

Would be interesting to see whether it works.

Please sign in to reply.

First off, welcome to Liferay.com Paul! It's good to have you!

Second, I didn't try that but it's an excellent idea! I will certainly give it a try as it sounds like a very interesting idea!

Also, since I have your attention, perhaps you had already considered this, but perhaps not; that is the notion of using PojoSR as clever test harness for OSGi bundles. (I realize it's much more than that) As you know testing OSGi bundles can sometimes present difficulty for some developers. It occurred to me that PojoSR could avoid a lot of that difficulty by allowing developers to quickly build up test plans with dependent modules outside of a full OSGi runtime.

Lastly, the next thing I'm going to be experimenting with is the possibility for Arkadiko to support resolving dependencies ("locating" services) from within the OSGi framework to satisfy the bean dependencies in spring without having an implementation existing on the spring side. Currently dependencies still needs to be satisfied on the spring side, which later could get overridden by an OSGi services. I'd like to solve that so code can finally and completely be moved from the spring side to the OSGi side.

Anyway, Thanks for stopping by!

Please sign in to reply.

Ray,
I just have a few questions here,
1. when you say that Arkadiko exposes all the beans as Services, don't you think we are violating the fundamental concept of OSGi the "modularity" by exposing all he stuff of the jar to external world ?
2. How does version of the classes taken care by Arkadiko ? Lets taken an example i have 1.0.0 version of Bean called "MyBean" already deployed as Spring beans and now i deploy 2.0.0 of the same bean called "MyBean" ..

Please excuse me if my questions are very basic, its just for my understanding emoticon

Please sign in to reply.

First, Spring knows nothing of versioning since it's plain java! Therefore there is no way that two versions can be in play, within spring.

Second, you have to export the interfaces you want to load from OSGi via the system bundle, and so again the version is known and so only a matching version can be used.

Within OSGi you can have multiple versions, within spring, there can be only one!

I think this is still reasonable trade off considering that you get the benefit of the dynamic nature of OSGi which is already far more flexible than what spring alone can offer.

Please sign in to reply.

That was an answer to the second question.

This is the answer to the first one:
To begin there is absolutely no way to get Liferay to a modular design in one shot! Not only would it break everything for backward compatibility but the gap between releases would have to be too big, Liferay would lose to much momentum and all interest would be lost.

The WHOLE POINT of Arkadiko is to address that specific case where the code is so large than it has to be redesigned incrementally. When faced with that fact, there is little incentive to actually want to start migrating to OSGi at all. The cost may be too high. BUT if we form a partnership with the OSGi framework, and we expose the services that we have (which is the bulk of what developers need from Liferay) then we can begin to form a working model where developers can write plugins fully based in OSGi, and gain from it's benefits while slowly Liferay takes reorganizes. That would still be no change to developer code... since you don't care which bundles expose what.. you only care that something is exposed or not. This is the beauty and simplicity of Arkadiko, exposing as much as possible to OSGi NOW, while giving ourselves time to restructure it all.

Please sign in to reply.

Menu Display

Blogs

Category Filter

More Blog Entries

Radio Liferay Episode 5: Cynthia Wilburn

Liferay 2011 Community Excellence Awards