异中有同同中有异

作为彼此竞争的应用平台，J2EE和.NET开发平台在目标和体系结构上极其相似，但在实现上又完全不同。平台的体系架构是支撑平台的基础，平台各方面的性能也会因平台架构实现的不同而有差异。对两个平台产生至关重要影响的三个方面是：系统平台基础构造、三层/多层体系结构和移植/性能/扩展。J2EE是一个平台规范而非产品，对等而论，在这里述及的.NET也专注于该平台的架构规范，而较少地涉及到具体产品，尽管对.NET而言有时候这方面并不能被区分得很清楚。

类似的平台基础构造

一个平台在语言编译、代码执行、编程支持等基础构造方面往往会对平台的可用性、生产性、移植性等产生重要的影响，也是我们评判一个平台是否适合特定应用的重要依据。J2EE和.NET两个平台在底层的执行引擎都源于托管的虚拟机概念，但.NET的CLR沿着Java虚拟机(JVM)走得更远。CLR在借鉴了JVM的自动垃圾收集、异常处理等机制的同时，又为.NET平台添加了多语言支持、组件自描述等新的特性。

在.NET和 J2EE平台上，程序的编译都经过两个类似的过程。首先特定高级语言编译器将C#（及其他.NET语言）和Java源代码分别翻译成中间语言(IL)和字节代码(ByteCode)。.NET在中间语言设计时通盘考虑了多个主流高级语言，在这一层面实现了.NET平台的跨语言承诺。J2EE的基石是Java语言，它最典型的特征是：一次编写，多次运行。跨平台是J2EE一直引以为豪的关键，这是通过JVM来实现的。

其次，在执行时，中间语言被即时编译器(JIT)编译成特定平台的二进制代码，字节代码则通过JVM解释执行，完成各自语言的指令功能。鉴于微软在“Wintel平台”上的代码优化功底，.NET代码的执行速度较之于Java有明显的优势是不争的事实。但在Unix/Linux平台上，由于.NET迟迟未能实现其跨平台的承诺，J2EE几乎成了惟一的选择，执行效率的比较也就无所谓。在代码执行的同时，通用语言运行时和Java虚拟机也都提出了异常捕捉、类型安全、内存分配、垃圾收集等自动化内存管理工作，大大减轻了现代软件的内存泄漏问题和程序员繁重的负担。

面向对象程序设计在J2EE和.NET平台中都获得了直接的支持，单根继承加多接口实现是它们共有的特征。但在面向对象之外，.NET对现代组件编程提供了直接支持。当然，当下的很多企业中间件都是基于J2EE平台的,只是.NET从设计、编码、配置到运行给予了组件编程更多、更直接的支持。

一个能够为编程提供广泛服务的、可复用的API类库对于现代软件平台非常重要。从基础的集合、字符串操作到企业级的API接口，如JMS、JDBC、JAX、JNDI等，可以看到J2EE在这方面有着非常坚实的结构。微软.NET框架类库也不示弱，提供了从图画、网络、线程到ADO.NET、ADSI、Windows表单、ASP.NET等一系列的API。在这些基础的和企业级的服务上两个平台很难一决高下，而且对功能集合的支持很多时候是一个时间问题，往往是一个平台推出了某一子功能集，另一个平台马上推出类似的功能集。

除去API类库的无缝的功能复用外，对本地平台的调用操作也是值得关注的一点。CLR和Java虚拟机都支持本地方法的调用。在异构平台方面，J2EE更钟情于IIOP（Internet InterORB Protocol），而.NET则使用SOAP。

相同的三层/多层体系

基于三层/多层分布式计算结构已毋庸置疑地成为当今企业应用的主流模式，也是两个平台较量的着力点。

在客户端，表示层负责用户与系统的交互。对于不同的处理要求，.NET和J2EE都提出了基于桌面的应用程序和基于浏览器的Web应用的开发组件：Java Application与Windows表单、Java Servlet/JSP与ASP.NET双双形成犄角之势。但Windows表单依赖微软桌面系统的天然优势，不管在交互速度还是在界面的表现性能上都较Java Application稍胜一筹。Servlet/JSP与ASP.NET是目前企业在“瘦客户端”应用的重点，两者都基于HTTP请求/响应模型，通过HTML浏览器页面完成用户交互。虽然ASP.NET声称在底层通过编译执行获得了相当高的处理速度，以及服务器方控件的浏览器自适应能力，但目前并没有这方面的硬性数据，很难据此而论高下。在缓存、状态优化等方面两者可谓旗鼓相当。另一个和客户端应用相关的技术是ActiveX与Applet，但从目前的趋势来看，它们在两个平台上的地位逐渐边缘化，也不为大多数企业所接受。

