I read this last night, but I have seen this coming for over a year.
I normally don't write opinion pieces on my blog. But this one was special to me and I felt compelled to share my thoughts on the recent Spring Source announcement. We'll return to the normal tech-centric blog entries soon.
About this time last year, I was chatting with Rod Johnson on the phone and he said something to me that stuck: "We (SpringSource, then Interface 21) are poised to change enterprise Java more than ever before." To me, this seemed like a very bold statement coming from a man who had started a revolution that has already had a profound impact on enterprise Java. What more could be in store for us?
Then I started seeing the pieces come together: OSGi, Tomcat support, an application management suite, and perhaps dozens more pieces that I didn't associate with the "big picture". And that's not to mention several hints that Rod has given us in blog entries, interviews, and keynotes.
So, last night's announcement wasn't a surprise to me at all. In fact, I've pretty much been playing prognosticator for awhile now, predicting this new breed of application server to people I work with, meet at conferences, and exchange e-mails with. The only surprise was that it happened when it did...I was expecting a few more months before a big announcement.
I've read some of the comments on the InfoQ article and there are some interesting points made. In particular, one reader pointed out that this splinters the enterprise Java world into a "standard" JEE environment and a Spring/OSGi-enabled JEE environment--wouldn't adopters of the Spring application server be signing up for vendor lock-in?
Well, in a word, yes. Sorta. But not really. Well...maybe.
How's that for a definitive answer?
You see, along with my predictions of a Spring application server, I've also been predicting a shift in what we call "standard" JEE. I've been predicting a JEE future where applications are no longer deployed in big monolithic EAR/WAR files and instead are deployed in smaller, easier to manage, individually deployed bundles that collectively make up an application.
In my predictions, that piece-by-piece approach to development not only applies to the applications that you and I write, but also to the platform that they run on. Rather than deploy to application servers with every capability under the SUN (pardon the pun), why not size the platform appropriately to fit the needs of the applications running on it? If your application doesn't need EJB, then don't install the EJB bundle. You do need JMS? Okay...install the JMS bundle. This "right-sizing" of the application server works both ways: You don't need to have the entire JEE collection of specifications if all you're running is a servlet-based application. Likewise, if there's some capabilities that you need that go beyond the JEE specifications, then perhaps there's a bundle (or bundles) that provide what you're looking for.
Now, before I add "Soothsayer" to my business cards, I must admit that my predictions were quite easy to make. They are in line with things that Rod has been saying in his blog, in interviews, and in his Spring Experience keynote. It's also consistent with the two primary goals of Java EE 6 (JSR-316): extensibility and profiles. In short, I haven't envisioned anything that hasn't already been in the minds of Rod and several other people out there that are smarter than me.
Back to the original question: Does this splinter JEE? If you consider JEE a comprehensive suite of specifications to cover all enterprise needs, and if you think of EAR/WAR files as the end-all of deployment units, then yes...this is a departure from the JEE you've come to know and love. If this concerns you, then you are free to not use Spring's application server. Please go ahead and use whatever JEE platform suits you best.
But I say that while that model has served us well for several years, I think we can do better. And so does Spring Source.
So, while the development and deployment models of the new Spring application server are not exactly consistent with the standard JEE specs, they do represent a shift in the JEE landscape. I won't wager that Java EE 6 will follow the exact same model as the Spring application server, but I expect that it will be greatly influenced by it and that the Spring application server will ultimately be an implementation of JSR-316. (See Hibernate/JPA for a precedent case on how the JCP can be influenced by open-source.)
Put another way: The "standard" is changing.
