淺析J2EE與.NET平臺優劣 (轉)

淺析J2EE與.NET平臺優劣 (轉)[@more@]毫無疑問，員，開發商，企業IT經理一直都在密切的關注著和的發展，但是選擇一個在，價格，時間上滿足他們需求的平臺卻並不是一件簡單的事情。本文試圖在技術上做一個簡單的比較，希望對於他們做選擇時有所幫助。

一.技術概觀

在表現形式上，J2EE是一組規範，而.NET更象是一組產品。但它們的目的都是為了企業應用提供分散式的，高可靠性的解決方案.它們在架構上有著很多的相似之處，下表是一個簡單對照:

J2EE
通訊 Remote Method Invocation over Internet InterOrb Protocol (/IIOP)，
語言 ，，COBOL
執行時環境 Java Virtual Machine (JVM) Common Language Runtime (CLR)
胖客戶端 Java Forms
目錄服務 Java Naming and Directory Interface (JNDI) Active Directory Services Interface (ADSI)
資料訪問 Java Database Connection (JC) ，Java Connectors
非同步訊息處理 Java Message Service () Message Queue
表示層技術 s， Java Server Page() .NET
中間層模型 ，JavaBean COM+，
訪問 JAAS COM+ Security
Call Context
事物處理 Java Transaction Server (JTS) Microsoft Distributed Transaction Coordinator (MS-DTC)
開發工具 Gain Visual Café
Borland JBuilder
IBM VisualAge 等
(第三方提供，規範本身沒有定義) .NET


J2EE平臺的構成

EJB - J2EE 中間層，完成商業邏輯；

JAAS - J2EE 處理和授權的;

Java Connectors - J2EE 用於連線異種資料來源的API，對上層來講是透明的;

JSP， Java Servlets - J2EE的表示層技術，用於生成介面;

Java Virtual Machine - Java 語言執行環境；

- J2EE訪問；

JMS - J2EE的非同步訊息佇列；

JNDI - J2EE的名字查詢API，獨立於目錄；

JTS - J2EE用於處理交易的API；

RMI/IIOP - J2EE的分散式的通訊API，提供了和互動的能力。

.NET平臺構成

.NET - .NET應用執行的基礎；

IL (Intermediary Language) - 所有的.NET語言首先被編譯成該中間語言，然後在CLR中執行；

P - 用於服務訪問的工業標準；

DCOM - 元件間通訊協議；

MS-DTC - 用來在.NET平臺上使用兩階段提交協議來處理分散式交易；

CLR - .NET應用的執行時環境；

COM+ - .NET的中間層模型，用於構建商務邏輯；

ADO.NET - .NET 對資料訪問的API。

此外.NET平臺還包括其他一些產品象Application Center Server， Server ，NLBS (Network Load Balancing Service)，Commerce Server，Enterprise Servers，HIS (Host Integration Server)，I (Internet Security and Acceleration Server)用來提供象，安全訪問，B2B交易，負載平衡等服務.J2EE規範本身沒有定義這些服務，但可透過選擇第三方產品來滿足類似的要求。

二.技術比較

1.一 vs 多

一種語言vs多種語言，一個平臺vs多個平臺.這似乎是大家最喜於津津樂道的話題，也似乎是所有問題的焦點。

兩種平臺主流的開發語言Java和C#在架構上有著驚人的相似：虛擬機器技術，基於沙箱的安全模型，分層的名稱空間，垃圾回收等。所以從第一眼看上去，C#簡直就是Java的克隆。但並不這樣認為，微軟的說明是：“它整合了C++， Java，Modula 2，C和Smalltalk等多種語言的精華，對它們共同的核心思想象深度物件導向(deep -orientation)，物件簡化 (object-simplification)等都一一做了參考。”一方面，C#的大多數關鍵字來源於C++，使它在書寫上有別於Java。但另一方面，C#的嚴格的型別轉換等概念卻明顯來自於Java(當然，它的原始型別的定義更嚴格，並且據微軟聲稱沒有影響到.)，使其在內涵上有克隆之嫌.但即是Java，其有些特性也和Smalltalk頗有淵源.所以評價一種開發語言的優劣不僅是看其外在的表現形式，更重要的是其實實在在的功效.作為一種新語言，C#加入了基於XML的標記，可以被用來直接生成文件，C#的另一個特點:一站式軟體(one-stop-shop software)強調了自解釋( self-describing) 的編碼方式，即頭，IDL(Interface Definition Language)，GUID和其他複雜的介面無需再被引用.也即是C#，VB.NET等程式碼片斷可以任意的被加入到其他語言中.這無疑在多種語言混合程式設計的中是一次飛躍，但是，其難維護性也是不言而喻的。

