看到這個標題，也許會有人表示疑惑，J2EE和.NET並不在一個層次上，怎麼能將它們放在一起呢？需要指出的是，通常所說的.NET包含了一個相當廣泛的產品家族，包括開發平臺、作業系統、伺服器、終端裝置等，此外還包括服務平臺。開發平臺只是整個.NET戰略中的一部分，所以確切地說，放在這裡的.NET應該算是.NET開發平臺。

隨著三層/多層企業資訊系統結構的深度發展和下一代分散式計算模型Web 服務的出現，企業應用中關於平臺、框架、語言的競爭也愈演愈烈。J2EE平臺在過去幾年裡一直引領著企業應用的潮流，但最近微軟強力推出的.NET平臺也開始吸引著眾多IT企業和開發人員的注意力，向J2EE平臺提出了強有力的挑戰。企業應用領域的技術對抗也因此拉開了架勢。

需要強調的是，.NET是戰略產品，而J2EE是描述產品的標準，現在有很多符合J2EE標準的產品。在可以預見的未來，它們都將是構建企業資訊系統應用的基礎性平臺，尤其是開發和部署Web服務的重要平臺。

儘管可以同時使用幾種系統平臺和語言，但對於企業來說，還需要選擇一個戰略性的平臺來實現資料的無縫整合，加速企業應用的部署。而要做出正確的選擇，首先需要充分了解兩個平臺的特點和優勢。本期專題將為您細說J2EE和.NET。

一、群力所至的J2EE
二、.NET開發平臺留住Windows開發者
三、 J2EE與.NET平臺體系架構的異同
四、 J2EE vs .NET：Web服務誰主沉浮？

一、群力所至的J2EE
中南大學 羅新星 畢文傑
企業應用系統的開發一直面臨著重大挑戰：一方面，企業應用系統面對的是一個異構的分散式環境，它必須支援與已有系統的整合性和與其他系統的互操作性；另一方面，作為為客戶、合作伙伴和企業內部提供資訊服務的平臺，企業系統還必須具有高可用性、安全性、可靠性和可伸縮性。這些要求再加上覆雜多變的使用者需求和不斷伸縮的交付時間，使得企業系統的開發越來越困難。開發商和廣大程式設計師一直在努力推動和殷切期待一個成熟、標準的企業平臺來簡化和規範企業系統的開發和部署。Java技術的出現，尤其是J2EE（Java 2 Platform Enterprise Edition）平臺的推出正是這種努力的結果，也使得企業系統的開發由此變得更加快速和方便。需要指出的是，J2EE本身是一個標準，它為不同廠商建立平臺產品提供了標準，使不同J2EE平臺產品之間的互動成為可能。

J2EE旅程
Java於1996年由Sun公司推出，當時它的主要用途是製作產生動態網頁的Applet。後來，人們發現Java的“一次開發，多次執行”、純面向物件的特性、垃圾回收機制和內建的安全特別適合於開發企業應用系統。於是，企業應用開發商紛紛在Java標準版的基礎上各自擴展出許多企業應用API，其結果導致基於Java的企業應用呈爆炸式增長。但是各企業系統API之間又不能相互相容，破壞了Java的平臺獨立性。鑑於此，Sun公司聯合IBM、Oracle、BEA等大型企業應用系統開發商於1998年共同制訂了一個基於Java元件技術的企業應用系統開發規範，該規範定義了一個多層企業資訊系統的標準平臺，旨在簡化和規範企業應用系統的開發和部署。這一規範和其定義的平臺就構成了J2EE。目前J2EE的最新版本是J2EE 1.3。需要注意的是，J2EE本身是一個標準，而不是一個現成的產品（雖然現在有很多符合J2EE標準的產品），它由以下幾個部分組成：
J2EE規範。該規範定義了J2EE平臺的體系結構、平臺角色及J2EE中每種服務和核心API的實現要求。它是J2EE應用伺服器開發商的大綱。

