J2EE与.NET的比较

2024年2月3日发(作者：)

1．体系架构的比较

作为彼此竞争的应用平台，J2EE和.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接口，如JMS、JDBC、JAX和JNDI等，J2EE在这方面有着非常坚实的结构。微软.NET框架类库也不示弱，提供了从图画、网络、线程到、ADSI、Windows表单和等一系列的API。

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

Protocol），而.NET则使用SOAP。

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

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

在中间层，分布式业务组件负责企业应用的商业逻辑部署。由于这些业务组件经常负责处理数据库连接、网络资源和线程等高昂的资源，所以一直是三层/多层架构的关键和企业应用的核心。J2EE的EJB是一个成熟的、得到业界广泛支持的大型企业级组件框架，而.NET

组件则是建立在新型的COM+服务之上，两者在组件与操作系统的交互、客户端资源共享等方面都有很好的支持。.NET则通过元数据支持自描述性的组件开发、XCOPY部署以及多版本共存，无需注册表和描述文件，对企业客户有一定的吸引力。

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

两种架构的简单对照如表1所示。

表1 J2EE与.NET架构比较

架构

比较项

通信协议

编程语言

运行时环境

客户端

目录服务

数据访问

异步消息处理

表示层技术

中间层组件模型

安全访问

事物处理

JAAS

Java Transaction Server (JTS)

COM+ Security Call

Context

Microsoft Distributed

Transaction Coordinator

开发工具

2.安全配置和代码封装的比较

（1）安全配置

两个平台的配置都是通过XML或纯文本文件，两个平台最大的区别在于处理安全配置体系的方式不同。

在.NET平台，有图形接口和命令行二种方式来修改安全配置参数。是图形接口方式，提供了命令行方式，适用于批处理或配置文本。

JAVA平台只提供了图形接口的工具。和.NET不同的是，它的目标对象（配置文件）的名字和位置不是固定的。

Borland JBuilder，IBM VisualAge

等

(MS-DTC)

Visual

J2EE

Remote Method Invocation over

Internet InterOrb Protocol (RMI/IIOP)

Java

Java Virtual Machine (JVM)

Java Swing

Java Naming and Directory

Interface (JNDI)

Java Database Connection (JDBC)

Java Message Service (JMS)

Servlets， Java Server Page(JSP)

EJB，JavaBean

.NET

XML

C#，，COBOL等

Common Language

Runtime (CLR)

Windows Forms

Active Directory Services

Interface (ADSI)

Java Connectors

Microsoft Message Queue

COM+，COM

.NET定义了不同范围的安全配置文件：系统范围，本机范围，本用户范围。在配置有冲突时，原则上小范围的参数有优先权。

JAVA和J2EE的核心配置文件都保存在固定位置，但扩展配置文件随厂家不同而不同。

（2）①代码封装：检验

JAVA 和.NET 的Common Library Runtime (CLR) 都实行内存安全或类型安全的保护机制，在这些平台开发的应用的安全性也是可以检验的。他们的实现机制有很大的不同。

在.NET， CLR总是执行编译好的代码，它不解释代码。但是在中间语言（IL）被编译之前，编译器会有验证和检验的步骤。第一步是检查文件的结构和代码完整性；第二步包括一些扩展的检查，内存安全、堆栈跟踪、数据流分析、类型检查等。在运行阶段，由VES (Virtual

Execution System) 来负责安全性检查和出错意外情况处理。

在JAVA平台，JAVA虚拟机（JVM）负责类的载入、链接、检验和执行。对于已经编译和优化的代码，JVM也用二个无条件调用堆栈来保留最初的字节代码信息。

小结：和.NET不同，JVM的默认设置是不检验本地代码。另外，JVM保留最初的字节代码供运行时检查，而.NET把静态分析和运行时插入检验代码相结合。

②代码封装：应用隔离

在.NET， 域隔离建立在内存安全机制的基础上，不同的域不能直接访问彼此的地址空间，只能通过.NET远程通信机制访问。

在JAVA平台，应用隔离是通过ClassLoaders 和 ProtectionDomains 相结合来实现的，安全类加载是JVM安全机制的基石。

小结：.NET的 AppDomains 就象操作系统的进程一样，使用起来比JAVA的

ProtectionDomains 更直接、容易一些。

③代码封装： 语言特征

两个平台基本上差不多，.NET在灵活性上稍微好一点。

