白蜂蜡和黄蜂蜡的区别:J2EE与.NET平台之间的差别

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.aspresulttype=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的解决方案的成本的一小部分就可以在商品硬件平台上获得。

.NET vs. J2EE：谁与争锋？

--==.NET vs. J2EE：谁与争锋？==--

类型：转载 | 来源：CSDN | 时间：2006-3-17 |  人气： 

文章关键字:.NET,J2EE

2005年，开发平台可谓热闹非凡，重量级的软件公司纷纷推出新的开发平台和开发工具。主打.NET的微软公司在2005年第4季度，隆重推出了酝酿已久的Visual Studio 2005及其相关的软件。其发布活动将在全球90多个国家先后举行，并且在国内巡展了20个城市，其宣传力度之大前所未有。可见微软对这个五年磨一剑的产品极为重视，把它视为今后开发平台的一注重量级筹码。

微软也试图通过这个产品与诸多的J2EE开发工具，特别是Tiger（J2SE 5.0）相抗衡。而J2EE阵营的主要开发工具厂商巨头IBM，也推出了最新版本Eclipse 3.1 RC4。Eclipse从3.1 M4开始支持J2SE 5.0的开发，IBM认为J2SE 5.0的发布是Java语言发展史上一个重要里程碑，是迄今为止在Java编程方面所取得的最大进步。

Borland公司也推出了Together 2006和Delphi 2006等产品。随着这些开发平台的相继推出，在即将到来的2006年，开发平台将展开新一轮的激烈竞争，各个公司力图在整个开发平台市场上重新洗牌。

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

J2EE平台:更开放

开放性是J2EE的一个重要特点，这也是Java发展的生命源泉。Sun公司在其发展中起着关键性作用，同时很多世界级公司如IBM、BEA、甲骨文等，都是其忠实盟友。这些都决定了开发工具是少不了的。

由于Java的开放性特点，很多厂商都会创建自己的开发工具。右表中提到的是几家主要公司的Java开发工具。此外还有甲骨文公司的Jdeveloper、赛门铁克公司的 Visual Cafe for Java、Adobe公司的JRUN以及Apache公司的ANT等也是常见的开发工具。

.NET平台:易上手

至于由微软开发的.NET平台下的开发工具，主要是基于Visual Studio系列的商业开发工具。.NET最大特点就是容易上手，是软件开发人员入门的较好选择。优异的用户界面反应速度以及与Windows的整合度，可以使软件人员较快地构建出用户界面比较好的应用程序。

其实作为一个开发平台，.NET和Java都非常成熟和稳定。但.NET比Java的诞生晚了六年，这也恰恰在某种程度上增加了.NET的优越性。因为新技术总可以借鉴旧技术的发展经验，达到取长补短的效果。

Visual Studio .NET是特性丰富的开发环境，通用语言的支持能力使开发人员能够在C++、VB和C#间自由转换。而且，Visual J#.NET还使Java开发人员可以使用所选的语言对.NET平台进行编程。编程人员利用Visual J#.NET创建基于.NET的应用程序，这些应用程序可以无缝地与使用任何其他.NET平台支持语言编写的.NET应用程序进行交互操作。

有了Visual J#.NET，Java开发人员就可利用.NET框架的丰富工具（ADO.NET、ASP.NET和许多其他工具），这些工具的功能和简单性超过了Java开发工具包（JDK）规范中的功能。

Visual Studio.NET的编辑器还支持XML文档、XML大纲、HTML和CSS的创建。比如，XML是在Java诞生之后，.NET诞生之前出现的技术，所以.NET对于XML的整合会比较完善，而Java是后来将之加入的，整合程度自然比不上.NET。下面对微软最新发布的Visual Studio 2005的特点作一个简单介绍:

微软把 Microsoft SQL Server 2005、Visual Studio 2005，以及将于明年推出的BizTalk Server 2006共同构成新一代企业级应用平台，其核心是Visual Studio 2005。

