關(guān)于.NET技術(shù)與Sun公司的Java2企業(yè)版（J2EETM）相比較，許多客戶都想了解Microsoft公司的觀點。由于以下的幾個原因，.NET和JEE的比較有點棘手：

1)   一般來說，Windows .NET Framework是Microsoft的Windows系統(tǒng)中經(jīng)過精心定義的技術(shù)部分，而J2EE則是一個書面的協(xié)議。如果不局限于學術(shù)方面的討論，換句話說，就是在幾個應用平臺上討論這個話題的商業(yè)價值，那么僅僅比較J2EE和一個實際應用的工具是沒有意義的。

這樣實際應用的工具如：IBM公司的WebSphere應用服務，BEA的WebLogic服務或是其它類似的應用服務。

要想得到令人滿意的分析，只有進行產(chǎn)品之間的比較，例如比較開發(fā)效率。使用J2EE，開發(fā)者需要創(chuàng)建4個組件來建立一個單一的EJB。表面上看來，這只不過是為開發(fā)效率付出的一點代價而已。但是Java的一些開發(fā)工具隱藏了一些開發(fā)技巧，降低了效率。另一個例子，J2EE的部署體系十分復雜難解，類嵌入 JAR，而JAR嵌入WAR，WAR又嵌入EAR。但是在一定程度上，有些工具能自動完成部署進程。上述情況導致決定一個應用服務商業(yè)價值的關(guān)鍵因素開發(fā)效率因不同的銷售商而有差異，這主要取決于開發(fā)工具的效率。

2) 關(guān)于"J2EE全明星隊伍"的問題。當比較.NET和J2EE所有組件的集合時，這個問題就產(chǎn)生了。例如，分析者考慮開發(fā)效率時可能碰到下列問題，A公司的產(chǎn)品， B公司的應用服務程序， C公司的安全規(guī)則， D公司簡便安裝， E公司決定價格。所有這些都可能和J2EE有關(guān)。集合上述這些特征屬性，J2EE工具看起來還行：價格便宜，安裝簡便，速度快，安全性高，有超高速緩存，并且有好的開發(fā)工具，等等。但這些都無關(guān)痛癢—因為不可能同時獲得所有的這些特性。事實上，一次只能得到一個準確的特性。因為這些產(chǎn)品來自不同的公司，它們不可能合作無間。例如，IBM公司的工具不能和BEA公司的WebLogic服務同時工作，因為后者是用的Oracle公司的緩存引擎，而 Oracle的引擎不能用Iona的價格獲得，等等諸如此類。人們有時候會誤將"J2EE的所有特性集合"作為比較的基礎；但這是不合理的?？蛻粜枰氖侵酪粚σ?，產(chǎn)品對產(chǎn)品的比較。

3）比較.NET和J2EE而忽視其它應用平臺是十分重要的。J2EE是僅關(guān)注應用程序服務器的規(guī)范。但是絕大多數(shù)客戶對下列這些感興趣：應用程序服務器，端口，商業(yè)服務器和分析工具，數(shù)據(jù)庫，分離數(shù)據(jù)和流動性，信息代理，應用程序集合，容量管理，智能客戶端等等。作為對客戶要求的回應，這些因素應該統(tǒng)一工作，所有的主要銷售商應該推行整合的平臺。例如Microsoft的平臺（包括Windows系統(tǒng)的客戶端和服務器，Windows .NET Framework，Visual Studio.NET Framework，和Microsoft企業(yè)服務器）；BEA的WebLogic平臺；IBM公司的WebSphere平臺；Oracle的平臺；還有Sun公司的一個平臺。將精力集中在這些平臺的一個難題（應用服務器）上將會導致一個類似"樹林和森林"關(guān)系的問題。這樣的一個比方是合適的，但是它應該被考慮到一個更廣闊平臺的一部分。

從Microsoft的角度來看，和那些不常見的警告相比，這些是Windows .NET Framework和基于J2EE的產(chǎn)品的關(guān)鍵性的異同點。

