Foreword

It was during the very hot summer of 2003 that I first heard of Richard S. Hall. During a coffee break, a colleague from Deutsche Telekom told me that the local university had a teacher who was very much into OSGi. This teacher was the author of Oscar, one of the first open source OSGi frameworks. In 2003, wholeheartedly adopting OSGi was rare, so I was intrigued. Also around that time, Eclipse was investigating moving to a new module system, and I was asked to participate as an OSGi expert. I thought Richard could be valuable for this, so I asked him to join the Equinox committee. That innocent invitation started an enormously long email thread that hasn’t ended yet and, I hope, never will. Richard is often abrasive when specifications aren’t clear, or worse, when we attempt to violate modular purity. Sometimes I think he physically feels pain if we have to compromise on a dirty feature. As an invited OSGi researcher, he has became one of the key people behind the specifications, making sure we don’t bloat the framework and always follow our principles.

When Manning sent a flattering email proposing an OSGi in Action book to the key OSGi people, Richard was among them. This email triggered intense discussions about collectively writing this book; the idea to write a book had been discussed many times before. We went into negotiations with Manning, but in the end I withdrew from the group, urging the others to continue. Why did I bail out? As the editor of the OSGi specifications, I was aware of how much work it is to write a book in collaboration with other opinionated people. To extend my day job into the night and weekends for free wasn’t something I was looking forward to, regardless of how much I liked and appreciated these guys. Unfortunately, my desertion deflated the effort, and it faltered.

Until the day Richard told me he had picked up the book effort again from where we had stopped, now with a better team: Karl Pauls, Stuart McCulloch, and David Savage. Each of these authors is a great contributor to the open source world as well as to the OSGi specifications: Karl for his work on Felix and his testimony to modularity by doing Felix security as a separate bundle, proving that even the framework architecture is modular; Stuart for his work on the Maven bundle plugin, the popular Ops4J work, and the Peaberry extension to Guice; and David for the excellent work he is doing with Sigil at Apache and his work at Paremus. It would be hard to come up with a team that knows more about how OSGi is used in the real world. All this experience radiates from the chapters they’ve written in this impressive book.

While this team undertook the Herculean effort to write this book, I was in close contact with them all along the way—not only because of our work in the OSGi Alliance, but also because authoring a book about OSGi is likely to expose weakness or deficiencies in the specifications, which then obviously results in another, often heated argument over Skype or email. Unfortunately, to my chagrin, the team was too often right.

They also asked me to provide the text about the history of OSGi, an effort that resulted in probably the highest compression rate ever achieved. Of the 4,356 words I wrote, I think the word OSGi remained. But this is exactly what I like: the quest for quality drove this book, not only in its details but also in its form. It isn’t like many books today, full of listings outlining in minute steps how to achieve a result. No, this is a book exactly the way I like it: not only showing in detail how to use OSGi, but also going to great length to point out the rationale. It’s a book that explains.

And such a book is needed today. I understand that OSGi isn’t easy. Although it builds on an object-oriented foundation, it adds a new set of design primitives to address the shortcomings of object-oriented design that were uncovered when applications became humongous assemblies of multiple open source projects and proprietary code. Objects remain an invaluable technique for building software, but the object-oriented paradigm isn’t well suited to allowing large building blocks (components) collaborate without causing too much coupling. We desperately fight objects with patterns like factories and class-loading hacks, but at a certain scale the work to prevent coupling becomes a significant part of our efforts. Dependency injection alleviated much of the coding pain but moved a lot of the code into XML, a language that has the most ill-suited syntax imaginable for human programming tasks. Annotations provide another level of support for dealing with coupling-—but cause a coupling problem in themselves. Many of the painkillers we use to alleviate coupling are largely cosmetic because boundaries aren’t enforced at execution time in traditional Java.

OSGi is different. It treats an application as a collaboration of peer modules: modules that can adapt themselves to the environment instead of assuming that the environment is adapted to them. Adapting to the environment requires a reification of that environment, and this is where OSGi has its biggest innovation: µServices. µServices are the oil between modules that allows modules to evolve over time without affecting other modules. During a recent OSGi community event, David Savage used the term spiky to describe modules, to indicate how a set of modules causes friction that makes it hard to change each module. µServices are a design primitive in OSGi that is so powerful, it’s even possible to update or install modules on the fly without bringing down the application. They palliate the spikes of modules by reifying the interconnection between modules.

µServices are a new paradigm that requires a way of thinking that is different from what is prevalent in Java today. In many ways, OSGi is where object-oriented programming was 25 years ago, providing new design primitives that were ill understood by the mainstream. Objects required a generation to grow up thinking in terms of design primitives like polymorphism, inheritance, classes, and objects. OSGi is on the verge of making a new paradigm shift happen with its bundles and µServices. I believe that these design primitives will be the next software paradigm after object orientation. This book is an excellent way to become part of the generation that can really think in OSGi and reap its full benefits.

PETER KRIENS

OSGI TECHNICAL DIRECTOR