微軟的.NET的平臺提供了象C#，VB.NET，COBOL等多種開發語言，C#是新的，而其他的每一種語言都是在原有的基礎上改造而來.這是微軟煞費苦心並且也是不得以的要為習慣於這些語言的程式設計師鋪一條便捷之路.但是，這些語言的改造與其說是整容到不如說是一次開膛破肚的大手術.首先是觀念變了，Basic，Cobol等語言先天的缺少物件導向的內涵，現在卻變成了物件導向的語言，這就不是要求其傳統的程式設計師僅僅熟悉一些額外的關鍵字那麼簡單的問題了.基於物件導向的軟體分析設計開發測試是完全不同於基於傳統過程性語言的質變，所以這一過程的轉變對傳統程式設計師來講也是一個痛苦和漫長的過程.在傳統程式設計師面前，微軟看似提供了豐富多采的解決方法，但對於實際問題而言，卻怕是有些力不從心.所以一個簡單的辦法是:直接使用C#.對於獨立軟體開發商來講，其轉換成本不容忽視.其次，在一個軟體專案中使用多種語言，開發商必須同時擁有多種語言專家和多個獨立的難以互相支援的開發小組，無疑的，這也使其軟體的維護的成本已非線性的曲線增長.多樣性是雙韌劍，實施時需仔細斟酌.

跨平臺是J2EE的最大賣點，也是至今為止還絆住微軟的柵欄.當開發商完成了符合J2EE規範的軟體時，其客戶可以依據其喜好和實力來選擇不同應用伺服器.從基於的免費軟體到高階滿足B2B需求的商業套件來搭建自己的平臺.但是由於J2EE的規範還不完善，各個J2EE伺服器的提供商為了使其提供其各自理解的完整的功能，不得不新增一些額外的特性.這就使得使用了這些特別功能的應用軟體，繫結到了特定的應用伺服器上.隨著J2EE規範的發展，這種差別會逐漸減小.

微軟的跨平臺解決方案是Web services，它解決的是異種平臺上不同應用之間的連通性問題.從技術角度講，它除了以XML為介質之外沒有什麼新意.但它的重要意義在於:它是微軟這樣一個重量級選手所推出的，前景不容小視.構造和使用 Web services 的過程較為簡單:

服務提供者用他所選擇的語言構造服務;

服務提供者用WSDL(the Web Services Description Language)來定義該服務;

服務提供者在UDDI (Universal Description， Divery， and Integration )中註冊該服務;

使用者的應用程式從 UDDI中查詢已註冊服務;

使用者的應用程式透過 SOAP (the Simple Object Access Protocol )來服務.(SOAP使用HTTP來傳遞基於XML為表現形式的引數)

正如我們所討論的: Web services解決的是異構平臺上服務連通性的問題，但在現實中所更迫切需要的是如何在異構的平臺上構造具有可擴充套件性，高可靠性，高可用性，故障冗餘，錯誤恢復能力的企業應用.缺少這一點，從結構上講，.NET平臺還遠未完善.

2.中間層

基於元件的軟體開發技術可以在較高的級別上實現軟體複用，加快企業軟體開發的程式.在J2EE構架中， JavaBean和EJB(Enterprise JavaBeans) 被用來完成事物邏輯.其中EJB和 JavaBean 有著類似的模型，但它被用來建立分散式的企業應用.它定義伺服器端元件的模型，具有以下一些特性:

生存期模型；

訪問模型；

安全模型；

事物處理模型；

會話處理模型；

資料封裝模型；

部署模型

根據這些模型，簡單的編碼就可完成複雜的功能。

在微軟的.NET平臺中，舊的COM 和 COM+的元件模型被新的元件模型所代替。增加了象基於沙箱的安全模型和垃圾回收等功能.並且實現了多重介面繼承，擴充套件的後設資料和新的模型等.舊有的COM和COM+元件也可被對映到新的執行環境中。

綜上所述，兩眾架構在基於元件的中間層的設計上各有千秋，對於建立分散式的，複雜的，高效的，高可靠性的的應用程式都有著足夠的能力。

3.表示層

