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.
There are so many CMSs, 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.
I'm not a lawyer, but I play one on the Internet. Blog
In the mid 80s a computer came out with shared libraries. Multiple versions of the same shared library could be installed, and when an application needed a library, it would request the minimum version number required. If the API actually changed, then you would just have a different library altogether, so you could run both libraries besides each other. One would open 'library', the other, open 'library2', for example.
Java doesn't have libraries, it just has more and more classes on the classpath. So when your com.foo.bar API changes entirely, you can't do squat about it (well, apparently you can use the system this book is about). Your program has no means to say "import com.foo.bar from library" or "import com.foo.bar from library2".
This is similar to the annoyance of having two classes named the same on different paths. Instead of being about to do:
import com.foo.Bar;
import com.meerkat.Bar as MKBar;
so you don't have to write the full class name in your code... you can't.
The application you're building is realistic enough, and you incrementally add functionality
Then you a servlet container, a "dependency injection mechanism", and some "beans" whatever the FUCK they are.
Later your application collapses under unmanageable complexity, and you wish you'd avoided the Java ecosystem completely.
n/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
I'm a minority race. Save your vitriol for white people.
http://my.safaribooksonline.com/book/software-engineering-and-development/ide/9781849511384
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.
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
This takes it a step further. This can allow you to have different plugins using different libraries inside the same webapp/ear.
I'm a good cook. I'm a fantastic eater. - Steven Brust
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