利用Visual Studio 2005以及.NET Framework 2.0 这一企业级开发平台，广大开发人员及其团队能够开发出更加高效、安全和可靠的解决方案。Visual Studio 2005增加了一系列新的工具，其中，Visual Studio Team System是一个可扩展的、支持整个软件开发生命周期的工具平台，能使软件开发团队之间更好地协作，从而开发出现代化的、具有服务导向性的解决方案。

Microsoft Visual Studio 2005 开发工具系列，有许多令人期盼已久的强化功能，包括提供更高的程序开发效率、更精简的程序代码、更佳的安全性能等。

另外该工具系列还具备一些新特色，包括.NET Framework 2.0、ASP .NET 2.0、64-bit 程序开发支持、新的Windows Form程序设计以及对行动装置解决方案的全新开发支持。

值得注意的是，首度推出的 Visual Studio Team System 是与开发工具完全整合的软件开发生命周期管理平台，与Agile方法论以及CMMI规范都相整合。

Visual Studio Team System 除了在软件开发流程上更加严谨之外，软件开发的质量与时间也更易于掌控，同时，还将Visual Studio开发工具一贯支持个人开发者高生产力的优势，延伸到支持整个高效率及流程导向的开发团队。

.NET在技术上的进步也开始体现在市场占有率上。如果以前大家对两种平台的认识是.NET可能无法胜任大规模的企业开发，那么最近的一系列调查数据则能够反驳这一观点。

IDC公司在2005年10月份进行的一项调查发现，35.7%的大公司采用.NET来开发最重要的业务软件，而使用Java的比例只有25.3%。

未来:代码管理工具比平台更重要

但现在就说Java平台将会退出竞争市场还为时过早。毕竟Java平台已经发展了这么多年，不会因为.NET的胜利而消失。而且对于大型企业来说，由于现有规模和业务种类已经十分复杂，加之有多年遗留下来的应用系统，Java平台可能还是最适当的选择。

对于软件开发人员来说，单学习哪种语言都不会找不到工作。一旦选择一方作为开发工具，惟“精实”才是惟一的出路。在此基础上去不断尝试新东西，才是IT行业的生存之道。

对于企业来说，.NET和J2EE都有自己相对稳定的用户群。虽然这两个开发平台在很多方面都有很多相同或者相似的特性，但是不等于就可以互相替换，因为双方毕竟还有许多本身的独到之处，可称为是“独门绝技”。

首先这两个开发平台的开发思路截然不同。J2EE依托于开放的工业标准，注重开源代码，强调跨平台的应用。而.NET则注重开放工具功能的日趋强大和丰富，可以兼收其他产品的优点。比如在微软的开发平台上可以兼容20多个开发语言，简单易学，界面友好，是微软产品的一贯特征。

然而微软的开发平台只能在Windows系统上运行，不支持开源代码。

一般认为，在中小企业中，微软的开发平台将继续成为主流的产品。而在大中企业中，特别是那些使用UNIX系统或者具有多个操作系统、业务环境和IT环境十分复杂、对业务要求十分苛刻的大型企业中，J2EE将继续占有较大的市场。

微软则试图将自己的开发平台向大中企业延伸，争夺J2EE原有的市场份额。J2EE则力图保住原有的市场和用户。争夺最激烈的是中型企业—它成为了两大阵营竞争的前沿阵地。这一争夺随着两大阵营的最新产品发布，将在2006年更趋白热化。

谁将在2006年的竞争中占有上风，获得更多用户的青睐？那些开发平台推出的新特点和新工具能否得到用户的认可？能否经住实践的考验？谁也无法给出确切的答案。

以Compuware公司为代表，在两大阵营夹缝中生存，推行“左右逢源”方针能否获得成功？能否走出一条融合之路，异军突起？也是我们在2006年关注的焦点之一。

现在，市面上出现了一些软件公司推出了同时支持Java和.NET两种平台的开发工具，在二者之间架起了桥梁，Compuware公司就是其中的代表。在Compuware看来，选择Java平台还是.NET平台已经不重要了，重要的是谁有一套完善、高效的软件代码管理工具。因此，两种平台并存的局面还会持续很长时间。

