三. 異中有同同中有異
——J2EE與.NET平臺體系架構的異同
南京郵電學院 李建忠
中南大學 畢文杰

作為彼此競爭的應用平臺，J2EE和.NET開發平臺在目標和體系結構上極其相似，但在實現上又完全不同。平臺的體系架構是支撐平臺的基礎，平臺各方面的性能也會因平臺架構實現的不同而有差異。對兩個平臺產生至關重要影響的三個方面是：系統平臺基礎構造、三層/多層體系結構和移植/性能/擴展。J2EE是一個平臺規范而非產品，對等而論，在這里述及的.NET也專注于該平臺的架構規范，而較少地涉及到具體產品，盡管對.NET而言有時候這方面并不能被區分得很清楚。
類似的平臺基礎構造
一個平臺在語言編譯、代碼執行、編程支持等基礎構造方面往往會對平臺的可用性、生產性、移植性等產生重要的影響，也是我們評判一個平臺是否適合特定應用的重要依據。J2EE和.NET兩個平臺在底層的執行引擎都源于托管的虛擬機概念，但.NET的CLR沿著Java虛擬機(JVM)走得更遠。CLR在借鑒了JVM的自動垃圾收集、異常處理等機制的同時，又為.NET平臺添加了多語言支持、組件自描述等新的特性。
在.NET和 J2EE平臺上，程序的編譯都經過兩個類似的過程。首先特定高級語言編譯器將C#（及其他.NET語言）和Java源代碼分別翻譯成中間語言(IL)和字節代碼(ByteCode)。.NET在中間語言設計時通盤考慮了多個主流高級語言，在這一層面實現了.NET平臺的跨語言承諾。J2EE的基石是Java語言，它最典型的特征是：一次編寫，多次運行。跨平臺是J2EE一直引以為豪的關鍵，這是通過JVM來實現的。
其次，在執行時，中間語言被即時編譯器(JIT)編譯成特定平臺的二進制代碼，字節代碼則通過JVM解釋執行，完成各自語言的指令功能。鑒于微軟在“Wintel平臺”上的代碼優化功底，.NET代碼的執行速度較之于Java有明顯的優勢是不爭的事實。但在Unix/Linux平臺上，由于.NET遲遲未能實現其跨平臺的承諾，J2EE幾乎成了惟一的選擇，執行效率的比較也就無所謂。在代碼執行的同時，通用語言運行時和Java虛擬機也都提出了異常捕捉、類型安全、內存分配、垃圾收集等自動化內存管理工作，大大減輕了現代軟件的內存泄漏問題和程序員繁重的負擔。
面向對象程序設計在J2EE和.NET平臺中都獲得了直接的支持，單根繼承加多接口實現是它們共有的特征。但在面向對象之外，.NET對現代組件編程提供了直接支持。當然，當下的很多企業中間件都是基于J2EE平臺的,只是.NET從設計、編碼、配置到運行給予了組件編程更多、更直接的支持。
一個能夠為編程提供廣泛服務的、可從玫腁PI類庫對于現代軟件平臺非常重要。從基礎的集合、字符串操作到企業級的API接口，如JMS、JDBC、JAX、JNDI等，可以看到J2EE在這方面有著非常堅實的結構。微軟.NET框架類庫也不示弱，提供了從圖畫、網絡、線程到ADO.NET、ADSI、Windows表單、ASP.NET等一系列的API。在這些基礎的和企業級的服務上兩個平臺很難一決高下，而且對功能集合的支持很多時候是一個時間問題，往往是一個平臺推出了某一子功能集，另一個平臺馬上推出類似的功能集。
除去API類庫的無縫的功能復用外，對本地平臺的調用操作也是值得關注的一點。CLR和Java虛擬機都支持本地方法的調用。在異構平臺方面，J2EE更鐘情于IIOP（Internet InterORB Protocol），而.NET則使用SOAP。
相同的三層/多層體系
基于三層/多層分布式計算結構已毋庸置疑地成為當今企業應用的主流模式，也是兩個平臺較量的著力點。
在客戶端，表示層負責用戶與系統的交互。對于不同的處理要求，.NET和J2EE都提出了基于桌面的應用程序和基于瀏覽器的Web應用的開發組件：Java Application與Windows表單、Java Servlet/JSP與ASP.NET雙雙形成犄角之勢。但Windows表單依賴微軟桌面系統的天然優勢，不管在交互速度還是在界面的表現性能上都較Java Application稍勝一籌。Servlet/JSP與ASP.NET是目前企業在“瘦客戶端”應用的重點，兩者都基于HTTP請求/響應模型，通過HTML瀏覽器頁面完成用戶交互。雖然ASP.NET聲稱在底層通過編譯執行獲得了相當高的處理速度，以及服務器方控件的瀏覽器自適應能力，但目前并沒有這方面的硬性數據，很難據此而論高下。在緩存、狀態優化等方面兩者可謂旗鼓相當。另一個和客戶端應用相關的技術是ActiveX與Applet，但從目前的趨勢來看，它們在兩個平臺上的地位逐漸邊緣化，也不為大多數企業所接受。
在中間層，分布式業務組件負責企業應用的商業邏輯部署。由于這些業務組件經常負責處理數據庫連接、網絡資源、線程等高昂的資源，所以一直是三層/多層架構的關鍵和企業應用的核心。J2EE的EJB是一個成熟的、得到業界廣泛支持的大型企業級組件框架，而.NET組件則是建立在新型的COM+服務之上，兩者在組件與操作系統的交互、客戶端資源共享等方面都有很好的支持。EJB的核心是容器，容器是一個為組件提供服務的運行時環境，負責為組件提供諸如事務處理、持久性、安全性、組建狀態自動化管理等服務，它分離了商業邏輯和系統底層邏輯，使開發人員的工作大為簡化。.NET則通過元數據支持自描述性的組件開發、XCOPY部署以及多版本共存，而無需注冊表和描述文件，對企業客戶有一定的吸引力。
在后端數據層，兩個平臺都為數據庫連接量身定做了一套數據存取模型：J2EE的JDBC和.NET的ADO.NET。它們在支持傳統SQL數據源的同時，也都支持新型的XML數據源。這方面由于更多地涉及到具體的數據庫產品，很難說那種數據模型更有優勢。
值得指出的是，在打造三層/多層體系結構的同時，Web服務作為新一代企業計算模型也得到了J2EE和.NET平臺相當的關注，在后面的文章會有這方面的詳細評述。
不同的移植、性能和擴展
在移植性方面，微軟通過.NET 通用語言運行時來消除編程語言的差別，而J2EE則通過Java虛擬機來消除平臺差別。“選擇.NET平臺就意味著選擇Windows”，這句話至少在可預見的一段時間里仍然是一個基本事實。跨平臺是J2EE的一大賣點，也是在選擇企業應用開發平臺時的一個重要參考因素，幾乎所有的主流操作系統都提供了對J2EE的支持。實際上如果要搭建跨Unix、Windows等多個操作系統平臺，J2EE平臺幾乎是惟一的選擇。J2EE更關注跨平臺而不是跨語言。但微軟認為，如果企業的應用都能通過標準協議以Web服務的方式發布，那么平臺都是中立的。跨平臺甚至是微軟所不想的。為了吸引更多的開發者和鼓勵廣大企業廠商轉到.NET平臺，微軟提出了多語言支持，希望用跨語言的交互性來平衡跨平臺的互操作。
性能是J2EE和.NET喋喋不休的話題。二者之間著名的論戰是一個關于寵物店的范例應用。寵物店是Sun一度以來作為J2EE典型應用的展示范例，但.NET“自告奮勇”地在自己的平臺上實現了該寵物店應用，且聲稱代碼行是J2EE的1/3，效率卻是J2EE的30倍。但Sun的理由是這個范例根本不適合用來做性能比較，該范例實現也沒有做針對性能的優化，而且指責微軟通過后端數據庫優化和緩存虛抬了.NET平臺的效率。這樣的爭吵當然不能作為我們判斷的依據，目前也沒有見到更客觀的第三方評測報告。在“Wintel平臺”上我們也許沒有理由懷疑.NET的性能，而至于非Windows平臺，.NET和J2EE也不再具有可比性。
在平臺的成熟度方面，兩者也有一拼。J2EE在1999年形成了其成熟的架構，并且到今天已經有相當成熟的經過檢驗的企業應用系統。而.NET究其淵源是源自微軟以前開發企業應用程序的平臺DNA（Distributed Network Architecture），其中包括了許多已經被證實的技術，并且這些技術已經在產品中得到實現，包括微軟的事務服務器、COM+、消息隊列、SQL Server數據庫等。而對于擴展性，廣為業界接受的事實是.NET平臺的擴展思想是基于軟件的橫向擴展，而J2EE平臺的擴展思想則是基于硬件的縱向擴展。這也符合微軟和Sun各自的產品利益。
J2EE另一個重要特征就是它的架構開放性，它本身是一系列規范，而不是產品，任何符合這一規范的產品都是J2EE兼容的。這使得J2EE從制訂之初就得到了廣泛的支持。BEA、IBM、Oracle等都相繼開發了符合J2EE的應用服務器，它們的產品相互之間甚至可以兼容。而.NET在設計之初就緊緊地把平臺規范與產品膠合在一起，雖然.NET架構的一小部分具有開放性（如C#語言、通用語言基礎構造CLI 和Web服務標準），但至少目前很難想像會有一個非微軟的.NET實現。


