Similarities between J2EE and the .NET Platform

A full listing of equivalencies between J2EE and the .NET platform is given in Figure 5. As you can see, many of the .NET platform functional areas have no counterpart in J2EE. In some of these cases, it is considered to be an implementation specific decision as to whether or not to support the functionality, and if so, how. Note: for unfamiliar abbreviations, see the glossary.

Figure 1. Technology equivalences

some of Differences between J2EE and the .NET Platform
You can see that there is tremendous overlap between the J2EE and .NET platform technologies. How, then, does one choose between them? In this section I will discuss what I see as the main differences.

Vendor Neutrality
Many companies buy into J2EE believing that it will give them vendor neutrality. And, in fact, this is a stated goal of Sun's vision:
A wide variety of J2EE product configurations and implementations, all of which meet the requirements of this specification, are possible. A portable J2EE application will function correctly when successfully deployed in any of these products. 
In fact, few non-Sun J2EE proponents believe this is achievable. One of the most prominent independent J2EE spokespersons is Paul Harmon, a principal consultant for the Cutter Consortium and the writer of the widely read Architecture/e-Business E-Mail Advisory. While Harmon is usually very pro-J2EE, he recently wrote this unusually frank assessment of J2EE vendor portability
Has the EJB model reached the point where I can move EJB components from one EJB application server to another?  Not in most cases.  The EJB specification isn't comprehensive enough.  EJB application server vendors have "filled in" by providing proprietary solutions to complete the model and to guarantee that their clients can build production systems. 
Harmon summarizes the vendor neutrality situation today, as do many, with this assessment:
The reality, at the moment, is that if you want to develop an EJB application, you should stick with a single vendor.
The reality today is that there is no such thing as vendor neutrality. Of course, the .NET platform is not vendor neutral, it is tied to the Microsoft operating systems. But neither are any of the J2EE implementations. The best advice I can give is to choose some vendor, plan on staying with that vendor, and leverage the heck out of the platform that vendor provides.
 

Framework Support
When building a large, eCommerce solution, it goes without saying that one does not want to start from scratch. One wants to build on top of a well defined and tested eCommerce framework. The use of such a framework can dramatically reduce development costs, probably by a factor of at least 10.
The .NET platform includes such an eCommerce framework called Commerce Server. At this point, there is no equivalent vendor-neutral framework in the J2EE space. With J2EE, you should assume that you will be building your new eCommerce solution from scratch. Paul Harmon appears to agrees with this assessment, saying
Moreover, no matter what [J2EE] vendor you choose, if you expect a component framework that will allow you to quickly field complete e-business applications, you are in for a frustrating experience.
If MS Commerce Server can serve as your eCommerce foundation, then it will likely have a tremendous impact on the cost of developing your system. Commerce Server is particularly well suited for retail operations. Such eCommerce systems should look carefully at this technology.

Portability
Much of the appeal of J2EE lies in the promise of portability. There are two flavors of portability. The first is vendor portability. I refer to this as vendor neutrality, and have already discussed (and rejected) this idea earlier. The second flavor of portability is operating system portability. This refers to the ability to move a code base from one operating system to another without having to change the code itself. Operating system portability, unlike vendor portability, is a possibility with most implementations of J2EE.
The reason that operating system portability is a possibility with J2EE is not so much because of any inherent portability of J2EE, as it is that most of the J2EE vendors support multiple operating systems. Therefore as long as one sticks with a given J2EE vendor and a given database vendor, moving from one operating system to another should be possible. This is probably the single most important benefit in favor of J2EE over the .NET platform, which is limited to the Windows operating system. It is worth noting, however, that Microsoft has submitted the specifications for C# and a subset of the .NET Framework (called the common language infrastructure) to ECMA, the group that standardizes JavaScript.
It is obvious why vendor portability/neutrality would be desirable, but what is the benefit of operating system portability? There are typically two types of companies that think they need operating system portability: independent software vendors (ISVs) and corporations looking for scalability solutions.
ISVs need operating system portability when they have a significant customer base on non-Windows platforms. One can't sell a product to Unix customers that is tied to  the .NET platform. It doesn't matter if the .NET platform is better than J2EE or not. It doesn't run on Unix.
J2EE offers an acceptable solution to ISVs when the product must be marketed to non-Windows customers, particularly when the J2EE platform itself can be bundled with the ISV's product as an integrated offering.
If the primary customer base for the ISV is Windows customers, then  the .NET platform should be chosen.  It will provide much better performance at a much lower cost.
Many companies that want operating system portability are not ISVs. Most of these companies think portability is the path to scalability. These companies believe that they can achieve higher scalability by migrating applications to higher and higher end hardware platforms as throughput requirements expand.
If you believe operating system portability will in any way help you achieve scalability, you are making a serious mistake. Scalability is not a hardware problem; it is a software problem. The highest scalability is achieved by writing for a highly scalable platform and then leveraging that platform as much as possible. Writing for a J2EE implementation that just happens to run on multiple platforms will be a distant second in terms of achievable scalability. The platform that is by far the best documented in terms of its ability to achieve high scalability is the .NET platform.
Using the numbers given in my section on scalability, the .NET/Windows platform can scale from 16,000 transactions per minute to over 500,000 transactions per minute. The IBM WebSphere J2EE/Unix technology, one of the best representatives of the J2EE genre, will probably do no better than a 17,000 to 110,000 range of transactions per minute, at a much higher cost per transaction.
So portability is not as simple as it appears. If you really want scalability, the .NET platform is a clear winner over J2EE. If you must support non-Windows platforms, then J2EE is the clear winner over the .NET platform.
If you want portability so that you are independent of the whims or fortunes of a particular vendor, then forget it. That kind of portability doesn't exist. So choose your vendor carefully. Make sure that you understand and are comfortable with the technical direction of that vendor. Make sure that your vendor has a long-term commitment to that platform. And finally, make sure that your vendor has the financial resources to be a survivor in this highly competitive technical arena.

Client device independence
I discussed the difference between the Java and the .NET platform presentation tier programming models. The major difference being that with Java, it is the presentation tier programmer that determines the ultimate HTML that will be delivered to the client, and with .NET, it is a Visual Studio.NET control.
This Java approach has three problems. First, it requires a lot of code on the presentation tier, since every possible thin client system requires a different code path. Second, it is very difficult to test the code with every possible thin client system. Third, it is very difficult to add new thin clients to an existing application, since to do so involves searching through, and modifying a tremendous amount of presentation tier logic.
The .NET Framework approach is to write device independent code that interacts with visual controls. It is the control, not the programmer, that is responsible for determining what HTML to deliver, based on the capabilities of the client device.. In the .NET Framework model, one can forget that such a thing as HTML even exists!
This approach solves all three of the problems of the Java/old-ASP approach. One can write an effective presentation tier application with much less code, since a single code path works for all possible thin clients. It is much easier to test that code, since one is only testing one's interaction with the control, rather than the client devices themselves. And finally, one can add new client devices very easily, but simply downloading the latest version of the control that has hopefully been updated with the latest knowledge about thin client devices.
From a cost perspective, the .NET Framework approach is a clear winner. Development, debugging, and maintenance are all much easier (and much cheaper) when the presentation tier developer is not responsible for determining what will be displayed on the client device.