.NET真的战胜了J2EE吗？它能吗？

核心提示：让我们来看看J2EE和.NET各自都有哪些优势，The Middleware Company (TMC)是一家从事java培训和咨询的公司，.NET真的战胜了J2EE吗？它能吗？，由于该公司于2002年10月发表的一篇有争议的报告而引起了J2EE社团的争论，这篇有关J2EE和Microsoft .NET Framewo

　　让我们来看看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社团的担忧还在后头呢。
　　
　　关于作者:
　　
　　Budi Kurniawan是一名IT顾问，他专门从事Internet和面向对象的编程，曾教授Java和Microsoft技术。他是销量很好的Java for the Web with Servlets, jsp, and EJB;A Developer's Guide to Scalable Solutions（new Riders）一书的作者，他还开发了最受欢迎的Java Upload Bean，你可以从BrainySoftware.com得到它，许多重要的公司都得到许可并将它用于项目中了。Budi的联系方式是budi@brainysoftware.com。