Picking a Winner: .NET vs. J2EE

Although both frameworks stand on a foundation of programming languages, object models and virtual machines, they are strikingly different when you consider the design goals of their runtime environment.

The Java 2 Enterprise Edition (J2EE) framework has captured significant mindshare among online application developers and their organizations, as a powerful, portable and widely-supported application development environment. Microsoft's announcement of .NET (dot-NET) has captured the attention of just as many, since it represents the future direction of all things Microsoft, from desktop applications like Microsoft Office to development tools like Visual Studio to back-end servers like SQL Server, and everything in between.

Opinions on the ultimate outcome of this framework competition range far and wide—zealots on either side of the "demilitarized zone" claim emphatically that either Sun and J2EE or Microsoft are doomed to fail. Some of the more balanced analysts predict a near-term stalemate, with J2EE and dot-NET eventually claiming a roughly equal share of the application development market. This prediction seems the most sensible, given the two forces facing off—J2EE with a significant amount of development inertia and a broad array of tool and application vendors behind it, and dot-NET with the marketing influence of Microsoft fueling its spread.

Regardless of the long-term result, it seems unavoidable that technology managers, strategists and software developers will have to contend with both of these frameworks for some time to come, and I've tried to provide some guidance to the development community around this "framework divide." Whether you're part of an organization committed to either J2EE or Microsoft platforms, trying to assess the costs and benefits of sticking with your current framework, jumping to the other or attempting to support both; or if you're an organization about to venture into a development effort and attempting to pick the most suitable path, I've attempted to lay out the two frameworks as clearly and unambiguously as possible.

(Half-)Sisters Under the Skin
It's important to acknowledge that despite what the best marketing minds at Sun and Microsoft might lead you to believe, dot-Net and J2EE are surprisingly similar from a pragmatic standpoint. Both offer a server- and client-side component model for assembling enterprise applications, APIs that allow you to create both fat and thin user interfaces for these applications, and specifications and corresponding APIs that allow you to access critical services such as transactional data sources, directory services and remote objects.

At a lower level, the two frameworks are both based on a virtual machine architecture aimed at portability (though the type of portability each strives for is a critical difference between the two). Also, J2EE and dot-NET are comparable in some areas in terms of feature support and architecture.

Don't Know Beans?
When J2EE was introduced by Sun, it subsumed, to a large degree, the JavaBean and Enterprise JavaBean component models. JavaBeans are the meat-and-potatoes Java components, with well-defined properties, event-handling provisions, persistence through Java serialization and introspection, in addition to all of the basic services provided by the Java runtime environment, like memory management, "sandbox" security and the core Java APIs. Enterprise JavaBeans are the distributed equivalent: remotely-accessible components that operate within an environment that provides application security, distributed transaction support, richer persistence management facilities, life cycle management and resource pooling.

The dot-NET framework, meanwhile, subsumes Microsoft's workhorse COM and COM+ component models. These component models are replaced, in a sense, by the n