The bridge between Spring and OSGi

Q&A - Liferay's Raymond Augé about Arkadiko

Raymond Augé

Raymond Augé

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 help? 

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

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

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

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 months?

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.

Chris Mayer

What do you think?

JAX Magazine - 2014 - 05 Exclucively for iPad users JAX Magazine on Android

Comments

Latest opinions