It must have been in 2006 that I got a call as OSGi’s Technical Director from Adrian Colyer, CTO of Interface21, the company that was the source of the Spring Framework. Yes, I’d heard of the Spring Framework, and I understood that it was a great improvement over existing techniques for writing software for the enterprise. As a developer who had gained most of his experience in developing embedded and middleware applications, I found all that XML rather foreign. However, I’d noticed the enterprise world’s interest in OSGi, so I too was interested.

It turned out that Interface 21, BEA, and Oracle were considering creating support for OSGi in the Spring Framework. Spring is very good at configuring an application built out of simple objects that use, among other things, the simplified Spring interfaces to communicate with the world. However, Spring did not provide any support for modularity. In contrast, OSGi provides strong modularity support but it’s not strong in configuration and it had no services in the enterprise space. This was a match made in heaven!

To discuss supporting OSGi in Spring, Adrian proposed a conference call with Hal Hildebrand (Oracle), John Wells (BEA), and one of the authors of this book: Andy Piper (BEA). B.J. Hargrave (IBM) also attended as OSGi’s CTO. The initial conference call was followed by a meeting in London at the offices of BEA. It was a meeting I’ll always remember, it was the start of what became Spring DM. At first, I felt that the group saw OSGi as something that needed to be supported by Spring; that is, as one of many things to be supported. As the meeting progressed, it became clear how nice the combination of Spring and OSGi could be; there was a lot of synergy and surprisingly little overlap. At the end of the meeting, we were thrilled with this project's potential.

The Spring DM project became crucial for the adoption of OSGi in the enterprise space. At that time, OSGi had been adopted by Eclipse, which made it acceptable for general programming. However, the enterprise space is conservative and was hesitant about adopting OSGi. The fact that Interface21 people started to sell OSGi at the many conferences they visited helped to give OSGi a place in the enterprise world. That said, it was a surprise for me when Interface21 changed their name to SpringSource and put a lot of emphasis on the OSGi connection. They quickly became a member of the OSGi Alliance and started RFC 124, as an endeavor to put Spring DM under the OSGi flag. This RFC later turned into the Blueprint specification. SpringSource also introduced the dm Server (now project Gemini in Eclipse) and more importantly, they launched the OSGi Bundle Repository, filling a crucial gap for the acceptance of OSGi in the enterprise. This repository contained bundles based on open source projects. Before this repository, developers were forced to create their own bundles from open source projects, and this was not always painless.

Alas, it still is not always painless. The core principle of OSGi is modularity, creating inside and outside spaces with well-defined ports. The advantages of modularity are numerous and well proven. However, OSGi enforces those rules strictly on all levels. Unfortunately, it turns out that many open source libraries do not live well inside modules—thay need global visibility of all classes. Over the past decade, mainstream Java has given rise to a number of patterns that appear to be modular but are not so in reality.

That’s why this book about Spring DM and Blueprint is so crucial. First, it provides an excellent introduction to OSGi and what the guiding principles are. As one of the participants of the OSGi specification, I do not think I could have improved on this description. The book then explains how you should structure your projects with Spring DM, but it doesn’t stop there. It doesn’t hide the complexities of today’s reality, which is that you have to use existing (open source) libraries. It provides an extensive description of what you should do when you need to use libraries that do not play well in a modular world.

If you’re already building applications using Spring, then read this book and take the leap into the OSGi world. Although you might run into some hurdles, this book will help you solve them, and the rewards are well worth it.

Peter Kriens
OSGi Technical Director