Forgot your password?
typodupeerror
Book Reviews

Book Review: OSGi and Apache Felix 3.0 52

Posted by samzenpus
from the read-all-about-it dept.
RickJWagner writes "OSGi is a Java framework that's designed to simplify application deployments in shared environments. It allows applications with differing dependencies to run side-by-side in the same container without any deployment time contortions. The end result is that your application that needs FooLib v2.2.2 can run right beside my application that needs FooLib v1.0, something not often possible in today's application servers." Keep reading for the rest of Rick's review.
OSGi and Apache Felix 3.0, Beginner's Guide
author Walid Joseph Gedeon
pages 336
publisher Packt Publishing
rating 8/10
reviewer RickJWagner
ISBN 1849511381
summary A step-by-step beginner's guide based on developing a case study
OSGi is actually more than that, though. It's a framework with a very granular component lifecycle model, so you can carefully manage when the various parts of your application start up. It contains a service registry, so your application can either advertise or consume services. It's a controllable application runtime framework, complete with shell language that allows administrative tasks to be performed.

All these things and more are covered in the book. The author assumes the reader knows nothing more than what an average Java coder would know, so the development environment is given great coverage. (As is increasingly common, Maven2 is the build mechanism being used. The author goes to great lengths to explain how to construct every .pom file you'll need.) By the way, you'll be needing plenty of .pom files, as you are going to be incrementally building a simple bookshelf application, adding functionality chapter by chapter.

The book's example business logic is nothing out of the ordinary, which is good. If you're new to OSGi you're going to have your hands full learning the ins and outs of packing applications, the component deployment cycle, etc. Any experienced developer is going to instantly recognize the business problem you're trying to solve, so at least you won't be bothered by that. There is plenty of new material to study otherwise-- even tasks as ordinary as logging or deploying a servlet are vastly different than what you're probably used to. I remember I once read an article on the web about a new Java spec, the article was called "Don't make me eat the elephant again!" Well, if you're new to OSGi and want to get started.... break out the silverware!

In some ways, I'd compare Felix to an application server. It's an environment you use to deploy your applications, and it comes complete with a shell language used to administer the container. (The shell language, called 'Gogo', is given it's own chapter. You're also given Gogo commands throughout the book as you develop, deploy, and run your application.)

OSGi specifies a "Bundle Repository", which is a place where you can place your deployment artifacts so others can access them when they're listed as dependencies to their applications. (All this is done in the manifest files, by the way. You're given a good overview of all of this.) The OBR is yet another part of the landscape that will become important to you, so it's given good coverage in several chapters as you need to access it.

