異中有同同中有異

申請免費試用、咨詢電話：400-8352-114

異中有同同中有異

作為彼此競爭的應用平臺，J2EE和.NET開發(fā)平臺在目標和體系結構上極其相似，但在實現上又完全不同。平臺的體系架構是支撐平臺的基礎，平臺各方面的性能也會因平臺架構實現的不同而有差異。對兩個平臺產生至關重要影響的三個方面是：系統平臺基礎構造、三層/多層體系結構和移植/性能/擴展。J2EE是一個平臺規(guī)范而非產品，對等而論，在這里述及的.NET也專注于該平臺的架構規(guī)范，而較少地涉及到具體產品，盡管對.NET而言有時候這方面并不能被區(qū)分得很清楚。

類似的平臺基礎構造

一個平臺在語言編譯、代碼執(zhí)行、編程支持等基礎構造方面往往會對平臺的可用性、生產性、移植性等產生重要的影響，也是我們評判一個平臺是否適合特定應用的重要依據。J2EE和.NET兩個平臺在底層的執(zhí)行引擎都源于托管的虛擬機概念，但.NET的CLR沿著Java虛擬機(JVM)走得更遠。CLR在借鑒了JVM的自動垃圾收集、異常處理等機制的同時，又為.NET平臺添加了多語言支持、組件自描述等新的特性。

在.NET和 J2EE平臺上，程序的編譯都經過兩個類似的過程。首先特定高級語言編譯器將C#（及其他.NET語言）和Java源代碼分別翻譯成中間語言(IL)和字節(jié)代碼(ByteCode)。.NET在中間語言設計時通盤考慮了多個主流高級語言，在這一層面實現了.NET平臺的跨語言承諾。J2EE的基石是Java語言，它最典型的特征是：一次編寫，多次運行?？缙脚_是J2EE一直引以為豪的關鍵，這是通過JVM來實現的。

其次，在執(zhí)行時，中間語言被即時編譯器(JIT)編譯成特定平臺的二進制代碼，字節(jié)代碼則通過JVM解釋執(zhí)行，完成各自語言的指令功能。鑒于微軟在“Wintel平臺”上的代碼優(yōu)化功底，.NET代碼的執(zhí)行速度較之于Java有明顯的優(yōu)勢是不爭的事實。但在Unix/Linux平臺上，由于.NET遲遲未能實現其跨平臺的承諾，J2EE幾乎成了惟一的選擇，執(zhí)行效率的比較也就無所謂。在代碼執(zhí)行的同時，通用語言運行時和Java虛擬機也都提出了異常捕捉、類型安全、內存分配、垃圾收集等自動化內存管理工作，大大減輕了現代軟件的內存泄漏問題和程序員繁重的負擔。

面向對象程序設計在J2EE和.NET平臺中都獲得了直接的支持，單根繼承加多接口實現是它們共有的特征。但在面向對象之外，.NET對現代組件編程提供了直接支持。當然，當下的很多企業(yè)中間件都是基于J2EE平臺的,只是.NET從設計、編碼、配置到運行給予了組件編程更多、更直接的支持。

一個能夠為編程提供廣泛服務的、可復用的API類庫對于現代軟件平臺非常重要。從基礎的集合、字符串操作到企業(yè)級的API接口，如JMS、JDBC、JAX、JNDI等，可以看到J2EE在這方面有著非常堅實的結構。微軟.NET框架類庫也不示弱，提供了從圖畫、網絡、線程到ADO.NET、ADSI、Windows表單、ASP.NET等一系列的API。在這些基礎的和企業(yè)級的服務上兩個平臺很難一決高下，而且對功能集合的支持很多時候是一個時間問題，往往是一個平臺推出了某一子功能集，另一個平臺馬上推出類似的功能集。

除去API類庫的無縫的功能復用外，對本地平臺的調用操作也是值得關注的一點。CLR和Java虛擬機都支持本地方法的調用。在異構平臺方面，J2EE更鐘情于IIOP（Internet InterORB Protocol），而.NET則使用SOAP。

相同的三層/多層體系

基于三層/多層分布式計算結構已毋庸置疑地成為當今企業(yè)應用的主流模式，也是兩個平臺較量的著力點。

在客戶端，表示層負責用戶與系統的交互。對于不同的處理要求，.NET和J2EE都提出了基于桌面的應用程序和基于瀏覽器的Web應用的開發(fā)組件：Java Application與Windows表單、Java Servlet/JSP與ASP.NET雙雙形成犄角之勢。但Windows表單依賴微軟桌面系統的天然優(yōu)勢，不管在交互速度還是在界面的表現性能上都較Java Application稍勝一籌。Servlet/JSP與ASP.NET是目前企業(yè)在“瘦客戶端”應用的重點，兩者都基于HTTP請求/響應模型，通過HTML瀏覽器頁面完成用戶交互。雖然ASP.NET聲稱在底層通過編譯執(zhí)行獲得了相當高的處理速度，以及服務器方控件的瀏覽器自適應能力，但目前并沒有這方面的硬性數據，很難據此而論高下。在緩存、狀態(tài)優(yōu)化等方面兩者可謂旗鼓相當。另一個和客戶端應用相關的技術是ActiveX與Applet，但從目前的趨勢來看，它們在兩個平臺上的地位逐漸邊緣化，也不為大多數企業(yè)所接受。