相似點

1）  Windows .NET Framework和Java都有一個受控的運行時環(huán)境，它不但將源代碼轉(zhuǎn)換成中間語言，而且將這些中間語言編譯成本地的可執(zhí)行代碼。兩個環(huán)境都支持碎片整理、動態(tài)類加載和異常處理等。

2）  .NET和Java都倡導和支持基于組件的設計、多態(tài)性、繼承和接口等，也提供基礎類庫來執(zhí)行I/O、XML處理、帶有連接池的數(shù)據(jù)庫接入、文本操作與網(wǎng)頁腳本編寫等。

3）  兩者都經(jīng)過特有的銷售商的產(chǎn)品進行發(fā)布。J2EE規(guī)范自己是"銷售中立"的，但實際上那些遵從規(guī)范的產(chǎn)品都必須實現(xiàn)規(guī)范外的特性，例如管理特性或是展開特性。因此，這些產(chǎn)品必須是對應特定的銷售商。例如Microsoft公司的Windows和.NET系統(tǒng)。

4）   Windows .NET Framework和基于J2EE的產(chǎn)品都和第三方的產(chǎn)品一起工作。例如，在后端數(shù)據(jù)庫領域，.NET和基于J2EE的應用程序能訪問儲存在Microsoft的SQL服務器、IBM的DB2、Oracle，Informix、Sybase等服務器里面的數(shù)據(jù)。再舉一個例子，.NET和基于J2EE的系統(tǒng)能訪問流行的信息中間設備，如Microsoft的MSMQ或是IBM的MQSeries。同樣，也包括文件系統(tǒng)，第三方開發(fā)工具，代碼版本系統(tǒng)，防火墻等。

不同點

1）  原理

J2EE是一個單一語言的平臺，關(guān)注跨平臺的可移植性。這就意味著，要利用J2EE，設計方案能使用多個操作系統(tǒng)其中的一個，但開發(fā)者必須接受關(guān)于Java的培訓。Microsoft提供的.NET構(gòu)架作為Windows系統(tǒng)的一部分。開發(fā)者能使用多種語言，并且效率很高而不用進行一種新語言的重新訓練。但.NET Framework是 Windows系統(tǒng)的一部分。

2）  寬度和廣度

a.       .NET包括代碼、產(chǎn)品、工具和構(gòu)架，來利用網(wǎng)絡上全部的計算資源，包括設備、個人電腦和服務器等。.NET使所有的這些設備能經(jīng)過標準通訊協(xié)議全部連接在一起，即所謂的"XML WEB服務"。（.NET應用程序可以和任何一個系統(tǒng)連接，無論系統(tǒng)用什么語言和平臺，甚至是J2EE。只要目標系統(tǒng)遵照XML WEB服務標準。）.NET模型是廣泛的分布式計算，它和許多代碼互相通訊并交換信息。

b.       J2EE是面向服務器的模型，它并不開發(fā)網(wǎng)絡上的智能和計算功能?？偟膩碚f，基于J2EE的產(chǎn)品只支持服務器端的應用程序。J2EE一般把PC只看作是一個HTML的瀏覽器，而將這些設備認為是啞終端。至于 XML WEB服務，現(xiàn)有的協(xié)議標準支持分布式的計算，現(xiàn)有版本的J2EE規(guī)范并沒有提到XML WEB服務的問題，但是基于J2EE的產(chǎn)品在添加了附加裝置后也可以支持XML Web服務。然而，添加附加裝置也就意味著有嚴格的限制。例如，還不清楚現(xiàn)有的規(guī)范是否允許EJB調(diào)用Web服務，雖然Web服務的組件能調(diào)用一些EJB程序。

3）  編程模型的一致性

