Modular Java with OSGi and Spring

I was lucky enough to be asked to preform a technical review of “Modular Java: Creating Flexible Applications with OSGi and Spring“.  It’s Craig Walls‘ next book and it’s being published by the Pragmatic Programmers.

Craig does a great job of making the case for modular Java development with OSGi.  He covers why we need to start thinking about more than just how we design our methods / classes and focus more on how we design reusable Java modules.

First, Craig makes the case for modular design.  Then he talks about how OSGi enables us to write modular Java applications.  He covers both the Apache Felix and Eclipse Equinox OSGi containers.  Next you are writing and deploying a HelloWorld OSGi service.  And that’s all done in the first two chapters!

Craig spends the rest of the book covering modular Java and OSGi concepts through the development of an example project, Dude Where’s my JAR.  You also throughly learn an invaluable tool for OSGi development, Pax Construct. You learn about and writing and deploying OSGi bundles, then writing, deploying and consuming OSGi services.

Once you think you know everything about OSGi, and might be thinking that it’s a bit complicated, Craig brings in the Spring Framework.  He covers Spring Dynamic Modules for OSGi (Spring-DM) which is used to eliminate all of the OSGi-specific code in the example application.  You refactor the app away from depending on the OSGi API.  You change the services to POJOs and OSGi services then inject them into other beans.

My favorite thing about this book was that I didn’t have to read 1000 pages to understand the concepts and get up and running.  Like all the Pragmatic Programmer books, you are educated, and up and running in a few 100 pages.  Read this book if you want to quickly get up-to-speed on OSGi and Spring Dynamic Modules.

5 thoughts on “Modular Java with OSGi and Spring”

  1. Craig’s books are always well written. He’s definitely the Spring alpha geek. The problem is OSGi. It is a technology solution looking for a problem. With the excitement happening in the RIA space, it would be a better investment for most developers to get comfortable with JavaScript/Flex/Silverlight. JavaScript and Groovy are tops on my shortlist of must-master skills right now. OSGi is either five years ahead of its time, or DoA.

  2. Tim,

    I’m not sure OSGi is a solution looking for a problem. I’d say that it’s just done a horrible job selling itself. I think books like Craig’s can help. I think companies like SpringSource will really help.

    Reads Craig’s book. If you don’t work the examples you can get through it in a weekend. You’ll be ready to refactor the OrangeLeap webapp into OSGi modules. When that happens, you know who to call. 😉

  3. When we get finished fixing the front end, I’ll take a look. We could get more value out of using a dynamic language for some of the middle tier (Groovy) than moving to OSGi. Down the road, once we have people writing plugins to extend the application, OSGi becomes more interesting.

    If you can get me a copy of the book, I’ll be happy to take a look 🙂

  4. I agree with Tim: My books are always well-written.

    I also agree that RIA is very interesting. I’ve recently become a Flex fan, myself. But I’m also impressed with Silverlight and like the stuff that Ext-JS, Prototype, and jQuery add to JavaScript.

    But while technologies in the RIA space are interesting and may be a good investment, they are hardly the only thing worth investing your skills in. There’s much more to application development than a “pretty face”.

    I also disagree with Tim’s assessment that OSGi is either 5 years ahead of its time or DOA. On the contrary, I think we’re approaching a time where OSGi is really going to shine. As has been pointed out in recent days on other blogs, there are still some unanswered questions about OSGi, but there are far more questions that have already been answered.

    Unfortunately, there are far too many developers who disregard what is possible with OSGi and what benefits that it does already provide. I’m not sure why, except that perhaps OSGi doesn’t have a sexy name or perhaps because too many associate it with other more complex component frameworks from days gone by.

    In any event, there are plenty of things that a developer can invest themselves in. I absolutely do recommend that if user-interface matters interest you that you should invest some time getting to know the RIA technologies Tim listed. But even Tim should agree that it’s good to diversify your skill portfolio–Didn’t you have an interest in Jini/JavaSpaces at one time, Tim?

  5. Very good analogy, Craig. As much as I loved Jini/JavaSpaces, it was also a technology way ahead of its time, and DoA because of it. OSGi is very similar in its desire to handle dynamic aggregation of services (bundles). OSGi is sort of a “single server Jini”.

    Even in the largest enterprises, like our former employer, most development teams aren’t ready to grok services/bundles. There is still a lot of confusion and bitterness around failed SOA attempts, so OSGi, being another “services” technology, is going to be a hard sell. Backend technologies in general are hard sell right now. The pendulum has swung to the client side.

    Diversification is always a good thing, but drinking from the ExtJS fire hose is killing enough of my braincells right now. Once our application reaches the point that something like OSGi/Spring DM makes since, I’ll definitely be taking a look at it.

Leave a Reply

Your email address will not be published. Required fields are marked *