四。Web服務誰主沉浮？
■ 柴曉路
現在已經是2002年第二季度，Gartner Group對Web服務發展的預測似乎被產品提供商稍稍延誤了，最近微軟的.NET Framework及其開發工具VS .NET剛剛正式發布。而作為Web服務世界中另一個重量級角色Sun，也為它的J2EE Framework增添了開發Web服務的強有力的工具包Java Web Services Developer Pack(WSDP)。從2002年起到2005年，Gartner Group所預測的B2C、B2B以及e-Government領域Web服務的開發和部署將會大量依賴J2EE和.NET這兩個平臺及其上的開發工具。
.NET與J2EE 對Web服務的支持
從.NET和J2EE這兩個平臺的發展歷程來看， .NET從一開始就深深打上了Web服務技術的烙印，在它的市場推廣活動中，無時無刻不凸顯其作為Web服務的開發和部署平臺的特征。可以說，.NET天生就是為Web服務準備的開發和部署平臺。相對.NET而言，J2EE是一個比較“老”的東西，最初它是為了將Java平臺拓展到企業級應用領域而制訂的一個平臺框架規范。隨著Web服務的興起和發展，J2EE平臺作為一個企業級應用的開發和部署平臺，無法回避業界的重大技術革命——Web服務。隨著Web服務技術的發展，J2EE也不斷地引入了對Web服務的支持。
從服務描述、服務實現和服務的發布、發現與綁定，以及服務的調用和執行這些不同的角度看，J2EE和.NET的支持基本不相上下，惟一的區別可能是.NET的開發工具更為方便一些，集成度更高一些。.NET是一個在J2EE之后出現的平臺，所有的重量級技術產品無一例外地都會吸收先前成功者的優點，.NET就大量地吸收了J2EE平臺的優點。其中，最重要的一點就是.NET不再完全沿襲微軟先前的技術，從.NET開始，其應用不再以本地機器代碼運行，而是編譯成中間代碼，由稱為CLR的虛擬機來運行，這樣，.NET也具備了跨平臺的可能。不過.NET的跨平臺特性主要體現在支持多種開發語言上，VB.NET、C#、C++、JScript等都可以被編譯成相同的中間代碼，使用相同的運行庫執行。
第三方廠商的支持
J2EE作為一種開放的規范，從一開始就得到了眾多廠商的支持，IBM、BEA、HP、Oracle等在J2EE的實施上都有較大的投入。目前市場上最好的J2EE應用服務器并不是Sun與Netscape合資的iPlanet，而是BEA的WebLogic和IBM的Webshpere。一年一度的JavaONE就有成千上萬的開發商參加。由于J2EE是開放的規范框架，任意廠商只要有實力都可以按照規范來開發實現，不同廠商的組件也可以在一起協同使用，當然最關鍵的是這些參與J2EE的廠商都具有很強的實力。除了微軟以外，基本上所有的軟件業巨擎都鐘情于J2EE。
然而，J2EE雖然是開放的規范，但是它的使用卻不是那么開放，每家使用J2EE技術的公司都不得不為此向Sun支付一筆不小的費用。同時也正因為Sun對J2EE規范的獨家控制，使得J2EE規范的開發進度緩慢，迄今為止，J2EE規范中并不包含對Web服務的支持，Sun推出的WSDP只是一種插件形式的擴展支持。有消息表明，在今年年底前，Sun和Java領域的其他支持商，包括IBM、Bea、Silverstream等會就J2EE如何支持Web服務達成一致，然而這一切均存在變數，其中的根結就在于Sun對Java技術的獨家控制。
同時，由于J2EE對Web服務支持的步履維艱，各大廠商分別自行開發Java平臺的Web服務支持，IBM在這個領域的步伐是飛快的，它的WSAD（Webshpere Studio Application Developer）集成了大量自行開發（部分來自于Apache.org，不過這個項目的前身是IBM發起，而后移交給Apache.org）的Web服務組件，業已成為Java領域開發Web服務的最佳開發工具，同時IBM的Websphere也慢慢向Web服務開發部署應用平臺的角色轉化。
而對于微軟的.NET而言，雖然從一開始，微軟就以獨占、壟斷、不開放的形象出現在平臺市場上。然而，它的.NET卻表現出了前所未有的開放姿態。
.NET的主力開發語言C# 已經提交給 ECMA，開始標準化，ECMA是一個致力于推動行業范圍內采用信息和通信技術的非特定供應商的國際標準組織。C#的標準化使希望在任何平臺上都可以實現 C# 編程工具的公司能夠實現其愿望。微軟 還向 ECMA 提交了微軟.NET框架的一個子集，叫做CLR（公共語言架構，Common Language Infrastructure）。這將使其他供應商能夠在各種平臺上實現 CLI，以便用.NET框架提供的基本體系結構模型編寫的軟件可以在各種平臺上用各種工具來創建。美國Ximian公司已于2001年7月啟動了一個名為Mono 的開放源碼版.NET開發項目，計劃內容包括一個C#編譯器、與微軟的CLI兼容的類庫和Linux版CLR編譯器。雖然這只是起步，然而誰也不能肯定，它不會像當初的Java那樣，從Sun的小玩具，變成了今天如此重要的開發平臺。
Web服務規范的控制
由于Web服務的各種技術都是先以規范的形式制訂，然后再交付各大開發商進行實施。所以，某個開發商如果從一開始就參與某種Web服務規范的開發，那么它的平臺就能夠以最快的速度支持這一Web服務規范。在這一點上，微軟給人以非常積極進取的印象。在Web服務領域，微軟與IBM共同主推了大量的Web服務規范，在一段時間內，兩家公司Web服務技術的市場推廣活動都是聯合舉行的，不難看出這兩家公司在這個領域背后的戰略合作關系。最初的Web服務核心技術SOAP、WSDL主要由這兩家公司制訂;后來的UDDI是由這兩家為首的多家核心企業共同制訂;再后來的一些不是核心的Web服務規范，如WS-Inspection、WSFL、WS-Security、WS-Routing、WS-License、WS-Referral等，則完全由這兩家來制訂，不難看出IBM和微軟對于Web服務的貢獻以及它們對Web服務規范的控制。
而Sun自從在XML規范的制訂中發揮了重要的作用之后，在其后的Internet規范，尤其是Web服務規范的制訂中，聲音變得非常微弱，而且似乎并沒有改善的趨勢。最近在Web服務領域中的一件大事是WS-I.org的成立。WS-I.org是為保證Web服務所承諾的互操作性而成立的一個組織，主要工作就是開發保障Web服務互操作性的相關規范，并進行規范實施的測試。WS-I.org的核心成員包括Accenture、BEA、HP、Intel、IBM、Microsoft、Oracle、SAP等，Sun不在其中，甚至都不在非核心成員的列表中。是Sun的發展戰略的問題，還是受盈利問題的困擾，我們不得而知，不過我們可以知道的是，Sun再一次在Web服務領域中落后了，由它控制的J2EE規范的狀況也就可想而知。
潛在的市場
從技術的發展來看，大型的企業用戶或有著成功實施經驗的企業用戶，并不會因為新技術的推出而盲目地否定舊技術，它們總是在保護投資的前提下，在不推翻現有架構的前提下，有選擇地挑選適合的技術。
J2EE已經是一個成熟的、成功的企業級應用解決方案，擁有大量的客戶，已經實施了J2EE的企業不太可能在Web服務的時代全面否定J2EE而去接受.NET。.NET是一個全新的架構，雖然它的開發語言中已經包含了諸如VB、C++等傳統開發語言，剛剛接觸.NET的開發人員會以為能將以前使用VB開發的代碼平滑地轉移到.NET平臺上來。其實不然，VB.NET的語法與VB 6.0已經有了根本性的差別，與其說VB.NET是VB 6.0的升級，不如說VB.NET是C#的Basic版。由于采用了CLI的結構，VB.NET將很難兼容以前的VB 6.0的代碼，大量的VB代碼無法順利地轉移到.NET上，我們期待著微軟能夠提供轉換程序以實現代碼的升級。雖然在源代碼級別上的升級變得不是那么容易，不過開發人員仍然可以在.NET平臺下，將原有的COM組件進行重新包裝，形成 .NET平臺下的Web服務組件，而且.NET的整個平臺、開發工具的高集成性和友好的開發環境還是會給開發人員留下深刻印象。在Java領域中，無論是Borland的JBuilder 6，還是Sun的Forte for Java，或是IBM的WebShpere Studio Application Developer、VisualAge for Java都無法達到VS .NET的生產效率。開發工具是.NET的一大優勢，同時.NET平臺對Web服務規范的支持力度也僅有IBM的J2EE平臺能夠與之相媲美。
因此，筆者認為在大型企業級應用場合，如果已經采用了J2EE架構，應該會在Web服務的時代繼續使用J2EE架構。而原先就是采用微軟架構的，出于技術延續性的考慮，大多數仍然會選用微軟的.NET。那些采用其他技術的企業級應用則會在開發效率、安全性、可靠性、維護代價等不同指標上對兩種架構進行考察，應該說機會是均等的，J2EE強在有大量的應用實例，而.NET強在整合集成的優秀開發部署環境。
在中小級別的應用領域，J2EE的占有率優勢不再那么明顯，一方面，長期以來微軟專長于這個領域;另一方面，Java解決方案已經是如此地深入人心，即使是中小企業也會考慮J2EE架構，在這個領域，兩者平分秋色。
而在桌面應用（Web服務客戶端）領域，除了一些管理客戶端會采用Java開發以外，絕大多數的應用毫無疑問地會在微軟平臺上開發和部署。
誰主沉浮
下面這張表格概括了對兩者的比較：
比較項目? J2EE? .NET?
對Web服務的支持?
服務描述? 好? 好?
服務實現? 好? 很好?
服務發布、發現與綁定? 好? 很好?
服務調用和執行? 好? 好?
第三方支持?
平臺提供商? 很好? 有待考察?
軟件開發商? 很好? 好?
對Web服務規范的控制? 情況復雜(注）? 很好?
市場前景?
企業級大型應用? 很好? 一般?
中小級別應用? 好? 好?
桌面應用? 差? 很好?
注：J2EE的控制者Sun對Web服務規范幾乎沒有什么控制能力，然而Sun在J2EE上的合作伙伴IBM等對Web服務規范卻具備強大的控制力，所以表格中顯示“情況復雜”。
從表格中，不難看出兩者是旗鼓相當的對手，現在就斷言誰主沉浮還為時過早。應該說，J2EE目前需要做的是盡快真正將Web服務規范融入到J2EE規范中去，從規范出發統一對Web服務的支持。而.NET迫切需要進行的則是加大平臺的開放力度，爭取改善微軟在用戶心目中獨斷、單方控制、不開放的形象。
在未來相當長時期內，J2EE和.NET都將是企業構建應用系統的重要選擇，兩個平臺將相互共存，兩者本身也在不斷地相互借鑒和完善，并且有望通過Web服務實現互操作。真正的市場，正是需要強大的競爭者之間的較量，這樣用戶才能得到最好的技術和解決方案。
小資料·
Gartner Group對未來Web服務發展狀況的預測：
2001年，Web服務的架構平臺、開發工具將基本被各大開發商開發完畢。開發人員能夠購買到這些面向服務的開發工具，同時將開始構建實際使用的Web服務。
2002年，商業Web服務將大量出現，大量的面向消費者的B2C Web服務將投入使用。
2003年，UDDI注冊中心隨著Web服務的發展，將變得越來越重要，其中的商業數據也越來越豐富。私有的UDDI注冊中心將被投入使用，以支持內部服務信息的交換。而政府的Web服務應用也將不斷出現。
2004年，各類企業將會普遍接受基于Web服務的商務應用模式，而服務集中的計算模式將進入青年期。私有的UDDI注冊中心仍然在各類應用中處于優勢地位，新的贏利模式和商業渠道將到處可見。40％的金融財務服務事務將使用Web服務模式，而35%的在線政府服務將以Web服務的形式提供。
2005年，公共的UDDI注冊中心作為公共商務信息的交換機制將大量應用。動態服務同樣將大量投入使用。