.NET and J2EE Battle for the Enterprise

Keeping track of the ongoing rivalry between Microsoft and Sun Microsystems as they seek to control the enterprise application development market can puzzle even the most dedicated developer. For the software architect, the competing "standards" can be bewildering. Yet would you believe that today's choices actually make it a relatively easier time for enterprise developers, compared to the previous generations of tools?

Microsoft and Sun share compelling visions for a new enterprise architecture, and each vision features strong interoperability through Web services and various standards.

It's certainly easier to deal with the .NET Framework and the Java 2 Platform Enterprise Edition (J2EE) now rather than handle five or ten largely incompatible visions, which is where the middleware industry was headed previously.

One of the most widely debated questions in the industry today is whether to choose Microsoft .NET or J2EE. From an enterprise architectural planning perspective, .NET and J2EE have a great deal in common and developer skills transfer nicely between them. J2EE products from vendors such as BEA, IBM, Macromedia, Oracle, and Sun have matured to the point where it's necessary for enterprise architects to place bets on either .NET or J2EE or both; the vast majority will place bets on both. For these reasons, think of .NET and J2EE as complementary, not competitive.

It's not surprising that the J2EE/.NET domain has been controversial and confusing. To begin with, both represent the culmination of decades of software evolution. For instance, Sun's J2EE 1.3 tutorial weighs in at more than 700 pages, and there are many books on J2EE and .NET that tip the scale at more than 1,300 pages. Such heft is not surprising, given that these documents attempt to address almost the entire computing spectrum, from enterprise middleware to handheld devices.

J2EE and .NET are also dynamic and fast-moving projects, each building on a large number of standards initiatives, especially for XML and Web services. As these standards are thrown together with the usual software industry marketing and propaganda, J2EE/.NET competition is so intense that it's often difficult to remember what the software market was like before they arrived. (Anyone embarking on a career in IBM's CICS or BEA's Tuxedo these days?)

Clear Up the Terminology

The inconsistent use of terminology has complicated the understanding of similarities and differences between the two models. Terms such as objects, components, and services are used in both models, for example, but often with subtly different meanings. It doesn't help that the press and industry analysts often compare specifications with product releases, and are imprecise about what's included in current releases versus what's planned for the future.

Even the scope of the competitive offerings is confusing. For example, J2EE products often include integration and portal services, while .NET is generally used as a blanket term to describe all future Microsoft software and services. Standing back from the hype and dynamic definitions, however, it's possible to discern many ways in which J2EE and .NET are converging toward a common enterprise architecture model.

At the core of an enterprise application, there's almost always a database management system (DBMS), transaction processing (TP) monitor, and message-oriented middleware (MOM) service included, such as IBM WebSphere MQ, Microsoft Message Queuing (MSMQ), or TIBCO. Indeed, in most enterprise contexts there are usually multiple instances of each, although they're increasingly morphing into platform services instead of distinct server product categories—a trend accelerated by the advent of Web application servers.

In the J2EE/.NET model, both the underlying DBMS/TP/MOM services and the business application contexts are managed at an object-oriented (OO) level of abstraction. The J2EE/.NET model brings the OO approach to mainstream enterprise computing, with powerful OO frameworks (class libraries) for services such as object persistence, transactions, Web services, and more. This model greatly extends the scope of work that can be done declaratively (with little or no procedural coding), and often includes a page/form/layout-driven drag-and-drop approach for application development.

Components are a key part of the J2EE/.NET model; think of them as collections of objects packaged and deployed together for simplicity, reusability, and flexibility. On the Java side, think "component" whenever you see "bean." .NET Enterprise Services and J2EE's Enterprise JavaBean (EJB) features are especially powerful for enterprise components, offering object and connection pooling and robust load balancing services.

UML-based tools are often used for J2EE/.NET application analysis and design, both because UML's object orientation is ideal for the J2EE/.NET implementation model and because of the expanding scope and complexity of today's enterprise endeavors. Although the approaches diverge at the coding/implementation phase, a common set of analysis and design techniques applies to both J2EE and .NET.

The use of a virtual machine (VM) architecture is also common to J2EE and .NET. Application development tools—such as Borland JBuilder, Sun Forte for Java, and Microsoft Visual Studio .NET—produce intermediate-level code instead of platform-specific binary code, which means the VM interprets that code in real time or performs Just-In-Time (JIT) compilation; the Microsoft VM always runs JIT-compiled code. This VM-based model results in platform-independent applications and is conducive to the late-binding technique that's critical to the OO approach.

J2EE and .NET share an asynchronous, loosely coupled, service-centric communication model, with application flow of control determined by messages among objects instead of sequential flow within monolithic programs. The newer model is more appropriate for the inherently object-oriented natures of J2EE and .NET, but it leads to a potentially steep learning curve for developers who are accustomed to the more traditional program-flow approach.

Finally, J2EE and .NET share a broad common foundation of standards, especially around XML and Web services. Web services are rapidly becoming the neutral zone between J2EE and .NET because they offer a self-describing, vendor- and technology-independent means of inter-application communication over the Internet. If it weren't for Web services, J2EE/.NET interoperability would be much more problematic and Internet-based communication among applications based entirely on either .NET or J2EE would be much more complex.

The multi-tiered approach typically followed for J2EE and .NET applications helps separate presentation from structure (for example, HTML at the presentation layer and XML at the business logic layer, and transaction from user interaction [see Table 1]).

Given the scope of the new enterprise model, it's important to follow an approach that supports role specialization so that all developers shouldn't feel it's necessary to understand the entire big picture (see Table 2 for J2EE/.NET perspectives by enterprise application development role types).

Here's Where They Differ

Although there's much common ground between J2EE and .NET, significant d