J2EE相容性測試站點。Sun公司提供的一個測試J2EE應用伺服器是否符合J2EE規範的站點，對通過該站點測試的產品，Sun公司將發放相容性證書。

J2EE參考實現。即J2EE SDK，它既是Sun公司自己對J2EE規範的一個非商業性實現，又是為開發基於J2EE企業級應用系統原型提供的一個免費的底層開發環境。

J2EE實施指南。即BluePrints文件，該文件通過例項來指導開發人員如何去開發一個基於J2EE的多層企業應用系統。

元件-容器 搭建體系架構
J2EE規範定義了一個基於元件的多層企業應用系統開發平臺，其邏輯結構如圖1所示。圖中的橢圓形表示元件，大矩形表示容器，包含向下文字的小矩形表示API，箭頭表示訪問，箭頭線上的文字表示相應的協議。

J2EE是一個基於元件-容器模型的系統平臺，其核心概念是容器。容器是指為特定元件提供服務的一個標準化的執行時環境，Java虛擬機器就是一個典型的容器。元件是一個可以部署的程式單元，它以某種方式執行在容器中，容器封裝了J2EE底層的API，為元件提供事務處理、資料訪問、安全性、永續性等服務。在J2EE中元件和元件之間並不直接訪問，而是通過容器提供的協議和方法來相互呼叫。元件和容器間的關係通過“協議”來定義。容器的底層是J2EE伺服器，它為容器提供J2EE中定義的各種服務和API。一個J2EE伺服器（也叫J2EE應用伺服器）可以支援一種或多種容器。在圖1中，你可能已經注意到每個容器的服務包括兩部分：J2SE（Java 2 Platform Standard Edition）和一組擴充套件的服務。這是因為J2EE是以Java標準版為基礎的，各容器在J2SE之上再根據需要提供一些擴充套件的服務，如目錄服務、事務管理、資料訪問、訊息機制、安全性等。

J2ee的核心——EJB
J2EE定義了四種元件：Applet元件、Application客戶元件、Web元件及EJB（Enterprise JavaBeans）元件。其中Applet和Application客戶元件在客戶端執行，J2EE通過Java外掛為Applet提供執行環境，Application客戶的容器就是本地Java虛擬機器。Web及EJB元件在服務端執行。J2EE中包含兩種Web元件：JSP和Servlet。它們是Web伺服器的功能擴充套件，都能生成動態Web頁面。不同的是JSP是將Java程式碼嵌入到HTML中，伺服器負責解釋執行，生成結果返回使用者（與ASP技術相似）。而Servlet是單獨的Java類，它動態生成HTML檔案返回給客戶。Web元件的容器比較典型的就是基於Java的Web伺服器。

EJB是J2EE平臺的核心，也是J2EE得到業界廣泛關注和支援的主要原因。我們知道，J2EE的一個主要目的就是簡化企業應用系統的開發，使程式設計師將主要精力放在商業邏輯的開發上。EJB正是基於這種思想的伺服器端技術，它本身也是一種規範，該規範定義了一個可重用的元件框架來實現分散式的、面向物件的商業邏輯。EJB的核心思想是將商業邏輯與底層的系統邏輯分開，使開發者只需關心商業邏輯，而由EJB容器實現目錄服務、事務處理、永續性、安全性等底層系統邏輯。

一個可部署的EJB元件包含3個部分：
Remote 介面 Remote介面定義EJB元件中提供的可供使用者呼叫的方法，也就是通常所說的實現商業邏輯的函式或過程（如計算商品價格的函式），以供遠端客戶端呼叫。在EJB元件部署到容器的時候，容器會自動生成Remote介面相應的例項，即EJB物件，它負責代理使用者的呼叫請求。

Home介面 Home介面定義一組方法來建立新的EJB物件，查詢、定位和清除已有的EJB物件。在EJB元件部署時容器也會自動生成相應的Home物件，該物件負責查詢和建立EJB物件，返回EJB物件的引用給客戶；使用者利用該引用呼叫EJB元件的方法，得到結果；最後Home物件清除EJB物件。我們可以形象地稱Home介面為EJB物件的工廠。

