In my previous post I stated that OSGi lite would provide 80% of the benefits and this was seen as too high by some. I do agree that the 80% was not very scientific, it is a very personal estimate. I picked 80% because I do believe that the µservice layer is the most important software innovation since OO came around in the eighties. Building systems out of µservices automatically makes systems more modular because they minimize coupling.
That said, the modularity layer also does provide lots of advantages, especially when used within larger groups. Strong modularity can enforce rules across the development life cycle that are vital for large projects. As John Wells (from BEA at the time, now Oracle) once said: "If you think you're working modular but you're not using OSGi, then you're not working modular." Unfortunately, most people are not working modular and find the path to OSGi's strong modularity too painful. OSGi lite is the on-ramp to OSGi because it provides immediate benefits in any WAR or class path based application without any pain. Once you moved your code base to µservices you can then more easily transition to OSGi to reap its additional benefits.
So the question of conscience is, what will I use? If I think I get 80% of the benefits, why bother with the real thing?
After working with OSGi lite last week I felt, a bit to my surprise, that the development cycle with OSGi is much faster and smoother than with OSGi lite. The difference is the dynamic update of OSGi. The Eclipse debugger can replace code in memory but it often has to restart because certain changes cannot be applied in a running process. Using bndtools this is never a problem because every time you save the source file it rebuilds all artifacts and deploys them on the running framework immediately. It works so smooth that that the deployment step becomes largely invisible. So with OSGi you can work for days with the same framework happily humming along. In contrast, working with OSGi lite forced me to use the standard Java Application run mode and the GWT Servlet runner that were not even remotely as smooth. And not to forget, the framework finds many hidden errors like missing packages, invalid versions, etc. before your code stumbles over them.
Last but not least, with OSGi I know it will deliver when I run into hard problems because it is mature. I might today not have many of the problems OGSi provides solutions to, but when tomorrow comes that situation might differ. If you would develop on OSGi lite you're bound to have a serious porting problem when you would not test/develop your bundles on OSGi regularly. After all, its strength that allows all these class loader hacks is also its greatest weakness.
Peter Kriens
P.S. All opinions in this blog are mine not necessarily the opinion of the OSGi Alliance. As should be clear in this case, OSGi lite is not without controversy inside the OSGi Alliance.
Peter, I think I agree with the people you were arguing with. From my POV, it is the modularity of OSGi that is the winner feature. That is pretty much gut feeling, but one thing modularity has going for it is that it applies to any kind of software, including batch applications, which have a very trivial lifecycle (like compilers). Another thing is that the modularity aspect by itself does not impose a programming model, which no matter how amazing benefits it could bring, can be too high a cost for existing applications, whereas breaking an application into bundles can be primarily a buildmeister's job, with localized impact.
ReplyDeleteI also do agree with the people I arguing with :-)
ReplyDeleteHowever, if the µservice model has as much value as I believe it has it seems a rather purist view to deny them these partial advantages unless they buy-in to the whole package?
I strongly believe that once you start using µservices you automatically reduce the need for class loading hacks and minimize the coupling between "modules". After this going to real OSGi is a lot easier.
I have another use case for OSGi Lite having to do with using OSGi services in a build or design time environment.
ReplyDeleteThe OBR spec will introduce a new OSGi API that takes a list of repositories (including a running OSGi container) and requirements and produces a resolution. The resolution describes the wiring that would be the result of a deployment operation based on the given requirements. In many enterprise applications you may want to pre-flight the deployment and give the user a detailed understanding of the consequences of a pending installation without actually changing the state.
With the proposed API this can be easily done for a running container, but because of the service nature it becomes more complicated when you want to use the same API in a build or provisioning environment.
In most cases, you would create a repository mimicking the deployment of the target container and several repositories from which to draw new bundles from. Using OSGi Lite, you start a OSGi framework during the build or provisioning pre-flighting that provides the OBR service together with the bundles providing the repositories for the deployment. The module layer is less relevant here. The service layer is much more intersting as it provides the exact same functionality as in a running container, making the code much more portable and the result more predicatable, e.g. by using the same resolver.
I'd have expected something labelled "OSGi light" to be the opposite: modules without services. Seems to me that this is a more basic need, given that it's being duplicated elsewhere (e.g. Maven and the Java 8 Module System)?
ReplyDelete