.NET重要技术思考-DCOM 的技术

　　從 COM(Component Object Model) 時代到 DCOM(Distributed COM) ，微軟扮演了一個推動者的角色。如果說 COM 提供了一個 Windows 平臺上的對象通訊技術，並且逐漸成為應用程式之間彼此通訊及互動的技術主流，那麼 DCOM 則是解決了電腦的通信和互動技術。
　　
　　COM 的著眼點是在於同一台電腦上不同應用程式之間的通訊需求，跨到另外一台電腦之外，就不是一開始 COM 所設想到的領域。所幸跨程式的通訊和跨電腦的通訊差異僅在於通訊協議的處理 ( 也就是定位問題 ) ，對於數據交換上型別差異的處理並不會因此而有區別。所以要讓 COM 的環境能更進一步延伸到跨電腦的領域，只要妥善解決電腦定位的需求，就有機會克服。同樣幸運的是， COM 在一開始的設計中完全不去碰觸跨電腦的問題，使得要在 COM 的架構之上再架上一層跨電腦的處理環境並不會去破壞到原本的架構。於是 COM 的網路延伸版本 DCOM(Distributed COM) 就此出現，專責讓 COM 組件可以在網路環境下持續提供服務。 DCOM 最主要處理的是兩個議題，第一個議題是網路通訊能力，第二個議題則是許可權的問題。之前 COM 是在同一台電腦中找特定的組件，而 DCOM 則要更進一步去找網路上的某台電腦，之後沿用 COM 的機制找到電腦上的組件。
　　
　　到了 .NET 當中，跨電腦的問題同樣也需要對應的技術進行處理， .NET Remoting 就是一個對應于 DCOM 的技術，它讓存活在不同應用程式域 (AppDomain ，一個 .NET 中的新概念 ) 、不同執行程式、以及不同電腦上的對象能夠順暢的進行溝通協作。在累積了長期以來分佈式應用的經驗之後，微軟沒有理由把東西設計的更難用。從某種意義來說， .NET Remoting 提供了比過去更易於使用的開發架構，用來來支援跨電腦的溝通作業，省卻開發人員建立分佈式應用程式時必須花費的心力，不過這樣一個“出色”的分佈式應用應用框架並沒有得到本來應該得到的“待遇”。相對於 Java 的 RMI 而言，它更加簡單同時保持設計方面的彈性，同時擯棄了 DCOM 的一些缺點，在對於一個前後端必須以有狀態緊密結合方式進行互動作業，同時又期望呼叫和數據交換的動作上能以最有效的方式進行的環境而言， .NET Remoting 是一個比較恰當的選擇方案。
　　
　　可是問題在於微軟本身對於 XML Web Services 的狂熱推崇讓 .NET Remoting 迷失了本來屬於它自己的陣地，也就是說 XML Web Services 的過火讓 .NET Remoting 忘記了自己應該承擔的角色，於是在開發者眼中成為了一個“可有可無”的作品，至少對於很多開發人員而言，在需要創建分佈式應用程式的時候首先考慮的是 XML Web Services ，而在於企業內部應用，特別是在可以控制伺服器和客戶端平臺的情況下（比如完全基於 .NET 平臺的應用）， Web Service 因為效率等等各個方面的原因並無法體現出優勢。從技術本身來講， .NET Remoting 是一個非常出色的架構，但在商業方面，這是一個失敗，畢竟，設計一個出色的產品然後束之高閣難免“不像話”。
　　
　　.NET Remoting 恰恰是這個戰略的犧牲品，雖然擁有與生俱來的優點，不過依然生不逢時。
　　
　　Enterprise Services
　　從一個很直接的感覺來說， Enterprise Services 只是對於 COM+ 的一個包裝，從使用方式和技術實現本身而言，和 VB 或者 VC 下使用 COM+ 服務沒有本質的區別，而更多的只是在於多了一層託管代碼的包裝，讓 .NET 開發人員能夠比較順利的使用這些服務的功能。
　　
　　相對於 J2EE 平臺上的應用伺服器如 BEA 的 WebLogic ， IBM 的 WebSphere 或者開放源代碼的 JBoss ，微軟是希望能夠在企業級應用之中分一杯羹，可是因為先天不足的原因，在企業應用中需要的事務、負載平衡、故障轉移等等技術中的表現不是那麼盡如人意，至少缺乏非常清晰的應用伺服器（ Application Server ）的概念，雖然微軟不止一次的強調作業系統本身就是一個應用伺服器，一個 IT 資訊的基礎結構。但是從開發人員實際的使用來看，這是一個“晦澀難懂”的產品。
　　
　　雖然 .NET Framework 改變了很多東西，但是作為企業級應用中最重要的支撐技術——事務和服務，並沒有得到同等程度的發展，我想這個也就是很多大型企業應用目前不選擇 .NET 的一個理由吧，畢竟從 MTS —— COM+ —— Enterprise Services ，這一路走來微軟始終不是提供一個非常透明的機制讓開發人員去控制各個環節（可能和微軟一貫以來的策略有關，只是關心最廣泛的應用而不是最高端的應用），而 .NET 中的所謂企業服務，和競爭對手提供的相當的 EJB 還是有比較大的差距，這是一個日前的微軟無法解決的軟肋。
　　
　　Web Service
　　從一開始，微軟就將其作為“重頭戲”推出，並且饒有意思的增加了 XML ，然後那個“ XML Web Services ”就成為了 .NET 戰略中一個非常重要的術語，就如微軟的白皮書所言“ Microsoft? .NET 是 Microsoft XML Web Services 平臺”，微軟通過 .NET 來改變現有的互聯網路結構，“ Windows 正在走向過去”這樣的宣傳是在於希望各個子系統之間的通信完全基於 Web Service ，那樣的話，作為 Win32 開發人員一直困擾的組建註冊，分發等等一系列問題都能夠得到解決，並且能夠用更多的語言更多的平臺去開發應用。
　　
　　“一切皆是 Web Service ”，這是一個冒進的舉動，至少對於 4 年以前的世界，而這四年以來，雖然 Web Service 有很多很多的優點可以讓我們“歌功頌德”，但是不是“萬金油”，比如一直稱垢的性能和安全問題也阻礙了 Web Service 一統天下，於是其他分佈式應用架構在特定的領域依然能夠有自己的生存空間。
　　
　　這一次，微軟高估了 Web Service ，雖然目前的 .NET 是實現 XML Web Services 最好的平臺， Visual Studio .NET 也提供了從上至下的包裝，讓開發人員完全可以不關心協議的底層實現，比如 SOAP ，比如對象序列化，比如 WSDL ，因為一切的一切都可以在 IDE 中自動完成。我們不否認因為 .NET ， Web Service 從概念已經走進應用，而 WSE 2.0 的出臺更加 Web Service 具備了互操作能力，不過依然無法改變開發人員的觀點，只有在企業外網應用集成或者內部異種平臺整合的時候才能夠體現出優勢，在於需要高度響應和服務支援的應用方面， Web Service 只是一個臆造的神話。
　　
　　ASP.NET
　　我們無法否認，這項技術對於開發人員而言是一個顛覆性的改變，從靜態的 HTML 到 CGI 再到 ASP/JSP/PHP 時代，我們都必須去了解 HTML ，了解 HTTP ，對於高水準的開發人員而言，需要掌握的還遠遠不止這個，在腳本橫行的時代，我們必須很清楚的去了解實現的各個細節，包括 HTML ， JavaScript ， CSS ，還有和伺服器相關的 Request 、 Response 。最直接而言，開發人員必須嚴格控制所有 HTML 及其相關內容的產生，腳本帶來的只是一個相對於 CGI 層次更加高級的“自動化”罷了。
　　
　　然後， ASP.NET 將這一切完全改變， WebForm 讓 Web 開發人員能夠和 Windows 開發人員一樣處理頁面事件，同時可以完全的訪問強大的 .NET Framework 類庫，而且預先編譯機制解決了 ASP 一直以來的效率低下問題。而在伺服器端的設計，在原先 ISAPI 的基礎上從新實現了 HttpHandler 和 HttpMoudle ，從而為開發人員提供了高度擴展的可能，而日前比較成熟的 WebLog 引擎 .Text 正是這些技術的經典之作。
　　
　　XML Web Services 的內置集成則使 ASP.NET 成為 Web Service 應用的最好實現，日前市場上相當大部分的 Web Service 都是基於 ASP.NET 的，在這點方面 ASP.NET 已經遠遠超出 Java 社群的技術，包括 JSP ，包括 Struct ，包括 JSF 還有其他相關的 Web 應用技術，在 ASP.NET 都能夠得到非常好的集成。
　　
　　我們不可能否認這個事實，相當大一部分（我個人認為是大部分）的開發人員轉向 .NET 是因為 ASP.NET ，對於 ASP 開發人員而言， ASP.NET 提供了更加強大的功能，很多在 ASP 中必須依賴組件技術來解決的問題比如文件上傳在新的平臺上已經成為內置支援，當然更加重要的是依賴 Visual Stuio.NET 強大的集成開發環境能夠成倍的提高生產率。而另外平臺的開發人員轉向 ASP.NET 我想也是因為彈性的設計及其便捷的開發，我相信沒有太多人會懷疑 ASP.NET 已經走在 Web 開發的最前沿。
　　
　　當然，任何事情沒有絕對的完美，在 .NET Framework 1.1( 也就是 .NET 的第二個版本 ) 之前，太多的 Postback 也是讓開發人員抱怨之處，而且採用 WebForm 的開發方式讓很多開發人員不是那麼容易的處理客戶端腳本，所有的事件實現都是依賴於 ViewState ，因此在低帶寬下的網路應用，不斷地提交也讓有些用戶感到“惱火”。
　　
　　這個世界沒有絕對的完美，但是會一點一點走向完美，也許 ASP.NET 2.0 就有太多東西值得期待。
　　
　　ADO.NET
　　相信大家不會忘記 ADO （ ActiveX Data Object ） , 我想 Windows 上面數據庫開發流行它功不可沒，通過統一的接口來實現對於數據庫的訪問，從而遮罩複雜的數據庫訪問協議。而到了 .NET 時代， ADO.NET 進一步將數據訪問“進化”，不要以為 ADO.NET 只是 ADO 的一個升級，在 ADO 的技術上提供了一個託管類庫，除了都是數據訪問框架，其他沒有太多本質的關聯。
　　
　　雖然 ADO.NET 帶來的震撼遠遠不如其他技術，可依然有很多東西值得我們去欣喜，畢竟創新總是一件好事情，何況是這個最成功的軟體公司帶來的創新，那麼我們就來看看到底帶來了什麼：
　　
　　1．除了提供了傳統 ADO 的 Connection,Command 以外，我們意外的沒有看到 Recordset 這樣的對象，而是提供了 DataReader 用來處理向前滾動的數據訪問，最最重要的是加入了 DataSet 這樣的概念，因為如此，我們能夠實現很多數據庫應用中需要的“ Disconnected Application ”，能夠實現“ InProc-Database ”，而這一切，通過 DataSet 能