Windows .NET Framework提供了一個跨服務器、PC和其它設備的一致的、面向組件的模型。而J2EE提供EJB作為服務器端的組件模型；為客戶端或是本地組件建立開放的完全用Java編寫的API；為用戶界面提供servlet；也為移動設備提供另一種不同的模型。甚至在EJB內(nèi)部也有至少3種明顯不同的子模型，每一種子模型都有不同的語言定義。

 

Microsoft的.NET編程模型與Java平臺相比較，在各種服務器和客戶端上有更好的一致性。J2SE是基于開放的完全用Java編寫的API，而J2EE是基于Java servlet和EJB。

DH Brown, 2002年7月

 

4）  功能

a.       Windows .NET Framework 提供一個能識別版本的類加載器，這就意味著應用程序的開發(fā)者能確保他們開發(fā)的應用程序在一部分代碼已經(jīng)更新的情況下仍能運行。而Java和J2EE（現(xiàn)有的）沒有版本識別的類加載器，這就意味著開發(fā)者和管理員不能保證代碼被執(zhí)行時是正確的。或是說，開發(fā)者只能靠運氣來保證這一點。

b.       Windows .NET Framework 顯示了語言層面上的類屬性—這就使得編程更加簡單。例如，在源代碼中只用一個簡單的屬性就能把.NET組件標志為處理模式?；蛘哒f，一個.NET組件和 XML的串行化可以在一個屬性中被定義。這個機制大大簡化了許多編程任務。而Java不顯示語言層上的類屬性，雖然Sun公司考慮到要修改Java語言來改變現(xiàn)狀。這種變化估計在兩三年內(nèi)才能第一次實現(xiàn)。

c.       .NET還支持分離數(shù)據(jù)訪問，這主要用于在移動設備或是偶爾聯(lián)網(wǎng)的場合里運行的應用程序。數(shù)據(jù)能被脫機操作，接著再和起始數(shù)據(jù)重新同步。而不論是J2EE還是J2SE現(xiàn)階段都不支持分離數(shù)據(jù)訪問，需要這項功能的 J2EE開發(fā)者必須自己寫"plumbing code"。

d.       為建立基于網(wǎng)絡的用戶界面， Windows .NET Framework提供基于事件的模型，這些模型類似于流行的Visual Basic中的智能客戶端模型。ASP .NET 模型使得建立、發(fā)布和維護一個基于網(wǎng)絡的用戶界面變得更加容易。與之形成對比的是，J2EE在JSP中不支持這樣的模型。有一些第三方的擴展程序部分彌補了這些功能，但是它們的實用性和簡便性不能和ASP .NET相比。作為一個推薦的J2EE附加程序，Java Server Faces可能做到這一點。但這個附加程序并沒有包括在J2EE的1.4版本以前。而要獲得銷售商的支持，則又需至少一年的時間。

e.       J2EE支持一個對象相關(guān)的數(shù)據(jù)映像模型，它被稱作EJB Entity Beans。這樣是為了允許開發(fā)者更容易地從一個相關(guān)的數(shù)據(jù)庫建立對象模型。然而，實際上把這個想法編程實現(xiàn)卻要面對下列問題：

Ⅰ. 易用性：當那些熟知的、正規(guī)定義的、被廣泛支持的結(jié)構(gòu)化查詢語言（SQL）和開發(fā)者的數(shù)據(jù)相互作用時，開發(fā)者不得不放棄它們，而使用一個被稱為EJBQL 的弱定義查詢語言。和SQL相類似，EJBQL的功能并不強大（例如，在現(xiàn)有的規(guī)范中，它沒有ORDER BY的語句，這樣開發(fā)者就沒法使用特定數(shù)據(jù)庫的 SQL擴展），而它的語義也沒有被正規(guī)定義。還有，在對象間建立聯(lián)系和附屬關(guān)系十分困難，而且在對象間和XML以及后端之間的數(shù)據(jù)翻譯是手動控制的。

