The J2EE Architecture
The J2EE architecture defined by the Sun standards can be discussed in less space than the .NET platform vision because there is less of it. If one looks at a specific vendor's offering, such as IBM's WebSphere, the largest part of its technology will be specific to WebSphere. It is beyond the scope of this article to compare all of the vendor specific enhancements to J2EE, and in my experience, most companies interested in J2EE as a platform are interested in the portability of the standard. Anybody interested in portability will need to limit themselves to what is defined by Sun.
The J2EE architecture can be divided into these five parts:
The Java language system
The client programming model
The middle tier infrastructure
The programmer enterprise API
Non programmer visible API
The last of these, the non programmer visible API, includes API that defines how other products plug into J2EE, such as the Connector API, and APIs that have been effectively superseded by later advancements in the J2EE model, such as the JTA (Java Transaction API). Since the non programmer visible APIs are not important from the perspective of comparing the Microsoft and Sun platform visions, I will not cover these areas in my J2EE overview (as I did not cover the equivalent APIs in the .NET platform overview).

The Java Language System
At a high level, the Java language system looks similar to the .NET Framework. In both cases, source code is translated into an intermediate language. Whereas in the .NET platform, that intermediate language is MSIL, in the Java system, it is Java Byte Code. In both cases, the intermediate language is brought into the runtime environment. In the Framework, that environment is the Common Language Runtime. For Java, that environment is the Java Virtual Machine. Overall, the Common Language Runtime and the Java Virtual Machine have similar functions, and both will undoubtedly evolve and leapfrog each other in technological advances.
The most important difference between the two systems has to do with the translation of source code to the intermediate language. In the .NET platform, the intermediate language has been designed to accommodate the needs of any language. In Java, the intermediate language is designed to meet the needs of Java. While is theoretically possible to generate Java Byte Code from languages other than Java, in practice that has not been demonstrated in any commercial product.

he Client Programming Model
The J2EE client programming model focuses on interacting with the browser. The client programming model has three pieces: Java Applets, Java Servlets, and Java Server Pages.
Java Applets are used to package Java code that will run within the browser. In the .NET platform space, this is functionally equivalent to ActiveX. In my experience, relatively little usage is made of either applets or ActiveX components. ECommerce architectures are typically based on a browser making HTTP requests to a presentation tier, and the presentation tier responding with HTML pages. This type of a system does not use either ActiveX components or Java Applets and therefore I do not cover either of these technologies in this white paper.
The important technologies that deal with HTTP requests and HTML responses are Java Servlets  and Java Server Pages . These two technologies are analogous to ASP.NET (Active Server Pages) in the Microsoft space.
The major difference between the .NET platform presentation tier and the Java presentation tier is how each deals with different client functionality. The Java presentation tier follows the old Microsoft ASP (pre .NET) model, which makes it the presentation tier programmer's responsibility to determine the ultimate destination browser (or other thin client system), what the capabilities of that thin client system are, and how to generate HTML to best take advantage of that thin client system.

The Middle Tier Infrastructure
With J2EE, the middle tier infrastructure is Enterprise Java Beans (EJB). The current version of the specification is 2.0 which is available on-line . The .NET platform equivalent to J2EE is COM+.
There are very few architectural differences between EJB and COM+. Both are essentially derivative architectures from MTS (Microsoft Transaction Server), the original component-oriented middle tier infrastructure introduced by Microsoft in 1996. The key ideas first introduced by MTS and then incorporated into both EJB and COM+ included the following:
•    High scalability through sharing of component instances
•    Middle-tier centric security
•    Automatic transaction boundary management
EJB did add one new architectural idea, a technology for automatically managing component state. This technology is  referred to as entity beans. While the idea of entity beans is attractive, the current implementations are dependent on middle tier data caches that are independent of the database caches. Unfortunately, there is no mechanism for maintaining coherency between the two caches. This means that
 any usage of entity beans introduces a high risk of database corruption. Until the
cache coherency problem is solved, entity beans must continue to be considered at best experimental techology.

The Programmer Enterprise API
The most important parts of what we might call the Java Enterprise API are the following:
•    Java Database Connection (JDBC) 2.0 - The API for accessing relational databases from Java  . This is equivalent to ADO.NET in the .NET platform space.
•    Java Naming and Directory Interface (JNDI) - The API for accessing information in enterprise name and directory services from Java . This is somewhat similar to the Active Directory Services Interface (ADSI) in the .NET platform space.
•    Java Message Service (JMS) 1.0 - The Java API for asynchronous workflow . This is functionally equivalent to Microsoft Message Queue API, which, in the component space, has been superceded by queued components.