隨著三層/多層企業資訊系統結構的深度發展和下一代分散式計算模型Web 服務的出現，軟體開發中關於平臺、框架、語言的競爭也愈演愈烈。自從微軟推出平臺，業界關於J2EE平臺與平臺的比較從未停止過。那麼J2EE與有什麼區別呢?下面跟yjbys小編一起來了解吧!
本文在收集整理相關文章的基礎上，試圖對目前兩種主要的應用軟體開發技術架構J2EE與進行一個客觀、公正、全面的比較，以幫助軟體開發商選擇一個較為合適的開發平臺進行應用軟體的開發。
一、J2EE簡介
Java於1995年由Sun公司推出，當時它的主要用途是製作產生動態網頁的Applet。後來，人們發現Java的“一次開發，多次執行”、純面向物件的特性、垃圾回收機制和內建安全特別適合於開發企業應用系統。於是，企業應用開發商紛紛在Java標準版的基礎上各自擴展出許多企業應用API，其結果導致基於Java的企業應用呈爆炸式增長。但是各企業系統API之間又不能相互相容，破壞了Java的平臺的獨立性。鑑於此，Sun公司聯合IBM、Oracle、BEA等大型企業應用系統開發商於1999年共同制訂了一個基於Java元件技術的企業應用系統開發規範，該規範定義了一個多層企業資訊系統的標準平臺，旨在簡化和規範企業應用系統的開發和部署。這一規範和其定義的平臺就構成了J2EE。它定義了基於元件的方式設計、開發、組裝和部署企業應用系統的各個組成部分。同時，J2EE規範定義了分散式多層應用系統模型、元件重用策略、一體化的安全模型以及靈活的事務控制策略等，使得獨立軟體提供商(ISV)能夠比以前更快的速度，向市場推出使用者適應的解決方案。
J2EE是一套針對於企業級分散式應用的計算環境，其結構體系如圖1所示。它定義了動態Web頁面功能(Servlet和Jsp)、商業元件(EJB)、非同步訊息傳輸機制(JMS)、名稱和目錄定位服務(JNDI)、資料庫訪問(JDBC)、與子系統的聯結器(JCA)和安全服務等。
需要注意的是，J2EE本身是一個標準，而不是一個現成的產品(雖然現在有很多符合J2EE標準的產品)，它由以下幾個部分組成：
(1)J2EE規範 該規範定義了J2EE平臺的體系結構、平臺角色及J2EE中每種服務和核心API的實現要求。它是J2EE應用伺服器開發商的大綱。
(2)J2EE相容性測試站點 Sun公司提供的一個測試J2EE應用伺服器是否符合J2EE規範的站點，對通過該站點測試的產品，Sun公司將發放相容性證書。
(3)J2EE參考實現 即J2EE SDK，它既是Sun公司自己對J2EE規範的一個非商業性實現，又是為開發基於J2EE企業級應用系統原型提供的一個免費的底層開發環境。
(4)J2EE實施指南 即BluePrints文件，該文件通過例項來指導開發人員如何去開發一個基於J2EE的多層企業應用系統。
1.元件-容器模型
J2EE是一個基於元件-容器模型的系統平臺，其核心概念是容器。容器是指為特定元件提供服務的一個標準化的執行時環境，Java虛擬機器就是一個典型的容器。元件是一個可以部署的程式單元，它以某種方式執行在容器中，容器封裝了J2EE底層的API，為元件提供事務處理、資料訪問、安全性、永續性等服務。在J2EE中元件和元件之間並不直接訪問，而是通過容器提供的協議和方法來相互呼叫。元件和容器間的關係通過“協議”來定義。容器的底層是J2EE伺服器，它為容器提供J2EE中定義的各種服務和API。一個J2EE伺服器(也叫J2EE應用伺服器)可以支援一種或多種容器。
2.J2EE的核心——EJB
J2EE定義了四種元件：Applet元件、Application客戶元件、Web元件及EJB(Enterprise JavaBeans)元件。其中Applet和Application客戶元件在客戶端執行，J2EE通過Java外掛為Applet提供執行環境，Application客戶的容器就是本地Java虛擬機器;Web及EJB元件在服務端執行。J2EE中包含JSP和Servlet兩種Web元件，它們是Web伺服器的功能擴充套件，都能生成動態Web頁面。不同的是JSP是將Java程式碼嵌入到HTML中，伺服器負責解釋執行，生成結果返回使用者(與ASP技術相似);而Servlet是單獨的Java類，它動態生成HTML檔案返回給客戶。Web元件的容器比較典型的就是基於Java的Web伺服器。
EJB是J2EE平臺的核心，也是J2EE得到業界廣泛關注和支援的主要原因。眾所周知J2EE的一個主要目的就是簡化企業應用系統的開發，使程式設計師將主要精力放在商業邏輯的開發上。EJB正是基於這種思想的伺服器端技術，它本身也是一種規範，該規範定義了一個可重用的元件框架來實現分散式的、面向物件的商業邏輯;其核心思想是將商業邏輯與底層的系統邏輯分開，使開發者只需關心商業邏輯，而由EJB容器實現目錄服務、事務處理、永續性、安全性等底層系統邏輯。
一個可部署的EJB元件包含3個部分：Remote介面、Home介面和Enterprise Beans類。
(1)Remote介面 Remote介面定義EJB元件中提供的可供使用者呼叫的方法，也就是通常所說的實現商業邏輯的函式或過程(如計算商品價格的函式)，以供遠端客戶端呼叫。在EJB元件部署到容器的時候，容器會自動生成Remote介面相應的例項，即EJB物件，它負責代理使用者的呼叫請求。
(2)Home介面 Home介面定義了一組方法來建立新的EJB物件，查詢、定位和清除已有的EJB物件。在EJB元件部署時，容器也會自動生成相應的Home物件，該物件負責查詢和建立EJB物件，返回EJB物件的引用給客戶;使用者利用該引用呼叫EJB元件的方法，得到結果;最後Home物件清除EJB物件。可以形象地稱Home介面為EJB物件的工廠。
(3)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的部署、釋出和生命週期管理。
3.平臺標準服務
服務是元件和容器之間，以及容器和J2EE伺服器之間的介面，在實現層面上它就是一系列API和協議。J2EE平臺定義了一組標準的服務，其中有些服務是由J2SE提供的，有些則是J2EE對Java的擴充套件。
(1) 目錄服務JNDI(Java Name and Directory) API為應用程式提供了一個統一的介面來完成標準的目錄操作，由於JNDI是獨立於目錄協議的，應用程式可以用它訪問各種目錄服務，如LDAP、NDS、DNS等。
(2) 資料訪問JDBC(Java Database Connectivity) API為訪問不同型別的資料庫提供了統一的途徑，遮蔽了不同資料庫的細節，具有平臺無關性。J2EE平臺除了要求核心的JDBC API(包含在J2SE中)外，還要求擴充套件的JDBC API 2.0，它支援行集、連線池和分散式的事務處理。
(3) 事務處理JTA(Java Transaction Architecture) 它定義了一組標準的介面，為應用系統提供可靠的事務處理支援。JTS(Java Transaction Service)是CORBA OTS事務監控的Java實現。JTS規定了事務管理器的實現方式，該事務管理器在高層支援JTA標準，在底層實現了OMG OTS規範的Java對映。
(4) 訊息服務JMS(Java Message Service) 它是一組用於和麵向訊息的中介軟體相互通訊的API,它既支援點對點的訊息通訊，也支援釋出/訂閱式的訊息通訊。電子郵件 JavaMail API允許在應用程式中以獨立於平臺、獨立於協議的方式收發電子郵件。JAF(JavaBeans Activation Framework)負責處理MIME編碼，JavaMail利用JAF來處理MIME編碼的郵件附件。
(5) CORBA相容介面 RMI(遠端方法呼叫)是在分散式物件間通訊的Java本地方法，它使應用程式呼叫遠端方法像呼叫本地方法一樣，不需要考慮所呼叫物件的位置。RMI-IIOP是RMI的擴充套件，是符合CORBA標準的物件通訊協議，也是J2EE預設的元件通訊協議。Java IDL允許J2EE應用元件通過IIOP協議訪問外部的CORBA物件。
(6) 安全服務JAAS(Java Authentication and Authorization Service) 它用兩個步驟實現安全性：認證，即由使用者提供認證資訊(如使用者名稱和密碼)來獲得系統認證，這一過程又稱之為登入;授權，在被確認為合法使用者後，系統根據使用者的角色授予其相應的許可權。J2EE的授權是基於安全形色的概念，一個安全形色是一個擁有相同許可權的邏輯組。J2EE的安全形色由應用元件提供商來定義。
4.對WEB服務的支援
Sun提供了一套API及其實現WSDP作為對J2EE的擴充套件。在WSDP中，JAXP用來解析XML文件;JAXR向UDDI伺服器註冊Web Services;JTX/RPC用基於XML的協議(如SOAP)來發送和接收XML文件;JWSDL處理WSDL文件。
J2EE 1.4的設計目標就是Web服務，其中新加入了像JAX-RPC/SAAJ和JAXR等API，另外EJB 2.1裡也增加了許多針對Web服務設計的特性。
5 多層應用模型
從應用的角度來看，J2EE為企業應用系統的開發提供了一種多層分散式企業應用模型。在J2EE中，應用邏輯按功能不同可以劃分為不同型別的元件，各元件根據它們所在的層分佈在不同的機器上，共同組成一個基於元件的分散式系統。
如圖1所示，J2EE定義了一個典型的四層結構，分別是客戶層、表示層(Web層)、業務邏輯層和企業資訊系統層。
在應用開發時，J2EE定義的四層模型可根據實際情況靈活運用。由於除Applet外，其他的元件都可以訪問資料庫、EJB元件和企業資訊系統，因此通過不同層的取捨及組合，可以衍生出許多應用軟體開發模型，如基於Web的四層模型、基於桌面應用的三層模型(不包括Web層)、B2B模型(不包括客戶層)等。如果應用系統比較簡單，一般不用EJB作為邏輯層，而直接用Web元件來實現商業邏輯和資料訪問，畢竟EJB的開發和部署費用還相當高。
二、簡介
來自於微軟，是一套全能的框架平臺，支援C++、C#、J++、VB、ASP等語言，能夠解決C/S、B/S和單機等結構的軟體開發需求。平臺將這些語言編譯成CLR語言，使它們可以無差別的執行在 Framework上，是2000年以後微軟最為重要的軟體開發套件產品。
的絕大部分是微軟Windows DNA(Distributed Network Architecture)的重寫，DNA是微軟以前開發企業應用程式的平臺。Windows DNA中包括了許多已經被證實的技術，新的框架取代了這些技術，幷包含了Web服務層和改良的語言支援。圖2是開發平臺的體系結構。
1.﹒NET框架核心
框架實現了語言開發、程式碼編譯、元件配置、程式執行和物件互動等各個層面的功能，為Web服務及普通應用程式提供了一個託管、安全和高效的執行環境。所有在平臺上建立的應用程式執行都需要兩個核心模組:Common Language Runtime(CLR，通用語言執行時)和 Framework類庫。
(1)CLR——的虛擬機器 CLR是一個軟體引擎，用來載入應用程式，確認它們可以沒有錯誤地執行，並進行相應的安全許可驗證，執行應用程式，然後將被清除。它為應用程式提供了一個託管的程式碼執行環境，託管意味著將原來由程式設計師或作業系統做的工作剝離出來交由CLR來完成，從而使程式執行獲得更高的安全性和穩定性。這些工作包括記憶體管理、即時編譯、元件自描述、安全管理、程式碼驗證以及其他一些系統服務。CLR提供一個技術規範，無論程式使用什麼語言編寫，只要能編譯成中間語言，就可以在它的支援下執行，這樣應用程式就可以獨立於語言。CLR還在應用程式執行環境中為基於元件的程式設計提供了直接支援，比如它支援屬性、事件、物件、繼承性、多型性和介面等元件程式設計特性。
CLR中的自動垃圾收集器負責應用程式執行時的記憶體分配、物件佈局、記憶體釋放等記憶體管理問題，徹底解決了多年來困擾程式設計師的記憶體洩漏問題，大大增強了應用程式的健壯性。
即時編譯器在執行時，將中間語言以呼叫物件的方法將單位動態編譯成本地二進位制程式碼。
(2)類庫 NET Framework類庫向程式設計師提供軟體元件，用來編寫在CLR控制下執行的程式碼，它們按照單一有序的分級組織提供了一個龐大的功能集，包括從檔案系統到對XML功能的網訪問的每一樣功能。該類庫為開發提供了三種基本程式設計模板：基於的Web表單應用、基於的Web服務應用和基於傳統GUI互動的Windows應用。
Framework類庫由一組廣泛的、面向物件的、可被開發者用於任何程式語言的可重用類集合組成，它提供了幾乎所有應用程式都需要的公共程式碼;在此之上是許多應用程式模板，這些模板為開發網路站點和網路服務提供特定的高階元件和服務，無論是傳統的命令列程式，還是Windows圖形介面程式，亦或是面向下一代網際網路分散式計算平臺的或Web服務應用，與在Windows和它的SDK中傳送的程式碼庫一樣，框架類庫將程式設計師從繁重的程式設計細節中解放出來，而專注於程式的商業邏輯。它將核心Win32 API最常用的功能和外掛SDK的功能封裝到了一個統一的包中，並採用清晰而有條理的方式對類庫進行分組和描述，這樣開發者就能夠更方便地找到其應用程式所需要的大多數功能。
元件
為基於網路的、可擴充套件的應用程式和服務提供資料訪問服務。它不僅支援傳統的基於連結指標風格的資料訪問，而且對於更適合於把資料返回到客戶端應用程式的無連結資料模板，也提供高效能的訪問支援。
資料元件
通過它開發人員可以對任何資料進行XML轉換、傳輸和確認，所有資料都可以被看作是XML格式的。同時，系統也支援資料與XML資料之間的通用轉換。
OWS表單元件
Windows表單元件為開發人員提供了強大的Windows應用程式模型和豐富的'Windows使用者口，包括傳統的ActiveX控制元件和Windows XP的新介面，如透明的、分層的浮動視窗。
應用服務
的核心是其用於處理基於HTTP請求的高效能的執行語言，其編譯執行的方式大大提高了它的效能。使用基於構件的框架配置模板，因此，它獲得了諸如XCOPY配置、構件並行配置和基於XML配置之類的優點。它還支援應用程式的實時更新，同時提供高速緩衝服務，以改善效能。
Web表單把VB表單高效率的優點帶到了Web應用程式的開發中。它支援傳統的將HTML內容與指令碼程式碼混合的ASP語法，但是它提出了一種將應用程式程式碼和使用者介面內容分離的、更加結構化的方法。它提供一套對映傳統HTML使用者介面部件(包括列表框、文字框和按鈕)的 Web表單控制元件和一套更加複雜的Web應用控制元件(如日曆和廣告轉板)。
6.對Web服務的支援
應用服務體系架構為用建立Web服務提供了一個高階的可程式設計模板。雖然建立Web服務並不限定使用特定的服務平臺，但是的許多優點將簡化其開發過程。使用這個程式設計模型，開發人員甚至無需理解HTTP、SOAP或其他任何網路的服務規範。可以利用現存的體系架構和應用程式，為在網際網路上繫結應用程式提供了一個簡單、靈活和基於產業標準的模型。
三、J2EE與比較
1.體系架構的比較
作為彼此競爭的應用平臺，J2EE和開發平臺在目標和體系結構上極其相似，但在實現上又完全不同。
(1)類似的平臺基礎構造 J2EE和兩個平臺在底層的執行引擎都源於託管的虛擬機器概念,但的CLR沿著Java虛擬機器(JVM)走得更遠，CLR在借鑑了JVM的自動垃圾收集、異常處理等機制的同時，又為平臺添加了多語言支援、元件自描述等新的特性。
在和 J2EE平臺上，程式的編譯都經過兩個類似的過程。首先，特定高階語言編譯器將C#(及其他語言)和Java原始碼分別翻譯成中間語言(IL)和位元組程式碼(ByteCode)。在中間語言設計時通盤考慮了多個主流高階語言，在這一層面實現了平臺的跨語言承諾;J2EE的基石是Java語言，它最典型的特徵是：一次編寫，多次執行。跨平臺是J2EE一直引以為豪的關鍵，這是通過JVM來實現的。
其次，在執行時，中間語言被即時編譯器(JIT)編譯成特定平臺的二進位制程式碼，位元組程式碼則通過JVM解釋執行，完成各自語言的指令功能。鑑於微軟在“Wintel平臺”上的程式碼優化功底，程式碼的執行速度較之於Java有明顯的優勢是不爭的事實。但在Unix/Linux平臺上，由於遲遲未能實現其跨平臺的承諾，J2EE幾乎成了惟一的選擇，執行效率的比較也就無所謂。在程式碼執行的同時，通用語言執行時和Java虛擬機器也都提出了異常捕捉、型別安全、記憶體分配和垃圾收集等自動化記憶體管理工作，大大減輕少了現代軟體的記憶體洩漏問題，減輕了程式設計師的繁重負擔。
面向物件程式設計在J2EE和平臺中都獲得了直接的支援，單根繼承加多介面實現是它們共有的特徵。但在面向物件之外，對現代元件程式設計提供了直接支援。當然，當下很多企業中介軟體都是基於J2EE平臺，只是從設計、編碼、配置到執行都給予了元件程式設計更多、更直接的支援。
在基礎的和企業級的服務上兩個平臺很難一決高低。從基礎的集合、字串操作到企業級的API介面，如JMS、JDBC、JAX和JNDI等，J2EE在這方面有著非常堅實的結構。微軟框架類庫也不示弱，提供了從圖畫、網路、執行緒到、ADSI、Windows表單和等一系列的API。
除去API類庫的無縫的功能複用外，對本地平臺的呼叫操作也是值得關注的。CLR和Java虛擬機器都支援本地方法的呼叫。在異構平臺方面，J2EE更鐘情於IIOP(Internet InterORB Protocol)，而則使用SOAP。
(2)相同的三層/多層體系 基於三層/多層分散式計算結構已毋庸置疑地成為當今企業應用的主流模式，也是兩個平臺較量的著力點。
在客戶端，表示層負責使用者與系統的互動。對於不同的處理要求，和J2EE都提出了基於桌面的應用程式和基於瀏覽器的Web應用的開發元件：Java Application與Windows表單、Java Servlet/JSP與雙雙形成犄角之勢。但Windows表單依賴微軟桌面系統的天然優勢，無論在互動速度還是在介面的表現效能上都較Java Application稍勝一籌。Servlet/JSP與是目前企業在“瘦客戶端”應用的重點，兩者都基於HTTP請求/響應模型，通過HTML瀏覽器頁面完成使用者互動。雖然聲稱在底層通過編譯執行獲得了相當高的處理速度和伺服器方控制元件的瀏覽器自適應能力，但目前並沒有這方面的硬性資料，很難據此而論高低。在快取、狀態優化等方面兩者可謂是旗鼓相當。另一個與客戶端應用相關的技術是ActiveX與Applet，從目前的趨勢來看，它們在兩個平臺上的地位逐漸邊緣化，也不為大多數企業所接受。
在中間層，分散式業務元件負責企業應用的商業邏輯部署。由於這些業務元件經常負責處理資料庫連線、網路資源和執行緒等高昂的資源，所以一直是三層/多層架構的關鍵和企業應用的核心。J2EE的EJB是一個成熟的、得到業界廣泛支援的大型企業級元件框架，而元件則是建立在新型的COM+服務之上，兩者在元件與作業系統的互動、客戶端資源共享等方面都有很好的支援。則通過元資料支援自描述性的元件開發、XCOPY部署以及多版本共存，無需登錄檔和描述檔案，對企業客戶有一定的吸引力。
在後端資料層，兩個平臺都為資料庫連線量身定做了一套資料存取模型：J2EE的JDBC和的，它們在支援傳統SQL資料來源的同時，也支援新型的XML資料來源。這方面由於更多地涉及到具體的資料庫產品，很難說那種資料模型更有優勢。
兩種架構的簡單對照如表1所示。
2 移植性比較
在移植性方面，支援跨語言，J2EE支援跨平臺。
微軟通過 通用語言執行時來消除程式語言的差別，“選擇平臺就意味著選擇Windows”，這句話至少在可預見的一段時間裡仍然是一個基本事實。J2EE則通過Java虛擬機器來消除平臺差別，跨平臺是它的一大賣點，也是在選擇企業應用開發平臺時的一個重要參考因素，幾乎所有的主流作業系統都提供了對J2EE的支援;實際上如果要搭建跨Unix、Windows等多個作業系統平臺，J2EE平臺幾乎是惟一的選擇，J2EE更關注跨平臺而不是跨語言。但微軟認為，如果企業的應用都能通過標準協議以Web服務的方式釋出，那麼平臺都是中立的。為了吸引更多的開發者和鼓勵廣大企業廠商轉到平臺，微軟提出了多語言支援，希望用跨語言的互動性來平衡跨平臺的互操作。
3. 效能比較
效能是J2EE和喋喋不休的話題。二者之間著名的論戰是一個關於寵物店的範例應用。寵物店是Sun一度以來作為J2EE典型應用的展示範例，而“自告奮勇”地在自己的平臺上實現了該寵物店應用，且聲稱程式碼行是J2EE的1/3，效率卻是J2EE的30倍。但Sun的理由是這個範例根本不適合用來做效能比較，該範例實現也沒有做針對性能的優化，而且指責微軟通過後端資料庫優化和快取虛抬了平臺的效率。這樣的爭吵當然不能作為判斷的依據，目前也沒有見到更客觀的第三方評測報告。在“Wintel平臺”上也許沒有理由懷疑的效能;至於非Windows平臺，和J2EE也不再具有可比性。
4.安全性、穩定性比較
WINDOWS本身的安全漏洞，使得的安全性不如J2EE。同時，在應用伺服器的選擇上，只能用IIS，安全性、穩定性難以保證;而J2EE有更多的選擇，可以在諸多遵循標準的廠商所提供的應用程式伺服器中，選擇最符合需要、成本最低、而且又被認為是最佳的平臺。
5.可擴充套件性比較
平臺的擴充套件思想是基於軟體的橫向擴充套件，而J2EE平臺的擴充套件思想則是基於硬體的縱向擴充套件。
Windows系統一般只能擴充套件到不超過8個處理器，而Sun的系統卻可以擴充套件到100個甚至更多處理器。
基於J2EE平臺的應用程式可被部署到各種作業系統上，例如可被部署到高階UNIX與大型機系統，這種系統單機可支援64至256個處理器，這是NT伺服器所望塵莫及的。J2EE領域的供應商提供了更為廣泛的負載平衡策略，能消除系統中的瓶頸，允許多臺伺服器整合部署。這種部署可達數千個處理器，實現可高度伸縮的系統，滿足未來商業應用的需要。
6.成熟度比較
在平臺的成熟度方面，兩者也有一比。J2EE在1999年形成了成熟的架構，發展至今已經具有相當成熟的、經過檢驗的企業應用系統。而究其淵源是源自微軟以前開發企業應用程式的平臺DNA(Distributed Network Architecture)，其中包括了許多已經被證實的技術，並且這些技術已經在產品中得到實現，包括微軟的事務伺服器、COM+、訊息佇列和SQL Server資料庫等。
7.第三方廠商的支援
J2EE作為一種開放的規範，從一開始就得到了眾多廠商的支援，IBM、BEA、HP、Oracle等在J2EE的實施上都有較大的投入。目前市場上最好的J2EE應用伺服器並不是Sun與Netscape合資的iPlanet，而是BEA的WebLogic和IBM的Webshpere。開發工具有Borland的JBuilder、Sun的Forte for Java、BEA的WebLogic Workshop、Oracle 的JDeveloper、IBM的VisualAge for Java等。
而在設計之初就緊緊地把平臺規範與產品膠合在一起。雖然，NET架構的一小部分具有開放性(如C#語言、通用語言基礎構造CLI 和Web服務標準)，但至少目前很難想象會有一個非微軟的實現。Visual 是其唯一的開發工具。
8.開源支援比較
J2EE開源產品眾多，免費框架居多，相應的最佳實踐設計模式層出不窮。而無開源社群支援，是以框架開發者為主導的設計。
9.學習成本比較
J2EE門檻較高，由於多且雜，需要開發人員花費很長時間才能熟悉整個體系。而門檻較低，使用方便，學習成本較低。但是，對於開發人員來說，在系統整體架構的設計方面不如J2EE易於把握。
10.對WEB服務支援的比較
從和J2EE這兩個平臺的發展歷程來看，從一開始就深深打上了Web服務技術的烙印，在它的市場推廣活動中，無時無刻不凸顯其作為Web服務的開發和部署平臺的特徵，可以說，天生就是為Web服務準備的開發和部署平臺。相對而言，J2EE是一個比較“老”的東西，最初它是為了將Java平臺拓展到企業級應用領域而制訂的一個平臺框架規範，隨著Web服務技術的興起和發展，J2EE平臺作為一個企業級應用的開發和部署平臺，無法迴避業界的重大技術革命——Web服務，J2EE也不斷地引入了對Web服務的支援。
從服務描述、服務實現和服務的釋出、發現與繫結，以及服務的呼叫和執行這些不同的角度看，J2EE和的支援基本不相上下，惟一的區別可能是的開發工具更為方便一些、整合度更高一些。
在Web服務規範的控制方面，微軟與IBM共同主推了大量的Web服務規範，在一段時間內，兩家公司Web服務技術的市場推廣活動都是聯合舉行的，不難看出這兩家公司在這個領域背後的戰略合作關係。最初的Web服務核心技術SOAP、WSDL主要由這兩家公司制訂，後來的UDDI是由這兩家為首的多家核心企業共同制訂，再後來的一些不是核心的Web服務規範，如WS-Inspection、WSFL、WS-Security、WS-Routing、WS-License和WS-Referral等，則完全是由這兩家來制訂的。不難看出：IBM和微軟對於Web服務的貢獻以及它們對Web服務規範的控制。
儘管由於某種原因，Sun公司曾經在很長的一段時間裡被排除在WS-I(由IBM，微軟和BEA發起成立的促進WEB服務互操作的一個組織)的門外，但這並沒有影響Sun公司繼續在WEB服務方面堅持開放的戰略。Sun公司是Java語言的發明者，而作為一個開放的跨平臺的技術體系，Java在WEB服務的開發方面也起著非常重要的作用。雙方妥協後，Sun最終被接納為WS-I的董事成員。
Sun公司積極地參與了制訂Web服務規範的過程，像XML和ebXML。並已經在Java中支援WEB服務中最重要的規範，例如SOAP(JAX-RPC、JAXM、SAAJ和JMS)、WSDL(Java API for WSDL)、UDDI/ebXML(JAXR)和XML(JAXP，JAXB)等等。Sun公司除了積極地參與Web服務領域裡的標準化工作，更是努力地為客戶提供全面的軟體產品，為使用者開發和部署Web服務提供平臺。Sun公司的Sun ONE Web服務平臺開發版，是業界第一個用於基於Java技術的Web服務和Web應用開發的全方位的整合平臺。該平臺集成了多種Sun ONE伺服器軟體、Java開發工具，支援業界的WEB服務標準，而且是面向開發人員設計，安裝和使用都非常簡單。
四、結束語
關於J2EE和之間的討論已經持續很多年了，孰優孰劣仍然很難下結論。事實上，和J2EE都各有特長，兩者都是十分優秀的開發平臺，短時間內誰也不可替代對方。選擇哪種開發平臺，除了要看軟體開發人員對語言的掌握能力及個人喜好，也要根據開發內容和企業具體情況、具體需求而定。
J2EE最大的優勢是跨平臺，最大的優勢是入門容易和效能較高(鑑於微軟在“Wintel平臺”上的程式碼優化功底，程式碼的執行速度較之於JAVA有明顯的優勢)。對於沒有和J2EE平臺基礎的開發團隊來說，如果開發的應用軟體沒有跨平臺的要求，只需要運行於微軟平臺之上，則選擇平臺較好;如果要求跨平臺，則只能使用J2EE。如果開發團隊具有或J2EE平臺基礎，在進行新的應用軟體開發時，如果沒有跨平臺要求，則沒有必要更換開發平臺，因為，更換平臺會帶來不小的培訓成本。