（3）总结：

JAVA在安全配置上有较多的优势，.NET在代码封装的选择性和易用性好一些。

3.加密和通信 的比较

（1）①加密法：概论

.NET的加密法主要基于CryptoAPI 和相关扩展。大多数有关加密的类都在graphy, X509Centificates 和XML中。.NET利用基于流的模型来完成加密传输，所有的算法都被默认为最高的安全级别。.NET也允许用户自己在

中定义自己的算法。

JAVA平台的加密算法分二个部分：Java Cryptography Architecture (JCA) 和 Java

Cryptography Extension (JCE)。 JCE的出口受到有关法律的限制。如果要使用用户自己的加密算法，必须得到认证机构（SUN 或 IBM）的认证。

②加密法：算法

.NET主要提供了下面几大类加密算法：非对称算法、HASH算法、对称算法、随机数生成法。

JAVA提供的加密算法更多，但是较少第三方厂商可以在JAVA中提供自己的算法。

（2）安全通信

SSL已经是事实的传输安全的工业标准了。JAVA和.NET都支持最新版本 SSL 3.0。

①安全通信：平台

.NET只在基于IIS的应用中使用SSL来保护HTTP传输，对于非IIS应用，.NET不能保护传输中的数据。

在JAVA中，JSSE （Java Secure Socket Extensions） 提供了平台级的服务，保证基于TCP/IP的通信安全。

除了IIS，.NET没有提供任何其它平台级的通信保护的标准方案，但是JAVA在这方面提供了全套的解决方案。

②安全通信：应用

.NET通过WSA （Web Service Architecture）和 WSE (Web Service Extension) 包来提供最新的WEB服务安全保证，JAVA目前还没有提供这方面的支持。

（3）总结：

在加密方法上，JAVA和.NET基本没有太大的差别；在通信保护方面，JAVA 比.NET提供了更多的选择方案；但是在WEB服务安全性上，JAVA明显比.NET落后一些。

4.移植性比较

在移植性方面，.NET支持跨语言，J2EE支持跨平台。

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

5.性能比较

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

6.安全性、稳定性比较

WINDOWS本身的安全漏洞，使得.NET的安全性不如J2EE。同时，在应用服务器的选择上，.NET只能用IIS，安全性、稳定性难以保证；而J2EE有更多的选择，可以在诸多遵循标准的厂商所提供的应用程序服务器中，选择最符合需要、成本最低、而且又被认为是最佳的平台。

7.可扩展性比较

.NET平台的扩展思想是基于软件的横向扩展，而J2EE平台的扩展思想则是基于硬件的纵向扩展。

Windows系统一般只能扩展到不超过8个处理器，而Sun的系统却可以扩展到100个甚至更多处理器。

基于J2EE平台的应用程序可被部署到各种操作系统上，例如可被部署到高端UNIX与大型机系统，这种系统单机可支持64至256个处理器，这是NT服务器所望尘莫及的。J2EE领域的供应商提供了更为广泛的负载平衡策略，能消除系统中的瓶颈，允许多台服务器集成部署。这种部署可达数千个处理器，实现可高度伸缩的系统，满足未来商业应用的需要。

8.成熟度比较

在平台的成熟度方面，两者也有一比。J2EE在1999年形成了成熟的架构，发展至今已经具有相当成熟的、经过检验的企业应用系统。而.NET究其渊源是源自微软以前开发企业应用程序的平台DNA（Distributed Network Architecture），其中包括了许多已经被证实的技术，并且这些技术已经在产品中得到实现，包括微软的事务服务器、COM+、消息队列和SQL Server数据库等。

9．第三方厂商的支持

J2EE作为一种开放的规范，从一开始就得到了众多厂商的支持，IBM、BEA、HP、Oracle等在J2EE的实施上都有较大的投入。目前市场上最好的J2EE应用服务器并不是Sun与Netscape合资的iPlanet，而是BEA的WebLogic和IBM的Webshpere。开发工具有Borland的JBuilder、Sun的Forte for Java、BEA的WebLogic Workshop、Oracle 的JDeveloper、IBM的VisualAge for Java等。

而.NET在设计之初就紧紧地把平台规范与产品胶合在一起。虽然，NET架构的一小部分具有开放性（如C#语言、通用语言基础构造CLI 和Web服务标准），但至少目前很难想象会有一个非微软的.NET实现。Visual 是其唯一的开发工具。