在中間層，分布式業(yè)務組件負責企業(yè)應用的商業(yè)邏輯部署。由于這些業(yè)務組件經常負責處理數據庫連接、網絡資源、線程等高昂的資源，所以一直是三層/多層架構的關鍵和企業(yè)應用的核心。J2EE的EJB是一個成熟的、得到業(yè)界廣泛支持的大型企業(yè)級組件框架，而.NET組件則是建立在新型的COM+服務之上，兩者在組件與操作系統的交互、客戶端資源共享等方面都有很好的支持。EJB的核心是容器，容器是一個為組件提供服務的運行時環(huán)境，負責為組件提供諸如事務處理、持久性、安全性、組建狀態(tài)自動化管理等服務，它分離了商業(yè)邏輯和系統底層邏輯，使開發(fā)人員的工作大為簡化。.NET則通過元數據支持自描述性的組件開發(fā)、XCOPY部署以及多版本共存，而無需注冊表和描述文件，對企業(yè)客戶有一定的吸引力。

在后端數據層，兩個平臺都為數據庫連接量身定做了一套數據存取模型：J2EE的JDBC和.NET的ADO.NET。它們在支持傳統SQL數據源的同時，也都支持新型的XML數據源。這方面由于更多地涉及到具體的數據庫產品，很難說那種數據模型更有優(yōu)勢。

值得指出的是，在打造三層/多層體系結構的同時，Web服務作為新一代企業(yè)計算模型也得到了J2EE和.NET平臺相當的關注，在后面的文章會有這方面的詳細評述。

不同的移植、性能和擴展

在移植性方面，微軟通過.NET 通用語言運行時來消除編程語言的差別，而J2EE則通過Java虛擬機來消除平臺差別。“選擇.NET平臺就意味著選擇Windows”，這句話至少在可預見的一段時間里仍然是一個基本事實?？缙脚_是J2EE的一大賣點，也是在選擇企業(yè)應用開發(fā)平臺時的一個重要參考因素，幾乎所有的主流操作系統都提供了對J2EE的支持。實際上如果要搭建跨Unix、Windows等多個操作系統平臺，J2EE平臺幾乎是惟一的選擇。J2EE更關注跨平臺而不是跨語言。但微軟認為，如果企業(yè)的應用都能通過標準協議以Web服務的方式發(fā)布，那么平臺都是中立的?？缙脚_甚至是微軟所不想的。為了吸引更多的開發(fā)者和鼓勵廣大企業(yè)廠商轉到.NET平臺，微軟提出了多語言支持，希望用跨語言的交互性來平衡跨平臺的互操作。

性能是J2EE和.NET喋喋不休的話題。二者之間著名的論戰(zhàn)是一個關于寵物店的范例應用。寵物店是Sun一度以來作為J2EE典型應用的展示范例，但.NET“自告奮勇”地在自己的平臺上實現了該寵物店應用，且聲稱代碼行是J2EE的1/3，效率卻是J2EE的30倍。但Sun的理由是這個范例根本不適合用來做性能比較，該范例實現也沒有做針對性能的優(yōu)化，而且指責微軟通過后端數據庫優(yōu)化和緩存虛抬了.NET平臺的效率。這樣的爭吵當然不能作為我們判斷的依據，目前也沒有見到更客觀的第三方評測報告。在“Wintel平臺”上我們也許沒有理由懷疑.NET的性能，而至于非Windows平臺，.NET和J2EE也不再具有可比性。

在平臺的成熟度方面，兩者也有一拼。J2EE在1999年形成了其成熟的架構，并且到今天已經有相當成熟的經過檢驗的企業(yè)應用系統。而.NET究其淵源是源自微軟以前開發(fā)企業(yè)應用程序的平臺DNA（Distributed Network Architecture），其中包括了許多已經被證實的技術，并且這些技術已經在產品中得到實現，包括微軟的事務服務器、COM+、消息隊列、SQL Server數據庫等。而對于擴展性，廣為業(yè)界接受的事實是.NET平臺的擴展思想是基于軟件的橫向擴展，而J2EE平臺的擴展思想則是基于硬件的縱向擴展。這也符合微軟和Sun各自的產品利益。

J2EE另一個重要特征就是它的架構開放性，它本身是一系列規(guī)范，而不是產品，任何符合這一規(guī)范的產品都是J2EE兼容的。這使得J2EE從制訂之初就得到了廣泛的支持。BEA、IBM、Oracle等都相繼開發(fā)了符合J2EE的應用服務器，它們的產品相互之間甚至可以兼容。而.NET在設計之初就緊緊地把平臺規(guī)范與產品膠合在一起，雖然.NET架構的一小部分具有開放性（如C#語言、通用語言基礎構造CLI 和Web服務標準），但至少目前很難想像會有一個非微軟的.NET實現。