Enterprise Beans類 Enterprise Beans類是商業邏輯的具體實現類。其可供使用者呼叫的方法在Remote介面中定義。根據功能不同，EJB 2.0規範中定義了三種Enterprise Beans:會話Beans（Session Beans）、實體Beans（Entity Beans）和訊息驅動Beans（Message-driven Beans）。

會話Beans分無狀態和有狀態兩種。一般無狀態的會話Beans模擬商業邏輯，比如計算價格等。有狀態的會話Beans通常模擬一個客戶會話，它會臨時儲存客戶資訊，根據客戶要求呼叫其他Beans來存取資料。兩種會話Beans都不儲存狀態資訊或資料，當客戶斷開連線或伺服器關閉時，會話Beans也隨之消失。一個會話Beans的典型例子是網站上的購物車。

實體Beans模擬商業資料，它表示一個數據儲存，可以是狀態資訊或資料庫中的一條紀錄。實體Beans在客戶斷開連線或伺服器關閉後，仍有服務保證其資料得以儲存。一個實體Beans的典型例子就是客戶賬號資訊。
訊息驅動Beans在行為上很像會話Beans。不同的是僅在需要向這些Beans傳送訊息時才呼叫訊息驅動Beans,比如在需要的時候傳送使用者確認資訊等。

另外，在提交和部署EJB元件時，還需要兩個檔案：部署描述檔案，容器根據該檔案來部署Enterprise Beans，提供所要求的服務；EJB jar檔案，它是提交給EJB容器的一個部署單元，容器（應用伺服器）在部署時解開它，裝入Enterprise Beans。

EJB容器非常複雜，一般由專業的J2EE應用伺服器開發商提供，比較流行的EJB容器由IBM的WebShpere、BEA公司的WebLogic Server、Sun公司的iPlant等應用伺服器提供。EJB容器除了為EJB提供事務處理、目錄服務、永續性管理和安全性服務外，還負責EJB的部署、釋出和生命週期管理。

平臺標準服務

服務是元件和容器之間，以及容器和J2EE伺服器之間的介面，在實現層面上它就是一系列API和協議。J2EE平臺定義了一組標準的服務，其中有些服務是由J2SE提供的，有些則是J2EE對Java的擴充套件。

目錄服務　JNDI（Java Name and Directory） API為應用程式提供了一個統一的介面來完成標準的目錄操作，由於JNDI是獨立於目錄協議的，應用程式可以用它訪問各種目錄服務，如LDAP、NDS、DNS等。

資料訪問 JDBC（Java Database Connectivity) API為訪問不同型別的資料庫提供了統一的途徑，遮蔽了不同資料庫的細節，具有平臺無關性。J2EE平臺除了要求核心的JDBC API（包含在J2SE中）外，還要求擴充套件的JDBC API 2.0，它支援行集、連線池和分散式的事務處理。

事務處理 JTA（Java Transaction Architecture）定義了一組標準的介面，為應用系統提供可靠的事務處理支援。JTS（Java Transaction Service）是CORBA OTS事務監控的Java實現。JTS規定了事務管理器的實現方式，該事務管理器在高層支援JTA標準，在底層實現了OMG OTS規範的Java對映。

訊息服務　JMS（Java Message Service）是一組用於和麵向訊息的中介軟體相互通訊的API。

它既支援點對點的訊息通訊，也支援釋出/訂閱式的訊息通訊。 電子郵件 JavaMail API允許在應用程式中以獨立於平臺、獨立於協議的方式收發電子郵件。JAF（JavaBeans Activation Framework）負責處理MIME編碼，JavaMail利用JAF來處理MIME編碼的郵件附件。

CORBA相容介面　RMI（遠端方法呼叫）是在分散式物件間通訊的Java本地方法，它使應用程式呼叫遠端方法像呼叫本地方法一樣，不需要考慮所呼叫物件的位置。RMI-IIOP是RMI的擴充套件，是符合CORBA標準的物件通訊協議，也是J2EE預設的元件通訊協議。Java IDL允許J2EE應用元件通過IIOP協議訪問外部的CORBA物件。

