終于了解了下.net 和 j2ee的區別
2020-01-24 03:49:33
供稿：網友
關于.NET技術與Sun公司的Java2企業版（J2EETM）相比較，許多客戶都想了解Microsoft公司的觀點。由于以下的幾個原因，.NET和JEE的比較有點棘手：
1) 一般來說，Windows .NET Framework是Microsoft的Windows系統中經過精心定義的技術部分，而J2EE則是一個書面的協議。如果不局限于學術方面的討論，換句話說，就是在幾個應用平臺上討論這個話題的商業價值，那么僅僅比較J2EE和一個實際應用的工具是沒有意義的。
這樣實際應用的工具如：IBM公司的WebSphere應用服務，BEA的WebLogic服務或是其它類似的應用服務。
要想得到令人滿意的分析，只有進行產品之間的比較，例如比較開發效率。使用J2EE，開發者需要創建4個組件來建立一個單一的EJB。表面上看來，這只不過是為開發效率付出的一點代價而已。但是Java的一些開發工具隱藏了一些開發技巧，降低了效率。另一個例子，J2EE的部署體系十分復雜難解，類嵌入 JAR，而JAR嵌入WAR，WAR又嵌入EAR。但是在一定程度上，有些工具能自動完成部署進程。上述情況導致決定一個應用服務商業價值的關鍵因素開發效率因不同的銷售商而有差異，這主要取決于開發工具的效率。
2) 關于"J2EE全明星隊伍"的問題。當比較.NET和J2EE所有組件的集合時，這個問題就產生了。例如，分析者考慮開發效率時可能碰到下列問題，A公司的產品， B公司的應用服務程序， C公司的安全規則， D公司簡便安裝， E公司決定價格。所有這些都可能和J2EE有關。集合上述這些特征屬性，J2EE工具看起來還行：價格便宜，安裝簡便，速度快，安全性高，有超高速緩存，并且有好的開發工具，等等。但這些都無關痛癢―因為不可能同時獲得所有的這些特性。事實上，一次只能得到一個準確的特性。因為這些產品來自不同的公司，它們不可能合作無間。例如，IBM公司的工具不能和BEA公司的WebLogic服務同時工作，因為后者是用的Oracle公司的緩存引擎，而 Oracle的引擎不能用Iona的價格獲得，等等諸如此類。人們有時候會誤將"J2EE的所有特性集合"作為比較的基礎；但這是不合理的。客戶需要的是知道一對一，產品對產品的比較。
3）比較.NET和J2EE而忽視其它應用平臺是十分重要的。J2EE是僅關注應用程序服務器的規范。但是絕大多數客戶對下列這些感興趣：應用程序服務器，端口，商業服務器和分析工具，數據庫，分離數據和流動性，信息代理，應用程序集合，容量管理，智能客戶端等等。作為對客戶要求的回應，這些因素應該統一工作，所有的主要銷售商應該推行整合的平臺。例如Microsoft的平臺（包括Windows系統的客戶端和服務器，Windows .NET Framework，Visual Studio.NET Framework，和Microsoft企業服務器）；BEA的WebLogic平臺；IBM公司的WebSphere平臺；Oracle的平臺；還有Sun公司的一個平臺。將精力集中在這些平臺的一個難題（應用服務器）上將會導致一個類似"樹林和森林"關系的問題。這樣的一個比方是合適的，但是它應該被考慮到一個更廣闊平臺的一部分。
從Microsoft的角度來看，和那些不常見的警告相比，這些是Windows .NET Framework和基于J2EE的產品的關鍵性的異同點。
相似點
1） Windows .NET Framework和Java都有一個受控的運行時環境，它不但將源代碼轉換成中間語言，而且將這些中間語言編譯成本地的可執行代碼。兩個環境都支持碎片整理、動態類加載和異常處理等。
2） .NET和Java都倡導和支持基于組件的設計、多態性、繼承和接口等，也提供基礎類庫來執行I/O、XML處理、帶有連接池的數據庫接入、文本操作與網頁腳本編寫等。
3） 兩者都經過特有的銷售商的產品進行發布。J2EE規范自己是"銷售中立"的，但實際上那些遵從規范的產品都必須實現規范外的特性，例如管理特性或是展開特性。因此，這些產品必須是對應特定的銷售商。例如Microsoft公司的Windows和.NET系統。
4） Windows .NET Framework和基于J2EE的產品都和第三方的產品一起工作。例如，在后端數據庫領域，.NET和基于J2EE的應用程序能訪問儲存在Microsoft的SQL服務器、IBM的DB2、Oracle，Informix、Sybase等服務器里面的數據。再舉一個例子，.NET和基于J2EE的系統能訪問流行的信息中間設備，如Microsoft的MSMQ或是IBM的MQSeries。同樣，也包括文件系統，第三方開發工具，代碼版本系統，防火墻等。
不同點
1） 原理
J2EE是一個單一語言的平臺，關注跨平臺的可移植性。這就意味著，要利用J2EE，設計方案能使用多個操作系統其中的一個，但開發者必須接受關于Java的培訓。Microsoft提供的.NET構架作為Windows系統的一部分。開發者能使用多種語言，并且效率很高而不用進行一種新語言的重新訓練。但.NET Framework是 Windows系統的一部分。
2） 寬度和廣度
a. .NET包括代碼、產品、工具和構架，來利用網絡上全部的計算資源，包括設備、個人電腦和服務器等。.NET使所有的這些設備能經過標準通訊協議全部連接在一起，即所謂的"XML WEB服務"。（.NET應用程序可以和任何一個系統連接，無論系統用什么語言和平臺，甚至是J2EE。只要目標系統遵照XML WEB服務標準。）.NET模型是廣泛的分布式計算，它和許多代碼互相通訊并交換信息。
b. J2EE是面向服務器的模型，它并不開發網絡上的智能和計算功能。總的來說，基于J2EE的產品只支持服務器端的應用程序。J2EE一般把PC只看作是一個HTML的瀏覽器，而將這些設備認為是啞終端。至于 XML WEB服務，現有的協議標準支持分布式的計算，現有版本的J2EE規范并沒有提到XML WEB服務的問題，但是基于J2EE的產品在添加了附加裝置后也可以支持XML Web服務。然而，添加附加裝置也就意味著有嚴格的限制。例如，還不清楚現有的規范是否允許EJB調用Web服務，雖然Web服務的組件能調用一些EJB程序。
3） 編程模型的一致性
Windows .NET Framework提供了一個跨服務器、PC和其它設備的一致的、面向組件的模型。而J2EE提供EJB作為服務器端的組件模型；為客戶端或是本地組件建立開放的完全用Java編寫的API；為用戶界面提供servlet；也為移動設備提供另一種不同的模型。甚至在EJB內部也有至少3種明顯不同的子模型，每一種子模型都有不同的語言定義。
Microsoft的.NET編程模型與Java平臺相比較，在各種服務器和客戶端上有更好的一致性。J2SE是基于開放的完全用Java編寫的API，而J2EE是基于Java servlet和EJB。
DH Brown, 2002年7月
4） 功能
a. Windows .NET Framework 提供一個能識別版本的類加載器，這就意味著應用程序的開發者能確保他們開發的應用程序在一部分代碼已經更新的情況下仍能運行。而Java和J2EE（現有的）沒有版本識別的類加載器，這就意味著開發者和管理員不能保證代碼被執行時是正確的。或是說，開發者只能靠運氣來保證這一點。
b. Windows .NET Framework 顯示了語言層面上的類屬性―這就使得編程更加簡單。例如，在源代碼中只用一個簡單的屬性就能把.NET組件標志為處理模式。或者說，一個.NET組件和 XML的串行化可以在一個屬性中被定義。這個機制大大簡化了許多編程任務。而Java不顯示語言層上的類屬性，雖然Sun公司考慮到要修改Java語言來改變現狀。這種變化估計在兩三年內才能第一次實現。
c. .NET還支持分離數據訪問，這主要用于在移動設備或是偶爾聯網的場合里運行的應用程序。數據能被脫機操作，接著再和起始數據重新同步。而不論是J2EE還是J2SE現階段都不支持分離數據訪問，需要這項功能的 J2EE開發者必須自己寫"plumbing code"。
d. 為建立基于網絡的用戶界面， Windows .NET Framework提供基于事件的模型，這些模型類似于流行的Visual Basic中的智能客戶端模型。ASP .NET 模型使得建立、發布和維護一個基于網絡的用戶界面變得更加容易。與之形成對比的是，J2EE在JSP中不支持這樣的模型。有一些第三方的擴展程序部分彌補了這些功能，但是它們的實用性和簡便性不能和ASP .NET相比。作為一個推薦的J2EE附加程序，Java Server Faces可能做到這一點。但這個附加程序并沒有包括在J2EE的1.4版本以前。而要獲得銷售商的支持，則又需至少一年的時間。
e. J2EE支持一個對象相關的數據映像模型，它被稱作EJB Entity Beans。這樣是為了允許開發者更容易地從一個相關的數據庫建立對象模型。然而，實際上把這個想法編程實現卻要面對下列問題：
Ⅰ. 易用性：當那些熟知的、正規定義的、被廣泛支持的結構化查詢語言（SQL）和開發者的數據相互作用時，開發者不得不放棄它們，而使用一個被稱為EJBQL 的弱定義查詢語言。和SQL相類似，EJBQL的功能并不強大（例如，在現有的規范中，它沒有ORDER BY的語句，這樣開發者就沒法使用特定數據庫的 SQL擴展），而它的語義也沒有被正規定義。還有，在對象間建立聯系和附屬關系十分困難，而且在對象間和XML以及后端之間的數據翻譯是手動控制的。
Ⅱ.性能：基于EJB系統的性能仍是一個未知數。沒有提供公開的基準。客戶反映，得到的性能遠遠偏離了Entity Beans，并且轉向一個更直接的數據訪問策略。這是EJB Entity Beans沒有被廣泛使用的一個關鍵因素。
在Windows .NET Framework 中，數據訪問是基于數據集比較的。數據集保存了相關數據的一個子集，它由一個或多個SQL查詢語句描述。數據集中的數據可能保存關鍵的聯系，并且開發者能直接對數據進行操作，能將數據轉換成XML格式和上次操作的類型，能使用標準的SQL過濾數據等。總而言之，相對于EJB Entity Beans，. NET的數據集模型提供一個更豐富而且簡單熟悉的途徑。
5） 簡便性
a． 配置：對于J2EE，配置是由部署描述信息獲得的XML格式的文件，它們和實際執行的商用邏輯代碼有明顯區別。這種方法有很多問題。第一，考慮到特定類的元數據，有些代碼中的改變和元數據中的改變是相互依賴的。兩個獨立文件的同步性要求有可能產生錯誤。第二，考慮到應用程序層的元數據，在J2EE中，沒有可以從一個程序繼承元數據到另一個程序的途徑。與J2EE不同，Windows的.NET構架包括了這個功能，使得可以在源代碼中直接向類添加屬性，這樣就不會產生第一個問題。 Windows .NET中的元數據模型允許客戶自己添加擴展程序，這樣開發者就可以編寫和使用自己的屬性。為了在Windows的.NET構架中配置外部元數據，這個功能被包括在配置文件的分級系統中，它能從父系統中繼承屬性，這樣每個文件會很小，它只記錄改變的設定。這就避免了J2EE模型的第二個問題
b． 數據庫連接池Windows .NET Framework中，是根據需要自動建立和管理這些池的。而在J2EE模型中，連接池必須被明確配置和管理。
c． XML Web服務：在.NET中建立一個XML Web服務就像在類中添加一個屬性那樣簡單。有些基于J2EE的產品也想在Java中模擬這個功能，.NET提供更簡單的方法來建立和使用可由雙方共同操作的 XML Web服務。
d． 部署：在.NET中，要部署一個應用程序，管理員只需要拷貝文件。而在J2EE中，管理員必須將很多編譯文件和JAR、WAR以及EAR綁定，然后在一個特定的服務器部署工具中解開并運行它們，接著拷貝結果檔案。這個多步部署過程意味著典型的編輯/編譯/調試循環被大大延長了。此外，由于動態加載類過程中的一些變化，更新一個簡單的類常常需要重新啟動基于J2EE的服務器。
雖然許多公司選擇Java作為企業發展的策略平臺，但它們的使用卻由于J2EE的復雜性而受到阻礙。Meta Group，8月
6） 成本
a． 為了部署，運行在Windows .NET Framework之外編寫的服務器端的應用程序需要一個Windows Server的許可，這比三個遵從J2EE的商業服務器中的任何一個許可都便宜很多。包括四個網絡服務器的系統部署費用的差別可達到數十萬美元。例如， Microsoft Windows Server 2003（企業版）的一個四機器系統（每個有四個pc）的許可費用不超過16，000美元（這考慮了零售因素）。而WebSphere Application Server 5.0在同樣的系統中每臺pc的許可費用達12，000美元，這共要192， 000美元。這個比率是12比1。大多數基于J2EE的商業應用程序服務器的價格都和這類似。（這假定了性能相等。然而實際上Middleware公司 2002年10月的報告顯示，一個建立在Windows .NET Framework上的應用程序的效率是建立在同樣流行的基于J2EE的服務器上的程序的2-4倍。所以實際上價格的優勢遠高于12比1）有很多免費的，基于J2EE的開放源應用服務器，但是它們并沒有J2EE-compliant的商標。還有關于文件和產品的問題：需要產品之間的比較來討論采許可費用。
b． 為Windows .NET Framework開發工具的費用也更加低廉。Visual Studio .NET是.NET的整合開發工具，它的許可費用大大低于商業化的J2EE銷售商制定的開發工具的費用。并且在業界，Visual Studio .NET作為最佳開發工具贏得了一系列的大獎。評估過Visual Studio .NET和其競爭對手的客戶都說，相對于最好的Java工具，Visual Studio .NET開發效率更高（See Giga，2002年6月）。
c． 使用Windows .NET Framework的開發和維護費用更低。專家認為許可費用并不是一個項目的最大開支。典型的軟件開發和維護占項目總費用的50-80%（Glass，2002；Kemerer，1995；Gartner，2001）。Middleware公司2002年10月的研究表明，在Windows .NET Framework上一個給定的應用程序開發相對于J2EE，只需要1/3的代碼。代碼越少就意味著維護更加簡單。
總結
顯而易見：正確的產品選擇決策不可能不評估實際的產品。對比Microsoft Windows Server及 Windows .NET Framework和J2EE（Sun公司的規范）是有價值的，但是這樣的努力缺少實際產品的評估。然而，還是可以從中得出一些結論：
1） J2EE展現了一個以服務器為中心的原則，并將重心放在EJB和解決"相關對象的映像問題"上。J2EE在支持 XML和Web服務上已經落后了。Windows .NET Framework的原則則是通過協議標準和XML、充分利用服務器、接口和設備的的大規模分布式計算。
2） 相對于編寫在Windows .NET Framework上的程序，J2EE應用程序需要更多的代碼來執行相同的任務。
3） J2EE的管理和部署模型更像是一個主機模型，它關注保護和限制稀有的計算資源，按比率使用。而Windows .NET Framework展現出的原則是計算資源是廉價的，而且將更加廉價，但是部署能力將保持大部分昂貴的資源。
總之，如果一個項目要求必須從幾個操作系統中選擇一個作為部署平臺，而不考慮開發成本；強制（并且重新培訓訓練）開發者使用單一的編程語言來執行這個項目，從而代碼的版本問題就不再重要；重要的是配給和限制相對便宜的計算資源；這樣使用昂貴復雜的開發和維護工具就顯得順理成章；而編寫更多的代碼也有其優越性 -- J2EE也許是一個不錯的選擇。
然而，如果商業目標顯示最優化的開發效率是重要的；低廉的性價比更符合要求；通過通訊協議的標準獲得的可相互操作性有較高價值；大量支持基于界面的應用程序和移動的應用程序是重要的；更感興趣的是易擴展性―這樣的話，建立一個 Windows .NET Framework上的Windows Server應用程序是正確的選擇。
