Slashdot Mirror
Book Review: OSGi and Apache Felix 3.0
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.
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.
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.
Lurking at the bottom of the gravity well, getting old
If those things cause your application to collapse under unmanageable complexity, then those things probably weren't the right tool for the job, or you didn't know how to use them.
It sounds like you don't understand dependency injection or beans, so you're very likely to end up hating it all and losing control of your project. If you do understand those things, then you know when they are appropriate to use and when not to, so you don't end up hating something without a valid reason simply because you didn't understand how to use it.
This really simple application of making informed, logical decisions applies to all areas of programming (in any language) and most other things in life. You'll learn that as you mature.
Except this is exactly what OSGi is designed to work around. Each plugin runs in its own classloader, in effect sandboxing each one. One plugin can work on library, while the other works on library2.
Now if you need one piece of java code that depends on 2 versions of a library. Yep you are screwed. However I have never had a case of
As far as api vendors breaking library compatibility without notifying anyone. Yes this sucks, and yes this exists in every language I have ever worked in. If you are lucky the classes wont compile so you know what is comming.
I'm a good cook. I'm a fantastic eater. - Steven Brust
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.
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? To properly specify the behaviour of the new module, of course. But the xml file is too large and unwieldy to massage? Not a problem - lets create a framework and/or more modules that lets us edit *any* xml file. Why does your module *need* the app framework? Because the app framework supplies a basic architecture for pluggable modules (configured by xml, natch!) Wait, if thats the case, where's the reason for the application server? So that we can run multiple pluggable applications and/or frameworks that each get configured with a different xml file. Why do we need to run all of this? Because business logic is complex!!!!
See, here's my take - you see a problem, you write a general solution that is made specific by configuration parameters? No problem. You see a problem and write a module to solve that problem that gets used within a wider framework? No problem. You see a problem, and write a general solution to be used in a very specific framework, which results in a different problem, that gets a different solution, that results in a different problem, that gets a different solution ... etc ad nauseum.
(Yes, I've had to deal with this recently and am still sore that, of the entire codebase, a mere 1.2% LoC were devoted to actually solving the business problem - most of the code was spent inheriting, specifying interfaces, dumped in xml config files, or xml build files, doing weird reflection-fu at runtime for little to no actual gain in business logic, doing equally strange things with long chains of inherited classes (with each class only getting subclassed once, which sort of brings up the question of why separate the classes in the first place)).
The JAINSLEE is a good example of artificial complexity in action.
I'm a minority race. Save your vitriol for white people.
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
The difference between Canada and the USA is that in Canada healthcare is a right and gun ownership is a privilege.
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 probably will be a while away from needing OSGI, but in an enterprise scale environment, OSGI solves some very nasty problems. Nick