10.开源支持比较

J2EE开源产品众多，免费框架居多，相应的最佳实践设计模式层出不穷。而.NET无开源社区支持，是以框架开发者为主导的设计。

11.学习成本比较

J2EE门槛较高，由于多且杂，需要开发人员花费很长时间才能熟悉整个体系。而.NET门槛较低，使用方便，学习成本较低。但是，对于开发人员来说，.NET在系统整体架构的设计方面不如J2EE易于把握。

12.对WEB服务支持的比较

从.NET和J2EE这两个平台的发展历程来看，.NET从一开始就深深打上了Web服务技术的烙印，在它的市场推广活动中，无时无刻不凸显其作为Web服务的开发和部署平台的特征，可以说，.NET天生就是为Web服务准备的开发和部署平台。相对.NET而言，J2EE是一个比较“老”的东西，最初它是为了将Java平台拓展到企业级应用领域而制订的一个平台框架规范，随着Web服务技术的兴起和发展，J2EE平台作为一个企业级应用的开发和部署平台，无法回避业界的重大技术革命——Web服务，J2EE也不断地引入了对Web服务的支持。

从服务描述、服务实现和服务的发布、发现与绑定，以及服务的调用和执行这些不同的角度看，J2EE和.NET的支持基本不相上下，惟一的区别可能是.NET的开发工具更为方便一些、集成度更高一些。

在Web服务规范的控制方面，微软与IBM共同主推了大量的Web服务规范，在一段时间内，两家公司Web服务技术的市场推广活动都是联合举行的，不难看出这两家公司在这个领域背后的战略合作关系。最初的Web服务核心技术SOAP、WSDL主要由这两家公司制订，后来的UDDI是由这两家为首的多家核心企业共同制订，再后来的一些不是核心的Web服务规范，如WS-Inspection、WSFL、WS-Security、WS-Routing、WS-License和WS-Referral等，则完全是由这两家来制订的。不难看出：IBM和微软对于Web服务的贡献以及它们对Web服务规范的控制。

尽管由于某种原因，Sun公司曾经在很长的一段时间里被排除在WS-I（由IBM，微软和BEA发起成立的促进WEB服务互操作的一个组织）的门外，但这并没有影响Sun公司继续在WEB服务方面坚持开放的战略。Sun公司是Java语言的发明者，而作为一个开放的跨平台的技术体系，Java在WEB服务的开发方面也起着非常重要的作用。双方妥协后，Sun最终被接纳为WS-I的董事成员。

Sun公司积极地参与了制订Web服务规范的过程，像XML和ebXML。并已经在Java中支持WEB服务中最重要的规范，例如SOAP（JAX-RPC、JAXM、SAAJ和JMS）、WSDL（Java API for WSDL）、UDDI/ebXML（JAXR）和XML（JAXP，JAXB）等等。Sun公司除了积极地参与Web服务领域里的标准化工作，更是努力地为客户提供全面的软件产品，为用户开发和部署Web服务提供平台。Sun公司的Sun ONE Web服务平台开发版，是业界第一个用于基于Java技术的Web服务和Web应用开发的全方位的集成平台。该平台集成了多种Sun ONE服务器软件、Java开发工具，支持业界的WEB服务标准，而且是面向开发人员设计，安装和使用都非常简单。

13.结束语

关于J2EE和.NET之间的讨论已经持续很多年了，孰优孰劣仍然很难下结论。事实上，.NET和J2EE都各有特长，两者都是十分优秀的开发平台，短时间内谁也不可替代对方。选择哪种开发平台，除了要看软件开发人员对语言的掌握能力及个人喜好，也要根据开发内容和企业具体情况、具体需求而定。

J2EE最大的优势是跨平台，.NET最大的优势是入门容易和性能较高（鉴于微软在“Wintel平台”上的代码优化功底，.NET代码的执行速度较之于JAVA有明显的优势）。对于没有.NET和J2EE平台基础的开发团队来说，如果开发的应用软件没有跨平台的要求，只需要运行于微软平台之上，则选择.NET平台较好；如果要求跨平台，则只能使用J2EE。如果开发团队具有.NET或J2EE平台基础，在进行新的应用软件开发时，如果没有跨平台要求，则没有必要更换开发平台，因为，更换平台会带来不小的培训成本。