熱點推薦:
您现在的位置: 電腦知識網 >> 編程 >> .NET編程 >> 正文

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

2022-06-13   來源: .NET編程 

  從 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 開發人員能夠比較順利的使用這些服務的功能
  
  相對於 JEE 平台上的應用服務器如 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 那樣的話作為 Win 開發人員一直困擾的組建注冊分發等等一系列問題都能夠得到解決並且能夠用更多的語言更多的平台去開發應用
  
  一切皆是 Web Service 這是一個冒進的舉動至少對於 年以前的世界而這四年以來雖然 Web Service 有很多很多的優點可以讓我們歌功頌德但是不是萬金油比如一直稱垢的性能和安全問題也阻礙了 Web Service 一統天下於是其他分布式應用架構在特定的領域依然能夠有自己的生存空間
  
  這一次微軟高估了 Web Service 雖然目前的 NET 是實現 XML Web Services 最好的平台 Visual Studio NET 也提供了從上至下的包裝讓開發人員完全可以不關心協議的底層實現比如 SOAP 比如對象序列化比如 WSDL 因為一切的一切都可以在 IDE 中自動完成我們不否認因為 NET Web Service 從概念已經走進應用而 WSE 的出台更加 Web Service 具備了互操作能力不過依然無法改變開發人員的觀點只有在企業外網應用集成或者內部異種平台整合的時候才能夠體現出優勢在於需要高度響應和服務支持的應用方面 Web Service 只是一個臆造的神話
  
  ASPNET
  我們無法否認這項技術對於開發人員而言是一個顛覆性的改變從靜態的 HTML 到 CGI 再到 ASP/JSP/PHP 時代我們都必須去了解 HTML 了解 HTTP 對於高水平的開發人員而言需要掌握的還遠遠不止這個在腳本橫行的時代我們必須很清楚的去了解實現的各個細節包括 HTML JavaScript CSS 還有和服務器相關的 Request Response 最直接而言開發人員必須嚴格控制所有 HTML 及其相關內容的產生腳本帶來的只是一個相對於 CGI 層次更加高級的自動化罷了
  
  然後 ASPNET 將這一切完全改變 WebForm 讓 Web 開發人員能夠和 Windows 開發人員一樣處理頁面事件同時可以完全的訪問強大的 NET Framework 類庫而且預先編譯機制解決了 ASP 一直以來的效率低下問題而在服務器端的設計在原先 ISAPI 的基礎上從新實現了 HttpHandler 和 HttpMoudle 從而為開發人員提供了高度擴展的可能而日前比較成熟的 WebLog 引擎 Text 正是這些技術的經典之作
  
  XML Web Services 的內置集成則使 ASPNET 成為 Web Service 應用的最好實現日前市場上相當大部分的 Web Service 都是基於 ASPNET 的在這點方面 ASPNET 已經遠遠超出 Java 社群的技術包括 JSP 包括 Struct 包括 JSF 還有其他相關的 Web 應用技術在 ASPNET 都能夠得到非常好的集成
  
  我們不可能否認這個事實相當大一部分(我個人認為是大部分)的開發人員轉向 NET 是因為 ASPNET 對於 ASP 開發人員而言 ASPNET 提供了更加強大的功能很多在 ASP 中必須依賴組件技術來解決的問題比如文件上傳在新的平台上已經成為內置支持當然更加重要的是依賴 Visual StuioNET 強大的集成開發環境能夠成倍的提高生產率而另外平台的開發人員轉向 ASPNET 我想也是因為彈性的設計及其便捷的開發我相信沒有太多人會懷疑 ASPNET 已經走在 Web 開發的最前沿
  
  當然任何事情沒有絕對的完美NET Framework ( 也就是 NET 的第二個版本 ) 之前太多的 Postback 也是讓開發人員抱怨之處而且采用 WebForm 的開發方式讓很多開發人員不是那麼容易的處理客戶端腳本所有的事件實現都是依賴於 ViewState 因此在低帶寬下的網絡應用不斷地提交也讓有些用戶感到惱火
  
  這個世界沒有絕對的完美但是會一點一點走向完美也許 ASPNET 就有太多東西值得期待
  
  ADONET
  相信大家不會忘記 ADO ( ActiveX Data Object ) 我想 Windows 上面數據庫開發流行它功不可沒通過統一的接口來實現對於數據庫的訪問從而屏蔽復雜的數據庫訪問協議而到了 NET 時代 ADONET 進一步將數據訪問進化不要以為 ADONET 只是 ADO 的一個升級在 ADO 的技術上提供了一個托管類庫除了都是數據訪問框架其他沒有太多本質的關聯
  
  雖然 ADONET 帶來的震撼遠遠不如其他技術可依然有很多東西值得我們去欣喜畢竟創新總是一件好事情何況是這個最成功的軟件公司帶來的創新那麼我們就來看看到底帶來了什麼
  
  .除了提供了傳統 ADO 的 ConnectionCommand 以外我們意外的沒有看到 Recordset 這樣的對象而是提供了 DataReader 用來處理向前滾動的數據訪問最最重要的是加入了 DataSet 這樣的概念因為如此我們能夠實現很多數據庫應用中需要的 Disconnected Application 能夠實現 InProcDatabase 而這一切通過 DataSet 能
From:http://tw.wingwit.com/Article/program/net/201311/11599.html
    推薦文章
    Copyright © 2005-2022 電腦知識網 Computer Knowledge   All rights reserved.