Ⅱ.性能：基于EJB系統(tǒng)的性能仍是一個未知數(shù)。沒有提供公開的基準?？蛻舴从?，得到的性能遠遠偏離了Entity Beans，并且轉(zhuǎn)向一個更直接的數(shù)據(jù)訪問策略。這是EJB Entity Beans沒有被廣泛使用的一個關(guān)鍵因素。

在Windows .NET Framework 中，數(shù)據(jù)訪問是基于數(shù)據(jù)集比較的。數(shù)據(jù)集保存了相關(guān)數(shù)據(jù)的一個子集，它由一個或多個SQL查詢語句描述。數(shù)據(jù)集中的數(shù)據(jù)可能保存關(guān)鍵的聯(lián)系，并且開發(fā)者能直接對數(shù)據(jù)進行操作，能將數(shù)據(jù)轉(zhuǎn)換成XML格式和上次操作的類型，能使用標準的SQL過濾數(shù)據(jù)等?？偠灾鄬τ贓JB Entity Beans，. NET的數(shù)據(jù)集模型提供一個更豐富而且簡單熟悉的途徑。

5）  簡便性

a．  配置：對于J2EE，配置是由部署描述信息獲得的XML格式的文件，它們和實際執(zhí)行的商用邏輯代碼有明顯區(qū)別。這種方法有很多問題。第一，考慮到特定類的元數(shù)據(jù)，有些代碼中的改變和元數(shù)據(jù)中的改變是相互依賴的。兩個獨立文件的同步性要求有可能產(chǎn)生錯誤。第二，考慮到應用程序?qū)拥脑獢?shù)據(jù)，在J2EE中，沒有可以從一個程序繼承元數(shù)據(jù)到另一個程序的途徑。與J2EE不同，Windows的.NET構(gòu)架包括了這個功能，使得可以在源代碼中直接向類添加屬性，這樣就不會產(chǎn)生第一個問題。 Windows .NET中的元數(shù)據(jù)模型允許客戶自己添加擴展程序，這樣開發(fā)者就可以編寫和使用自己的屬性。為了在Windows的.NET構(gòu)架中配置外部元數(shù)據(jù)，這個功能被包括在配置文件的分級系統(tǒng)中，它能從父系統(tǒng)中繼承屬性，這樣每個文件會很小，它只記錄改變的設定。這就避免了J2EE模型的第二個問題

b．  數(shù)據(jù)庫連接池Windows .NET Framework中，是根據(jù)需要自動建立和管理這些池的。而在J2EE模型中，連接池必須被明確配置和管理。

c．  XML Web服務：在.NET中建立一個XML Web服務就像在類中添加一個屬性那樣簡單。有些基于J2EE的產(chǎn)品也想在Java中模擬這個功能，.NET提供更簡單的方法來建立和使用可由雙方共同操作的 XML Web服務。

d．   部署：在.NET中，要部署一個應用程序，管理員只需要拷貝文件。而在J2EE中，管理員必須將很多編譯文件和JAR、WAR以及EAR綁定，然后在一個特定的服務器部署工具中解開并運行它們，接著拷貝結(jié)果檔案。這個多步部署過程意味著典型的編輯/編譯/調(diào)試循環(huán)被大大延長了。此外，由于動態(tài)加載類過程中的一些變化，更新一個簡單的類常常需要重新啟動基于J2EE的服務器。

 

雖然許多公司選擇Java作為企業(yè)發(fā)展的策略平臺，但它們的使用卻由于J2EE的復雜性而受到阻礙。Meta Group，8月

 

6）  成本

