When I first started writing this column more than a decade ago, my attention was focused on the teeming segment of enterprise Java technologies. Two areas in particular were hubs of competitive activity: J2EE servers and JMS providers. Different vendors’ products jockeyed for the market lead or to become the technological pacesetter. It was a great part of the market to cover, and the innovation it produced was fun to report on.
The market settled down due to two main factors: BEA’s WebLogic server was faster, better and more innovative than competitors. These advantages cemented BEA’s market lead, and the drama among commercial offerings steadily evaporated from competitors (Sun, Allaire/Macromedia, SilverStream, Novell, Pramati and others). In the free space, JBoss became the de facto implementation.
During this period, JMS vendors became largely irrelevant. The messaging bus was overtaken by ESBs, which sort of lost their way when Web services and (later) REST came to the fore. No longer were performance details that distinguished Fiorano from, say, BEA’s built-in messaging layer of much interest to anyone. Today, sites generally use the JMS implementation that comes with their Java server—and it takes care of most needs.
As the market resolution was working out, our then-Java columnist, Allen Holub, frequently pointed out that the resulting solutions were, with few exceptions, overkill. He claimed (and I believe rightly so) that the vast majority of sites using J2EE servers would be better served with an instance of Tomcat driving the app and plain old JDBC doing the bulk of back-end I/O.
For most of the intervening decade, the quest for a lighter way to do enterprise Java has been widely discussed, but without great enthusiasm. Some progress was made, though. The success of Rod Johnson’s Spring project was one step in this path. But because Spring is an omnibus solution that rides on the entire Java EE stack, it does not reduce the complexity so much as mask it. The Groovy-based Grails server does the same thing to Spring: It’s an even higher layer that comprises both Spring and Java EE.
With Java EE 6, we’ve seen more of a definite mainstream effort to reduce system complexity. Unfortunately, except for the open-source GlassFish project, there are no major Java EE 6 implementations. Even WebLogic, a server whose reputation was built on its early and eager adoption of new standards, still runs Java EE 5 only. IBM WebSphere—always a late adopter of standards—is also on EE 5. Only JBoss seems to have responded to GlassFish’s gauntlet. And by the time this column sees print, the Java EE 6 JBoss AS server should be out of beta.
The lack of enthusiasm for this new generation of servers is striking and indicative of a ground-shift in enterprise Java, first mentioned by Alex Handy: Java EE is no longer the future of enterprise Java.
The proliferation of Java Web frameworks suggest that developers are indeed identifying and building the functionality they want while letting the official version of Java do its own thing. This approach was no doubt given a shot in the arm by the success of Ruby on Rails, which demonstrated convincingly how simple it could be to assemble Web apps from components designed for integration (even if they are primarily not at enterprise scale).
However, my view is that if enterprise Java is going to segue to anywhere, it won’t be toward another framework—whether Spring, Grails or any of the third-party products. Rather, I believe the change will be driven by the needs of the cloud; that is, the need for small-footprint solutions that can be replicated in numerous instances and wired together to provide the core enterprise services.
VMware, which views itself as the driver of cloud technologies, is seeing things the same way. It purchased SpringSource (the company behind Spring) and has been figuring out how to leverage it in the cloud. At the moment, though, its focus is on a series of integrated products called vFabric, which includes a commercial version of Tomcat, a messaging layer from RabbitMQ, the GemFire database, a load-balancing product, and Hyperic’s system management product.
For this approach to truly scale, there must be a data fabric that can make data items consistently available to all nodes at all times—an equivalent to Oracle’s Coherence product. For vFabric, that functionality is provided primarily by GemFire and (to a lesser extent) by RabbitMQ.
As these technologies are mixed and matched to scale up apps, this highly distributed way of computing is likely to replace the monolithic approach of Java EE that Sun/Oracle and JBoss have now pushed for a decade.
Andrew Binstock is the principal analyst at Pacific Data Works. Read his blog at binstock.blogspot.com.
