J2EE vs. .Net: Dilemma or nondebate?

feature
Feb 22, 20023 mins

Choosing a platform on which to standardize your Web services-based architecture may appear fraught with uncertainty. When comparing Sun J2EE (Java 2 Enterprise Edition) with Microsoft .Net, making a clear-cut distinction through the whirl of marketing spin is a challenge. Despite general similarities between the two platforms, when evaluating the pros and cons that could give one the edge over the other, it’s clear that neither — in the grand scheme of Web services — has proven its worth.

Microsoft has had the distinct advantage of architecting .Net from the ground up, weaving Web services natively into all aspects of the architecture. Sun, by comparison, has had to retrofit APIs onto J2EE in order to facilitate capabilities for XML-based processing and communications. The open standards, committee-based process for developing these add-ons has imposed considerable delay, as well as given Microsoft a jump-start in developing XML processing and a formidable IDE (integrated development environment) coming to bear in Visual Studio. Microsoft’s solutions are on par with those from Java proponents such as BEA Systems or IBM, whose WebSphere is demonstrating its own strengths in XML.

J2EE brings to Sun’s solutions important platform strengths, such as portability, strong enterprise connectors, and inherent transactional state management. Also, J2EE isn’t encumbered by the training requirements imposed by the .Net redesign; because .Net introduces new concepts to the Microsoft platform, developers must build their skills with new tools and concepts, including Common Language Runtime and the C# language.

Ultimately, the primary differentiators between the two — Java’s platform independence and vendor flexibility vs. Microsoft’s performance benefits and ease of use — will likely persist. And take with a grain of salt the debates currently waging between both camps, extolling the virtues of code size and throughput metrics won by each solution.

The final choice for deployment in any enterprise scenario will rest on issues such as existing architectures and in-house skill sets. But with Web services, CTOs won’t have to deliberate so meticulously over the synergy between new technology deployments and partners and vendors in any long-term technical strategy; the new technology will offer enough flexibility to mitigate many concerns.

The requirements for Web services, however, will remain much the same as with any traditional enterprise platform — reliability, scalability, and availability — but with the bonus of being easier to implement than traditional integration, regardless of the platform on which you standardize.