If you are interested in the ideas of modularity, there is quite a good chance you have looked at OSGi. But there is also quite a good chance that you have been put off by the extra development overhead required to set up and maintain OSGi-based applications.
If this is the case for you, my message is this: don't let fact that you are put off by OSGi put you off the ideas of modularity. Modularity is a bigger, more important and valuable idea than any particular technology. The ability to modularise an application can massively improve your application's ability to absorb complexity as new features and components are added, which in turn means that you remain much more productive as your application grows. It reduces the rate of entropy in your system, extending its potential life span, which of course if great for business.
This kind of modularity is one of the fundamental benefits of Impala. Also, because Impala's modules are dynamically reloadable, and you also get dynamic redeployment of small parts of your application, allowing you to greatly accelerate application development, maintain high levels of productivity, and retain high levels of code and functionality reuse as you application grows.
Impala does not solve all of the problems solved by OSGi. Notably, it does not provide versioning of third party libraries. However, it solves most of the important ones relevant for day to day development. Fundamentally, it allows you to modularise your application, without having to worry about micro-managing the dependencies of third party libraries in your application. Don't get me wrong - there are times when this capability can be important, especially for very large projects with large budgets and teams. But certainly not for every project, and probably not even for the typical one.
One way to think of choice is to look at the graph below.
The basic idea behind modularity is that the growth in complexity of your application slows as your application grows in size, compared to applications without modules. This applies both for Impala and OSGi-based applications. The difference is that because the barriers to entry are lower for Impala-based applications, the benefits kick in sooner, and accumulate for longer over the duration of the project, greatly reducing the overall cost of complexity over the lifetime of a project.
So, don't shy away from modularity just because OSGi looks complex. The benefits of modularity are too valuable, and an alternative like Impala make these attainable with fewer headaches.
2 comments:
I'm not from a developer background but I'm interested to know if comparing OSGi and Impala is a apples to apples comparison. Second, what other alternatives to OSGi are out there?
Mitchell
Impala includes classloaders and modules, dynamic services + a declarative services layer. At a basic level, OSGi includes classloaders and modules and dynamic services, but various projects (such as Spring DM) add a declarative service layer. The "apples to apples" comparison is at this level, although to be fair, the biggest difference from a practical and conceptual standpoint is how third party libraries are managed - which is very much at the module/classloader level of the respective alternatives.
Regarding alternatives, surprisingly few. There are plenty of projects using custom class loaders to achieve some of the objectives. There are plans to introduce modularity into the Java language itself, but its still pretty unclear how this will sit with OSGi - I know the initiative hasn't been very well received by OSGi enthusiasts.
Phil
Post a Comment