Preface

I first used Java EE many years ago, in 2002. (Yes, Stateless Session Beans and Passivated Entity Beans, stop hiding at the back—I’m talking to you.) I can’t remember when I started using OSGi, but it was also a long time ago. Nonetheless, until recently, I’d never used the two technologies at the same time. If I was writing a desktop application or an application server (as one does), I used OSGi. If I was writing a web application, I used Java EE.

But OSGi seemed the most natural way to develop a working system. When I was writing Java EE applications, the thought of leaving my dependencies to chance or exposing all the internals of my JARs made me pretty uneasy. It felt downright icky. What if classes I needed weren’t on the classpath when my application was deployed? What if the classes I needed were there, but the version was incompatible with the one I used when I was developing? What if a colleague coded against one of my internal classes, and then I refactored and deleted it? What if I accidentally coded against the internals of a library I was using? And wasn’t there a cleaner way to get hold of interface implementations than the reflective factory pattern? Applications might work in the short term, but it felt like an accident waiting to happen.

For a long time, Java EE developers didn’t have much choice except to close their eyes, hold tight, and wait for the accident. It’s not that they didn’t want to use OSGi—they couldn’t. OSGi didn’t play well with the Java EE programming model. OSGi’s tightly modularized classpath wasn’t compatible with the discovery mechanism for Java EE services, which assumed global visibility. Similarly, many of the Java EE implementations relied on classloading tricks to do their work, and these tricks failed miserably in the more controlled OSGi environment.

In 2009, I heard Zoe Slattery give a talk on a new Apache incubator, Apache Aries. Aries promised to allow Java EE technologies to work in an OSGi environment. It wasn’t reinventing the Java EE wheel, just allowing Java EE developers to take advantage of OSGi. I thought it was cool—and desperately needed. A few months later, I was signed up to help develop Aries and the IBM WebSphere feature pack built on top of it.

As well as developing Aries itself, I was speaking at conferences about enterprise OSGi. Manning contacted me and asked me if I’d be interested in writing a book on the subject. I was excited by the idea, but scared—after all, there were lots of people who’d been working with enterprise OSGi for much longer than I had. What I did have was insight into what people learning enterprise OSGi needed to know. After all, I’d had lots of the same questions and made lots of the same mistakes myself pretty recently.

But it was clear that reinforcements would be required. This is where Tim Ward came in. Tim is one of the brightest guys I know, and I was delighted when he said he was interested in the book. Tim was one of the first developers to prototype the early implementations of the OSGi Enterprise Specifications, and he’s been working with enterprise OSGi ever since. Even better, he’s coauthored some of the specifications. There isn’t much about enterprise OSGi that Tim doesn’t know. Although my name is first on the cover (thank you, alphabet!) this book is authored by both of us equally.

Writing this book has been a great adventure. We hope you enjoy it and find it useful, and we’d love to hear from you on the Manning Author Online forum.

HOLLY CUMMINS