.NET 与 J2EE优势比较

作者:J2EE 来源:本站整理 发布时间:2007-11-14 22:24:32

让我们来看看J2EE和.NET各自都有哪些优势。

The Middleware Company (TMC)是一家从事Java培训和咨询的公司，由于该公司于2002年10月发表的一篇有争议的报告而引起了J2EE社团的争论。这篇有关J2EE和Microsoft .NET Framework的The report contained benchmark tests似乎在暗示.NET是优于J2EE的（比如提到.NET 应用程序更快更容易升级，能够用更少的时间来构建和配置，以及比J2EE 程序所用的代码更少。) 这引起了Java社团的强烈抗议，尤其当一些分析家们指出该基准（benchmarking）应该在更早一些时候颁布时更是遭到了回击。我是不会参与到这些声讨中的，我只希望能够客观地对这两种技术进行比较。

该基准是TMC公司花费了巨大的努力才研究出来的成果，然而其结果却并不那么理想。TMC最初的计划是准备在这两个平台之间进行一场公平的测试，但最终却因只联系到Microsoft而未能和BEA、IBM、Sun以及其他J2EE的成员取得联系而使得这一计划被迫中断。后来的结果显示Microsoft是该项测试的投资者。

公众们还发现TMC邀请了Microsoft的专家来对用于该基准的.NET Framework进行配置和调试，但却没有向J2EE方面寻求任何建议。也许TMC认为它本身已经是J2EE领域的专家了（它曾出版过两本备受好评的EJB书籍），就如它在其网站上声称的那样。很遗憾而且相当出乎意料的是，它并没有按照自己所推荐的最佳实践来进行实施。（你可以在www.dreambean.com/petstore.html中找到Rickard Oberg所做的分析。）

先让我们将政治和金钱放到一边。.NET Framework是否还能象去年年初发布时那样击败J2EE？到目前为止这个答案还是未知的，要等到TMC重新指导一场包括Microsoft和J2EE权威认证的测试之后才能揭晓。然而，这里我想指出为什么J2EE社团需要认真对待.NET的几点原因――我是说更认真地对待它。首先，我们来看看J2EE能够战胜Microsoft .NET的优势所在：

由于有着广泛的类库，Java的语言和技术更成熟且经过大量测试，这一点Microsoft要花好几年才能赶上。

Java是最早可用的商业语言（它比Visual Basic .NET还要更早一些）。

许多遍及世界的编译器和编程语言研究室都在使用Java，这些研究项目的结果直接提高了Java的社会知名度。比如，IBM曾采用Jikes JVM及其编译器所完成的just-in-time（JIT）优选法（optimization）。而.NET还很新，所以只有Microsoft在独自进行研究。但这种情况很快便会有所改变。

更多Java开放式资源项目是用户无需花费太多成本便可以得到的，比如Tomcat Web container和JBoss，以及Jonas EJB服务器。这些产品通常证明Java是小型的、预算有限的企业的最佳选择。

然而，没有人能够低估Microsoft（去问问Sony有多担心Xbox）。以下这些因素会证明.NET比J2EE发展得更快：

.NET运行于Windows平台，同其他产品相比，它是Microsoft产品中具有较高位置的一个。从事.NET的工程师能够访问到该操作系统的各个细节，因此对他们来说调试.NET程序是非常容易的。在J2EE 同.NET之间的任何角逐都要在Windows上进行，因为.NET还不是真正可移植的。然而，对于J2EE程序服务器来说，Windows只不过是一个黑盒子而已。

