一.技术概观
在表现形式上，J2EE是一组规范，而.NET更象是一组产品。但它们的目的都是为了企业应用提供分布式的，高可靠性的解决方案.它们在架构上有着很多的相似之处:
J2EE平台的构成
.NET平台构成
技术比较
1.一 vs 多
一种语言vs多种语言，一个平台vs多个平台.这似乎是大家最喜于津津乐道的话题，也似乎是所有问题的焦点。
两种平台主流的开发语言Java和C#在架构上有着惊人的相似：虚拟机技术，基于沙箱的安全模型，分层的命名空间，垃圾回收等。
跨平台是J2EE的最大卖点，也是至今为止还绊住微软的栅栏.当开发商完成了符合J2EE规范的软件时，其客户可以依据其喜好和实力来选择不同应用服务器.从基于open source的免费软件到高端满足B2B需求的商业套件来搭建自己的平台.但是由于J2EE的规范还不完善，各个J2EE服务器的提供商为了使其提供其各自理解的完整的功能，不得不添加一些额外的特性.这就使得使用了这些特别功能的应用软件，绑定到了特定的应用服务器上.随着J2EE规范的发展，这种差别会逐渐减小.
微软的跨平台解决方案是Web services，它解决的是异种平台上不同应用之间的连通性问题.从技术角度讲，它除了以XML为介质之外没有什么新意.但它的重要意义在于:它是微软这样一个重量级选手所推出的，前景不容小视。
正如我们所讨论的: Web services解决的是异构平台上服务连通性的问题，但在现实中所更迫切需要的是如何在异构的平台上构造具有可扩展性，高可靠性，高可用性，故障冗余，错误恢复能力的企业应用.缺少这一点，从结构上讲，.NET平台还未尽人意。
2.中间层
基于组件的软件开发技术可以在较高的级别上实现软件复用，加快企业软件开发的进程.在J2EE构架中， JavaBean和EJB(Enterprise JavaBeans) 被用来完成事物逻辑.其中EJB和 JavaBean 有着类似的模型，但它被用来创建分布式的企业应用。
在微软的.NET平台中，旧的COM 和 COM+的组件模型被新的组件模型所代替。增加了象基于沙箱的安全模型和垃圾回收等功能.并且实现了多重接口继承，扩展的元数据和新的代理模型等.旧有的COM和COM+组件也可被映射到新的运行环境中。
综上所述，两者架构在基于组件的中间层的设计上各有千秋，对于创建分布式的，复杂的，高效的，高可靠性的的应用程序都有着足够的能力。
3.表示
两种架构都同时支持胖客户端和瘦客户端.即C/S模式和B/S模式.对于C/S模式，J2EE提供了替代Java AWT的Java Swing，同时作为可视化组件的JavaBean也可用来构造系统。对于B/S结构的表示层，J2EE使用 servlet ，JSP(Java Server Page) ，HMTL，WML，XML等工具来实现。
微软的胖客户端技术则由 Windows Forms代替了MFC.它们起的作用相同，在结构上 Windows Forms 被插入到.NET的运行时框架(runtime framework)和组件模型 (component model)中.在瘦客户模型中， ASP.NET代替了旧有的ASP和 HMTL， WML ，XML作为表示层。在 ASP.NET 中，C#，VB.NET等语言的代码片断可被自由引用.ASP.NET 页面被首先转换成中介语言( Intermediary Language)，然后再被 中介语言及时编译器(just-in-time IL compiler)编译，最后运行于公共语言运行环境中，并且 ASP.NET 提供了页面的缓冲，所以，其运行速度要远远快于ASP。
大体上，两种架构所使用的表示层的技术非常类似，虽在细节上各有所长，但总体功能当在伯仲之间。
4.数据访问
J2EE 和 .Net 已不同的形式支持数据的访问。JDBC和ADO一样和所连接的数据库无关，并且通过连接，命令语句和结果集来对数据进行操作.所以属于中间层次的 API.更高一级的数据封装和数据管理是通过实体EJB (entity EJB)来完成的.基于容器管理的实体EJB使开发更快捷，管理更方便.事实上，由于实体EJB的load()和store()方法的同步机制，将大大缓解因并发而使数据库产生的瓶颈.也可以采用不属于J2EE规范的第三方数据访问工具，象WebGain的 TopLink。
而微软的.NET的数据访问工具则由基于XML的ADO.NET代替了基于COM组件的ADO.任何以XML为输出的数据源都可以作为 ADO.NET 的数据源.相应的结果集升级为数据集 (DataSets)，命令语句则升级为数据集命令(DataSetCommands).从形式来看，微软的ADO.NET更新潮和时髦一些，基于XML的特性使其可以处理极其丰富的数据源，并且，因其构架在HTTP协议之上，易于穿透防火墙，使沟通更为便利.但由于XML本身的基于标记的特性，很明显限制了在有超大数据量和有网络瓶颈的应用中的使用.而J2EE的数据访问规则则显得略有单薄，但同时却更简单，更有效.并且通过对应用程序有效的层次的设计，对于数据库和基于XML的数据源的访问，也是可以无缝的整合的。
三.整体评价
在微软还没有足以和Java平台相对抗的产品的时候，微软所乐于做是大声的宣传:"write once， debug everywhere"。而它的对手则更乐于这样评价它:"微软开始也喜欢Java，他们喜欢它的方式是让它死去，他们当然也憎恨它，他们甚至憎恨每一个以J开头的单词。"但是现在，形式不同了，微软有了足以自豪的.NET他们可以已他们自己所喜好的方式来对J2EE和.NET来做各种比较。最热闹的应该算是微软出示的第三方对.NET Pet Shop和J2EE的 Pet Store的综合比较了.有兴趣的读者可以到MSDN，www.onjava.com，IBM开发者原地等网站看到相关评论。
| J2EE | .NET | |
|
易用性
|
 |
|
|
扩展能力
|
|
|
|
多平台支持
|
|
|
|
多语言支持
|
|
|
|
可靠性
|
|
|
|
性能
|
|
|
|
可管理性
|
|
|
|
重用性
|
|
|
|
负载平衡
|
|
|
|
开放标准
|
|
|
就企业而言，内部众多系统的整合、系统的延展性、安全性是更需要注意的议题，而这些都是J2EE的优势，也是微软的不足处。 在效率方面，J2EE阵营主张通过硬件的效能增加来弥补软件的不足.开放标准，功能强大，易于移植这些都是J2EE的卖点。但让人奇怪的是IBM的WebSphere和BEA的WebLogic在J2EE市场占了大半壁江山，而作为规则制定者的SUN却在做壁上观。
微软确实提供了从桌面的办公软件，开发工具，到后台服务器数据库的全方位的产品。 但统一平台的使用者可能要牺牲跨平台的好处，并也有可能由此就被无穷无尽的锁定在微软的许可证的汪洋中.更简单，更快捷，更高效是微软的目标，随着时代的发展，我们也许会看到更完美的技术解决方案。