安全服務　JAAS（Java Authentication and Authorization Service）用兩個步驟實現安全性：認證，即由使用者提供認證資訊（如使用者名稱和密碼）來獲得系統認證，這一過程又稱之為登入；授權，在被確認為合法使用者後，系統根據使用者的角色授予其相應的許可權。J2EE的授權是基於安全形色的概念，一個安全形色是一個擁有相同許可權的邏輯組。J2EE的安全形色由應用元件提供商來定義。

Web服務支援 目前J2EE還不提供對Web服務的支援。Sun提供了一套API及其實現WSDP作為對J2EE的擴充套件，但目前還不是J2EE規範的內容。在WSDP中，JAXP用來解析XML文件;JAXR向UDDI伺服器註冊Web Services；JTX/RPC用基於XML的協議（如SOAP）來發送和接收XML文件；JWSDL處理WSDL文件。雖然J2EE不是為Web服務而生，但它現在正在努力追趕Web服務的腳步。

多層應用模型
從應用的角度來看，J2EE為企業應用系統的開發提供了一種多層分散式企業應用模型。在J2EE中，應用邏輯按功能不同可以劃分為不同型別的元件，各元件根據它們所在的層分佈在不同的機器上，共同組成一個基於元件的分散式系統。

J2EE定義了一個典型的四層結構，分別是客戶層、Web層、商業邏輯層和企業資訊系統層。

 
在應用開發時，J2EE定義的四層模型可根據實際情況靈活運用。由於除了Applet外其他的元件都可以訪問資料庫、EJB元件和企業資訊系統，所以通過不同層的取捨及組合，可以衍生出許多應用軟體開發模型，如基於Web的四層模型、基於桌面應用的三層模型（不包括Web層）、B2B模型（不包括客戶層）等。如果應用系統比較簡單，一般不用EJB作為邏輯層，而直接用Web元件來實現商業邏輯和資料訪問，畢竟EJB的開發和部署費用還相當高。

 
二、.NET開發平臺留住Windows開發者
南京郵電學院 李建忠
.NET開發平臺一推出，就開始了與J2EE平臺的競爭。它的絕大部分是微軟Windows DNA(Distributed Network Architecture)的重寫，DNA是微軟以前開發企業應用程式的平臺。Windows DNA中包括了許多已經被證實的技術，新的.NET框架取代了這些技術，幷包含了Web服務層和改良的語言支援。從戰略角度看，.NET開發平臺擔負著整合.NET戰略的重任，但它最直接的目標則是努力為微軟保留住龐大的Windows使用者基礎。

 
微軟的Windows開發使用者群是微軟通過Windows作業系統獲得的最大財富。對於為什麼要推出.NET開發平臺，微軟表示，主要原因之一就是由於Java向開發者承諾的硬體和作業系統無關性，可能會導致這些使用者轉向其他平臺。雖然開發平臺本身不會給微軟帶來很多收益，但Windows程式設計師是企業內部對微軟產品的主要支援力量，商用軟體的開發者形成了向客戶銷售微軟產品的重要渠道。如果微軟可以讓開發者在.NET開發平臺上編寫應用程式，那麼就會有更多的公司購買微軟的其他產品。

認識.NET
認識.NET最好的方法是看它做什麼。.NET戰略將網際網路本身作為構建新一代作業系統的基礎，並對網際網路和作業系統的設計思想進行合理延伸，使開發人員能夠創建出與裝置無關的應用程式，以便輕鬆實現網際網路連線。.NET包括一個相當廣泛的產品家族，它們構建於XML和網際網路產業標準之上，為使用者提供Web服務的開發、管理、應用和體驗。圖1是對.NET戰略的總體描述。組成.NET戰略的五個方面包括：
.NET開發平臺 這是一組用於建立Web服務應用程式和Windows桌面應用程式的軟體元件，包括 .NET Framework（框架）、.NET開發者工具和ASP.NET。於今年3月釋出的Visual Studio .NET將是RAD開發工具中一個重要的產品。

