The bridge between Spring and OSGi

Q&A – Liferay’s Raymond Augé about Arkadiko

Chris Mayer

We talk with Ray about Liferay’s newest open source project

What are the difficulties in porting existing Java
Enterprise applications to OSGi?

 RA: OSGi has a ‘puritanical’ java
architecture. In other words, its strictness makes it much, much
harder to solve problems with flagrant misuse of low level Java
mechanics, namely classloader hacks. The problem is that this
practice is rampant in modern Java software. This means that moving
existing code into OSGi is a matter of eliminating all these
malpractices and that can be a very expensive and daunting task. In
fact, code that is properly written to begin with can move
relatively quickly into OSGi. As such the difficulty is really a
factor of the size and quality of the application. A massive amount
of well written code will still take a long time to port, but the
job will likely be much more enjoyable than even a small amount of
very poorly written code. 

Other difficulties tend to be side effects of that; dependencies
of the application simply don’t work in OSGi. There are solutions
there, but they add additional steps to the process of migrating
your own code. An example may be forcing the development team to
maintaining wrapper bundles of libraries that don’t yet provide
OSGi bundles.

How can the new project Arkadiko

RA: The realisation was made that the costs of achieving an OSGi
port or integration may be too high for projects with significant
amount of code and/or without the resources necessary to commit
fully to the task. Meanwhile OSGi provides some very compelling
benefits even from relatively thin and early integration. As a
plugin mechanism OSGi already provides significant value. It seemed
logical that adoption of OSGi should happen as early as possible.
But there wasn’t a clear way of how to maximize the potential while
subjecting ourselves to the least amount of risk. 

The goal then, for Arkadiko, was to bring a large body of
existing work as close to OSGi as possible without having to change
a single line of code. This large body is of course the Spring Framework. As most Java
developers are aware Spring is perhaps one of the most prolific
Java frameworks in the industry. Its power and flexibility are
quite legendary and I think that few Java developers still active
today have not touched Spring in some way. With that in mind it
seems logical that a huge benefit could be gained by creating a
bridge between Spring Framework and OSGi. This would provide the
early benefits while allowing for a measured approach to porting or
migration of code into OSGi, effectively lowering the risk.

Where are the differences between Arkadiko and the
approach of µservices promoted by Peter Kriens?

RA: µservices are the ideal way of decoupling code. Whether
inside OSGi or outside, µservices allow developers to clearly
delineate the logical components of an application to enable loose
coupling. Once this delineation is made, mapping those components
into OSGi is really very simple.

Spring beans are very closely related to uservices and one might
argue that idealistically Spring beans are in fact an
implementation of µservices. The process of migration existing code
to OSGi should still follow the path of realizing a redesign into
µservices. In the meantime, one can take the existing, select
Spring beans and publish those into OSGi, to be consumed or even
replaced by µservices inside of OSGi, until such a time as those
fully mature into true µservices, packaged and then moved wholly
into OSGi.

As such Arkadiko is really an ally of uservices providing a
garden where they can grow and flourish as resources become
available, again lowering the risk of moving large applications to

Can you tell us a bit about the project history? Who
initiated the arkadiko project? Who is maintaining it

RA: Arkadiko is very young and not all of its features are yet
realized or even fully proven. It was conceived by myself over the
past year (so from early 2011) as my desire to integrate with OSGi
increased as a means to improve the state of our (very large)
application’s extensibility and perhaps more importantly, it’s
maintainability and future proofing. 

The application I’m referring to is Liferay Portal, the leading open
source enterprise Java portal in the industry.

Liferay Portal is a very sophisticated, large and technically
complex application having great extensibility but with a plugin
architecture that is completely based on the web
application/servlet specifications. The fact that our promise is to
be compatible with practically every servlet container and app
server on the market, commercial and/or open source, means that our
plugin architecture is at the mercy of the underlying container.
This leaves us with the unenviable task of having to deal with a
vast number of intricacies specific to each container which is a
maintenance nightmare.

If our plugin architecture was completely under our control,
most if not all of these issues could disappear as we could revert
to the “lowest common denominator” strategy for the container
exposed edges of our application. 

Add the fact that Liferay is a heavy user of the Spring
Framework and you begin to understand what motivated the design of
Arkadiko. My intention was to provide a low risk means of evolving
our architecture into an OSGi based/enabled one. Due to size and
complexity the task certainly would have to occur over several
generations of our product. We want to continue to move the product
forward feature-wise while still having the option to re-architect
components into a more modular and maintainable design.

And so Arkadiko
was born!

The actual version of Arkadiko is 0.1, which probably
means, that the project is in a early state of development. Is
Arkadiko already mature for enterprise purposes? 

RA: Arkadiko is still in early development. The proof of concept
is certainly at the stage of being useful. But, it’s too early to
claim it as being enterprise ready. On the other hand, as I
mentioned earlier, the risk is so low that there is nothing to be
lost but the few minutes it would take to configure it in a Spring

Currently it has two main functions: 

1) to publish eligible beans into the OSGi framework as services
(beans which do not implement any interfaces are ignored, and it’s
possible to ignore beans by name or class, including wildcards
pattern recognition)

2) to register a listener for each registered bean which will
react to new services arriving into the OSGi framework which could
fulfill the dependency satisfied by the bean and replace it thus
altering the behavior of the beans being used outside in the Spring
Framework container, adding dynamic bean replacement features to
spring via the OSGi framework.

How is Arkadiko supposed to evolve in the next weeks and

RA: You could say that Arkadiko is a project that hopes to
obsolete itself. If there is no more code that needs to be migrated
into OSGi, then Arkadiko would have done it’s part to achieve that
and would be of no more use. But I highly doubt that we will ever
reach that state, and in fact I could envision Arkadiko achieve use
solely for the purpose of bridging between Spring and  OSGi
rather than as a vehicle for evolutionary migration. 

An additional goal that is still in conception is the ability to
remove dependencies completely from the Spring Framework (aside
from interfaces of course) such that they be resolved completely
from the OSGi framework. The goal being complete migration of
code within the OSGi. 

The goals of Arkadiko are few and so the code is small. I would
imagine that most if not all of its goals could be proven and reach
maturity in a matter of weeks or months. Being an open source
project, I hope to attract some interested parties to help achieve
that maturity quickly. 

Raymond Augé is Senior Software Architecht at Liferay
Inc. You should keep in touch via Twitter too with all Liferay’s
latest developments.

comments powered by Disqus