对于 .NET 技术和 Sun J2EE (Java 2 Enterprise Edition, J2EE) 的对比，许多客户希望了解 Microsoft 对此的看法。事实上 .NET 和 J2EE 之间的比较很难进行，原因如下。

1. .NET（正式名称为 Windows .NET 框架）是作为 Microsoft Windows 组成部分的多种技术的优异集合；而 J2EE 只是一种书面规范。如果我们的讨论不限于纯技术领域（换句话说，对于服务器应用程序平台的商业价值进讨论），则必须比较相关的应用（例如应用于 IBM WebSphere Application Server、BEA WebLogic Server 或其他应用程序服务器）而不是单纯的比较 J2EE。
在产品之间进行比较才能得到令人信服的分析结果。举例如下：开发人员生产效率。在 J2EE 中，开发人员需要创建 4 个模块来建造一个 EJB。表面上看，这降低了开发人员的生产效率。但一些 Java 开发工具能自动完成其中部分工作，从而提高开发人员的工作效率。另一个例子：J2EE 的开发架构（类装入 JAR，JAR 装入 WAR，WAR 装入 EAR）复杂而难以理解。但一些工具可在一定程度上对其进行自动处理。因此，开发人员工作效率 — 衡量应用程序服务器商业价值关键因素 — 就可能因不同供应商工具的质量而变化。

2. "J2EE All-Star team"所产生的问题。分析人员在比较 .NET 和 J2EE 的各种因素时不难发现这个问题。例如，分析人员对开发人员工作效率的分析关注下列情况：A 公司产品的使用、B 公司应用程序服务器的性能、C 公司服务器的安全性或数据缓存性能、D 公司产品安装的难易程度，以及 E 公司产品的价格。这些情况都在某些方面与 J2EE 相关。考虑到下列功能和特点，J2EE 的确具有一定的优势：价格低廉、安装简便迅速、安全性高、具有良好的缓冲性能、带有优秀的开发人员工具软件等等。但问题是您无法同时享有这些优势。事实上，您在任意时刻仅可享有其中之一。这是由于不同厂商的产品不能保证彼此兼容。IBM 工具不能用于 BEA WebLogic 服务器，BEA WebLogic 服务器不能用于 Oracle 缓存引擎，Oracle 缓存引擎不包含在 Iona 的报价中，等等。人们有时错误地将"J2EE 综合指标"作为比较的基础，但这样做是不恰当的。客户必须进行针对相同产品和使用环境的一对一的比较，才能得出所需的结果。

3. 单纯比较 .NET 和 J2EE 忽略了应用程序平台的其余部分，而这些部分同样是至关重要的。J2EE 是一种规范，仅面向"应用程序服务器"。但大多数客户关心应用程序服务器、端口、商业服务器和分析工具、数据库、脱机数据和便携性、信息代理、应用程序集成、内容管理器、智能客户端和其他众多方面的内容。作为对客户需求的响应，所有主要的厂商都致力于开发集成化的平台，以便提供全面的解决方案。集成化平台的例子有 Microsoft 平台（包括 Windows 客户端和服务器、Windows .NET 框架、Visual Studio .NET 和 Microsoft Enterprise Server）；BEA 的 WebLogic 平台；IBM 的 WebSphere 平台；Oracle9i 平台；以及 Sun One。如果我们仅对平台问题的一个方面（应用程序服务器）专门进行讨论，则存在"全局和局部"的问题。虽然这样的比较是有一定的作用，但应将之作为更大范畴的平台问题的一部分加以考虑。

抛开上述因素，下列内容即为 Windows .NET 框架和基于 J2EE 的产品的主要相同点和不同点（仅代表 Microsoft 的观点）。

1. Windows .NET 框架和 Java 都使用了一种托管的运行时环境，都将源代码转换为一种中间语言，然后将其编译为本地的可执行代码。两种环境都提供垃圾收集、动态类加载和异常。

2. .NET 和 Java 都采用基于组件的设计、多形性、继承和接口。两者都提供基础类库以执行输入/输入、XML 处理、使用连接缓冲访问数据库、进行文本处理、网页脚本编辑和其他操作。

