JBoss and SpringSource

how-to
Jan 22, 20105 mins

Both are owned by corporate parents that have large market shares in their respective product categories: Linux servers for Red Hat, and corporate data center virtualization for VMWare, respectively, which allows the two subsidiaries of the parents to exert some sort of free-wheeling and experimentation with messaging, such as JBoss’ new non-Java EE push through other languages, and SpringSource’s anti-Java EE push through their own language, of sorts….but make no mistake about the competition, it boils down to a heavily intensive fight for the mindshare of Java developers worldwide, with the eventual victor controlling what is left of the corporate IT spend that does not go to Microsoft, IBM, and Oracle…this is major terrain for the once-small start-ups to undertake…. JBoss appears to have the lead, since they held the initiative for so long, as the only open source application server vendor, that bled BEA Systems to death, and in to the arms of Oracle, all while advancing its reputation and influence within the Java community, via the JCP standardization process….but SpringSource has fought admirably, although their tactics have been suspect, in terms of deriding enterprise Java, basically on the whole, even as they adopt some of the specifications that comprise it….i find their most recent anti-application server vendor strategy around suggesting that OSGi is not ready for the enterprise to be interesting, to say the least, as Glassfish and JBoss played catch-up to delivering a micro-kernel architecture, right at the moment that they finally caught up, Spring Source pulled the rug out from underneath Glassfish, and JBoss, in particular, by saying that they are no longer interested in their customers deploying through OSGi, leaving fear, uncertainly and doubt in the minds of developers and particularly IT managers, over whether OSGi is in fact a “risky” proposition to deploy to…. JBoss has been successful with its version 5 release to coincide with JEE 5, even though it came more than a year after the specification was released, it was in keeping with its parent company’s reputation of only putting out supported products that have been battle-tested and offering assurances that there would be no surprises in developing with and deploying to a Red Hat product, JBoss included….and they will do the same with JEE 6, allowing Glassfish to attract the bulk of the early adopter users, that have little influence in the decision-making process of corporate IT spend, all while developing iterations of JEE 6 to keep their foot in the game….enterprise Java needs JBoss, but JBoss is giving the message that they can manage without the latest and greatest enterprise Java for the time-being…. Spring Source is different, altogether, basically wrapping enterprise Java with proprietary extensions that they claim offer greater productivity for developers with higher assurances of reliability for IT managers, they did not even participate in the JEE 6 discussion, choosing to make their apathy to enterprise Java felt most strongly through a policy of not even voting their vote within the JCP….in one respect this is baffling, though when you are running a political operation of mindshare battles, it is not surprising, as Spring source essentially has nothing to gain from the ongoing development of a community standard that truly only benefits JBoss and perhaps Glassfish, with the latter’s future still in question, considering the Oracle Fusion investment….Spring Source is better off with a fragmented community, as they are best-of-breed, apparently…. What comes next is anything but detente, as JBoss and Spring Source battle over everything from XML to integration to tools to eventually virtualization, itself….its a healthy competition, and i think the lasting impact of the EJB 2x debate is finally wearing off, as Spring Source cant say EJB is dead, as v. 3 makes clear, and EJB 3.1 takes even further with CDI, but dont count SpringSource out quite yet….this OSGi argument strikes a blow to Glassfish as they spent the past two years getting organized for it, and Spring Source is spreading successful FUD that it is not the right approach…JBoss will have to respond with assurances in v. 6 that it is enterprise ready, and can be trusted on Red Hat deployments, as VMWare certainly will carry Spring Source deep in to Linux accounts, it is going to be good…. Oracle will have to clear-up what they intend to do with Glassfish, as a stand-alone product-line, that is truly not in line with Fusion or ERP apps, and JBoss will have to respond with more than just JEE 6 marketing, and their tried-and-true open source heritage, they will have to become more of an enterprise vendor, and that may mean selling out to IBM’s Global Services to get the coverage to go deeper in to accounts, as i have said….but this competition has clearly been healthy for enterprise Java, even if Spring Source turns their nose at the community…its JBoss’ move with v. 6, and Spring Source will be waiting to play the antagonist of all the little holes that may add-up to a barrier to entry for JBoss in to the core of the enterprise accounts at Red Hat…. Only time will tell, but i think that this battle only makes things better for developers, more choices rather than .Net, and more innovation around Java, it will be a tough test for JBoss, but one that they can handle if execution is flawless, otherwise, look for Spring Source to drive a wedge between perceived and real advantages of JEE 6…sooner, rather than later, portability of applications will have to be demonstrated in order to counter the proprietary models, and that has not happened, Java Verified, notwithstanding….components on-the-fly, inter-operable between Glassfish and JBoss is the only way JEE 6 stares down the long-term threat that is Spring Source…