Understanding J2EE and .NET
With the pending release of the .NET Framework and Visual Studio.NET (now in beta 2), both Microsoft and its competitors providing products built on the Java 2 Enterprise Edition (J2EE) specification are ramping up their respective PR machines. As information technology professionals, it is important to understand at least at a high level how these two technologies and products compare. In this article, I'm primarily going to describe where the points of similarity are so that those working in either technology will be able to construct a mental map to get from one to the other and begin to become conversant in the technologies. At the same time, I'll point out some of the differences in terms of strategy, complexity, feature set, and product maturity.
From the J2EE perspective, I'll concentrate primarily on IBM WebSphere 4.0 because WebSphere appears to be gaining mind share (IBM recently topped BEA, 47% to 22%, as the preferred Web software in a survey of 150 CIOs done by Morgan Stanley Dean Witter earlier this year) with the release of its new version 4.0 product. However, other vendors such as BEA, with version 6.1 of its WebLogic Server; Sybase, with version 3.6.1 of EAServer; and Oracle, with version 9i of its Application Server, also provide J2EE-certified application servers.
A developer version of the WebSphere 4.0 product can be downloaded for free from the IBM site.
As mentioned previously, J2EE is not a product, but a specification produced by Sun that defines a standard (APIs and specifications) for developing and deploying enterprise applications. It is based on the Java 2 Platform, Standard Edition (J2SE), which defines the lower-level components of the platform, such as the Java Virtual Machine and Java SDK. Currently, J2EE 1.2 is the released specification and version 1.3 is in beta. Sun provides the specifications as well as reference implementations, documentation, tools, and samples on various platforms. Vendors such as IBM, BEA, Sybase, and Oracle then license J2EE and implement products based on the specifications.
Many different vendors have licensed J2EE. Those that have passed the Compatibility Test Suite (CTS) are listed at http://java.sun.com/j2ee/compatibility.html. WebSphere (WAS) 4.0 is J2EE 1.2–certified. WAS 3.5 is not certified, although IBM claims that it is compliant. If an application is built on a certified product, it can be ported more easily to competing products.
The idea behind the vendors implementing the same standard is, of course, WORA ("write once, run anywhere"). This concept is what initially pushed Java to the forefront in the IT world, and it is certainly attractive because it promises reusability across platforms. You can think of J2EE as simply extending this idea to the server. It should be noted that IBM's support for Java and J2EE was instrumental in ensuring that Java remained important in the IT landscape after it failed to take hold as a browser- or forms-based client-side development tool.
Obviously, Microsoft calls the WORA strategy into question and notes that porting J2EE applications between products such as BEA's WebLogic and WebSphere can be daunting, given IBM's 274-page paper describing the process. In addition, each vendor provides supplementary interfaces and APIs that are vendor-specific, to differentiate themselves and provide increased integration with their products. For example, WAS 4.0 Enterprise Edition will contain IBM extensions to J2EE. As an example, Microsoft recently made much of the May 14, 2001, assessment of application portability on J2EE by Will Zachman, an analyst for the Meta Group:
One major limitation to the Java camp is lack of portability among products from different vendors. ... Java users should realize that they will never achieve complete compatibility between any two of the several J2EE application servers on the market. They should realize that when selecting J2EE systems, they are not choosing a standard but a product platform, and should plan to focus on either WebLogic or WebSphere as a corporate standard.
Of course, the J2EE camp retorts that any degree of platform independence is more than you'll get with .NET, which will be limited to Windows (although talk of an open source implementation of the CLR has recently gotten attention). In any case, at a high level you can think of the J2EE strategy as single-language (Java) and multiple-vendor, while the .NET strategy is multiple-language through the Common Language Runtime (CLR) and single-vendor.