3. 两者都通过特定厂商的产品提供。J2EE 规范本身独立于厂商存在，但符合规范的实际产品必定实现与规范无关的功能，例如管理或部署功能。因此，这些必定是特定厂商的产品。例如 Microsoft Windows 和 .NET。

4. Windows .NET 框架和基于 J2EE 的产品都结合并用于第三方产品。例如在后台数据库领域中，.NET 和基于 J2EE 的应用程序都可以访问 Microsoft SQL Server、IBM DB2、Oracle、Informix、Sybase 和其他数据库上存储的数据。此外，.NET 和基于 J2EE 的系统都可以访问常用的消息中间件，例如 Microsoft MSMQ 或 IBM MQSeries。与此类似，两者也都可以访问目录系统、第三方开发人员工具、代码版本控制系统、防火墙等。

1. 体系
J2EE 为单语言的平台，便于在不同操作系统上使用。这意味着如果要利用 J2EE，项目可以使用多种操作系统，但开发人员可能必须重新接受 Java 培训。Microsoft 将 Windows .NET 框架作为 Windows 的一部分提供。开发人员可以使用多种语言，无须接受新语言的培训。而 Windows .NET 框架为 Windows 的一部分。

2. 应用范围

a. .NET 包括代码、产品、工具和架构，用户可通过 .NET 充分利用网络中的计算资源，包括台式机、服务器和其他设备。.NET 通过标准通讯协议（统称为"XML Web 服务"）连接所有这些设备 。（如果目标系统符合"XML Web 服务"标准，则 .NET 应用程序可以连接任何系统而不受语言或平台的限制，甚至连接到 J2EE）。.NET 模型为大规模分布式计算模型，具有大量进行通讯和信息交换的节点。

b. J2EE 为面向服务器的模型，不利用网络外围的资源和计算能力。通常，基于 J2EE 的产品仅支持服务器端应用程序。J2EE 基本上将 PC 视为 HTML 浏览器，并将其他设备视为哑终端。对于"XML Web 服务"，最新的协议标准支持分布式计算；而最新版本的 J2EE 规范未就"XML Web 服务"进行规定，但基于 J2EE 的产品可通过插件支持 Web 服务。但是，采用插件的方式可能有一些缺陷，例如，虽然 Web 服务组件可以调用部分类型的 EJB，仍不清楚当前的规范是否允许 EJB 调用 Web 服务。

3. 编程模型的一致性
Windows .NET 框架为服务器、台式机和其他设备提供一致的、面向组件的模型。J2EE 提供 EJB 作为服务器端的组件模型；提供 JavaBeans 用于客户端或本地组件，提供 Servlet 用于生成 UI，并为移动设备提供另一种模型。甚至在 EJB 内部也存在至少 3 种不同的子模型并分别具有不同的定义。

4. 功能

a. Windows .NET 框架提供以版本区分的类加载器，这意味着应用程序开发人员可以确保在更新部分代码后，其应用程序正常工作。Java 和 J2EE（当前）不具有区别版本的类加载器，这意味着开发人员和管理员无法保证在运行时执行正确的代码。这导致厂商投入更大的努力以保证基于组件的应用程序的可靠性。当然开发人员也可以仅依靠自己的信心。

b. Windows .NET 框架在语言层显示类属性，并以此简化程序编制。例如，使用源代码中的一个简单的属性可以将 .NET 组件标记为事务性组件。又例如，可以通过一个属性指定将 .NET 组件序列化为 XML 的方式。这种机制极大的简化了许多编程工作。Java 不在语言层显示属性，但 Sun 正在考虑如何修改这种语言使之具有此功能。此类更改大致在两至三年内完成。

c. 对于便携机或不持续连接网络的设备，.NET 支持脱机数据访问。用户可以脱机使用数据，然后与原始的数据源重新同步。目前 J2EE 或 J2SE 都不明确支持脱机数据访问；需要此功能的 J2EE 开发人员必须编写"管道代码"。