a．   為了部署，運行在Windows .NET Framework之外編寫的服務器端的應用程序需要一個Windows Server的許可，這比三個遵從J2EE的商業(yè)服務器中的任何一個許可都便宜很多。包括四個網(wǎng)絡服務器的系統(tǒng)部署費用的差別可達到數(shù)十萬美元。例如， Microsoft Windows Server 2003（企業(yè)版）的一個四機器系統(tǒng)（每個有四個pc）的許可費用不超過16，000美元（這考慮了零售因素）。而WebSphere Application Server 5.0在同樣的系統(tǒng)中每臺pc的許可費用達12，000美元，這共要192， 000美元。這個比率是12比1。大多數(shù)基于J2EE的商業(yè)應用程序服務器的價格都和這類似。（這假定了性能相等。然而實際上Middleware公司 2002年10月的報告顯示，一個建立在Windows .NET Framework上的應用程序的效率是建立在同樣流行的基于J2EE的服務器上的程序的2-4倍。所以實際上價格的優(yōu)勢遠高于12比1）有很多免費的，基于J2EE的開放源應用服務器，但是它們并沒有J2EE-compliant的商標。還有關(guān)于文件和產(chǎn)品的問題：需要產(chǎn)品之間的比較來討論采許可費用。

b．  為Windows .NET Framework開發(fā)工具的費用也更加低廉。Visual Studio .NET是.NET的整合開發(fā)工具，它的許可費用大大低于商業(yè)化的J2EE銷售商制定的開發(fā)工具的費用。并且在業(yè)界，Visual Studio .NET作為最佳開發(fā)工具贏得了一系列的大獎。評估過Visual Studio .NET和其競爭對手的客戶都說，相對于最好的Java工具，Visual Studio .NET開發(fā)效率更高（See Giga，2002年6月）。

c．   使用Windows .NET Framework的開發(fā)和維護費用更低。專家認為許可費用并不是一個項目的最大開支。典型的軟件開發(fā)和維護占項目總費用的50-80%（Glass，2002；Kemerer，1995；Gartner，2001）。Middleware公司2002年10月的研究表明，在Windows .NET Framework上一個給定的應用程序開發(fā)相對于J2EE，只需要1/3的代碼。代碼越少就意味著維護更加簡單。

總結(jié)

 

顯而易見：正確的產(chǎn)品選擇決策不可能不評估實際的產(chǎn)品。對比Microsoft Windows Server及 Windows .NET Framework和J2EE（Sun公司的規(guī)范）是有價值的，但是這樣的努力缺少實際產(chǎn)品的評估。然而，還是可以從中得出一些結(jié)論：

1）  J2EE展現(xiàn)了一個以服務器為中心的原則，并將重心放在EJB和解決"相關(guān)對象的映像問題"上。J2EE在支持 XML和Web服務上已經(jīng)落后了。Windows .NET Framework的原則則是通過協(xié)議標準和XML、充分利用服務器、接口和設備的的大規(guī)模分布式計算。

2）  相對于編寫在Windows .NET Framework上的程序，J2EE應用程序需要更多的代碼來執(zhí)行相同的任務。

3）  J2EE的管理和部署模型更像是一個主機模型，它關(guān)注保護和限制稀有的計算資源，按比率使用。而Windows .NET Framework展現(xiàn)出的原則是計算資源是廉價的，而且將更加廉價，但是部署能力將保持大部分昂貴的資源。

總之，如果一個項目要求必須從幾個操作系統(tǒng)中選擇一個作為部署平臺，而不考慮開發(fā)成本；強制（并且重新培訓訓練）開發(fā)者使用單一的編程語言來執(zhí)行這個項目，從而代碼的版本問題就不再重要；重要的是配給和限制相對便宜的計算資源；這樣使用昂貴復雜的開發(fā)和維護工具就顯得順理成章；而編寫更多的代碼也有其優(yōu)越性 -- J2EE也許是一個不錯的選擇。

然而，如果商業(yè)目標顯示最優(yōu)化的開發(fā)效率是重要的；低廉的性價比更符合要求；通過通訊協(xié)議的標準獲得的可相互操作性有較高價值；大量支持基于界面的應用程序和移動的應用程序是重要的；更感興趣的是易擴展性—這樣的話，建立一個 Windows .NET Framework上的Windows Server應用程序是正確的選擇。

最新評論