.NET伺服器 能夠提供廣泛聚合和整合Web服務的伺服器是搭建.NET平臺的後端基礎。 .NET基礎服務 密碼認證、日曆、檔案儲存、使用者資訊等基礎服務是必不可少的。微軟正在著力建設的.NET My Services等基礎性服務平臺是這方面可以借鑑的例子。

.NET終端裝置 廣泛的連線網際網路並體驗Web服務的終端裝置是實現.NET的前端基礎。PC、PDA以及各種嵌入式裝置將在這個廣闊的天地裡發揮作用。

.NET使用者體驗 能夠滿足人們各種各樣需求的使用者體驗是.NET的最終目標，也是.NET的價值實現。

在這五個組成部分當中，.NET開發平臺中的 .net框架是.NET軟體構造中最具挑戰性的部分，其他四個部分則緊緊圍繞.NET框架來進行組織整合。

.NET 框架核心
.NET框架實現了語言開發、程式碼編譯、元件配置、程式執行、物件互動等各個層面的功能，為Web服務及普通應用程式提供了一個託管、安全、高效的執行環境。所有在.NET平臺上建立的應用程式執行都需要兩個核心模組:Common Language Runtime（CLR，通用語言執行時）和.NET Framework類庫。CLR是一個軟體引擎，用來載入應用程式，確認它們可以沒有錯誤地執行，並進行相應的安全許可驗證，執行應用程式，然後將被清除。
.NET Framework類庫則向程式設計師提供軟體元件，來編寫在CLR的控制下執行的程式碼，它們按照單一有序的分級組織提供了一個龐大的功能集，包括從檔案系統到對XML功能的網訪問的每一樣功能。該類庫為開發提供了三種基本程式設計模板：基於ASP.NET的Web表單應用、基於ASP.NET的Web服務應用和基於傳統GUI互動的Windows應用。

CLR——.NET的虛擬機器
CLR為.NET應用程式提供了一個託管的程式碼執行環境。託管意味著將原來由程式設計師或作業系統做的工作剝離出來交由CLR來完成，從而使程式執行獲得更高的安全性和穩定性。這些工作包括記憶體管理、即時編譯、元件自描述、安全管理和程式碼驗證，以及其他一些系統服務。CLR提供一個技術規範，無論程式使用什麼語言編寫，只要能編譯成中間語言，就可以在它的支援下執行，這樣.NET應用程式就可以獨立於語言。CLR還在應用程式執行環境中為基於元件的程式設計提供了直接支援，比如它支援屬性、事件、物件、繼承性、多型性、介面等元件程式設計特性。

CLR中的自動垃圾收集器負責.NET應用程式執行時的記憶體分配、物件佈局、記憶體釋放等記憶體管理問題，徹底解決了多年來困擾程式設計師的記憶體洩漏問題，大大增強了應用程式的健壯性。

即時編譯器在執行時將中間語言以呼叫的物件方法為單位動態編譯成本地二進位制程式碼。

中間語言是在.NET平臺下編譯器輸出PE檔案（Windows可執行檔案）的語言，它為.NET平臺提供了多語言支援，允許開發者使用20多種不同的程式語言。而元資料是一個內嵌於PE檔案的表的集合，描述了程式碼中資料型別等在程式碼執行時CLR需要知道的資訊。元資料使得.NET應用程式程式碼具備自描述特性，提供了型別安全保障，而這在以前需要額外的型別庫或介面定義語言（IDL）。

CLR根據託管元件的來源（如網際網路、企業區域網、本地機器）等因素確定各元件的信任度，並根據信任度來限定它們執行諸如讀取檔案、修改登錄檔等敏感操作的許可權。此外，CLR藉助通用型別系統對程式碼型別進行嚴格的安全檢查，可以避免不同元件之間可能存在的型別不匹配問題。通過程式碼訪問安全機制，開發人員可以為應用程式指定完成工作所必需的許可權。CLR不僅規定了程式碼訪問安全，還規定了基於角色的安全。基於角色的認證為網際網路上分散式元件的執行提供了安全保證。