d. Windows .NET 框架提供基于事件的模型以建造基于 Web 的用户界面，类似于众所周知的 Visual Basic 中智能客户端的事件模型。ASP.NET 模型使建造、显示和维护基于 Web 的用户界面更加简单。相比之下，J2EE 不在 JSP 中支持此类模型。第三方扩展程序可提供部分相关功能，但其效果和易用性不及 ASP.NET。一种推荐的 J2EE 的增补软件 Java Server Faces 可以提供此功能。但最早要在 J2EE 1.4 版本中才会包含该软件。此后，供应商在大约一年之后才会提供对该功能的支持。

e. J2EE 支持对象相关的数据映射模型，称为 EJB Entity Beans。Entity Beans 的目的是便于开发人员从关系存储中建造对象。但是这种概念在实际应用中存在下列问题：

i. 易用性：在进行数据交互时，开发人员需要放弃众所周知的、曾被指定使用并受到广泛支持的结构化查询语言 (Structured Query Language, SQL)，转而使用非专用的查询语言 EJBQL。虽然类似于 SQL，但 EJBQL 的功能较弱（例如，在当前的规范中没有 ORDER BY 子句，您也不能使用特定数据库的 SQL 扩展），其规范也未事先定义。另外，建立对象间的关系和依赖性比较困难，对象和 XML 之间的翻译是一个手动过程。

ii. 性能：基于 EJB 的系统的性能仍不得而知。目前未公开任何 Benchmark 测试的结果。根据客户反馈，放弃 Entity Beans 并转而使用更直接的数据访问策略极大地提高了效率。这是 EJB Entity Beans 未被广泛采用的关键原因。

在 Windows .NET 框架中，数据访问基于 DataSet 术语；DataSet 包含可靠的数据源中的部分数据，并由于一个或多个 SQL 查询进行描述。DataSet 中的数据可能保留固定的联系，开发人员可以直接对数据进行操作，可以实现数据与 XML 之间的相互转换，可以使用标准的 SQL 筛选数据，并进行其他操作。总之，与 EJB Entity Beans 相比，.NET DataSet 模型提供了更丰富、更简便和更常用的数据访问方式。

5. 易用性

a. 配置 - 早期的 J2EE 通过部署描述文件完成配置，部署描述文件为 XML 文件，与实施业务逻辑的实际代码完全不同。这种方法存在一些问题。首先，对于特定类的元数据，有时对代码的更改和对元数据的更改是相互依赖的。对两个不同文件必须同步的要求可能导致出错。第二，对于"应用程序层"元数据，在 J2EE 中无法继承早期的元数据。相对于 J2EE，Windows .NET 框架可以将属性直接附加到源代码中的类，避免了上述问题。.NET 中的元数据模型允许自定义扩展，因此开发人员可以创建并使用自己的属性。在 Windows .NET 框架中，外部的配置元数据包含在配置文件的架构系统中，配置文件从父级文件中继承设置，用户可以仅指定更改的设置，因此文件很小，使用简便。这样就避免了 J2EE 模型的第二个问题。

b. 数据库连接池 – 在 Windows .NET 框架中，可根据需要自动建立并管理缓冲池。在 J2EE 模型中，用户必须单独配置并管理连接池。

c. XML Web 服务 – 在 .NET 中建立"XML Web 服务"就像添加类的属性一样简单。虽然一些基于 J2EE 的产品正试图在 Java 中模仿该功能，但 .NET 已明确提供了更简单的方式建造并使用可交互操作的"XML Web 服务"。

d. 部署 – 若要在 .NET 中部署应用程序，管理员只需复制文件。在 J2EE 中，管理员必须将完成编译的文件捆绑到 JAR，转换为 WAR，再转换为 EAR，然后将所有文件打包并通过特定服务器的"部署工具"运行，然后复制结果文件。这个包含多个步骤的部署过程意味着典型的编辑/编译/调试周期明显加长了。此外，由于动态类加载的需要，更新一个单独的类通常需要重新启动基于 J2EE 的服务器。

6. 成本

