|
|
 Number 17 October 2006 |
|
|
|
 |
What's Next? Life After J2EE |
 |
|
In the second half of the last decade, IBM did something remarkable. It decided to shelve its own efforts to create a next-generation application environment and instead back Sun’s nascent Java platform. BEA made the same decision, ending work on its proprietary approach and focusing instead on the Java technology acquired when it bought WebLogic. Other vendors followed suit, and by the end of the decade, J2EE had become a successful, widely supported, and widely used platform for enterprise applications. To give up control of their own destiny, trusting Sun to lead the industry in the right direction, was a remarkable step for these vendors. I admire the people who had the foresight and the courage to take that leap of faith. And it was clearly the right choice. If each of these companies had maintained its own single-vendor environment, the chances of them all being crushed by Microsoft would have been much higher. Instead, a unified J2EE wave surged into most large enterprises, providing the platform for a new generation of applications. But this unity is over. It was never reasonable to expect powerful vendors like IBM and BEA to remain Sun’s vassals, especially now that their J2EE market share vastly exceeds that of their putative lord. Combine this with Sun’s reluctance to give up control, and the result should surprise no one: the Sun-led J2EE alliance is at an end. The interesting question, then, is this: what comes next? What will succeed J2EE as the dominant platform for Java developers? The Three Branches
As the figure above shows, there are three approaches that are defining potential successor technologies to J2EE 1.4, the version currently implemented in leading products. They are:
While the processes used in these three approaches are quite distinct, the same players often participate in all of them. IBM, for instance, remains involved in the JCP, is a leader in Open SOA, and was the progenitor of Eclipse. Similarly, the platforms defined by the three aren’t mutually exclusive. The Open SOA approach still relies on Java Servlets and JavaServer Pages (JSP), for example, even though SDO and SCA largely replace JDBC, EJB, JAX-WS, and other parts of JEE5. Also, the open source world is both a source of new technologies, such as Spring, and an approach to implementing technologies defined in one of the other processes, as illustrated by the JBoss implementation of J2EE or the forthcoming Tuscany implementation of SCA and SDO. Despite these overlaps, the key point is that there’s no longer one unified process led by one organization that defines the primary alternative to Microsoft’s .NET Framework. Today’s J2EE world is fragmenting. The Future of the Java Platform A more likely outcome is that today’s dominant J2EE enterprise vendors—IBM, BEA, and the rest of the Open SOA alliance—will transition their customers to the new world they’re creating. If this happens, the core server technologies of this new platform will be Java Servlets and JSP for browser access, SDO for data access, and SCA for creating and connecting business logic. Yet these vendors have been reluctant to state clearly what the new platform will be. Rather than deprecating EJB 3.0 and the other aspects of JEE5 that don’t fit into the Open SOA world, they’ve chosen to present SCA and SDO as just more options for developers to use. Meanwhile, Microsoft is about to release version 3.0 of the .NET Framework. A straightforward extension to version 2.0, this next version also includes new technologies, such as Windows Communication Foundation (WCF). Unlike its competitors, however, Microsoft has been clear about the future for Windows developers, stating unequivocally that they should move away from the technologies that WCF supplants. As usual, Microsoft doesn’t need to worry about the inter-vendor politics that are perhaps inhibiting the Open SOA vendors from making their goals clear. Leaving Sun in control of the Java platform no longer makes any sense, and I sympathize with the attempts of IBM, BEA, and the other J2EE vendors to regain control over their destiny. Yet the .NET Framework has been gaining on J2EE in enterprises, and Microsoft has defined a clear path ahead for developers and decision makers. If the organizations behind its competition don’t reach consensus quickly on a single platform for Java developers, expect the enterprise popularity of .NET (and of Windows) to increase even faster. Today’s J2EE vendors banded together almost a decade ago to make common cause against Microsoft. In the years since then, Microsoft has become an even stronger competitor. Allowing the J2EE platform to be succeeded by several different solutions would be bad for J2EE vendors and bad for their customers. And in the end, it would even be bad for Microsoft—everybody needs competition.
|
|
||
 |
David Chappell is Principal of Chappell & Associates (www.davidchappell.com) in San Francisco, California. Through his speaking, writing, and consulting, he helps information technology professionals understand, use, and make better decisions about enterprise software. David has been the keynote speaker for conferences in the U.S., Europe, Asia, and Latin America, and he’s also delivered keynotes at many in-house events. His popular seminars have been attended by tens of thousands of developers, architects, and decision makers in forty countries, and his books on enterprise software technologies have been published in ten languages. In his consulting practice, David has helped clients such as Hewlett-Packard, IBM, Microsoft, Stanford University, and Target Corporation adopt new technologies, market new products, train their sales staffs, and create business plans.
|
© Copyright 2006
David Chappell and Associates
|
|
||||
|
