本文节选自美国ObjectWatch公司的一篇文章《J2EE vs .NET》
文章由他人翻译，本人只是转载。
如果对原文感兴趣，可以参考http://www.objectwatch.com/our_position.htm
J2EE与.NET平台之间的差别
你可以看到在J2EE与.NET平台技术之间由很大的重叠。但是，如何在它们之间进行选择呢？在本节中，笔者将讨论我所看到的主要差别。
开发商中立性
许多公司购买J2EE，他们相信这可以给他们开发商中立地位。而实际上，这是Sun公司计划的一个确定目标：
配置和实施各种满足J2EE规范需求的产品是可能的。一个可移植的J2EE应用程序在这些产品[1]中的任何一个产品中被成功部署后，都可以正确地运行。
实际上，除了Sun J2EE的拥护者，很少有人相信这是可以实现的。Paul Harmon是最重要的独立J2EE发言人之一，他是Cutter Consortium的首席顾问，广泛发行的Architecture/e-Business E-Mail Advisory的作者。虽然Harmon总是反对J2EE，但他最近对J2EE的开发商可移植性写了这样不同寻常的坦诚的评价。
EJB模型是否已经达到了我可以将EJB组件从一个EJB应用服务器移动到另一个服务器的程度？在大多数情况下不能。EJB规范不够全面。通过提供专有的解决方案来完善这个模型，确保他们的客户可以创建生产系统，EJB应用服务器开发商弥补了这一点。[2]
Harmon总结了当今开发商中立的情况， 他的评论如下：
此刻，现实情况是如果你想开发一个EJB应用程序，你应当忠心于一个开发商。[3]
今天的现实是，没有像开发商中立这样的情况。当然，.NET平台不是开发商中立的，它与微软公司的操作系统捆绑到了一起。但是两者都不是J2EE的实现。笔者可以给的最佳建议是，选择某一开发商，计划与其始终站在一起，这样可以充分利用该开发商所提供的平台优势。
整体成熟性
第一个J2EE规范，EJB规范在1998年提出，而第一个β版本出现于1999年。而这则是在与之相当的.NET平台技术，MTS，COM+的前身第一次实现的3年之后了。笔者在最近的一篇文章[4]中讨论了从MTS到COM+的发展过程。
在.NET平台比J2EE早出现两年的情况下，了解.NET平台比J2EE平台更成熟就不足为怪了。虽然我们有大量的使用.NET技术的高度可靠的网站（NASDAQ和戴尔就是众多例子中的两个），但我们不知道有哪个网站使用了J2EE平台。Paul Harmon又作了如下评论：
今天，任何一个正在尝试[基于J2EE的]公司范围的企业级系统的公司，都在尽力工作，更好的方法是让一个真正优秀的开发团队来帮助他们摆脱困境。更重要的是，它可能应当重新考虑一个综合的项目，并满足于初始近似。[5]
互用性与网络服务
诸如笔者详细讨论的，.NET平台电子协作模型是以UDDI和SOAP标准为基础的。这些标准被100多家公司广泛支持。微软公司，IBM和Ariba是这个领域的领导者。Sun公司是UDDI协会的会员，并且认识到了UDDI标准的重要性。在最近的新闻发布会上，Sun公司负责Java群体开发的副总裁George Paolini说：
“Sun公司一直在工作，以帮助建立和支持开放的、基于标准的技术，来促进基于网络的应用的增长，并且我们认为UDDI是一个重要的、为B2B电子商务建立一个注册架构的项目。”[6]
但是虽然Sun公司公开说相信UDDI标准，但实际上，Sun公司没有采取任何措施将任何一种UDDI标准合并到J2EE中。这包括最基本的、已经有一年多的UDDI标准，SOAP。正如IBM公司的Rod Smith（Emerging Technologies公司副总裁，该公司是Sun公司最强大的合作伙伴之一）所说：
迄今为止，Sun公司还没有对[UDDI]网络服务发表过得评论。但是我认为这样是有原因的。我认为他们正在考虑Java。当我们考虑网络服务的时候，我们正在倾听客户的声音和他们的需求，但事实是，客户已经有了不基于Java的系统和Java应用程序。因此，Sun公司仍然在坚持Java，但是在这个问题上非常平静。[7]
实际上，Smith对Sun公司的互用性策略的分析一语中的。Sun公司将重点主要集中在了J2EE开发商与CORBA开发商的互用性上。Sun公司的互用性想法是，应当以所谓的IIOP通信协议为基础。
利用基于IIOP的互用性，有三个主要缺陷。
第一，它需要全世界都运行J2EE或CORBA，这是一个连Sun公司的合作伙伴都反对的假定。IBM公司的Rod Smith解释了IBM支持SOAP，而不是支持IIOP作为互用性开放标准的原因：
当发布声明，并说我们[IBM]将把SOAP作为开放标准，并将其相应提前时，响应是令人无法置信的和积极的，因为人们希望进行这样的集成工作。他们拥有基于微软的解决方案。他们同时拥有基于Java的解决方案。他们还拥有基于[Windows] NT的解决方案和基于Linux的解决方案。[8]
第二个缺陷是，像所有通信协议一样，IIOP 应当服从在Internet上进行传输。这使得它不可能作为普遍的电子协作机制。
第三个缺陷是，即使全世界都同意使用IIOP和J2EE，即使在J2EE开发商中，对于确保互用性当前的IIOP规范也是不适当的。正如Paul Harmon所说的那样：
来自不同开发商的EJB应用服务器是否以能在更大的系统中咬接的方式实行了标准化？尽管使用Internet InterORB Protocol (IIOP)来支持EJB间的应用程序通讯，但仍不能随便地在一个网络中将多个EJB产品结合在一起。 将每个都依赖几个非标准工具进行平稳通信的两个EJB应用服务器仍然需要进行一些重要的程序设计工作。[9]
今天的现实情况是，与J2EE相比，.NET平台有一个更加强大的技术中性的电子协作策略。IBM公司深信不已，UDDI，而不是IIOP才是正确的互用性方法，在这个问题上，这已经与Sun公司决裂了。在这一点上，令人痛苦但却很明显的是，尽管在UDDI上已经领先了10年，但却是一个完全的失败。
可伸缩性
可伸缩性是指添加更多工作量的能力。一般来说，附加的工作量是客户的增加引起的。可伸缩性是一个复杂的问题，笔者已经在几篇已经可以得到的文章中对此进行了深入探讨[10]。未来简化这个讨论，笔者将在MoneyBroker可能会在接下来的3年中遇到的问题的上下文中讨论可伸缩性。笔者将进一步简化这个讨论，而只考虑运行商务层和数据库层的成本，尽管对表示层进行类似的分析可能会得出类似的结果。
让我们假定，MoneyBroker的商务模型要求它今年每天处理10万笔支付，明年为100万，而后年则为1000万。选择J2EE/Unix解决方案或.NET平台/Windows解决方案的相关成本有哪些呢？
为了判断MoneryBroker在接下来的3年中所需的机器规模，我们需要一个事务处理性能的标准的基准。事务处理吞吐量的工业标准基准是由所谓的Transaction Performance Council (TPC)协会规定的，该基准被称为TPC-C基准。TPC会员包括Sun、IBM、Oracle、BEA、微软和其他大部分销售中间层/数据库层产品的公司。
TPC-C基准评定了一个系统可以获得的最高工作量的等级。TPC-C基准定义的测量单位为tpmC，代表每分钟交易处理数（transactions per minute）。除了说该基准考虑的是在分布式订单输入系统环境中的交易处理外笔者将不对其进行讨论。该基准的说明可以在TPC网站[11]得到。(http://www.tpc.org/tpcc/results/tpcc_perf_results.asp?resulttype=all)
在MoneyBroker使用TPC-C数使其平台成为用户选择方面，正在面临两个问题。
第一个问题是TPC-C规定的交易处理与MoneyBroker交易处理完全不同。这需要MoneyBroker彻底审核TPC-C规范，猜测在工作量中多少TPC-C交易才能与一个MoneyBroker交易相当。我们假定MoneyBroker计算得出它的一个交易与10个TPC-C交易相当，从而有大量的富余用于处理错误。
第二个问题是，没有一个J2EE开发商已公开发布自己的TPC-C数。这使得MoneyBroker很难计算J2EE实施的吞吐量，即AIX。有趣的是，虽然所有重要的J2EE开发商已经提交了TPC-C基准，但没有一个开发商已经提交了基于他们的J2EE技术的TPC-C数。
例如，对于IBM公司的WebSphere技术（包含在J2EE技术中的IBM公司的一个品牌）有6个基准。但是，如果有人研究WebSphere的结果，就会发现没有一个基准的代码是使用Java编写的，并且没有一个基准使用了任何的WebSphere J2EE性能。实际上，这些基准使用了IBM公司传统的Encina事务处理监控技术，该产品是同时包含在总的WebSphere品牌下。类似地，BEA公司使用了其传统的Tuxedo技术来运行他们的基准，Tuxedo技术是其WebLogic品牌的一部分，但是却没有包含在J2EE中。
由于我们没有J2EE性能数字，我们得必须估计J2EE实现的相关性能。由于J2EE 基于传统的事务处理监控程序（开发商已经确定了基准），但是仍然会增加Java程序设计语言。Java虚拟机和EJB（中间层）的开销，比较合理的推测是J2EE将可以完成与之相当的非J2EE系统（如Tuxedo性能）50%的性能。因此，笔者将使用一个50%调节系数来估计J2EE的吞吐能力。
下面我们使用TPC-C 信息对MoneyBroker行为进行分析。MoneyBroker正在试图确定购买何种系统。显然，MoneyBroker希望花费尽可能少的资金，但仍确信可以获得在客户使用量达到峰值时所需的吞吐量，还确信它的系统可以进行伸缩以满足接下来的三年内的需求。
今年MoneyBroker每天需要处理10万笔交易。这相当于每分钟处理70笔交易，峰值时大约为每分钟处理700笔。由于一个MoneyBroker交易处理等于10 tpmC交易，这等于工作量达到峰值时大约为7000。明年，这个数目增加10倍达到70000 tpmC，而后年，这个数目再增加10倍，达到700000 tpmC。
那么，在接下来的三年中，这些系统需要哪些支出(包括硬件和软件在内)？让我们从J2EE/Unix的可能支出开始，因此笔者将考虑在IBM公司的AIX操作系统、WebSphere和Oracle 8i系统中，哪一个最能代表J2EE/Unix系统。对于这种配置，有6个基准。按tpmC从最低到最高的次序排列，以及J2EE调整（前面已经讨论），结果如下：
公司 系统 tpmC 总系统成本
Bull Escala T610 c/s 16,785 $1,980,179
IBM RS/6000 Enterprise Server F80 16,785 $2,026,681
Bull Escala EPC810 c/s 33,375 $3,037,499
IBM RS/6000 Enterprise Server M80 33,375 $3,097,055
Bull Escala EPC2450 110,403 $9,563,263
IBM IBM eServer pSeries 680 Model 110,403 $9,560,594
7017-S85
如果我们考虑某些有代表性的.NET平台系统（这些系统太多，不可能全部考虑，但数字非常一致），结果如下：
公司 系统 tpmC 总系统成本
Dell PowerEdge 4400 16,263 $273,487
Compaq ProLiant ML-570-6/700-3P 20,207 $201,717
Dell PowerEdge 6400 30,231 $334,626
IBM Netfinity 7600 c/s 32,377 $443,463
Compaq ProLiant 8500-X550-64P 161,720 $3,534,272
Compaq ProLiant 8500-X700-64P 179,658 $3,546,582
Compaq ProLiant 8500-X550-96P 229,914 $5,305,571
Compaq ProLiant 8500-X700-96P 262,244 $5,305,571
Compaq ProLiant 8500-700-192P 505,303 $10,003,826
你可以理解MoneyBroker 面临的选择。今年它只需一个7000 tpmC系统。在Unix市场这将大约花费200万美元，而在.NET平台市场则需要花费27.3万美元。明年MoneyBroker将需要一个70000 tpmC系统，在J2EE/Unix市场需要花费950万美元，而在.NET平台市场则需要花费350万美元。后年，MoneyBroker则需要一个700000 tpmC系统。这些系统中，没有一个被评定为700,000 tpmC，但到面前为止最靠近的系统是1000万美元的.NET平台系统。如果一个与之相当的J2EE/Unix机器存在的话，估计需要花费4750万美元。
很明显，如果系统的成本是一个重要的考虑事项，与J2EE相比，.NET平台有很大的优势。可以预计要获得相同的功能，需要花的费用是在.NET平台上所花的费用的5到10倍。如果一个工作单位在.NET平台上花10美分，同一个工作单位则可能需要在J2EE/Unix上花50美分到1美元。
笔者需要再次指出，虽然这些.NET平台基准是实际机器的实际基准，但在这些J2EE基准中，没有一个真正存在。这些基准是外推基准结果，实际的系统不一定能真正获得这些结果。在J2EE开发商发布他们的基准数之前，我们必须记住，没有一个J2EE平台已经被证明可以任何代价的情况下处理这些高工作量。
架构支持
当创建一个大型的电子商务解决方案时，不用说没有人希望从头开始。而是希望在已经完整定义的、结果测试的电子商务架构基础上创建解决方案。使用这样的架构可以极大地降低开发成本，可能至少降低10倍。
.NET平台包括一个所谓的Commerce Server电子商务架构。在这一点上，在J2EE空间内没有与之相当的开发商中立的架构。利用J2EE，你应当假定你需要从头创建你的新的电子商务解决方案。Paul Harmon看来同意这种评价，说：
选择哪一个[J2EE]开发商，如果你期望一个允许你很快实施的完善的电子商务应用程序，你将会有令人沮丧不已的体验。[12]
如果使用MS Commerce Server作为你的电子商务基础，那么很可能会对开发系统的成本有很大的影响。Commerce Server尤其适合零售业务。这样的电子商务系统应当仔细考虑这项技术。
语言
在语言方面，选择很简单。J2EE支持Java，并且只支持Java。在可预见的将来，它将不会支持其他任何种语言。.NET平台支持出Java以外的其他任何种语言（尽管它支持一种在语法和功能上与Java相当的语言，C#）。实际上，倘若.NET平台像一辆语言独立的车辆一样重要，在不远的将来，很可能任何一种出现的语言都支持.NET平台。
某些公司对J2EE支持其他语言所打动。尽管IBM公司的WebSphere和BEA公司的WebLogic支持其他语言，但是他们都不是通过J2EE技术实现的。在J2EE平台种，只有两种正式的方法来访问其他语言，一种是通过Java Native Interface，另一种方法是通过CORBA互用。Sun公司推荐采用后一种方法。正如Sun公司著名的科学家和Java设计师Rick Cattell在一次采访种所说：
你可以通过Java Native Interface功能和通过CORBA调用C++。CORBA可能是推荐的方法，因为它通过了更大的灵活性，并且我们已经设计了在认可的环境中能够很好地与CORBA一起工作的J2EE[13]。
在CORBA体系结构中创建任何新代码都是一个很有问题地策略。CORBA是20世纪90年代受人喜爱地体系结构，但现在已经不再使用了。据笔者所了解，没有一个CORBA开发商（除IONA外）在CORBA上盈利，并且没有一个开发商（包括IONA在内）在继续向该技术投资。底线是如果有人希望以Java以外的任何一种语言进行开发，那么J2EE是不正确的平台选择。
当前某些非Java公司正在考虑在Java上进行重新标准化的可能性。要实现这一点，有三种可能的方法：
对现有职员进行再培训
雇佣新职员，并尽可能地替换现有职员
外包
再培训可能是最昂贵的选择。以我的经验，有很大的管理费用与将传统的程序员培训成精通面向对象的Java程序员有关。这是Gartner集团最近的研究的结果，得出得结论是将一个COBOL程序员培训成Java程序员，每人大约需花费6万美元[14]。 笔者相信，对于Visual Basic程序员，费用大体相当。并且在训练结束，你在生产力方面一无所得。你可以简单地雇佣一个现在可以编写与花费6万美元进行培训后编写的代码相同，但现在就可以使用Java编写该代码的程序员。在许多公司中，笔者曾经看到由于采用面向对象的技术损害生产力的情况，工作时间通常会浪费在了无休止的和没有成果的关于“正确的”面向对象的设计与分析的理论讨论上。
雇佣和/或替换职员同样代价昂贵。当前，Java程序员所要求的薪水比传统的Visual Basic/COBOL程序员高30%。在笔者的经验中，他们还有更高的新雇人员比率。
对于希望转向Java的公司来说，外包可能是唯一可行的选择。但是，假定外包可以完全使你摆脱上面提到的问题是不现实的，很显然，尤其是额外的程序员成本被转移给你的情况下，更是这样。
那么你应当使用什么语言呢？底线是，如果你有经过Java培训的职员， 并且已经有了合适的策略来确保对程序设计过程的有效管理，那么尽一切办法坚持下去。笔者个人喜欢使用Java作为程序设计语言，尽管笔者认为至少有其他好的语言。另一方面，如果你的店铺主要是由Visual Basic和COBOL组成，那么转向Java差不多肯定会是代价昂贵的、令人沮丧的一次体验。
你的语言选择并不会必定决定你在J2EE和.NET平台之间的选择。当然，如果你希望使用Java以外的某些东西，那么你就处于J2EE空间之外了。但是，Java的吸引力并不需要剥夺你使用.NET平台的权利 。.NET平台包括对C#（发音为C Sharp）支持，该语言是一种与Java很类似的语言，以至于许多人第一眼还不能将它们分辨开来。一个有经验的Java程序员可以在几小时内学会C#语法。
但是，如果你选择Java不是因为J2EE所声称的可移植性策略，那么C#或任何其他可以在.NET平台上运行的语言不大可能会让你愉快的。如果这样，很明显J2EE是你的选择。但是，在做出选择之前，一定要阅读有关可移植性的章节。.
可移植性
J2EE的许多吸引力在于可移植性方面的承诺。有两种可移植性。的一种是开发商可移植性。笔者将这种可移植性称为开发商中立（vendor neutrality），前面已经讨论（并拒绝）了这种想法。第二种可移植性是操作系统可移植性（operating system portability）。这指的是在不对代码做任何改动的情况下，将代码基从一个操作系统转移到另一个操作系统的能力。与开发商中立不同，大多数J2EE实施最可能采取操作系统可移植性。
J2EE最可能会采取操作系统可移植性的原因是，在很大程度上并不是由于J2EE任何固有的可移植性，而是大多数J2EE开发商支持多种操作系统。因此，只要一个公司忠诚于一个既定的J2EE开发商和一个既定的数据库开发商，从一个操作系统转向另一个操作系统是可能的。这可能是唯一一个最重要的J2EE平台超过.NET平台的益处，而.NET平台仅限于Windows操作系统。但是，微软公司向ECMA（对JavaScript进行标准化的团体）提交C#规范和.NET Framework的一个子集（称为Common Language Infrastructure）毫无价值。
为什么开发商可移植性/中立令人满意很明显，但是操作系统可移植性有什么好处呢？我们认认为，一般有两种类型的公司需要操作系统可移植性：独立软件开发商（ISV，Independent Software Vendor）和寻求可收缩性解决方案的公司。
独立软件开发商（ISV）在有大量的非Windows平台客户群时需要操作系统可移植性。一个开发商不可能向依赖于.NET平台的Unix客户销售一件产品。如果.NET平台比J2EE好还是不好无关紧要。它并不在Unix上运行。
如果独立软件开发商的产品必须销售给非Windows客户，尤其是当J2EE平台本身需要与独立软件开发商的产品捆绑在一起作为集成产品提供时，J2EE提供了一个可接受的解决方案。
如果独立软件开发商的主要客户群是Windows客户，那么应当选择.NET平台。它可以在成本低得多的情况下提供好得多的产品。
许多需要操作系统可移植性的公司并不是独立软件开发商。这些公司的大多数公司认为可移植性是通向可收缩性的道路。这些公司相信他们，随着吞吐量需求的扩大，他们可以通过将应用程序移植到更高端硬件平台来获得更高的可收缩性。
如果你相信操作系统可收缩性能够以任何方式帮助你获得可收缩性，你正在犯一个严重错误。可收缩性不是一个硬件问题；它是一个软件问题。最高的可收缩性可以通过寻求高度可收缩的平台，然后尽可能地发挥该平台的优势获得。寻求在多个平台上运行的J2EE实施，在可获得的可收缩性方面还需很长的时间。到目前为止，在获得高可收缩性的能力方面，最好的被证明的平台是.NET平台。
使用笔者在关于可收缩性的一节中给出的数字，.NET平台可以从每分钟处理16,000笔交易增加到超过每分钟处理500,000笔交易。IBM WebSphere J2EE/Unix技术，是J2EE种类最好的代表之一，可能不会好于每分钟处理17,000到110,000笔交易，而每笔交易的成本则更高。
因此，可移植性并不是像看起来那么简单。如果你真的需要可收缩性，很明显，在.NET平台和J2EE中，.NET平台是胜者。如果你必须支持非Windows平台，那么很明显，J2EE是胜者。
如果你需要可移植性，不依赖于一时的念头或某一特定独立软件开发商的财富，那么忘掉它吧。这种 可移植性根本不存在。因此你要认真地选择开发商。确信你了解，并且对该开发商的技术指导感觉满意。确信你的开发商对该平台有一个长期的承诺。最后，确信你的开发商有财政资源以在这个高度竞争的舞台上生存。
客户端设备独立性
笔者讨论了Java和.NET平台表示层程序设计模型之间的差别。主要差别是，利用Java，决定传输给客户端的最终HTML的是表示层程序员，而使用.NET，则是Visual Studio .NET控件。
这种Java方法有三个问题。第一个问题，它需要很多位于表示层的代码，因为每个可能的瘦客户端都行需要一个不同的代码路径。第二个问题，很难使用每个可能的瘦客户端系统对代码进行测试。第三个问题，很难给现有的应用添加新的瘦客户端，因为这样做会涉及搜索和修改数量惊人的表示层逻辑。
.NET Framework方法是编写与可视控件交互的设备独立的代码。负责根据客户端设备的能力确定传送何种HTML的是控件，而不是程序员。
在.NET Framework模型中，一个人可能会忘记像HTML存在这样的事情！
这种方法解决了Java/老ASP方法的所有三个问题。一个人可以使用更少的代码。对代码进行测试更容易，因为只需对与控件的交互进行测试，而不是对客户端设备进行测试。最后，可以很容易地添加新的客户端设备，只需下载更新了关于瘦客户端设备的最新知识的控件的最新版本。
从成本角度看，.NET Framework方法是毫无疑问的胜者。如果表示层开发人员不再负责确定在客户端设备上显示哪些内容的话，开发、测试和维护将会容易得多（、便宜得多）。
结论
对于电子商务体系结构，我们有两个互相竞争的构想。
Sun公司的J2EE构想是以众多开发商可以实施的一族规范为基础的。任何公司都可以许可和实施该项技术，在这种意义上讲，J2EE是开放的，
但是从只有一个开发商控制该技术来说，它是封闭的，是一个具有非常有限的与外界互相影响的自我满足的体系结构的孤岛。
J2EE的一个主要缺点是，选择该平台表明使用一种程序设计语言，一种不很适合大多数企业的语言。
J2EE的一个主要优势是，大多数J2EE开发商提供了操作系统可移植性。
微软的.NET平台构想是一个产品，而不是一个规范家族，带有用来定义互用性要点的规范。这种方法的住雅缺点是，如果限于Windows平台，
那么为.NET平台编写的应用程序只能在.NET平台上运行。.NET平台有几个重要的优点：
开发应用程序的成本更低，因为可以使用标准的商务语言，并且可以编写设备独立的表示层逻辑。 运行应用程序的成本更低，因为可以使用商品硬件平台（成本是它们的Unix对手的1/5）。 伸缩的能力更大，被证明的可以支持客户端数是任何J2EET平台表明的可以支持的客户端数的10倍。 互用性更强，可以将工业标准电子协作内置到平台中。
这两个平台一个最有差别的特点是整个系统的可移植性。寻求的成本电子商务平台的公司可能会由于疏忽而忽视了微软公司提供的功能。电子商务总是需要高可靠性和出色的可收缩性。第一次，这些功能能够以基于Unix的解决方案的成本的一小部分就可以在商品硬件平台上获得。