The development tasks are carefully covered. You are given very clear instructions on Maven to start, later on the author might withhold a little information to make you work a little. (Hint: the book's sample code fills in gaps nicely, if you get stuck.) The book also includes a series of 'Pop quizzes' to help you check your understanding of the material. More than once I found I might've been reading a little too quickly and paged back-- sure enough, the material had been presented, but I hadn't been paying enough attention. I liked this part of the book.

The application you're building is realistic enough, and you incrementally add functionality to it to make it something similar to what you might actually need in the real world. You start with the basic object model needed for a CRUD application, then add on niceties like a text UI, logging, a graphical interface, etc. Along the way you're introduced to things like iPojo, which is a dependency injection mechanism for OSGi. (Remember that elephant? Here's a small chunk...)

The book ends with a nice-to-have chapter on troubleshooting issues and two appendices. The first one covers the development environment, Maven/Eclipse. The second one covers advanced topics that should be within reach for the reader by the time they've reached the end of the book.

So, what's the bottom line? I'd say this book is good for anyone who wants to learn OSGi in general, or Felix in particular. No prerequisites exist, except maybe basic competency in Java. For developers just shopping around for an instructional book, without a need to pick up OSGi..... I'd say maybe not. (Why clutter your brain with this stuff, unless you're going to put it to good use?) Overall, the book is well written and presents things in an easily understandable way. On a scale of 1 — 10, I'd give this book an 8.1.

You can purchase OSGi and Apache Felix 3.0, Beginner's Guide from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived. No new comments can be posted.

Book Review: OSGi and Apache Felix 3.0

Comments Filter:
  • There are so many CMSs [cmsmatrix.org], frameworks, Javascript libraries, DBs (even open source), and other parts of the stack that you could have one person in the company just devoted solely to trying to keep up, and be able to provide advice when a team is considering implementing something or another.

    It's hard to think that you'd be using the "best-of-breed" if you don't even know what's available.

    • by Nerdfest (867930)
      Or you could have 100 people writing your own version of each of them.

      Seriously, design for change, make your best effort at picking a framework in a given area and start developing. Change later if you chose wrong, your're still going to be ahead of the game and you've learned something. Provide feedback to the Java community about your experiences and recommendations. Despite what some companies have people thinking these days, choice is a good thing.
      • by Compaqt (1758360)

        Yeah, don't get me wrong. Even the middle of the pack for various categories of frameworks/libraries are far superior to hand-rolled stuff that we all used back in the day.

        The second part of my point is that it might actually be a good idea for larger organizations to actually have one person just devoted to testing new frameworks instead of devs having to guess on the applicability of a package for their company based on the its homepage.

    • I agree. But what is the alternative? To use only off-the-shelf or hosted CMS and issue tracking applications with no ability to customize at all? I suppose the opposite end of the spectrum is to roll your own system yourself. Either way the answer is "it depends...".

      Disclaimer: I have written plugins for Atlassian's Jira using their original home-grown plugin framework and the new OSGi "Plugin 2" framework. Both can be headaches, and both are way easier than writing my own Issue Management system.

      However I

    • by BohKnower (586304)
      I have big news for you, most framework are stackable, and you can use another framework like Spring to integrate them. Do not despair, start at your own pace and in a few days you will have a perfect architecture!
  • Your application would run within an application framework, which runs on an Application Server, which runs on a JVM, which runs on an OS, which then gets deployed into a node in some cloud. All to solve some problem that's already been solved.

    Sometimes I look at the crap that is most java enterprise development, and wonder what the hell is preventing the load of manure from collapsing under its own weight - then I realise that that is why it takes a minimum of a dev-team of at least 6 people to do *anyt
    • by BitHive (578094)

      Feh, that's nothing a 10,000-line XML config file can't solve! Power tools for power users!

    • Re:Java, huh? (Score:4, Interesting)

      by Cyberax (705495) on Monday February 07, 2011 @04:55PM (#35130084)

      Uhm. Have you ever had a thought that 'solved' problems tend to be unsolved in reality?

      15 years ago most of Java enterprise stuff would have been written in crashy C++ with a lot of impenetrable CORBA mappings and weird UI frameworks. Or maybe if you are 'lucky' in impenetrable COBOL.

      And actually, I can write software in Java (and now in Scala) single-handedly faster than several Python programmers. Because I know how to use all these tons of frameworks.

      • Uhm. Have you ever had a thought that 'solved' problems tend to be unsolved in reality?

        Yes . Yes I have. However, when the "problems" being solved are problems caused by using the tech in the first place, then I've little sympathy. The enterprise "java app" is actually a plugin to a framework which runs on an application server. To get your code to compile/test/debug cycle you need all 3. Not really a problem, until you find out that each of them have their own rats nest of xml configs, in not-quite-readable form. But not a problem, because yet another 3 plugins exist to provides a web-fron

        • by Cyberax (705495)

          "The enterprise "java app" is actually a plugin to a framework which runs on an application server. To get your code to compile/test/debug cycle you need all 3."

          Sure. And you also need an OS, and microcode in firmware. Oh, and probably electric connection as well.

          "Not really a problem, until you find out that each of them have their own rats nest of xml configs, in not-quite-readable form. "

          My current app has exactly one 20-line XML config, even though it uses Hibernate, Guice, GWT, querydsl, Wicket with ab

          • You do know there is flight reservation management software, and web-store CMSes written in LISP, right? And what's wrong with emacs? LISP is pretty much perfect, thing is, everything else is good enough, making them eternal enemies...
            • by Cyberax (705495)

              "You do know there is flight reservation management software, and web-store CMSes written in LISP, right?"

              No I don't. Haven't seen them, maybe it's possible to find them if one looks in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying "Beware of The Leopard". Yeah, they might exist but they are irrelevant.

              No popular sites I know use LISP, no popular tools I know use LISP, etc. And I know a lot of tools.

              Oh, sorry. I know of one tool which used LISP. It was Micr

              • That CMS thing - Yahoo! Store. And I somewhat doubt you work in the appropriate niche markets. On the last bit - you're right - though it's a good tool (I might have overstated a bit), but if no one uses it, well, tough... so you are right in a sense. OTOH, I dare you to find a technical limitation that doesn't apply doubly so for another programming language.
                • by Cyberax (705495)

                  LISP is old. It's seriously old, even though its concepts are still very advanced.

                  It doesn't have pattern matching - a staple of modern functional languages, for example. There's no algebraic types and they can't be emulated using macroses without writing half of a buggy Haskell implementation in LISP. No good list comprehensions as well. LISP macroses also look antiquated now - there's no quasiquotation.

                  Also, not much tools.

                  And as for niche markets, they does not mean anything. There's a niche market in VB

    • Your application would run within an application framework, which runs on an Application Server, which runs on a JVM, which runs on an OS, which then gets deployed into a node in some cloud. All to solve some problem that's already been solved. Sometimes I look at the crap that is most java enterprise development, and wonder what the hell is preventing the load of manure from collapsing under its own weight - then I realise that that is why it takes a minimum of a dev-team of at least 6 people to do *anything* at all, within this app-framework, within the app-server, within the jvm ....

      Is someone forcing you to use these frameworks? These various frameworks hold much value to those that have need of them (such as enterprises, for which it was intended), otherwise they wouldn't exist. Just because you don't need them to for your particular app space doesn't mean they are "crap". It's easy to "dis" a technology that you don't understand. Generally, true appreciation (or educated criticism) of a given technology only comes with at least a rudimentary understanding of why things are the way t

      • Your application would run within an application framework, which runs on an Application Server, which runs on a JVM, which runs on an OS, which then gets deployed into a node in some cloud. All to solve some problem that's already been solved. Sometimes I look at the crap that is most java enterprise development, and wonder what the hell is preventing the load of manure from collapsing under its own weight - then I realise that that is why it takes a minimum of a dev-team of at least 6 people to do *anything* at all, within this app-framework, within the app-server, within the jvm ....

        Is someone forcing you to use these frameworks?

        Yes.

        These various frameworks hold much value to those that have need of them (such as enterprises, for which it was intended), otherwise they wouldn't exist.

        I find that to be an illogical argument - namely, that their very existence is a result of them adding much value. Just because something *exists* does not mean that it is "holds much value". Lots of things exist, that have very little value.

        Just because you don't need them to for your particular app space doesn't mean they are "crap". It's easy to "dis" a technology that you don't understand. Generally, true appreciation (or educated criticism) of a given technology only comes with at least a rudimentary understanding of why things are the way they are.

        My understanding of why the java enterprise space is the way it is, is (I hope) more than rudimentary. Why do you need an app framework? Why, so that your enterprise can readily and easily have new logic added to it? Why does your new logic get monstrous xml-files?

        • I have no idea how much experience you have in enterprise development, but your comments are consistent with someone who hasn't spent much time in this area.

          Contrary to what many small time hackers and code monkeys think, most enterprise architects and CTOs are not complete idiots (though I'm sure some are). They are well aware of the additional complexity that powerful frameworks introduce. However, this complexity is a small price to pay when compared to the complexity of a thousand different application

          • by kaffiene (38781)

            The problem here is that /. is peopled with newbs who think that because they've hacked together a web-app in PHP, they understand all of what web development entails. The multi product, multiple system integration tasks you mention represent a business problem that these guys have never even seen before so they don't have the first idea what these ESB, SOA-type systems are developed to do. Hence, in ignorance, they claim that they do nothing at all but add redundant layers to a solution.

            Hating Java is a

    • by Anonymous Coward

      I've worked in both enterprise and startups and I can say that while Python and are all cool the reality is that most languages outside of Java & .net are missing many of the helpful libraries and functions you need to just get stuff done. I can't count the number of times we were working in python where we would need to do something complex because of requirements and we could easily find a java or .net library but python would have nothing.

      Now if you have real rockstars you can recreate any library

      • I can't count the number of times we were working in python where we would need to do something complex because of requirements and we could easily find a java or .net library but python would have nothing.

        Out of curiosity, why not use Jython or IronPython in that case?

    • by abigor (540274)

      No, you're pretty much wrong on all points. Let me guess: hobbyist programmer?

    • by Anonymous Coward

      Sometimes I look at the crap that is most java enterprise development, and wonder what the hell is preventing the load of manure from collapsing under its own weight - then I realise that that is why it takes a minimum of a dev-team of at least 6 people to do *anything* at all, within this app-framework, within the app-server, within the jvm ....

      No, there is a secret shortcut: Maven. With one command (mvn archetype:create) you suddenly have all of that set up, and just set-to coding your business logic. Our team (average size: 2) has built two large products in a short space of time using Java, OSGi, (and Groovy, JRuby, Jython, and all the other bits using the JVM gives you access too).

    • Take a look at the Play web framework for Java. It's a refreshing dose of sanity that takes all the lessons learned about web dev in the last 10 years and applies them to Java. It's a really nice experience and it also supports Scala.
  • Tomcat already handles this situation just fine with separate classloaders for each application. And even if it didn't, actually application servers like WebSphere or Glassfish do handle it. Just don't put your libs in the global lib folder and it's been working for years.

    • This takes it a step further. This can allow you to have different plugins using different libraries inside the same webapp/ear.

    • by nzNick (721082)
      Dude - OSGI is soooo much more then Tomcats class loader separation. Think of a SINGLE web app (war file in Tomcat) that needs to use two versions of the same jar file (think apache-commons).... This is OSGI -binding to specific library versions WITHIN the same class loader context - all dependencies specified in the manifest file. But I agree with the reviewer - if you are not running into enterprise level lass loader issues, dependency issues, and other resource management (pooling etc) management, you p
  • Eclipse (Score:5, Interesting)

    by TopSpin (753) on Monday February 07, 2011 @04:14PM (#35129668) Journal

    The review failed to mention that OSGi is the basis of Eclipse; Eclipse is primarily a collection of OSGi managed components. Eclipse 'Rich Client Platform' (GUI, in other words) applications also inherit this model. The point is that OSGi is not merely another web application container specification; it is entirely suitable for non-web related work. The specification is free and several of the best implementations (Equinox, in Eclipse) are open source.

    • The review also failed to mention that glassfish v3 runs on osgi [sun.com]

  • by smartin (942) on Monday February 07, 2011 @10:14PM (#35133314)

    I haven't read the book yet but if you want to get started with OSGi and Felix just pop over to the Felix web site and read their getting stared documentation. It is clear and well written and I was able to get an OSGi app up and running is a couple or hours.

    http://felix.apache.org/site/getting-started.html [apache.org]

If at first you don't succeed, you must be a programmer.

Working...