Microsoft已经证明了其在追赶新技术方面所取得的成功。仅仅用了一年时间，.NET Framework的性能已经能够同更为成熟的J2EE相提并论了。.NET甚至还实现了许多J2EE未曾实现的新技术，比如缓存（caching）和服务器端组件。在ASP.NET 页面中，只需写一行代码便可以实现缓存，因此极大地增强了性能。相反，在Java规范中还没有任何关于缓存的定义。Java开发人员不得不自己编写代码或者使用一个第三方工具来实现缓存，比如使用Jakarta Taglibs project。而且，.NET早在去年年初首次发布的时候就包含了GUI服务器端组件，而Java则会在未来的JavaServer Faces版本中包含这些组件，但这会是晚于这一技术一年之后的事了。

许多Java Web技术还没有形成标准，比如Struts，它是中等及大型Java Web应用程序所推荐使用的框架。它的使用非常普遍，但它并未被当作一个标准来采用。所以谁也无法保证这种被普遍使用的技术不会被后来的一种新标准所取代。对于首次尝试选择一个服务器端技术的人来说，这一点尤其会使人觉得困惑。而Microsoft却不同，它支持所有Redmond出台的东西。

J2EE有着相当多的参与者。这就会鼓励产生更多的创新，而许多努力都是多余的。比如BEA和IBM可以研究出导致产生同样增强性能的相同的R&D，如果他们参与竞争，那么他们一定会发展得更快。但这在商业竞争中并不一定能够实现。甚至在开放式资源的社团中的成员之间有时也会彼此竞争（包括JBoss和Jonas，Tomcat和Jetty）。另一方面，所有的.NET程序都由Microsoft来统一管理，因此也就没有什么冗余可言。

新的Java规范是由许多合作企业和个人以一种假想的民主形式共同起草的，当然这样使得即使最小的参与者也能够提出自己的想法，但这样做通常是一个耗时的漫长过程。而Microsoft新技术则是由一些小组所起草的，他们能够更快地做出决定。Microsoft已经证明了其在实现新技术方面的速度是相当快的。

的确，按照.NET Framework这样的发展速度，恐怕J2EE社团的担忧还在后头呢。

且看微软的.NET和Sun公司的J2EE如何对垒

http://tech.163.com　2006-03-21 20:21:05　来源: sun　　网友评论0 条 论坛

导 读：面对微软推出的.NET FRAMEWORK，你可能会有以下疑问：

¨     准确地讲.NET平台是什么？

¨     如何将.NET的体系结构和J2EE对比？

¨    从.NET的体系结构演绎出的一整套关于企业软件开发方案中我们能学到此什么？

在本文中作者将为你解开这些疑问。

廖永康 原文出处：http://java.sun.com/features/2000/11/dotnetvsms.html

即使你没有专门针对微软平台写过程序，你可能也会听到过微软的.NET。这是微软对最近一连串和非视窗事件竞争的回答。如果你读到过有关新闻、来自微软的撰稿、或者通过在MSDN端浏览得到的不完整的技术资料、或者你注意到了微软专家开发者会议(会上已经演示了.NET平台)的话，你可能至少还有两大疑问：

¨ 准确地讲.NET平台是什么？

¨ 如何将.NET的体系结构和J2EE对比？

如果你再深入一步的话，你可能还有第三个疑问活跃在你的脑海里：

¨ 从.NET的体系结构演绎出的一整套关于企业软件开发方案中我们能学到此什么？

.NET框架是其生命周期的十分早期阶段的产品，微软.NET部门还会不断地更深入和仔细地开发它，但是无论怎样，我们已经能够从已有的资料对这些问题作出公正的正确的回答。

它是什么？(.NET是什么？)

