J2EE v .NET

10 February 2006

Choosing between these two technologies is more of a strategic question than a technological matter.

The application server is one of the cornerstones of modern distributed computing. Such is its importance that very few systems are now deployed without using the technology, which simplifies development and deployment, and enables effective re-use of components and pre-developed services.

Since the idea of an application server was first introduced by Gemstone in 1995, it has emerged as a distinct market segment, catering to every corporate requirement in one package.

But application servers come in two very distinct flavours: Microsoft's .NET and Java 2 Enterprise Edition (J2EE). That means customers face some difficult buying decisions, since the ramifications of the choice are many. Most

Key issues

The leading application server platforms, both offer similar sets of technical features.

.NET runs on Windows only but supports multiple programming languages. J2EE is available for many platforms but can be programmed only in Java.

Legal restrictions on sharing benchmark data make performance comparisons difficult.

Development for .NET is perceived as quicker and easier than for J2EE, thanks to Visual Studio .NET. But the Eclipse project may change that assessment.

J2EE preserves the option of switching vendors. There is no second source for .NET.

analysts agree that after seven years of mutual leapfrogging, both offer broadly comparable technical features. Anything useful that appears in one is soon emulated by the other.

But there are important distinctions. Microsoft believes that the Windows operating system is all anyone should ever need, so .NET runs on no other platform - but it does allow developers to mix and match programming languages, even within a single application.

J2EE is based on the opposite principle: just one language (Java), but it will run on a wide variety of platforms.

Key points when choosing are performance, pre-existing investments and skill sets, availability of tools and the preference of other software suppliers, partners and managers.

Lacking hard data about runtime characteristics (thanks to vendors' bans on publishing benchmark results) purchasers are strongly influenced by the respective software development environments. Here Microsoft holds an apparent advantage, as its Visual Studio is a feature-rich, highly automated and reasonably priced package that provides everything needed for developing with .NET.

Only recently, however, the Java community (led by IBM) has struck back with the open source Eclipse project, which threatens to outdo Visual Studio in most respects.

The bottom line is whether customers prefer to be tied to the market leader or to retain (in theory) the option of switching vendors.

Paradoxically, the .NET option - probably cheaper initially - could entail some loss of control over costs in the medium to long term. Microsoft might change its strategic direction, withdraw support for system-critical API's or compel migration to a new platform.

The J2EE vendors, on the other hand, act as a check on each other. If IBM tries to railroad its users into some scheme of which they disapprove, they can move their applications to another vendor such as BEA or Oracle.

That would be disruptive and costly, with some incompabitilities to overcome, but it underlines the strategic considerations in choosing an application server platform.