I have heared a lot of people talking about Google I/O as the next Java One. The fears about what is going to happen to the #1 Java conference run by Oracle are big. It seems as if Google could provide a valid alternative with I/O. Unfortunatualy I was not able to attend it but of corse I listened carefully to whats happening there. And believe it or not, I think it's worth talking about it. Ok: Not realy as a replacement for J1 but about Google's and Spring's capabilities to provide a growing platform for a different kind of enterprise Java programming model.
This all started with the aquisition by VMware what made a smaller company able to move faster than ever before. Followed by the first major partnership with salesforce.com. What is called VMforce should be the first step to become something like a PaaS standard.
Our [VMware and Google] shared vision is to make it easy to build, run, and manage applications for the cloud, and to do so in a way that makes the applications portable across clouds. The rich applications should be able to run in an enterprise's private cloud, on Google's AppEngine, or on other public clouds committed to similar openness.
(Source: Steve Herrod, Chief Technology Officer)
Spring and everything around it is heading for the could. Literally with the speed of light. It only takes few weeks between new announcements around this topic. At the end of the day, Spring, VMWare and Google are providing a cloud based deployment platform for Spring based Java applications. That sounds modern, fast, easy and is potentially very interesting. It may provide the easiest, no-comprise way to publish Java applications. If you look at other cloud alternatives they are either more restrictive for the developers ("old" Google AppEngine) or provide services at an infrastructure level like Amazon's EC2.
But: Spring and VMware are going to build their own Java universe where they dictate momentum, their 'standards' and more and more the commercial consequences as well. From an Enterprise Java point of view it's simpler. Too many things are called "Spring". And this makes it easy on the first look. You don't have to talk about 30 something specifications but about one big framework. And while Spring and Rod Johnson in particular have been extremely valuable in influencing the direction of Java (2)EE after the 1.4 release to the new, much more pragmatic world of Java EE 5, Spring has also caused polarization and fragmentation. Instead of helping forge the Java community together, it has sought to advanced its own cause. Which is perfectly valid - but should be recognized for what it is. Spring is not necessarily open, is not free, is not a community or even multi-vendor effort. Lock in with Spring is just another type of vendor-lockin. And that is, why it will never be a replacement for Java EE.
But there is another takeaway for the Java community and the owner of Java. The hype around innovative and integrated solutions is a proof for the Java EE universe moving too slowly along. Bring in more flexibility. Have more courage with changes. Find a way to adopt trends faster and support better modularity.
Links and readings
Springing Ahead Toward The Open PaaS
VMware to Collaborate with Google on Cloud Computing
Google and VMware's "Open PaaS" Strategy
SpringSource Tool Suite with Google Integration Download
Enabling Cloud Portability with Google App Engine for Business and VMware
(Written with the help of some thoughts of fellow ACE Director Lucas Jellema (@lucasjellema). Thanks!)
I agree with you totally about recognizing Spring's moves just for what they are.
ReplyDeleteAbout advancing Java EE, Java EE 6 is the first version to feature a comprehensive SPI for extending the platform. Such extensions can be made by everyone, vendors, teams inside companies or individual programmers. Such extensions are completely portable. In effect, this gives the community the power to build their own Java EE 7.
I built a distributed app on JEE 2.1 and later on incorporated Spring to improve unit testing of EJBs. This was a vertical industry app running behind firewall that did a lot of automation and event interaction - heavily JMS MDB as well as mbean-based custom services. This architecture is still going strong and has since migrated to EJB3.
ReplyDeleteI moved on to architect an app that, though, Flex UI based for forms, adheres to HTTP (AJAX-style and HTTP streaming for notifications). This used a stack of Tomcat/Spring/iBATIS. Very positive experience with this stack.
Am now back to drive architecture of an app that is again behind the firewall, highly distributed, and event-oriented. Going back to JEE for this one.
Spring is great for the lean and mean web app stack, but JEE in its modern incarnation is better for vertical industrial applications where a web page is just a minor side show for the occasional admin or JMX console.
I say this after seven years experience architecting and building multiple applications on both stacks in these different venues. Both stacks have their strengths, but I tend to see them excelling in different application spaces.
"Architecture is frozen music" - didn't Goethe say that? ;)
ReplyDeleteNice article BTW.
I think Oracle needs to quickly come up with a easy way to put Java EE in the clouds. Both Google App Engine (java) and VmForce are going to offer Spring in the clouds.
ReplyDeletegood article...
ReplyDeletecan you elaborate on this statement?
"Spring is not necessarily open, is not free, is not a community or even multi-vendor effort. Lock in with Spring is just another type of vendor-lockin."