在中间层，分布式业务组件负责企业应用的商业逻辑部署。由于这些业务组件经常负责处理数据库连接、网络资源、线程等高昂的资源，所以一直是三层/多层架构的关键和企业应用的核心。J2EE的EJB是一个成熟的、得到业界广泛支持的大型企业级组件框架，而.NET组件则是建立在新型的COM+服务之上，两者在组件与操作系统的交互、客户端资源共享等方面都有很好的支持。EJB的核心是容器，容器是一个为组件提供服务的运行时环境，负责为组件提供诸如事务处理、持久性、安全性、组建状态自动化管理等服务，它分离了商业逻辑和系统底层逻辑，使开发人员的工作大为简化。.NET则通过元数据支持自描述性的组件开发、XCOPY部署以及多版本共存，而无需注册表和描述文件，对企业客户有一定的吸引力。

在后端数据层，两个平台都为数据库连接量身定做了一套数据存取模型：J2EE的JDBC和.NET的ADO.NET。它们在支持传统SQL数据源的同时，也都支持新型的XML数据源。这方面由于更多地涉及到具体的数据库产品，很难说那种数据模型更有优势。

值得指出的是，在打造三层/多层体系结构的同时，Web服务作为新一代企业计算模型也得到了J2EE和.NET平台相当的关注，在后面的文章会有这方面的详细评述。

不同的移植、性能和扩展

在移植性方面，微软通过.NET 通用语言运行时来消除编程语言的差别，而J2EE则通过Java虚拟机来消除平台差别。“选择.NET平台就意味着选择Windows”，这句话至少在可预见的一段时间里仍然是一个基本事实。跨平台是J2EE的一大卖点，也是在选择企业应用开发平台时的一个重要参考因素，几乎所有的主流操作系统都提供了对J2EE的支持。实际上如果要搭建跨Unix、Windows等多个操作系统平台，J2EE平台几乎是惟一的选择。J2EE更关注跨平台而不是跨语言。但微软认为，如果企业的应用都能通过标准协议以Web服务的方式发布，那么平台都是中立的。跨平台甚至是微软所不想的。为了吸引更多的开发者和鼓励广大企业厂商转到.NET平台，微软提出了多语言支持，希望用跨语言的交互性来平衡跨平台的互操作。

性能是J2EE和.NET喋喋不休的话题。二者之间著名的论战是一个关于宠物店的范例应用。宠物店是Sun一度以来作为J2EE典型应用的展示范例，但.NET“自告奋勇”地在自己的平台上实现了该宠物店应用，且声称代码行是J2EE的1/3，效率却是J2EE的30倍。但Sun的理由是这个范例根本不适合用来做性能比较，该范例实现也没有做针对性能的优化，而且指责微软通过后端数据库优化和缓存虚抬了.NET平台的效率。这样的争吵当然不能作为我们判断的依据，目前也没有见到更客观的第三方评测报告。在“Wintel平台”上我们也许没有理由怀疑.NET的性能，而至于非Windows平台，.NET和J2EE也不再具有可比性。

在平台的成熟度方面，两者也有一拼。J2EE在1999年形成了其成熟的架构，并且到今天已经有相当成熟的经过检验的企业应用系统。而.NET究其渊源是源自微软以前开发企业应用程序的平台DNA（Distributed Network Architecture），其中包括了许多已经被证实的技术，并且这些技术已经在产品中得到实现，包括微软的事务服务器、COM+、消息队列、SQL Server数据库等。而对于扩展性，广为业界接受的事实是.NET平台的扩展思想是基于软件的横向扩展，而J2EE平台的扩展思想则是基于硬件的纵向扩展。这也符合微软和Sun各自的产品利益。

J2EE另一个重要特征就是它的架构开放性，它本身是一系列规范，而不是产品，任何符合这一规范的产品都是J2EE兼容的。这使得J2EE从制订之初就得到了广泛的支持。BEA、IBM、Oracle等都相继开发了符合J2EE的应用服务器，它们的产品相互之间甚至可以兼容。而.NET在设计之初就紧紧地把平台规范与产品胶合在一起，虽然.NET架构的一小部分具有开放性（如C#语言、通用语言基础构造CLI 和Web服务标准），但至少目前很难想像会有一个非微软的.NET实现。