兩種架構都同時支援胖客戶端和瘦客戶端.即C/S模式和B/S模式.對於C/S模式，J2EE提供了替代Java AWT的Java Swing，同時作為視覺化元件的JavaBean也可用來構造。對於B/S結構的表示層，J2EE使用 servlet ，JSP(Java Server Page) ，HMTL，WML，XML等工具來實現。

微軟的胖客戶端技術則由 Windows Forms代替了MFC.它們起的作用相同，在結構上 Windows Forms 被插入到.NET的執行時(runtime framework)和元件模型 (component model)中.在瘦客戶模型中， 代替了舊有的ASP和 HMTL， WML ，XML作為表示層。在 ASP.NET 中，C#，VB.NET等語言的程式碼片斷可被自由引用.ASP.NET 頁面被首先轉換成中介語言( Intermediary Language)，然後再被 中介語言及時編譯器(just-in-time IL compiler)編譯，最後執行於公共語言執行環境中，並且 ASP.NET 提供了頁面的緩衝，所以，其執行速度要遠遠快於ASP。

大體上，兩種架構所使用的表示層的技術非常類似，雖在細節上各有所長，但總體功能當在伯仲之間。

4.資料訪問

J2EE 和 .Net 已不同的形式支援資料的訪問。JDBC和ADO一樣和所連線的資料庫無關，並且透過連線，命令語句和結果集來對資料進行操作.所以屬於中間層次的 API.更高一級的資料封裝和資料管理是透過實體EJB (entity EJB)來完成的.基於容器管理的實體EJB使開發更快捷，管理更方便.事實上，由於實體EJB的load()和store()方法的同步機制，將大大緩解因併發而使資料庫產生的瓶頸.也可以採用不屬於J2EE規範的第三方資料訪問工具，象WebGain的 TopLink。

而微軟的.NET的資料訪問工具則由基於XML的ADO.NET代替了基於COM元件的ADO.任何以XML為輸出的資料來源都可以作為 ADO.NET 的資料來源.相應的結果集升級為資料集 (DataSets)，命令語句則升級為資料集命令(DataSetCommands).從形式來看，微軟的ADO.NET潮和時髦一些，基於XML的特性使其可以處理極其豐富的資料來源，並且，因其構架在之上，易於穿透防火牆，使溝通更為便利.但由於XML本身的基於標記的特性，很明顯限制了在有超大資料量和有瓶頸的應用中的使用.而J2EE的資料訪問規則則顯得略有單薄，但同時卻更簡單，更有效.並且透過對應用程式有效的層次的設計，對於資料庫和基於XML的資料來源的訪問，也是可以無縫的整合的。

三.整體評價

在微軟還沒有足以和Java平臺相對抗的產品的時候，微軟所樂於做是大聲的宣傳:"write once， de everywhere"。而它的對手則更樂於這樣評價它:"微軟開始也喜歡Java，他們喜歡它的方式是讓它死去，他們當然也憎恨它，他們甚至憎恨每一個以J開頭的單詞。"但是現在，形式不同了，微軟有了足以自豪的.NET他們可以已他們自己所喜好的方式來對J2EE和.NET來做各種比較。最熱鬧的應該算是微軟出示的第三方對.NET Pet Shop和J2EE的 Pet Store的綜合比較了.有興趣的讀者可以到MSDN，，IBM開發者原地等網站看到相關評論。

&bsp; J2EE .NET
易用性 ** ***
擴充套件能力 *** **
多平臺支援 **** *
多語言支援 * ****
可靠性 *** ***
效能 *** ***
可管理性 *** ***
重用性 **** **
負載平衡 *** ***
開放標準 ***** *


就企業而言，內部眾多系統的整合、系統的延展性、安全性是更需要注意的議題，而這些都是J2EE的優勢，也是微軟的不足處。 在效率方面，J2EE陣營主張透過的效能增加來彌補軟體的不足.開放標準，功能強大，易於移植這些都是J2EE的賣點。但讓人奇怪的是IBM的和BEA的在J2EE市場佔了大半壁江山，而作為規則制定者的SUN卻在做壁上觀。

微軟確實提供了從桌面的辦公軟體，開發工具，到後臺伺服器資料庫的全方位的產品。 但統一平臺的使用者可能要犧牲跨平臺的好處，並也有可能由此就被無窮無盡的鎖定在微軟的許可證的汪洋中.更簡單，更快捷，更高效是微軟的目標，隨著時代的發展，我們也許會看到更完美的技術解決方案。