It has been interesting to follow the recent communications made by Rod Johnson as you can transparently read SpringSource's strategy. I wanted to blog about it during the last vacations but never fully finished the entry (they were vacations after all). Some elements are outdated now (including SpringSource acquiring covalent) but here it goes just refreshed with links.
Rod Johnson has been quite aggressive against JBoss AS in the last few weeks. It did not really bother me per se but the move is interesting. While it is well known that some JBoss folks and some Interface21 folks has been having tensions in the past, it came to a surprise that Rod joins the arena. Since Rod does not attack people for emotional reasons contrary to other folks, let's try a guess what's going on.
Interface21 (now SpringSource) received VC funding last year. Don't be naive, VC do transform a company, they are seeking for quick returns on their investment. Interface21 was mainly a consulting oriented company (in term of business) around the Spring portfolio. While this is a very steady and nobel business, it cannot provide the ROI VC people want to get: SpringSource's strategy had to be adjusted, the most obvious, safe and well defined solution is to follow the JBoss Inc model: go for the support money.
Well, to sell support, you need runtime. Unfortunately for SpringSource, Spring as a framework is not appealing enough for customers to jump into the support model. I think SpringSource did some interesting partnership / support deals with the folks at IBM, BEA and possibly Oracle (something JBoss never really did well because of the direct competition), but the only reasonable way to scale up the business is to have and support your own runtime. By the way, you can see the partnership going on in Rod's blogs, his tone is very sympathetic to IBM, BEA and Sun (I will come back to Sun later on). Generally speaking, the broader your platform is, the more likely you will be able to sell support. So SpringSource needs a platform to sell and support.
Writing your own proprietary set of platform API is not so much in the air (to unquote Steve Jobs). That's why SpringSource joined the JCP and started to bless Sun and the Java EE 6 efforts, especially the profile effort. They need a mini-EE they can reach implementation-wise. If I were SpringSource, I would then try and get the smallest web-ish profile as possible out of the Java EE expert group, implement it and then raise the Java EE compliant flag to sell supports.
Side note on profiles. While everybody agrees Java EE needs some profile, I am sure nobody agrees on what to put in which profile: every application has different needs. What people really need is an ability to deploy and buy infrastructure components a la carte (whether it be one vendor or several) with the warranty of well defined API / SPI so that the whole platform keep a coherent vision freeing the customer from any integration work (component integration or programmatic model integration). Nothing a rigid profiling set can do. But that is a hard job.
Back to the main story. Even with the smallest possible Java EE profile, SpringSource is lacking some important pieces, the first one being the servlet container. And here comes the reason why Rod has been trying to not so subtly sent the message that JBoss AS is crap (I summarize here) and Tomcat is great. The only obvious choice for SpringSource is Tomcat. They need to enter the platform/runtime by the low end and gain market share (as in support market share). I would not be surprised if SpringSource announce a fully supported platform effort based on Tomcat and Spring at it's core. Of course, they need to hire some of the key contributors of Tomcat to gain some credibility. Let's imagine this done, the first competition they think they will face is JBoss AS, so seeing Rod poopooing on JBoss AS and EJB 3 is not a surprise. The first competition they will face though is people that do not want support for Tomcat: JBoss has been offering Tomcat support for a long time but not surprisingly monetizing Tomcat never succeeded. Most applications deployed on Tomcat do not want need (of course exceptions apply). Maybe Tomcat + Spring will be the silver bullet but I seriously doubt it for a bunch of reasons. The second biggest competition will probably be their own ecosystem. When you start to compete with them, your partners tend to be pissed, that's life. Ask Larry about that.
By the way, Rod does not seem to know that JBoss uses an enhanced version of Tomcat as a web container named JBoss Web. Remy (Tomcat) and Mladen (Apache httpd) sat down and wrote a native integration between Tomcat and APR to make this server the best of both Tomcat and Apache httpd. Maybe he wants to check it out and fork it :) Oh, one more thing, anybody that has been charged by an elephant tend to smile at the cat vs elephant analogy.
Tomcat + Spring will still be a weak platform, SpringSource will have to beef it up with some additional components:
- a persistence framework (and no Spring is not a persistence framework :) )
- a transaction manager
- a messaging system
- maybe some webservices thingy stuffs
and a few more components. They probably will also have to announce a developer tooling strategy around that. I will only comment on the persistence piece of their platform as I know the field quite well. They can technically chose between Hibernate, OpenJPA, and Toplink. Hibernate would be the smartest move for them and the most aligned with their customer base but this probably will be a tough call for Rod. The two alternative strategie are Toplink (aka EclipseLink) and OpenJPA. If I were them, I guess I would go for OpenJPA as a second choice but they will have to invest R&D in the pieces that differenciate OpenJPA from Kodo.
Rod, please be more open with your strategy. I always liked Marc Fleury's own way to tell everyone what strategy he was following and what will be the next moves. To everyone, including the competition :)
Good luck anyway, I am eager to have competition in this field as I think JBoss AS, Seam, Web Beans and the technologies around them (JPA, EJB 3, JSF and so on) are more appealing to the next leap forward.
Usual disclamer, this represents my own thoughts not necessarily my current, past, future, potential employer, etc etc.
Very well put Emmanuel. I thought Rod's blog (today's post?) was very interesting how he pretty much trashed the whole EJB technolgy, while at the same time they're talking about how great JEE6 is.
I just wish the frontrunners of the Java Enterprise industry could sit together to solve the actual problems of the platform and stop playing this Spring vs JBoss vs xyz vs abc vs whatever game.
I am so sick and tired of it.
Sakuraba, Generally speaking, competition is good and benefits you as a user.
To reply more precisely to your comment, JBoss has always been commited to fix the platform. It is fair to say that we contributed a lot to Java EE 5 amongst other companies. We specifically worked a lot on JPA and EJB 3.
On the Java EE 6 side, we are still working in the JCP with other vendors incljuding JPA 2 and EJB 3.1. We also go beyond and try to improve the platform (or fix it depending on who you talk to ;) ). Web Bean is a good example, Bean validation is another one.
Comparison between different technologies are inevitable, though this was not at all the goal of my blog entry: just a mere analysis of the SpringSource strategy.
Hi René. I am very sorry, I removed your comment by mistake :( I managed to recover the content and quote it.
To answer your question, I am not sure I will make it for JAX this year unfortunately. But I might do Jazoon in Zurich.
Great aricle! and thanks for not making it too personal as most writers recently do... it's all business, isn't it?
regarding JEE6's profiles: hasn't JBoss's architecture been based around the concept of profiles from earliest versions? the entire JMX backbone is a profile enabler, and what was coined in JBoss terminology as configuration(namely, minimal, default, all) isn't anything else than a profile. Whather it is an inherent part of the technology or due to JBoss's implementation, I found that assembling configurations/profiles yourself can be a real hassle, mainly due to what seems to be implicit or unreported dependencies between MBeans/services. That's why I usually use a predefined jboss-web configuration for those of my consultees that need lightweught web container with transaction support. I don't think the requirements vary that much, to render the profile initiative meaningless. All this said, SpringSource may be praising the latter due to their own agenda, but that shouldn't count for the technology consumer.
Secondly, regarding SpringSource's recent monetization effort: Spring was a de-facto integration framework from the beginning, not a platform. And a great one, if I may say so, introducing IoC to many developers, abstracting underlying technologies(although I remember you resenting to it in the past on the account of technology semantics), and AOP tricks. Turning Spring into a platform will, in my opinion, diminish it's power. Too bad it's the only way envisioned by SpringSource to .
Trying to answer René's question regarding Spring's JSF efforts: I have to disagree. While MyFaces is reasonable enough for most companies, it still lacks advanced features/components, such as the ones introduced by JBoss's RichFaces, which, unfortunately, tends to introduce quite a few bugs per feature, hence the constantly-releasing versions. The guys developing these components chould really something from Spring development team... As you say, Cashing an Open Source company has it's toll.
thanks again for the enlightening reading, Zvika/
Hi Emmanuel,
I am sure nobody agrees on what to put in which profileIt's not like there's going to be a lot of them. AFAIK only a Web Profile is in the works.
Nothing a rigid profiling set can do.isn't that why is the other main theme for EE 6?
Hi Zvika and Alexis,
Yes, JBoss AS has had an modularized architecture for a long time and it's getting even better with the new Micro Container. But profile is a rigid version of a modularized system.
Let's try and define a web profile. It's a servlet container and:
So web profile could mean the bare minimum to display a web page and let everyone build it's own custom stack (and work in its integration). Or it could mean a profile that allows you to write Web Applications out of the box in a well defined manner (which I value more). In the latter case I would include all the elements in the previous list.
My hope agrees with you Alexis, I want JavaEE to have a well defined set of extensibility points, this would address my concerns on the moving target profiles. But as I said, this is, by far, not an easy task :)
:-)
http://www.infoq.com/news/2008/04/springsource-app-platform