Columns

.NET & Beyond: J2EE split ending war with .NET

• By David Chappell
• August 1, 2004

The big story in app development for the past few years has been the competition between Microsoft’s .NET Framework and products that support the J2EE specs. Lots of people have talked about it, and many development organizations have been faced with this issue. To a large extent, the .NET vs. J2EE struggle has defined the recent app development landscape.

This won’t be true much longer. I’m not suggesting that the technologies will merge, or that Microsoft will see the J2EE light, or anything else so drastic. Rather, the competition will end because the importance of J2EE as a coherent spec is rapidly winding down. The competition will become a three-way battle between Microsoft, IBM and BEA.

The J2EE specs have played an important role in the app development world. By creating a common technology platform to rally around, they helped Microsoft’s competitors present a united front. The largely proprietary efforts that preceded the emergence of J2EE, like IBM’s Component Broker and BEA’s M3, were quickly cast aside once the common J2EE flag was raised. These must have been difficult decisions for these vendors to make, but they were correct. Without J2EE’s unified assault on Redmond, it’s likely Microsoft’s market share in this area would be much greater than it is.

For IBM and BEA, the usefulness of J2EE is largely over. I’m not saying that they will stop supporting current J2EE standards. Rather, what’s likely to occur is that significant future enhancements in the only J2EE-based products that matter today -- IBM’s WebSphere and BEA’s WebLogic -- won’t be done through the process that created the current J2EE specs. These two vendors no longer have much use for a cumbersome multivendor process to produce official J2EE specs, especially one controlled by Sun. It makes much more sense for IBM and BEA to differentiate their products in proprietary ways, locking customers more into their platforms. The biggest impact of creating more official J2EE standards would be to help the open-source community in its efforts to create free equivalents of WebSphere and WebLogic, something I can’t believe either IBM or BEA wants to encourage.

In cases when it makes sense for the two dominant Java platform vendors to work together, they can produce ad hoc agreements. The BPELJ spec published earlier this year is a good example. The Business Process Execution Language (BPEL) -- defined by Microsoft, IBM and others -- defines an XML-based approach to defining Web services interactions between business processes. BPEL doesn’t define the details of implementing these interactions, so BPELJ fills in these holes in a Java-specific way. This is useful for IBM and BEA, since customers who can be induced to define BPEL processes in a Java-specific way will find that running them on .NET is less attractive. Yet rather than going through the formal spec process, IBM and BEA published a spec they’d written behind closed doors. While BPELJ has been submitted to the official Java process, what ultimately matters is what IBM and BEA choose to implement.

Here’s the fundamental truth: Given a choice between having customers profitably locked into a proprietary product or having them use a standards-based product, a rational software vendor will pick the proprietary product every time. Users tend to prefer option 2, so they’d probably rather see J2EE continue to be the route through which the Java platform advances. But now that the real competition among J2EE vendors is over, the two surviving vendors are in the driver’s seat. They’ll still be battling .NET, but they’ll be doing it with products that increasingly differ from one another rather than toe a standard J2EE line. Their customers might not like this, but their shareholders certainly will.