So, Spring Source has been able to keep a secret from us Secretly, they have been developing what looks a lot like a new application server, not like the JEE market, but with the springframework at its core. A well kept secret, which I did not see coming, even though we might have been able to, given the portfolio of products and people now employed at Spring Source.
And what are we to say to that? Me, personally, I welcome it. Yeah yeah, it is a non-standard, proprietary way to go, when compared to JEE servers. But, I am already utilizing the springframework as my main engine and have long time gone the POJO ORM way. All this way before JEE5 and JPA. And I like it. I have even ditched using JEE5 EJBs on new products, because I find the spring model superior in many ways.
And about it being proprietary. The platform is GPLv3 licensed, which I really like. In my eyes, the GPL license model is good for exactly this kind of product. It ensures openness, also when utilized by others, which adds or enhances it. We will have to give our contributions back! And that is good, for something that acts as a platform. Just like the Linux kernel, actually.
What Is It?
At a first glance, it looked to me as a lot like a server like the JBoss micro kernel architecture, which could (can) be tailored to only run the exact parts of JEE, that your application needs. No need to start JMS servers and EJB containers, if you ain’t gonna need it. I never got to like JBoss, though.
At a second glance, this is actually just a minor part of the Spring Source Application Platform (as I see the benefits to me). They are using OSGi (through a Spring Dynamic Modules kernel), to control their “services when needed” in the server, but they are also using it (OSGi) as the technology for deployment units for the applications running on it. Our applications! And that is where I see some benefits for me, as an application developer.
What Is the OSGi Part All About?
SpringSource consider war-deployment as not good enough and suggests the use of OSGi as deployment modules instead. I agree, that this might be a good choice, I just hope it will be simple enough to use. I do not agree totally, on the points of Rod Johnson here, where he states this about war deployment:
…the great deal of duplication going on with web.xml files, Spring configuration file, and so on. Also, the Java EE web-inf folder is unversioned and messy. It has problems with dependencies and potential duplications…
The war deployment unit (web.xml) is nice and simple. I for one, don’t mind putting the configuration data in there. Actually, I recently saw, that the expert group on the next servlet spec are working on features to make this easier. They are talking about auto-discovery of configuration data from web frameworks, so the need to edit web.xml becomes minor or vanishes.
What I like about the OSGi way of deployment, is the tight control on dependencies, that your can utilize. One example is how you tightly control which packages, a given (deployed) component, exports to other deployed components. I hope to see this solve the jar dependencies hell. Something that upcoming Java versions, JSR-294 and JSR-277 is also seeking to solve, albeit with a far too long time frame. OSGi is here today and works.
What’s more is, that OSGi is not only used to implement the micro kernel in the Spring DM kernel, but is also exposed to us developers, to use when deploying. I have recently battled an issue with hibernate using cglib and an old asm library, while at the same time needing CXF 2.1 which in turn needs asm lib 2.x. The problem was, that the two asm lib versions where binary incompatible. This can be solved elegantly with OSGi, by deploying each part of the application as separately packages groups, and not exposing the asm libs from these modules. Each group can then have their own asm library jar. Something which we, today, are trying to solve by re-packaging libraries under other package names, using tools like JarJar Links.
So, what does working with Spring Source Application Platform actually mean to us developers then, in our daily work?
Well, I like the idea of a spring-powered environment, where the need for configuration is far less. I hope it will be as easy as it is to start with EJB3, but with the power to extend with all the extra “magic”. I think JEE5 has had one good thing going for it, and that is it being easier to get started with. No need to know about and correctly configure the spring bean context.
The Need for OSGi Bundles
The libraries that our application depends upon, such as hibernate, spring, commons, etc., must be available as an OSGi bundle or library. This is the way of expressing dependencies in SpringSource Application Platform. What did we do before? Well, most of us just expressed our dependencies in the maven POM and let it (maven) download the proper jars from a maven repository. The maven repository has grown up to be very important, hence just about all java libraries are published in it. But not as OSGi bundles.
To address the need for OSGi packaged versions of libraries , SpringSource has made available their own repository of OSGi bundles here. Naturally, this repository is only a fraction of what is in the maven repository, and this will be a nuisance in the beginning. Frankly, I can only see that nuisance going away, if the SpringSource Application Platform becomes world popular, as they (SpringSource) will need community contributions from framework/lib developers themselves, to keep up with the steady flow of new versions.
Maybe the maven repository should be extended, to include such bundles. It seems to be the packaging of tomorrow. Not just because of OSGi becoming more and more popular and the Spring Source Application Platform, but also because of the upcoming work on modularity in the Java platform.
I do not know, if it is stuff like SpringSource Application Platform, that is pushing JSR-294 and JSR-277 to “merge”. It is a fact, that the springframework, together with powerfull POJO ORM frameworks, have threatened the JEE world heavily the last couple of years. Sun has had work on modularity going on for quite some time now (in JSR-294 and JSR-277), but it has also received a lot of heat. Mostly for not leaning to just accept the existing de-facto standard, OSGi, and go with that. Well, it seems they (Sun) might be shaping up. Stanley Ho, spec lead of JSR-277, announces that Alex Buckley (the spec lead on the other JSR on modularity, JSR-294) will join JSR-277 and bring the language level module specs into that JSR group.
All good stuff.