现在在众多的论坛中对.NET的反思，使人不禁联想起三个瞎子摸象的寓言；根据你的洞察力，可能得到非常不同的结论：有人认为.NET是微软下一代Visual Studio的开发环境；有人认为它只是一种新的编程语言(C#)；还有人为它是基于XML和SOAP的一种新的数据交换和报文的工作框架。实际上，.NET包含了这几部份内容，而且还会更多。

首先，让我们看一些具体的细节，浏览一下组成.NET平台的一系列技术构件：

¨ C#：是一种新写的描述(书)构件的语言，它将C、C++和Java的元素集成起来，并增加一些特点如：元数据标记、相关元素的开发。

¨ “公共语言运行时”：它以中间语言(IL)格式，运行字节代码，用一种语言写的代码和对象只要编译器是针对这种语言开发的，显然能够编译成IL运行时。

¨ 一组基本的可从“公共语言运行时”访问的构件(元件)，它可提供各种功能(如：连网功能、包容器功能等等)。

¨ ASP.NET：是新的ASP版本，支持将ASP编译成公共语言运行时功能(所以用任何语言写的ASP脚本，都能和IL捆绑在一起)。

¨ 视窗格式和Web格式：一种新的可从Visual Studio访问的UI构件框架。(用户接口=UI)。

¨ ADO：将XML和SLAP用于数据交换的新一代ADO数据访问构件(元件)。

.NET和J2EE如何比较？

正如我们所能看见的.NET平台，在其伞型结构下有一个技术矩阵(宝塔)。显然微软为了抓住视窗平台的开发商，正在将这些技术变成现有平台如J2EE和CORBA的代用品。但是怎样对它们进行逐项比较呢？一种方法就是将.NET和J2EE作成以下对比列表：

.NET J2EE 关键差异

C#编程语言 Java编程语言 C#和Java均来自C和C++，最显著的特 点(如垃圾收集层次结构的名字空间)在两个方面。C#借用了JavaBeans的某些构件概念(特性属性、事件等)，并增加了 某些自己的概念(如元数据标志)，但将这些特点合并成不同的语法。Java以Java虚拟机方式运行在任何平台上，而C#在可预见的将来，仅运行在视 窗环境内。C#隐含地结合到IL公共语 言运行时中，(见后)，然后按合理的顺 序(JIT)运行。编译成的字节编码或者整个编译成的自然编码。Java代码按照Java 虚拟机字节代码方式运行，它由VM解 析或JIT编译，或者整个编译成自然代码。

.NET公共元件(填补“.NET 框架结构的SDK”) Java核心API 高层的.NET元件，包括支持用XML和SOAP 的分布式访问(见ADO.NET)。

ASP.NET页面(ASP.NET) Java服务器页面(JSP) ASP.NET使用Visual Basic、C# 可能还有一 别的语言作为代码段。通过公共语言运行 时全部编译成自然代码(与此相对应<相反> 是象APS那样，每次都解析执行)。JSP使 用Java代码(段或者JavaBeans参考)，或者 编译成Java字节代码(按需或批编译要根据 JSP实现系统来决定)。 .NET公共语言运行时允许以多种语言的代码 (程序)在视窗环境下使用一组共享的元件。 优先于.NET框架的所有元件(公共元件、ASP.NET等)。

IL公共语言运行时 Java虚拟机和CORBA IDL和ORB Java的虚拟机规程，允许Java字节代码， 在任何平台上按JVM方式运行。 CORBA允许多种语言的代码使用一组共享 的对象，在任何带有ORB的平台上运行， 并不是紧密地集成到J2EE框架内。 同样的Web元件(如基于JSP的文件)在标准 的Java平台上是没有的，某些专有的元件 只能通过Java IDE等得到。

视窗格式和Web格式 Java的飘移通过MS Visual Studio的IDE而不是在本文 所说的IDE，支持视窗格式和Web格式的 RAD开发，在许多Java的IDE和工具中都 支持“飘移”(Swing)。

ADO.NET和基于SOAP的Web服务 JDBC、EJB、JMS和Java XML库(XML4J、JA-XP) ADO.NET建立在位于HTTP协议顶部的XML数据 交换的基础上(指在远程数据对象和多个应 用程序捆绑之间的数据交换)。一般说来， .NET的Web服务假定了SOAP发信模型。 而EJB、JDBC等将数据交换协议和开发者 处理权分离，不工作在HTTP、KMI/JRMP或 IIOP顶层。

该表的比较只抓住了表面现象，这里再总结一下.NET和J2EE的比较：

¨ 特点：.NET和J2EE都提供同样优秀的特点，尽管提供的方法不同。

¨ 可移植性(Portability)：.NET的核心只工作Windows环境下，但从理论上讲可以支持以多种语言开发(只要这些语言的子集/超集已经定义 好，并为他们建立了IL编译器)。也就是说：SOAP的能力允许在其它平台上的元件(部件)和.NET元件进行数据报文交换。而.NET中的一些元素：象SOAP，其恢复和查找协议，作为公共部份提供构架的核心部件(IL运行时环境、ASP.NET内部的视窗格式和Web格式元件“合同”等)仍由微软掌握，微软只扮演整个.NET开发环境和运行时环境提供者的角色。其实早就有了来自开发者协会要求微软公开这些规程，但是这和微软的标准经验相违背。

另一方面，J2EE只要遵循Java VM(规则)和一组平台需要的服务就可以在任何平台上工作(EJB包容器、JMS服务等等)。所有这些定义了J2EE平台的规程，都已经公开发表，并提供公众阅读。因此，许多供应商也提供兼容产品和开发环境。但是J2EE是单语言平台，若用其它语言调用或访问对象，可能需要通过CORBA，但是CORBA支持并不是平台普遍存在的部分。

巨大的前景：

上述最后的几点勾画出.NET和J2EE的某些关键性的差异，以及微软在这些方面所扮演的角色。微软现在正在为.NET做两件值得注意的事：通过将XML和SOAP集成到他们的信息传输方案中，从而为以其它编程语言开发商和非.NET部件打开通向.NET的道路。

通过让语言元件交叉互动，.NET正在释放Perl、Eiffel、Cobol和其它编程器，允许它们扮演微软“沙盘”的角色。这些语言的爱好者应该特别遵守规则，因为他们中大部分人在微软/SUN/OpenSource竞争中感受到约束和定界。因此，只要在他的元件发信层使用XML和SOAP，微软就能支持他们将开放性部件加到他们的平台上，从而摆脱对专用性的依赖。

浅析J2EE与。NET这两种技术的优缺点

育龙网校 WWW.CHINA- B.C0M   2009年02月22日  来源： 互联网

育龙网核心提示： 袁小蕾摘要文章论述了J2EE与。NET这两种技术各自的优缺点，以及在不同的环境下，面对不同的客户要求，应采用哪种技术更合适，对WEB程

袁小蕾

摘要文章论述了J2EE与。NET这两种技术各自的优缺点，以及在不同的环境下，面对不同的客户要求，应采用哪种技术更合适，对WEB程序员在选择自己的开发技术时有一定的帮助作用。
关键词WEB；程序员；J2EE；。NET
中图分类号TP311文献标识码A文章编号1008－1151（2005）09－0046－02

收稿日期2005－07－04
作者简介袁小蕾，女，山东寿光人，山东德州供电公司信通公司助理工程师，研究方向：企业MIS系统开发。

一、引言
在一个历史时期，我相信每一种技术，每一个开发工具只要存在就有其存在的理由，它不可能一无是处，而是根据开发需要去选择一个最合适你的技术、产品。开发技术和工具的比较没有绝对的标准。评价一种开发工具，不仅要看它对设计模式、对象结构以及治理的支持情况，更重要的是要针对具体的使用环境、开发方法、结构体系、开发群体以及用户来评价一种工具的适宜程度。
软件技术的发展日新月异，基于各种技术的WEB应用更是琳琅满目，网上有关微软。NET与SUN公司J2EE的“激战”也一直没有停止过。
二、J2EE与。NET的含义
J2EE：Java2PlatformEnterpriseEdition，是SUN公司为企业计算推出的企业级Java平台。J2EE是一个平台的一系列技术标准的组合。企业应用程序的开发必须具备在不同平台上的可互通性，而J2EE平台推出的目的便是要统一目前的各种技术，使得企业间网络、电子商务系统的开发，一样有标准平台可遵循。
。NET：微软将其对于未来计算的设想命名为。NET（dot－net）。认为未来的计算将是多个应用程序通过Internet以一种分布式的方式运行的世界。。NET框架的开发使得其它平台上的应用程序也可以访问服务提供者提供的服务，例如，。NET就是建立在诸如XML，SOAP之类的开放标准技术之上的。。NET思想的开发成果就是。NET框架，它包含通用语言运行时，。NET框架和一些高层特性，例如ASP。NET，Windows窗体。
三、J2EE与。NET的技术历史
Sun公司在1995年推出Java最初的版本，当时它的主要用途是制作产生动态网页的Applet。后来，人们发现Java的“一次编写，到处运行”、面向对象的特性、垃圾回收机制和内置的安全性非凡适合开发企业级的应用系统。于是，一些企业应用开发商纷纷在Java标准版的基础上各自扩展出许多企业应用API，使基于Java的企业应用迅速增长。但是各企业系统API之间又不能相互兼容，破坏了Java平台的独立性。于是，Sun公司联合IBM、Oracle、BEA等大型企业应用系统开发商于1998年制订了基于Java组件技术的企业应用系统开发规范，该规范定义了一个多层企业信息系统的标准平台，用以简化和规范企业应用系统的开发和部署。这一规范和定义的平台就是J2EE。
。NET技术平台一推出，就注定了它与J2EE的战争。。NET的绝大部分是微软WindowsDNA（Dis？鄄tributedNetworkArchitecture）的重写，DNA是微软以前开发企业应用程序的平台。微软为什么要推出。NET开发平台，主要原因之一就是由于Java向开发者承诺的硬件和操作系统无关性，可能导致大量微软用户转向其他平台。虽然开发平台本身不是微软利润的由来，但使用Windows操作系统的程序员是企业内部对微软产品的主要支持力量，商用软件开发者形成了向客户销售微软产品的重要渠道。假如微软可以让软件开发者在。NET开发平台上编写应用程序，那么就会有更多的公司购买微软的其他产品。
从。NET和J2EE这两个平台的发展历程来看，。NET所有组件都可以是Web服务，而Web服务也仅是一种组件。实际上，。NET框架提取出微软组件对象模型（COM）的精华，将它们与松散耦合计算的精华有机地结合在一起，生成了强大、高效的Web组件系统。。NET简直天生就是为Web服务预备的开发和部署平台。相对。NET而言，J2EE是一个比较旧的技术，最初它是为企业计算推出的企业级Java平台，是一组技术规范，随着Web服务的兴起和发展，J2EE平台作为一个企业级应用的开发和部署平台，无法回避IT业的重大技术革命———Web服务。随着Web服务技术的发展，J2EE也不断地引入了对Web服务的支持。
。NET是一个在J2EE之后出现的平台，所有的重量级技术产品都会吸收J2EE平台的优点，其中，最重要的一点就是。NET不再完全沿袭微软以前的技术，从。NET开始，其应用不再以本地机器代码运行，而是编译成中间代码，由称为CLR的虚拟机来运行。CLR有两个有趣的特征：
一是它的规范是开放式的，因而它同样适用于非视窗平台。
二是大多数语言都可以用来使用。NET框架类，并且都将获得CLR的支持。这样，。NET也具备了跨平台的可能。不过。NET的跨平台特性主要体现在支持多种开发语言上，C#、VB。NET、C++、JScript等都可以被编译成相同的中间代码，使用相同的运行库执行。
四、J2EE与。NET的应用比较
微软的东西是比较人性化的，有很多功能都从程序员的角度考虑方便了我们的编程。比如说DataGrid等等。而Java就不一样了，它主张的是“一次编译，到处使用”，有很多东西都要根据你的实际情况来配置，比起。NET要麻烦的多。所以，要论中小型软件的开发速度，Java要逊于。NET。
。NET适合中小型企业，Java适合大型企业、政府部门，但不是说大型企业和政府部门就一定要使用Java的东西，为什么大家都感觉Java的东西比。NET安全呢？我想这是由于。NET出自微软，而且只能在window系列的操作系统上运行，window操作系统在桌面PC领域几乎是垄断地位，最轻易被关注和骚扰，所以其安全问题一直在困扰微软。而Java由于是开源的，大公司、大企业、政府部门可以根据自己的需求来改写，非凡是安全机制的部分，这就需要一个合格的系统分析师、若干个技术优秀的核心程序员，也就使得J2EE产品价格不菲。
J2EE与。NET之争实际上是Linux+J2EE平台与Windows+。NET平台之争，Windows下的J2EE肯定不会好过。NET。安全性上有优势，又可跨平台，但投资周期长，成本高决定了J2EE会往大型企业方向走；而入门快，开发工具易用，投资周期短，成本低，会让。NET统治中小型应用。
至于说到跨平台，这个无疑是Java的优势，服务器端应用所依靠的硬件平台与桌面应用的PC不同，如今还是百家争鸣的情况，因此跨平台性是非常重要的，而且现有的应用也表明J2EE平台已经成为了事实的标准，因此，不管他合适与否，我们也只能继续使用。
总的来说，。NET的技术、速度、中文帮助、开发环境都要优于Java，但Java凭着跨平台这点优势就一直能和。NET竞争。究竟。NET才推出几年，肯定没有J2EE成熟，但“年轻”的技术肯定要比“年老”的技术先进。
J2EE已经是一个成熟的、成功的企业级应用解决方案，拥有大量的客户，已经实施了J2EE的企业不太可能在Web服务的时代全面否定J2EE而去接受。NET。在Java领域中，无论是Borland的JBuilder6，还是Sun的ForteforJava，或是IBM的WebShpereStu？鄄dioApplicationDeveloper、VisualAgeforJava都无法达到VS。NET的开发效率。开发工具是。NET的一大优势，同时。NET平台在对Web服务规范的支持上也只有IBM的J2EE平台能够与之相比。
五、我们该如何抉择
。NET由微软在支持。Java由IBM、BEA和一大批开源技术人员在支持。。NET开发入门快，学习曲线低，人员成本低，假如用于快速开发基于Windows的应用最好不过。唯一的问题是受限于Windows。在大型企业中，小型机以上的操作系统基本上没有Widows的份。J2EE的学习是个积累的过程，架构很多，难于学习，这也是Java技术人员薪水高的原因。
是微软让我们从繁琐的代码中解放出来，可是很多人不这么看待，他们反感微软的产品，认为这样子连普通人都可以写代码，就没意思了。有人说，选择。NET就是选择被微软牵着鼻子走，没有自由，没有前途，选择Java才是真理。使用Microsoft的。NET开发工具磨灭了人的创造性，降低了技术人员理解语言底层知识的热情，太轻易了，拖几个控件就能实现的东西谁也没必要去究其根本，久而久之，就会让人的技能平庸化，而作为技术人员自己的技术一旦变得平庸，变得可替代，也就标志着可以被淘汰。
开源软件的优点，在于它能让我们接触底层开发技术，但有一个前提，就是必须把握相应的开发技术。也就是说，只有把握了Linux下的开发技术，才真正获得了技术上的自由。
我个人认为，J2EE是在把问题做复杂。NET是在把编程简单化，我相信未来是越来越简单，技术工具的发展应该坚持简单易用原则，所以，我更欣赏。NET。还有，微软的。NET有多得拿不完的教学光盘，读不完的文件，看不完的MicrosoftPress出版品……，都是中文的。而选择J2EE你就要做好预备，查看长篇大论的英文资料。
其实说到底，选择J2EE还是。NET，一方面要看开发的实际需要，另一方面就是看微软是否继续长期垄断操作系统。J2EE和。NET都是好东西，要是能同时选择当然最好，学习J2EE是锻炼程序员“内功”的好方法，而作为新生事物的。NET也会大有前途。但不管怎么选择，踏踏实实学一些基础的东西还是最重要的，把握其本质，理解其思想是程序员成功的关键。