a. 对于部署，运行在 Windows .NET 框架上编写的服务器应用程序需要 Windows Server 许可，其价格要明显低于三种兼容 J2EE 的服务器的许可。部署由 4 台 Web 服务器构成的服务器场的价格差异可以达到数十万美元。例如，购买 4 台装有 4 枚处理器的 Microsoft Windows Server 2003 (Enterprise) 的许可并组成服务器场，需要花费不到 $16,000（按照零售价计算的总额）。如果同样为这些服务器购买 WebSphere Application Server 5.0 许可，则每一枚处理器需要 $12,000，或总共花费 $192,000。其价格比达到 12 : 1。大多数最常用的基于 J2EE 的应用程序服务器的价格与此相仿。[值得注意的是：我们目前仍假定它们具有相同的性能；但是据 Middleware Company 在 2002 年 10 月的报告显示，在使用相同硬件的情况下，在 Windows .NET 框架上建造的应用程序的性能比常用的基于 J2EE 的应用程序服务器上建造的同样的应用程序的性能要高出 2-4 倍。因此 Windows 实际的效费比优势高于 12 : 1。]目前已有基于 J2EE 的免费、开放源代码的应用程序服务器，但没有兼容 J2EE 的类似产品。这又是一个规范和产品的问题：用户需要在产品之间进行比较来讨论购买许可的花费。

b. Windows .NET 框架的部署工具价格更低。用于 .NET 的集成开发工具 - Visual Studio .NET 的许可费用要显著低于 J2EE 厂商的开发工具的价格。作为业界最佳的开发工具，Visual Studio .NET 已获得了一系奖项。对 Visual Studio .NET 及其竞争产品进行评估的客户评价，使用 Visual Studio 的开发人员的生产效率显著高于使用最佳 Java 工具的开发人员（请参阅 Giga，2002 年 6 月）。

c. 使用 Windows .NET 框架的开发和维护费用更低。据专家分析，典型开发项目中的软件购买和许可费用仅占项目费用的一小部分。通常，软件开发和维护费用约占整个项目周期成本的 50-80% (Glass, 2002; Kemerer, 1995; Gartner, 2001)。据 Middleware Company 2002 年 10 月的调查显示，在 Windows .NET 框架上开发的特定应用程序的代码长度仅为在基于 J2EE 的平台上开发的程序的代码长度的 1/3。较短的代码意味着更轻松的维护工作。

很明显：在对实际产品进行评估以前无法确定购买的产品。将 Microsoft Windows Server 和 Windows .NET 框架与（Sun 的规范）J2EE 进行比较有一定的作用，但如果没有实际的产品比较，规范定义的比较是没有意义的。现在我们可以得出一些结论。

J2EE 采用了以服务器为中心的体系，并将重点放在 EJB 和解决"对象关系映射问题"。J2EE 缺乏对 XML 和 Web 服务的支持。Windows .NET 框架的体系为通过协议标准和 XML 进行的大规模分布式计算，充分利用服务器、台式机和其他设备的计算功能。

与在 Windows .NET 框架上编写的应用程序相比，J2EE 应用程序需要更多的代码来执行同样的任务。

J2EE 的管理和部署模式类似于大型机，强调保护或限制对有限计算资源的使用，并进行资源优化。Windows .NET 框架体现的理念为，计算机的计算能力不断提高，价格也更加低廉，但开发仍是一项艰巨的任务。

总之，如果项目规定必须能够在多种操作系统之间选择使用开发平台；可以忽视购买许可的费用；可以限制（培训）开发人员必须使用单独的编程语言；可以忽视代码的版本控制；重视分配并限制价格相对低廉的计算资源；可以使用昂贵和复杂的开发和管理工具；可以接受编写冗长的代码 – 则 J2EE 可能是一个正确的选择。

但是，如果用户重视开发人员的生产效率的提高；期望获取最高的效费比；希望通过使用标准通讯协议实现可互操作性；希望为基于台式机和移动设备的应用程序提供广泛的支持；希望简化部署 – 则在 Windows .NET 框架上建造用于 Windows Server 的应用程序才是正确的选择。

若要获取 .NET 的详细信息，请参阅 HTTP://WWW.MICROSOFT.COM/NET
2003 Microsoft Corporation.保留所有权利。Microsoft、.NET、Visual Studio 和 Windows 为美国和/或其他国家/地区的 Microsoft Corporation 的商标或注册商标。此处涉及的其他产品和公司的名称可能是其相应所有者的商标。