Book Review: OSGi and Apache Felix 3.0 52
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 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.| 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 |
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 (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:1)
Re: (Score:1)
Sounds like the API version problem that would affect any language. If the API changes, you have no choice but to use a specific version that matches your app (without modifying/recompiling the app, that is). Java is the same, and Java apps can specify jar dependencies and versions of those.
But what we're talking about here isn't even that. We're talking about just one application (the app server) that runs multiple, sandboxed pieces of code (by "sandboxed" here I mean keeping these pieces of code separate
Re: (Score:3)
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 c
Re: (Score:2)
Just going to point this out, because no one seems to have pointed it out yet, but .NET solved this problem from the beginning. Libraries are versioned, and even (optionally) signed, and the correct version is always loaded, if it was signed. If not, the available version is loaded, and this behavior can be overridden through configuration at runtime, such that a reference to a library can be "redirected" to another version.
It's even possible to load multiple versions of the same library at the same time, a
Re: (Score:1)
I know this hell, but I still prefer java over c++, .net, php or ruby for most non-trivial tasks.
Re: (Score:3, Insightful)
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'
Java, huh? (Score:2)
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
Re: (Score:2)
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)
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.
Re: (Score:2)
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
Re: (Score:2)
"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
Re: (Score:1)
Re: (Score:2)
"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
Re: (Score:1)
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:3)
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?
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:1)
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
Re: (Score:2)
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?
Re: (Score:1)
No, you're pretty much wrong on all points. Let me guess: hobbyist programmer?
Re: (Score:2)
Re: (Score:2)
I can see why he'd think you were a hobbyist - you are remarkably ill-informed.
What enterprise level solutions have you developed? What problems / what technologies?
Re: (Score:2)
In twenty years of software engineering, I have never, ever, seen that to be the case.
Re: (Score:1)
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).
Re: (Score:1)
Re: (Score:2)
(At this point, I'm still wondering how I'm not modded troll - anyway, I've got the karma to burn
Uh, that's not just possible, it's super possible (Score:1)
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.
Re: (Score:2)
This takes it a step further. This can allow you to have different plugins using different libraries inside the same webapp/ear.
Re: (Score:2)
Eclipse (Score:5, Interesting)
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.
Re: (Score:3)
The review failed to mention that OSGi is the basis of Eclipse;
In much the same way that a book on Oracle P/L fails to mention anything about MSSQL.
In principal that's true, but because Eclipse is, by a very wide margin, the largest adopter of OSGi it does seem that it would have been mentioned at least as a side note.
It would be like a review of a book on using Objective-C for mobile development and never mentioning Apple.
Re: (Score:3)
The review also failed to mention that glassfish v3 runs on osgi [sun.com]
Getting started with OSGi and Felix (Score:3)
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]