In the future, you will no longer need to choose between OSGi and Impala. You can have the best of both worlds. As long as you have some appreciation for the value and benefits of dynamic modules in Java, then Impala can work for you, no matter what your stance on OSGi is.
If you have not looked at OSGi and have no intention of doing so, then you're already well covered by Impala. If you are likely to look at OSGi in the future, then you can take advantage now of a framework which already does most of what you'd want, and move towards OSGi when you're ready. If you're already an OSGi enthusiast, I'd encourage you to take a look now at the Impala OSGi sample. Just point your Eclipse SVN repository explorer to http://impala.googlecode.com/svn/trunk/osgi-sample, check out the contained projects, and run any of the unit tests. You'll see something like the following, for MessageServiceTest.
Note that the unit test is actually run on the Equinox OSGi container using the Spring Dynamic Modules test infrastructure. If this seems very easy, it's because it is - you won't even need to run any build scripts to get the example working!
If you're familiar with Impala you will notice that your OSGi-based application is configured in an identical manner to regular Impala applications, allowing a seamless transition from a plain Impala to an OSGi-based runtime (and back again). Impala's abstraction for representing relationships between modules provides a convenient mechanism for expressing and reloading module subgraphs, something you need to do continually during development.
Impala's OSGi support leverages much of the ground work covered by the Spring DM project. Impala also automatically generates OSGi compliant jars using Peter Kriens' BND tool when using Impala's build support, and provides a convenience target to generate an OSGi manifest so that you don't need to continually create a new set of OSGi jars each time you modify your application.
So is Impala's OSGi support production ready? Not at this point. Apart from the lack of any serious road testing, the big blocker is there is no explicit web support (yet). Additionally, Impala applications should have the option to use OSGi's service registry. I'd also like to better test framework integration so that Impala's interactive test runner and integration test suites can work equally well in an OSGi environment.
There are still some interesting technical challenges to overcome, and plenty of work to do to bring this project to its full potential. So if there is anyone out there with an interest in dynamic modules, Spring, OSGi , etc. and would like to help out, I'd love to hear from you.
So why add OSGi support to Impala?
The sweet spots in Impala are the ease in writing and running integration tests, ability to reload application modules, great web support, and a really simple, no-nonsense development environment. The sweet spots with OSGi is the way in which it gives you control over loading of third party libraries. OSGi allows you to dynamically reload third party libraries as well as concurrently run different versions of the same third party library classes, two things that you cannot do with Impala on its own.
I might stick my neck out a bit by saying that the features that I described above that are available in Impala on its own are much more valuable for the typical Java application than the extra features provided by OSGi. It is for this reason that Impala is built from the ground up to work in the simplest, most developer-friendly way possible without any reliance on third party runtime environments, tools or build systems.
That being said, there are clearly valid and potentially important use cases for the unique OSGi features. This, together with the growing industry momentum behind the technology, make OSGi support pretty much mandatory for any Java dynamic module system which demands to be taken seriously.
As I made clear at a talk in London last week, OSGi is the most powerful and sophisticated Java dynamic module system, particularly in its use of class loaders. But for many projects a simpler technology would suffice. Impala is the only dynamic module framework that offers the flexibility to choose easily between alternatives.
It is worth noting that in the upcoming version 1.0M4, Impala introduces support for expressing module dependencies via a graph rather than simply as a hierarchy. This allows individual modules to reuse functionality from multiple dependencies, rather than a single parent. This feature is particularly important both because it narrows the gap between Impala's built-in module support and that provided by OSGi, allowing for a more seamless and less constrained transition between the technologies.
4 comments:
I still don't really understand what the value of Impala is supposed to be. From your earlier descriptions it sounded very much like an alternative to OSGi and Spring-DM, which was fair enough although I didn't think you would be successful competing directly against those technologies.
Now you're using OSGi/Spring-DM, so what is left of Impala? In other words, can you explain what Impala now provides that cannot be done with just Spring-DM?
Neil,
I am surprised. You of all people should be pleased that I am starting to embrace OSGi!
To answer your questions:
Firstly, Impala is vastly more productive than Spring on it's own (for me, at least) or with Spring DM, not least because it's more test friendly. One scenario which I am quite likely to follow in my own projects is to use Impala without OSGi for most of my application development and functional integration testing, then potentially use OSGi for deployment, backed by a smaller and more coarsed grained set of OSGi based integration tests. Impala with OSGi gives you the flexibility to do that.
Secondly, Impala does have abstractions that I believe are useful in an OSGi environment. For example, you can use the module relationships which are explicit in Impala to manage reloading subgraphs of your application modules in OSGi. This is already supported. AFAIK, this feature is not available in Spring DM - there you simply specify a list of modules. There are other examples but it would be too much detail to explain now.
Third, if I am successful Impala test running features to work properly within OSGi, that will be a great boon to OSGi-based Spring development, offering levels of productivity similar in OSGi development to that available already in Impala.
Fourth, the approach I am taking gives you an insurance policy for free. In my opinion, almost all Java enterprise applications would benefit from dynamic modules. Not all of these in my opinion would benefit from the extra features provided by OSGi which are not already available in Impala. For these applications, the overhead of running OSGi (having to manage module dependencies more carefully, run a separate container, etc.) is arguably not justified. However, if your evolves in such a way as to justify OSGi, you'd have a simple migration path.
Of course, if you are absolutely and 100% definitely committed to using OSGi regardless - as you clear are - then this one might not count for much.
There we go - I've just rewritten my blog.
I am not trying to compete with OSGi and Spring DM. Impala provides practical and very effective solutions to the day to day issues I face as an application developer. With help rather than resistance from the likes of yourself, it would be possible to make those benefits much more widely available.
Phil, I didn't say I'm not pleased you're embracing OSGi. Of course I am! And, I'm not resisting what you're doing, just trying to understand it.
For the most part it seems that Impala is a testing framework along with some conveniences for assembling and launching an application. Would you say that's fair?
On the first point, I'm not sure why it would be more "productive" to launch a non-OSGi runtime during testing but then deploy to OSGi for production. Surely that exposes you to errors in production that you did not catch in testing?
In your second point you say that Impala expresses module relationships explicitly. Of course, OSGi does that too. Have you defined a parallel set of declarations for dependency relationships? While I can see the need for those in non-OSGi use cases, I think it would be better use OSGi's mechanisms directly when working with OSGi.
I don't understand the third point, sorry! And as you anticipated, the fourth point is not very attractive to me.
Maybe I'm just being dense but I still don't get what Impala really does and what the benefits are, at least for somebody who is using OSGi already. I'm sorry I missed your talk in London recently, it would have been useful to see a demo.
But please don't misinterpret my failure to comprehend Impala as resistance to it. Far from it, if it's as useful and productive as you say then I'll gladly sing its praises.
Neil
Thanks for taking an interest and apologies for misinterpreting the tone of your remarks.
Just to reply to a couple of your comments.
"For the most part it seems that Impala is a testing framework along with some conveniences for assembling and launching an application. Would you say that's fair?"
Testing is obviously a big part of Impala's focus, but there's a lot more to Impala than that.
I should point out that Impala was conceived out of frustrations from built in modularity within Spring, which was really hurting development and creating maintenance headaches in a project I was working on. In it's current form it now includes the abstractions that were missing to enable modularity. I've documented some of the interfaces involved on on:
http://code.google.com/p/impala/wiki/InternalInterfaces
My OSGi implementation in Impala involves overriding some of these interfaces - and thanks to work done in Spring DM, the effort required has been surprisingly little. Much more effort has gone into supporting graph-based dependencies between modules and their associated class loaders, something I remember you rightly identified as a weakness in the hierarchical class loader approach when I did my first JavaWUG talk.
Impala also has a service registry (another concept which I turned to on the back of a better understanding of OSGi), dynamic proxies to allow static references to beans consumed from other modules, and mechanisms for exporting Spring beans to the service registry.
There's a lot of work to support multi-module web apps. For example you can dynamically add web modules without touching web.xml. You can add dynamic loading support for web apps using other frameworks (wicket, tapestry, etc.).
There is some built in build support. The interactive test framework is there to enable productive TDD, but it really is building on the core features. Actually the test framework in Spring DM is a much more significant piece of work, because it is tackling the problem of enabling unit testing in an OSGi container.
I'm not sure why it would be more "productive" to launch a non-OSGi runtime during testing but then deploy to OSGi for production.
The fact that OSGi testing needs to be in-container does make testing more complex and cumbersome. The problem with Spring DM is that you can't do realistic integration testing of the real nuts and bolts of individual use cases outside of an OSGi container. With Impala you can. Correct me if I am wrong, but I expect that most of the "problems" that are likely to occur in an OSGi environment are likely to be classpath and wiring type issues. With Impala, you'd have the option of covering these in a smaller set of OSGi-based integration tests, while covering the detail of individual use cases in integration tests outside the container.
I still don't get what Impala really does and what the benefits are, at least for somebody who is using OSGi already. I'm sorry I missed your talk in London recently, it would have been useful to see a demo.
I understand where you are coming from. I'm probably going to do a session at the next JavaWUG code camp, which hopefully you can make. It would be good to talk you through it and particularly get your view on how to deal with some of the more subtle OSGi issues.
Post a Comment