一.技術概觀

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

J2EE .NET

通信協議 Remote Method Invocation over Internet InterOrb Protocol (RMI/IIOP)，XML

編程語言 Java C#，VB.NET，COBOL

運行時環境 Java Virtual Machine (JVM) Common Language Runtime (CLR)

胖客戶端 Java Swing Windows Forms

目錄服務 Java Naming and Directory Interface (JNDI) Active Directory Services Interface (ADSI)

數據訪問 Java Database Connection (JDBC) ，Java Connectors ADO.NET

異步消息處理 Java Message Service (JMS) Microsoft Message Queue

表示層技術 Servlets， Java Server Page(JSP) ASP.NET

中間層組件模型 EJB，JavaBean COM+，COM

安全訪問 JAAS COM+ Security

Call Context

事物處理 Java Transaction Server (JTS) Microsoft Distributed Transaction Coordinator (MS-DTC)

開發工具 WebGain Visual Café

Borland JBuilder

IBM VisualAge 等

(第三方提供，規范本身沒有定義) Visual Studio.NET

J2EE平臺的構成

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

JAAS - J2EE 處理認證和授權的API;

Java Connectors - J2EE 用于連接異種數據源的API，對上層來講是透明的;

JSP， Java Servlets - J2EE的表示層技術，用于生成用戶界面;

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

JDBC - J2EE數據庫訪問；

JMS - J2EE的異步消息隊列；

JNDI - J2EE的名字查找API，獨立于目錄服務器；

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

RMI/IIOP - J2EE的分布式對象的通訊API，提供了和CORBA交互的能力。

.NET平臺構成

.NET Framework - .NET應用運行的基礎；

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

SOAP - 用于服務訪問的工業標準；

DCOM - 組件間通信協議；

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

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

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

ADO.NET - .NET 對數據訪問的API。

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

二.技術比較

1.一 vs 多

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

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

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

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

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

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

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

服務提供者在UDDI (Universal Description， Discovery， 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.NET代替了舊有的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的特性使其可以處理極其豐富的數據源，并且，因其構架在HTTP協議之上，易于穿透防火墻，使溝通更為便利.但由于XML本身的基于標記的特性，很明顯限制了在有超大數據量和有網絡瓶頸的應用中的使用.而J2EE的數據訪問規則則顯得略有單薄，但同時卻更簡單，更有效.并且通過對應用程序有效的層次的設計，對于數據庫和基于XML的數據源的訪問，也是可以無縫的整合的。

三.整體評價

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

J2EE .NET

易用性 ** ***

擴展能力 *** **

多平臺支持 **** *

多語言支持 * ****

可靠性 *** ***

性能 *** ***

可管理性 *** ***

重用性 **** **

負載平衡 *** ***

開放標準 ***** *

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

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