Spring arrives

(I have not been on this blog site for some time, but did write about Glassfish on another blog I maintain; this is my response to the latest news from Spring)….

What is Spring?

In its most basic form, it is a development paradigm, disguised as a component model. Its value proposition is 2-fold, one stated, one not: create higher developer productivity and the unstated goal of replacing EJB. Through a transformation from an open source, proprietary development framework for Java to a borrowed-source, standards-based deployment run-time for its own software, SpringSource is attempting to become a ubiquitous presence in the decision making process of enterprise IT development staff, and potentially in to the echelons of IT management. In short, no company has come as close to the heady achievements of JBoss, as has Spring and its corporate sponsors.

This is why VC’s have put money to the cause, and believe that they can achieve the sort of returns that have guided previous calculations on JBoss and MySQL. But even beyond exit strategies, Spring challenges the very foundation of Java and its corporate sponsor, Sun Microsystems with this attempt at ubiquity. For beyond the hype of JSE and JME for desktop apps and mobile devices, respectively, is the true raison d’etre in JEE, where all the Java money resides. Embracing and extending JEE is something that not even Microsoft has figured out, so it is with optimism tempered with caution that the JEE developer utilizes Spring.

Of course, for many, the question is: why caution? By decree from supporters, Spring has become a “de-facto standard”, and should thus enjoy the same support and confidence as EJB, in its role as component model for the JCP-managed JEE specification. This is debatable, in the absence of true ubiquity, and the debate has carried on web forums, and presumably within customer accounts. Caution is reserved for EJB as well as Spring in the determination of what constitutes a standard. And ultimately the determination is an academic one, for IT staffs have varying degrees of risk vis-a-vis a standard, let alone different qualifications for what makes a so-called standard important. Suffice to say, when all is said and done about “legacy” EJB and “de-facto” Spring, they are roughly on common ground when claiming standards supremacy.

What is important about being a standard of any kind comes down to a single concept: portability. This takes two forms, along the lines of the component models of EJB and Spring. For EJB, it is through the Application Verification Kit (AVK), and for Spring components, it is assured through the presence of the Spring Framework in the environment which the components run. Both have their strengths and limitations, but without exploring in much detail, and similar to the standards claims of both technologies, EJB and Spring, it is suffice to say that user beware of the portability value proposition.

In short, EJB and Spring, controlled by two very different, yet competitive entities, in Sun and SpringSource, face a future of controlled confrontation. Sure, SpringSource will sit in on Sun’s JCP efforts to standardize JEE6, but this will be at expense of unanimous support from vendors on its component model, in the form of EJB 3.1. There are a myriad of sub-factors involved in the emergence of a Spring-endorsed JEE6 specification, from profiles to modularity, but the ultimate outcome is almost assuredly going to be ongoing competition between Sun and SpringSource, between Glassfish and S2AF, and between EJB and Spring, itself. Not even JBoss is relevant enough to engage in the discussion, even with Seam.

And so it will be an incredible display of marketing and engineering in genuity to upstage the other, occassionally with the support of a complimentary vendor for EJB (in the case of JBoss), and for Spring (in the case of WebLogic, assuming its longevity within Oracle).

But ultimately this is an execution based market where the spoils are the ever-monetizable quality of enterprise developer support. Sun and SpringSource have a lot at stake, coming from different stages and both attempting to grab the mantle of counter-weight to .Net. Who will win? Will it be the improving, but tainted EJB? Or will it be the upstart, yet relatively new Spring and its cadre of vocal supporters? Ultimately, only time will tell, and any bet is as good as the opposing one, but the one agreed upon statement is that whoever or whatever bests the other, EJB or Spring, a great deal of IT money will follow. A stalemate of equal but separate marketshare is not an option.