值得指出的是，CLR通常寄宿在其他高效能伺服器的應用程式中，比如網際網路資訊伺服器（IIS）、SQL Server資料庫伺服器等。這樣，開發者可以充分利用CLR諸多安全、高效的優點來部署自己的商業邏輯。

類庫——元件和服務的家園
.NET Framework類庫由一組廣泛的、面向物件的、可被開發者用於任何程式語言的可重用類集合組成。它提供了幾乎所有應用程式都需要的公共程式碼;在此之上是許多應用程式模板，這些模板為開發網路站點和網路服務提供特定的高階元件和服務，不管是傳統的命令列程式還是Windows圖形介面程式，亦或是面向下一代網際網路分散式計算平臺的ASP.NET或Web服務應用。與在Windows和它的SDK中傳送的程式碼庫一樣，.NET框架類庫將程式設計師從繁重的程式設計細節中解放出來，而專注於程式的商業邏輯。它將核心Win32 API最常用的功能和外掛SDK的功能封裝到了一個統一的包中，並採用清晰而有條理的方式對類庫進行分組和描述，這樣開發者就能夠更方便地找到其應用程式所需要的大多數功能。下面是它所提供的一些核心服務：

系統框架服務
服務框架包括一套開發人員希望在標準語言庫中存在的基類庫，如集合、輸入/輸出、字串、資料等基類。基類庫還提供訪問作業系統服務的類，如圖畫、網路、執行緒、加密等型別。此外，服務框架也包括資料訪問類庫以及開發工具。

ADO.NET元件
ADO.NET為基於網路的、可擴充套件的應用程式和服務提供資料訪問服務。它不僅支援傳統的基於連結指標風格的資料訪問，而且對於更適合於把資料返回到客戶端應用程式的無連結資料模板，它也提供高效能的訪問支援。

XML資料元件
通過它開發人員可以對任何資料進行XML轉換、傳輸和確認，所有資料都可以被看做是XML格式的。同時，系統也支援ADO.NET資料與XML資料之間的通用轉換。

Windows表單元件
Windows表單元件為開發人員提供了強大的Windows應用程式模型和豐富的Windows使用者口，包括傳統的ActiveX控制元件和Windows XP的新介面，如透明的、分層的浮動視窗。對CLR的強大支援也是Windows表單元件令人興奮的地方之一。

ASP.NET應用服務
ASP.NET的核心是其用於處理基於低階結構HTTP請求的高效能的執行語言，其編譯執行的方式大大提高了它的效能。ASP.NET使用基於構件的.NET框架配製模板，因此它獲得了諸如XCOPY配製、構件並行配製、基於XML配製之類的優點。它還支援應用程式的實時更新，同時提供高速緩衝服務，以改善效能。

ASP.NET Web表單
ASP.NET Web表單把VB表單高效率的優點帶到了Web應用程式的開發中。ASP.NET Web單支援傳統的將HTML內容與指令碼程式碼混合的ASP語法，但是它提出了一種將應用程式程式碼和使用者介面內容分離的、更加結構化的方法。它提供一套對映傳統HTML使用者介面部件（包括列表框、文字框和按鈕）的ASP.NET Web表單控制元件和一套更加複雜的Web應用控制元件（如日曆和廣告轉板）。

對Web服務的支援
ASP.NET應用服務體系架構為用ASP.NET建立Web服務提供了一個高階的可程式設計模板。雖然建立Web服務並不限定使用特定的服務平臺，但是ASP.NET的許多優點將簡化其開發過程。使用這個程式設計模型，開發人員甚至無需理解HTTP、SOAP或其他任何網路服務規範。ASP.NET可以利用現存的體系架構和應用程式，為在網際網路上繫結應用程式提供了一個簡單的、靈活的、基於產業標準的模型。 

異中有同同中有異
——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註冊中心作為公共商務資訊的交換機制將大量應用。動態服務同樣將大量投入使用。