本文摘自:http://www.job168.com/info/read_100394.htmlhtml
微軟的許多技術,如OLE、ActiveX、以及DirectX等都是基於COM技術而創建起來的。微軟自己也大量地使用COM組件來定製他們的應用程序及操做系統。那麼,什麼是COM呢?
所謂COM即「組件對象模型」,是一種說明如何創建可動態互變組件的規範,此規範提供了爲保證可以互操做,客戶和組件應遵循的一些二進制和網絡標準。經過這種標準將能夠在任意兩個組件之間進行通訊而不用考慮其所處的操做環境是否相同、使用的開發語言是否一致以及是否運行於同一臺計算機。開發COM的目的是爲了使應用程序更易於定製、更爲靈活。
其實,COM不是以一個單獨的開發過程的一部分出現的。相反,它最初是以對象及嵌入系統的形式產生於Windows 3.0。咱們知道,OLE 1容許一個應用程序(如WORD或EXCEL)能夠沒必要打開第二個應用程序就能顯示其它應用程序的數據。但OLE 1還存在兩個侷限:
·首先是嵌入的數據不能被應用程序所編輯;
·其次,沒有標準化的系統用於存放嵌入的信息。
因而,出現了OLE 2,OLE 2是與WINDOWS 3.1一塊兒推出的,它是第一個真正的COM技術,而OLE 1還不具有COM的各項特性—它使用的是另外一種技術體系。OLE 2中產生了一種新的惟一的數據格式,稱爲複合文件。這種文件中可以包括全部OLE支持的應用程序的相關信息,並在任一工做的應用程序中支持編輯、更新、打印等功能。
但OLE 2仍然存在一些侷限性,最爲明顯的是任什麼時候候要對一個嵌入的數據進行編輯都得從新打開一個窗口。對這一點的改進,生成了OLE的一個新版本,稱爲OLE自動化。該技術除了容許在調用數據的應用程序內部進行編輯(稱爲內部編輯),還在OLE 2的基礎上加入了其它兩項與COM技術相關的改進;一是提供了非C++開發程序(如VB程序)接入COM功能的能力;二是支持存在於複合文件之外的基於COM技術的部件的建立。Windows 3.11全面支持自動化技術。
雖然,這最後一次的技術改進給COM帶來了最持久的衝擊,可是COM的OLE實現並仍然沒有實現Bill Gate先生的部件化軟件的夢想。隨之而來的另外一技術革新卻經過從未想過的機制—VBX控件使之變成了現實。VBX是Visual Baisc開發環境的一些內帶工具,最先由C++開發,後來卻都是用VB本身開發的。VBX是一類DLL應用程序,具備特殊的支持以即可以在VB系統中使用。在一年左右的時間內,VBX控件的市場迅速發展成爲一個幾百萬美圓的產業,並帶動了VB產品的銷售。VBX具備兩項之前的自動化服務器所不具有的重要性質:用戶接口和它與客戶(容器)的通訊能力。
VBX的這種出乎意料的成功讓微軟決定讓COM工做組在自動化基礎上增長等效於VBX的性能。這一開發過程的結果就是OCX控件(是一種特殊的自動化DLL服務器),它採用COM技術支持VBX控件的全部功能,並且它今後升級爲32位的控件。惋惜,在OCX還沒有來得及普及之前,因特網和Java的出現使它們被從新改形成了ActiveX控件。
當時,沒有誰會預料到Java和Internet會在WWW領域以氫彈的威力在計算機領域爆炸。微軟長期以來一直認爲他們在PC機軟件領域的壟斷是無可挑戰的,可是Java和網頁瀏覽器伴隨着Internet,以一種全新的方式進入到我的微機的軟件領域,且該領域由Sun和Netscape控制而不是微軟。做爲迎擊,COM變成了ActiveX,複合文件變成了ActiveX文件,OCX控件變成了ActiveX控件等等。基於COM的ActiveX組件均根據Internet的特色增長相應的新特徵,如保密安全性能、代碼短、數據支持異步下載。同時,ActiveX組件還具備以下特色:
·ActiveX在自動化服務器上增長了用戶接口;
·通用屬性和屬性頁機制使ActiveX控件的行爲標準化;
·鏈接點機制支持從ActiveX控件向容器發送事件;
·ActiveX的持續性解決了越時的狀態存儲問題。
總之,OLE一、OLE二、OLE自動化、VBX控件、OCX控件、ActiveX以及COM+都是COM概念在Windows操做系統的各類實現方式。現在,COM已成爲微軟產品系列的核心組成技術:
·Internet Explorer 4網絡瀏覽器支持全部的ActiveX控件,實際上它正是採用了一個ActiveX組件用於它的顯示接口;
·Windows 98這種新版的Windows操做系統將IE與操做系統捆綁在一塊兒,它基於COM技術並支持活動桌面,使桌面部件具備網絡應用的功能;
·Internet信息服務器(IIS)是微軟加入網絡服務器大戰的重量級武器,IIS包括不少的功能強大的基於COM技術的系列內容,如Active Server Page,ISAPI擴展和ISAPI過濾器;
·微軟事務服務器(MTS)是一種面向數據庫的系統,MTS採用COM技術以支持多種數據庫系統和售貨機的混合事務處理,並仿造非數據庫的執行方式,將事務的處理變成單步的行爲,其結果能夠爲「成功」、「失敗」和「返回」而不會由於處理失敗而丟失數據;
·OLE DB推回到COM的OLE 2技術上,它採用與ODBC數據庫相同的技術,支持非數據庫應用程序與面向數據庫的技術(如MTS)共同工做。
從另外一方面看,最初,Windows是利用DLL在二進制級實現代碼共享的。這也是Windows程序運行的關鍵——重用kernel32.dll,user32.dll等。但DLL是針對C接口而寫的,它們只能被C或理解C調用規範的語言使用。由編程語言來負責實現共享代碼,而不是由DLL自己。這樣的話,DLL的使用受到限制。儘管在後來,MFC又引入了另一種MFC擴展DLL二進制共享機制,但它的使用仍受限制——只能在MFC程序中使用。
COM經過定義二進制標準解決了這些問題,即COM明確指出二進制模塊(DLL和EXE)必須被編譯成與指定的結構匹配。這個標準也確切地規定了在內存中如何組織COM對象。COM定義的二進制標準還必須獨立於任何編程語言(如C++中的命名修飾)。事實上,COM正是充分利用了Win32 DLL的靈活性才得以真正在Windows平臺上實現的。COM的發佈形式是:以win32動態連接庫(DLL)或者可執行文件(EXE)的形式發佈的可執行代碼組成。
注意,COM自己也要實現一個稱爲COM庫的API,由該庫提供諸如客戶對組件的查詢,以及組件的註冊/反註冊等一系列服務。通常來講,COM庫由操做系統加以實現,程序員沒必要關心其實現細節。
【注】DirectX技術
要在Windows平臺上進行遊戲開發必須瞭解兩個重量級遊戲API:DirectX和OpenGL。其中,DirectX是微軟開發的專門用於優化遊戲製做的API。DirectX由不少組件組成:DirectDraw、DirectSound、DirectMusic、DirectPlay、Direct3D、DirectInput、DirectSetup。它是容許你直接控制計算機硬件設備的軟件,它比Windows GDI要快好幾倍,可用於不一樣的語言和多種平臺,支持從繪製象素到高級3D圖像,從播放簡單聲音到數字音樂,從鍵盤控制到反震手柄……幾乎爲你的遊戲開發提供了所需的一切。注意,DirectX的基礎正是COM技術。
什麼是COM+?
必須明確,COM+並非COM的簡單升級,但它的底層結構仍以COM爲基礎,COM+綜合了COM、DCOM和MTS這些技術要素,把COM組件軟件提高到應用層而再也不是底層的軟件結構,它經過操做系統的各類支持,使組件對象模型創建在應用層上,把全部組件的底層細節留給操做系統;所以,COM+與操做系統的結合更加緊密。下圖3展現了COM+與MTS、COM/DCOM的關係。
圖3.COM+與MTS、COM/DCOM的關係
另外一方面,COM+再也不侷限於COM的組件技術,它更加註重於分佈式網絡應用的設計和實現。COM+繼承了COM幾乎所有的優點,同時又避免了COM實現中的一些不足,把COM、DCOM和MTS的編程模型有機地結合起來,繼承了它們的絕大多數特性,在原有的特性上增長了新的功能:
·真正的異步通信。
·事件服務。
·可伸縮性。
·可管理和可配置性。
·易於開發。
COM+標誌着微軟的組件技術達到了一個新的高度,它再也不侷限於一臺機器上的桌面系統,而是把目標指向了更爲廣闊的企業內部網,甚至國際互連網。COM+與多層結構模型(Windows DNA結構,詳見下一節)以及Windows操做系統爲企業應用或Web應用提供了一套完整的解決方案。
【問題】.NET時代,COM是否會消失?
不會。其實,.NET只不過是COM的別名而已。對於一個經驗豐富的C++程序員而言,.NET就是COM的進化,而微軟內部.NET能夠說是「COM 3.0」。其實,CLR就是一個徹徹底底的COM對象。可是,請注意,.NET使用一種不一樣的方法來編寫組件,這樣.NET組件與原先的COM組件存在明顯的不一樣。.NET組件不須要使用註冊表和類型庫,由於全部關於組件的信息都以元數據的形式包含在程序集(Assembly)中。可是,藉助於一個稱爲COM Interop的工具,COM對象和.NET對象能夠很好地協做:經過提供軟件包類,.NET對象能夠訪問COM對象;經過提供全部的註冊表項和COM對象構建機制,COM對象能夠訪問.NET對象。程序員