看到這個標題，也許會有人表示疑惑，J2EE和.NET並不在壹個層次上，怎麽能將它們放在壹起呢？需要指出的是，通常所說的.NET包含了壹個相當廣泛的產品家族，包括開發平臺、操作系統、服務器、終端設備等，此外還包括服務平臺。開發平臺只是整個.NET戰略中的壹部分，所以確切地說，放在這裏的.NET應該算是.NET開發平臺。
隨著三層/多層企業信息系統結構的深度發展和下壹代分布式計算模型Web 服務的出現，企業應用中關於平臺、框架、語言的競爭也愈演愈烈。J2EE平臺在過去幾年裏壹直引領著企業應用的潮流，但最近微軟強力推出的.NET平臺也開始吸引著眾多IT企業和開發人員的註意力，向J2EE平臺提出了強有力的挑戰。企業應用領域的技術對抗也因此拉開了架勢。
需要強調的是，.NET是戰略產品，而J2EE是描述產品的標準，現在有很多符合J2EE標準的產品。在可以預見的未來，它們都將是構建企業信息系統應用的基礎性平臺，尤其是開發和部署Web服務的重要平臺。
盡管可以同時使用幾種系統平臺和語言，但對於企業來說，還需要選擇壹個戰略性的平臺來實現數據的無縫集成，加速企業應用的部署。而要做出正確的選擇，首先需要充分了解兩個平臺的特點和優勢。本期專題將為您細說J2EE和.NET。
壹、群力所至的J2EE
二、.NET開發平臺留住Windows開發者
三、 J2EE與.NET平臺體系架構的異同
四、 J2EE vs .NET：Web服務誰主沈浮？
壹、群力所至的J2EE
中南大學 羅新星 畢文傑
企業應用系統的開發壹直面臨著重大挑戰：壹方面，企業應用系統面對的是壹個異構的分布式環境，它必須支持與已有系統的集成性和與其他系統的互操作性；另壹方面，作為為客戶、合作夥伴和企業內部提供信息服務的平臺，企業系統還必須具有高可用性、安全性、可靠性和可伸縮性。這些要求再加上復雜多變的用戶需求和不斷伸縮的交付時間，使得企業系統的開發越來越困難。開發商和廣大程序員壹直在努力推動和殷切期待壹個成熟、標準的企業平臺來簡化和規範企業系統的開發和部署。Java技術的出現，尤其是J2EE（Java 2 Platform Enterprise Edition）平臺的推出正是這種努力的結果，也使得企業系統的開發由此變得更加快速和方便。需要指出的是，J2EE本身是壹個標準，它為不同廠商創建平臺產品提供了標準，使不同J2EE平臺產品之間的交互成為可能。
J2EE旅程
Java於1996年由Sun公司推出，當時它的主要用途是制作產生動態網頁的Applet。後來，人們發現Java的“壹次開發，多次運行”、純面向對象的特性、垃圾回收機制和內置的安全特別適合於開發企業應用系統。於是，企業應用開發商紛紛在Java標準版的基礎上各自擴展出許多企業應用API，其結果導致基於Java的企業應用呈爆炸式增長。但是各企業系統API之間又不能相互兼容，破壞了Java的平臺獨立性。鑒於此，Sun公司聯合IBM、Oracle、BEA等大型企業應用系統開發商於1998年***同制訂了壹個基於Java組件技術的企業應用系統開發規範，該規範定義了壹個多層企業信息系統的標準平臺，旨在簡化和規範企業應用系統的開發和部署。這壹規範和其定義的平臺就構成了J2EE。目前J2EE的最新版本是J2EE 1.3。需要註意的是，J2EE本身是壹個標準，而不是壹個現成的產品（雖然現在有很多符合J2EE標準的產品），它由以下幾個部分組成：
J2EE規範。該規範定義了J2EE平臺的體系結構、平臺角色及J2EE中每種服務和核心API的實現要求。它是J2EE應用服務器開發商的大綱。
J2EE兼容性測試站點。Sun公司提供的壹個測試J2EE應用服務器是否符合J2EE規範的站點，對通過該站點測試的產品，Sun公司將發放兼容性證書。
J2EE參考實現。即J2EE SDK，它既是Sun公司自己對J2EE規範的壹個非商業性實現，又是為開發基於J2EE企業級應用系統原型提供的壹個免費的底層開發環境。
J2EE實施指南。即BluePrints文檔，該文檔通過實例來指導開發人員如何去開發壹個基於J2EE的多層企業應用系統。
組件-容器 搭建體系架構
J2EE規範定義了壹個基於組件的多層企業應用系統開發平臺，其邏輯結構如圖1所示。圖中的橢圓形表示組件，大矩形表示容器，包含向下文字的小矩形表示API，箭頭表示訪問，箭頭線上的文字表示相應的協議。
J2EE是壹個基於組件-容器模型的系統平臺，其核心概念是容器。容器是指為特定組件提供服務的壹個標準化的運行時環境，Java虛擬機就是壹個典型的容器。組件是壹個可以部署的程序單元，它以某種方式運行在容器中，容器封裝了J2EE底層的API，為組件提供事務處理、數據訪問、安全性、持久性等服務。在J2EE中組件和組件之間並不直接訪問，而是通過容器提供的協議和方法來相互調用。組件和容器間的關系通過“協議”來定義。容器的底層是J2EE服務器，它為容器提供J2EE中定義的各種服務和API。壹個J2EE服務器（也叫J2EE應用服務器）可以支持壹種或多種容器。在圖1中，妳可能已經註意到每個容器的服務包括兩部分：J2SE（Java 2 Platform Standard Edition）和壹組擴展的服務。這是因為J2EE是以Java標準版為基礎的，各容器在J2SE之上再根據需要提供壹些擴展的服務，如目錄服務、事務管理、數據訪問、消息機制、安全性等。
J2ee的核心——EJB
J2EE定義了四種組件：Applet組件、Application客戶組件、Web組件及EJB（Enterprise JavaBeans）組件。其中Applet和Application客戶組件在客戶端運行，J2EE通過Java插件為Applet提供運行環境，Application客戶的容器就是本地Java虛擬機。Web及EJB組件在服務端運行。J2EE中包含兩種Web組件：JSP和Servlet。它們是Web服務器的功能擴展，都能生成動態Web頁面。不同的是JSP是將Java代碼嵌入到HTML中，服務器負責解釋執行，生成結果返回用戶（與ASP技術相似）。而Servlet是單獨的Java類，它動態生成HTML文件返回給客戶。Web組件的容器比較典型的就是基於Java的Web服務器。
EJB是J2EE平臺的核心，也是J2EE得到業界廣泛關註和支持的主要原因。我們知道，J2EE的壹個主要目的就是簡化企業應用系統的開發，使程序員將主要精力放在商業邏輯的開發上。EJB正是基於這種思想的服務器端技術，它本身也是壹種規範，該規範定義了壹個可重用的組件框架來實現分布式的、面向對象的商業邏輯。EJB的核心思想是將商業邏輯與底層的系統邏輯分開，使開發者只需關心商業邏輯，而由EJB容器實現目錄服務、事務處理、持久性、安全性等底層系統邏輯。
壹個可部署的EJB組件包含3個部分：
Remote 接口 Remote接口定義EJB組件中提供的可供用戶調用的方法，也就是通常所說的實現商業邏輯的函數或過程（如計算商品價格的函數），以供遠程客戶端調用。在EJB組件部署到容器的時候，容器會自動生成Remote接口相應的實例，即EJB對象，它負責代理用戶的調用請求。
Home接口 Home接口定義壹組方法來創建新的EJB對象，查找、定位和清除已有的EJB對象。在EJB組件部署時容器也會自動生成相應的Home對象，該對象負責查找和創建EJB對象，返回EJB對象的引用給客戶；用戶利用該引用調用EJB組件的方法，得到結果；最後Home對象清除EJB對象。我們可以形象地稱Home接口為EJB對象的工廠。
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的部署、發布和生命周期管理。
平臺標準服務
服務是組件和容器之間，以及容器和J2EE服務器之間的接口，在實現層面上它就是壹系列API和協議。J2EE平臺定義了壹組標準的服務，其中有些服務是由J2SE提供的，有些則是J2EE對Java的擴展。
目錄服務 JNDI（Java Name and Directory） API為應用程序提供了壹個統壹的接口來完成標準的目錄操作，由於JNDI是獨立於目錄協議的，應用程序可以用它訪問各種目錄服務，如LDAP、NDS、DNS等。
數據訪問 JDBC（Java Database Connectivity) API為訪問不同類型的數據庫提供了統壹的途徑，屏蔽了不同數據庫的細節，具有平臺無關性。J2EE平臺除了要求核心的JDBC API（包含在J2SE中）外，還要求擴展的JDBC API 2.0，它支持行集、連接池和分布式的事務處理。
事務處理 JTA（Java Transaction Architecture）定義了壹組標準的接口，為應用系統提供可靠的事務處理支持。JTS（Java Transaction Service）是CORBA OTS事務監控的Java實現。JTS規定了事務管理器的實現方式，該事務管理器在高層支持JTA標準，在底層實現了OMG OTS規範的Java映射。
消息服務 JMS（Java Message Service）是壹組用於和面向消息的中間件相互通信的API。
它既支持點對點的消息通信，也支持發布/訂閱式的消息通信。 電子郵件 JavaMail API允許在應用程序中以獨立於平臺、獨立於協議的方式收發電子郵件。JAF（JavaBeans Activation Framework）負責處理MIME編碼，JavaMail利用JAF來處理MIME編碼的郵件附件。
CORBA兼容接口 RMI（遠程方法調用）是在分布式對象間通信的Java本地方法，它使應用程序調用遠程方法像調用本地方法壹樣，不需要考慮所調用對象的位置。RMI-IIOP是RMI的擴展，是符合CORBA標準的對象通信協議，也是J2EE默認的組件通信協議。Java IDL允許J2EE應用組件通過IIOP協議訪問外部的CORBA對象。
安全服務 JAAS（Java Authentication and Authorization Service）用兩個步驟實現安全性：認證，即由用戶提供認證信息（如用戶名和密碼）來獲得系統認證，這壹過程又稱之為登錄；授權，在被確認為合法用戶後，系統根據用戶的角色授予其相應的權限。J2EE的授權是基於安全角色的概念，壹個安全角色是壹個擁有相同權限的邏輯組。J2EE的安全角色由應用組件提供商來定義。
Web服務支持 目前J2EE還不提供對Web服務的支持。Sun提供了壹套API及其實現WSDP作為對J2EE的擴展，但目前還不是J2EE規範的內容。在WSDP中，JAXP用來解析XML文檔;JAXR向UDDI服務器註冊Web Services；JTX/RPC用基於XML的協議（如SOAP）來發送和接收XML文檔；JWSDL處理WSDL文檔。雖然J2EE不是為Web服務而生，但它現在正在努力追趕Web服務的腳步。
多層應用模型
從應用的角度來看，J2EE為企業應用系統的開發提供了壹種多層分布式企業應用模型。在J2EE中，應用邏輯按功能不同可以劃分為不同類型的組件，各組件根據它們所在的層分布在不同的機器上，***同組成壹個基於組件的分布式系統。
J2EE定義了壹個典型的四層結構，分別是客戶層、Web層、商業邏輯層和企業信息系統層。
在應用開發時，J2EE定義的四層模型可根據實際情況靈活運用。由於除了Applet外其他的組件都可以訪問數據庫、EJB組件和企業信息系統，所以通過不同層的取舍及組合，可以衍生出許多應用軟件開發模型，如基於Web的四層模型、基於桌面應用的三層模型（不包括Web層）、B2B模型（不包括客戶層）等。如果應用系統比較簡單，壹般不用EJB作為邏輯層，而直接用Web組件來實現商業邏輯和數據訪問，畢竟EJB的開發和部署費用還相當高。
二、.NET開發平臺留住Windows開發者
南京郵電學院 李建忠
.NET開發平臺壹推出，就開始了與J2EE平臺的競爭。它的絕大部分是微軟Windows DNA(Distributed Network Architecture)的重寫，DNA是微軟以前開發企業應用程序的平臺。Windows DNA中包括了許多已經被證實的技術，新的.NET框架取代了這些技術，並包含了Web服務層和改良的語言支持。從戰略角度看，.NET開發平臺擔負著整合.NET戰略的重任，但它最直接的目標則是努力為微軟保留住龐大的Windows用戶基礎。
微軟的Windows開發用戶群是微軟通過Windows操作系統獲得的最大財富。對於為什麽要推出.NET開發平臺，微軟表示，主要原因之壹就是由於Java向開發者承諾的硬件和操作系統無關性，可能會導致這些用戶轉向其他平臺。雖然開發平臺本身不會給微軟帶來很多收益，但Windows程序員是企業內部對微軟產品的主要支持力量，商用軟件的開發者形成了向客戶銷售微軟產品的重要渠道。如果微軟可以讓開發者在.NET開發平臺上編寫應用程序，那麽就會有更多的公司購買微軟的其他產品。
認識.NET
認識.NET最好的方法是看它做什麽。.NET戰略將互聯網本身作為構建新壹代操作系統的基礎，並對互聯網和操作系統的設計思想進行合理延伸，使開發人員能夠創建出與設備無關的應用程序，以便輕松實現互聯網連接。.NET包括壹個相當廣泛的產品家族，它們構建於XML和互聯網產業標準之上，為用戶提供Web服務的開發、管理、應用和體驗。圖1是對.NET戰略的總體描述。組成.NET戰略的五個方面包括：
.NET開發平臺 這是壹組用於建立Web服務應用程序和Windows桌面應用程序的軟件組件，包括 .NET Framework（框架）、.NET開發者工具和ASP.NET。於今年3月發布的Visual Studio .NET將是RAD開發工具中壹個重要的產品。
.NET服務器 能夠提供廣泛聚合和集成Web服務的服務器是搭建.NET平臺的後端基礎。 .NET基礎服務 密碼認證、日歷、文件存儲、用戶信息等基礎服務是必不可少的。微軟正在著力建設的.NET My Services等基礎性服務平臺是這方面可以借鑒的例子。
.NET終端設備 廣泛的連接互聯網並體驗Web服務的終端設備是實現.NET的前端基礎。PC、PDA以及各種嵌入式設備將在這個廣闊的天地裏發揮作用。
.NET用戶體驗 能夠滿足人們各種各樣需求的用戶體驗是.NET的最終目標，也是.NET的價值實現。
在這五個組成部分當中，.NET開發平臺中的 .net框架是.NET軟件構造中最具挑戰性的部分，其他四個部分則緊緊圍繞.NET框架來進行組織整合。
.NET 框架內核
.NET框架實現了語言開發、代碼編譯、組件配置、程序運行、對象交互等各個層面的功能，為Web服務及普通應用程序提供了壹個托管、安全、高效的執行環境。所有在.NET平臺上創建的應用程序運行都需要兩個核心模塊:Common Language Runtime（CLR，通用語言運行時）和.NET Framework類庫。CLR是壹個軟件引擎，用來加載應用程序，確認它們可以沒有錯誤地運行，並進行相應的安全許可驗證，執行應用程序，然後將被清除。
.NET Framework類庫則向程序員提供軟件組件，來編寫在CLR的控制下運行的代碼，它們按照單壹有序的分級組織提供了壹個龐大的功能集，包括從文件系統到對XML功能的網訪問的每壹樣功能。該類庫為開發提供了三種基本編程模板：基於ASP.NET的Web表單應用、基於ASP.NET的Web服務應用和基於傳統GUI交互的Windows應用。
CLR——.NET的虛擬機
CLR為.NET應用程序提供了壹個托管的代碼執行環境。托管意味著將原來由程序員或操作系統做的工作剝離出來交由CLR來完成，從而使程序運行獲得更高的安全性和穩定性。這些工作包括內存管理、即時編譯、組件自描述、安全管理和代碼驗證，以及其他壹些系統服務。CLR提供壹個技術規範，無論程序使用什麽語言編寫，只要能編譯成中間語言，就可以在它的支持下運行，這樣.NET應用程序就可以獨立於語言。CLR還在應用程序運行環境中為基於組件的編程提供了直接支持，比如它支持屬性、事件、對象、繼承性、多態性、接口等組件編程特性。
CLR中的自動垃圾收集器負責.NET應用程序運行時的內存分配、對象布局、內存釋放等內存管理問題，徹底解決了多年來困擾程序員的內存泄漏問題，大大增強了應用程序的健壯性。
即時編譯器在運行時將中間語言以調用的對象方法為單位動態編譯成本地二進制代碼。
中間語言是在.NET平臺下編譯器輸出PE文件（Windows可執行文件）的語言，它為.NET平臺提供了多語言支持，允許開發者使用20多種不同的編程語言。而元數據是壹個內嵌於PE文件的表的集合，描述了代碼中數據類型等在代碼執行時CLR需要知道的信息。元數據使得.NET應用程序代碼具備自描述特性，提供了類型安全保障，而這在以前需要額外的類型庫或接口定義語言（IDL）。
CLR根據托管組件的來源（如互聯網、企業局域網、本地機器）等因素確定各組件的信任度，並根據信任度來限定它們執行諸如讀取文件、修改註冊表等敏感操作的權限。此外，CLR借助通用類型系統對代碼類型進行嚴格的安全檢查，可以避免不同組件之間可能存在的類型不匹配問題。通過代碼訪問安全機制，開發人員可以為應用程序指定完成工作所必需的權限。CLR不僅規定了代碼訪問安全，還規定了基於角色的安全。基於角色的認證為互聯網上分布式組件的執行提供了安全保證。
值得指出的是，CLR通常寄宿在其他高性能服務器的應用程序中，比如互聯網信息服務器（IIS）、SQL Server數據庫服務器等。這樣，開發者可以充分利用CLR諸多安全、高效的優點來部署自己的商業邏輯。
類庫——組件和服務的家園
.NET Framework類庫由壹組廣泛的、面向對象的、可被開發者用於任何編程語言的可重用類集合組成。它提供了幾乎所有應用程序都需要的公***代碼;在此之上是許多應用程序模板，這些模板為開發網絡站點和網絡服務提供特定的高級組件和服務，不管是傳統的命令行程序還是Windows圖形界面程序，亦或是面向下壹代互聯網分布式計算平臺的ASP.NET或Web服務應用。與在Windows和它的SDK中發送的代碼庫壹樣，.NET框架類庫將程序員從繁重的編程細節中解放出來，而專註於程序的商業邏輯。它將核心Win32 API最常用的功能和外掛SDK的功能封裝到了壹個統壹的包中，並采用清晰而有條理的方式對類庫進行分組和描述，這樣開發者就能夠更方便地找到其應用程序所需要的大多數功能。下面是它所提供的壹些核心服務：
系統框架服務
服務框架包括壹套開發人員希望在標準語言庫中存在的基類庫，如集合、輸入/輸出、字符串、數據等基類。基類庫還提供訪問操作系統服務的類，如圖畫、網絡、線程、加密等類型。此外，服務框架也包括數據訪問類庫以及開發工具。
ADO.NET組件
ADO.NET為基於網絡的、可擴展的應用程序和服務提供數據訪問服務。它不僅支持傳統的基於鏈接指針風格的數據訪問，而且對於更適合於把數據返回到客戶端應用程序的無鏈接數據模板，它也提供高性能的訪問支持。
XML數據組件
通過它開發人員可以對任何數據進行XML轉換、傳輸和確認，所有數據都可以被看做是XML格式的。同時，系統也支持ADO.NET數據與XML數據之間的通用轉換。
Windows表單組件
Windows表單組件為開發人員提供了強大的Windows應用程序模型和豐富的Windows用戶口，包括傳統的ActiveX控件和Windows XP的新界面，如透明的、分層的浮動窗口。對CLR的強大支持也是Windows表單組件令人興奮的地方之壹。
ASP.NET應用服務
ASP.NET的核心是其用於處理基於低級結構HTTP請求的高性能的運行語言，其編譯運行的方式大大提高了它的性能。ASP.NET使用基於構件的.NET框架配制模板，因此它獲得了諸如XCOPY配制、構件並行配制、基於XML配制之類的優點。它還支持應用程序的實時更新，同時提供高速緩沖服務，以改善性能。
ASP.NET Web表單
ASP.NET Web表單把VB表單高效率的優點帶到了Web應用程序的開發中。ASP.NET Web單支持傳統的將HTML內容與腳本代碼混合的ASP語法，但是它提出了壹種將應用程序代碼和用戶接口內容分離的、更加結構化的方法。它提供壹套映射傳統HTML用戶接口部件（包括列表框、文本框和按鈕）的ASP.NET Web表單控件和壹套更加復雜的Web應用控件（如日歷和廣告轉板）。
對於.NET和Java本質區別最精辟的評述
java是平臺無關的語言， #e.O?e
.NET是語言無關的平臺。 U 1[
lTuVLQ*e
早說有報道 ?39aW4%g
java呈下面的三角型： 6 _^X@$IVD
java sBrpJc
unix linux windows... 'KxUv$5x
c c++ java vb C#... vtCd6cl=c
whidows be@})?gH
而oracle就這兩種都沒有，但有這兩者都沒有的數據庫平臺和sap。而甲骨文的最終幻想就是把這兩個三角型合起來成為壹個矩形。 Ri/?Y6r63
個人看法：不過單純從語言以及sun和ms的基本語言庫來說，java已經比不上.net了（以前是.net學java，現在是java學.net）。java剩下的只是哪將近十年來的經驗積累 iHa)XtI
~+H)"e
由於M$自己也有數據庫系統軟件，Oracle的這個最終幻想可能還要長久的幻想下去，而且有無終點還很難說。 uAYFZ{%C$
再則M$的產品線的互補性已經是很難撼動的了，Visual Studio、Windows、Office和Sql Server，太嚇人了@_@。 Z*6:;nzn
7$%'URFP]
net 是平臺壟斷 i }$soCE
java 是語言壟斷 nV%#lMQ G
2!myNh:zM
好像C++之父給個壹個論斷：JVM本身就是壹種平臺（大意）。 f950x3++L
SUN or M$都是要將開發者binding到自己的平臺上。 6H.2hW&Fm
不過不考慮技術本質，考慮現在的市場現象，這個論斷可以成立 0q>wxi`i
,3XmL
.net 基本看壹本書就夠了 而Java要看許多書 還不壹定能幹活 =#+0HLGCFA
`# >.Q,V
.net就像品牌機,什麽東西都預先由M$裝好,但整體性能總是那麽差強人意.JAVA更容易DIY,DIY就需要自看更多的書,當然這是取舍問題.
在SD Times的壹篇名為Java VS .NET？的文章中，作者提出了自己的觀點，在企業的應用中，Java並不會和.NET正面對抗，而更可能的是合作。Java和.NET各有特點，各有優勢：
1、 在智能客戶端領域，.NET絕對占有統治地位。
2、 Java在大規模的、跨平臺集成的服務端領域則有明顯優勢。
3、 論及開發工具的功能性和易用性，則首推.NET
4、 而在安全性方面，基於Linux和Unit的Java要強於基於Wnidows的.NET。
文中還提到，雖然以上的對比是當前的實情，但Java和.NET都在不斷的發展中，彼此之間的差距還在持續的縮小。兩個陣營都在相互學習，彌補自身的不足，最後的兩個產品將會越來越相似。
.NET將開發工具的易用性發揮到了極致。但微軟走的是傻瓜型工具的路線，這壹點為諸多優秀程序員所不屑。但傻瓜型工具的特點會帶來生產力的突破，可以預言，在壹些小型的企業中，將會在未來幾年更多的轉向.NET的方案。尤其是現在使用VB、PB、Delphi的各個企業。
開放源碼界給了Java很大的助力，而Java的很大壹部分的魅力也是通過各個優秀的開放源碼項目得到體現的。可能有壹些企業並不關心開放源碼，但這個態度其實是有問題的。開發源碼的價值在於，他提供了壹種生態環境：企業可以借助開源項目，在壹個很高的起點上發展，然後再實現盈利的同時，反之回饋開源項目。在人的問題上，開源軟件鍛煉了大批優秀的程序員，這批程序員不是依賴於某個公司提供的傻瓜型工具，而是靠自己，靠集體的智慧來提高勞動生產率。這種發展模式是和.NET的路線截然不同的。所以Java下有很多關於軟件管理、軟件建模方面的研究，而.NET這方面就差很多了。
而值得稱道的是，微軟做了壹件非常聰明的事情－將CLR規範和C#規範提交給了ECMA組織，從而實現了.NET底層框架的標準化，這使得壹些程序員開始將壹些優秀的開源項目轉移到.NET上來。而Mono項目的發展，也使得.NET真正實現了跨平臺的目標。這樣，.NET就正式涉足到了Unit環境中。但微軟還有很長的路要走。