.NET真的戰勝了J2EE嗎？它能嗎？

2019-11-18 12:27:46

字體：大中小

來源：轉載

供稿：網友

　　讓我們來看看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。

上一篇：Merlin 的魔力：Java 聯網增強技術

下一篇：在J2EE平臺上實施應用性能管理