Com與Com+的區別

COM的產生   
    
   在以前程序設計過程中,程序員把它們的函數庫放在一個叫做目標(Object)文件的單獨文件中,在這些文件中,包含了編譯過的代碼。當程序員要使用一個特別的目標文件的時候,他們把客戶程序編譯成機器代碼,然後依靠動態鏈接的手段把客戶程序聯接到目標文件上,最後變成一個單一的可執行文件。這種作法的唯一的好處在於它節省了編譯函數庫的時間。但是它有許多的缺點,比如由於在每個單獨的可執行文件中都有一個程序庫包括在裏面,浪費了許多存儲空間;對應用程序的維護也是非常困難的,如果在函數庫中發現了一個bug,整個可執行文件都要被重新編譯和分發。   
    
    
   還有不只一個的嚴重的限制在裏頭,一個客戶應用程序必須要和用同一種語言編制的函數庫在一起才能使用。比如說,一個用QuickBasic寫的客戶應用程序就不能引用一個用C++寫的函數庫。   
    
    
   因此,微軟公司出品了COM,COM僅僅只是一個規範。不管組件用什麼語言寫成,只要符合這個COM規範,就能被用任何一種語言寫成的客戶程序調用。此外,程序員不必再擔心要去建立一個單一的可執行文件,因爲組件是以GUID(Global    Unique    Identifier全球唯一標識符)來標識的。GUID是一個128位的號碼,和一些相關的信息一起被放在系統的註冊表中,用來唯一標識組件。客戶應用程序只在運行期間才動態地建立一個組件的實例,並使用這個組件的功能,因此,只需要一個函數庫的拷貝。它的缺點就是大家常常提到?quot;DLL地獄"。這個問題在一個DLL要被一個新版本的DLL所取代時引發。開發者不得不通過關閉所有的客戶應用程序的方法(如果不行,還要關閉WWW服務)來達到清除所用對這個組件的引用的目的。有時所有的方法都還起不了作用,那你只好重新啓動服務器後才能替換掉老的DLL。   
   

COM+   
    
   爲了讓企業級的應用程序能使用上COM,它必需要有以下的特定的能力。   
   ·    驗證能力     
   ·    對象池(Object    Pooling)   
   ·    事務處理     
   ·    支持分佈式架構   
   爲了使開發者不必去爲他們的組件添加這些能力,微軟公司出品了DCOM(Distributed    COM分佈式COM)和MTS(Microsoft    Transaction    Server微軟事務服務器)。使用這兩種技術,開發者就可以把精力用在他們的商業邏輯上,而不必放在後臺的他們的組件上。   
    
    
   DCOM是一個用於分佈式的組件之間的通訊的RPC(Remote    Procedure    Call)協議。客戶端向一個本地機的代理類發送請求,然後由代理類將這個請求隱含地給安裝在遠程機器上的"根"類,然後執行結果原路送回給代理類,最後代理類把它們回送給客戶端。因此,客戶程序的位置完全與組件的位置無關。DCOM的缺點在於,由於DCOM使用的是一個獨立的硬件端口,而不是HTTP協議的80端口,所以在組件間通訊的過程中,必須保證這個端口是開着的。這是一個嚴重的安全問題。所以DCOM不能夠輕易地穿越防火牆。   
    
   爲了使用MTS,程序員在它們的組件裏放置特別的MTS鉤子,編譯後把他們放在MTS包中。把有關係的組件放在一個單一的包中有它自己的好處。當客戶請求一個包中的一個組件的一個實例的時候,MTS確保爲這個包建立一個新的專門的線程,一個新的組件實例被建立在這個線程上並被應用事務服務。至於對象池服務和安全服務是否要被建立,那就要看開發者的請求了。   
    
    
   MTS允許相關的作業單元被當作一個事務來對待,這意味着如果所有的作業單元被成功地完成,整個事務就被當作成功地完成,反之如果有一個單元未成功完成,整個事務將被重新輪迴。   
    
    
   在客戶請求對象和釋放對象後,MTS仍保存着這個對象,所以當另一個客戶請求同一個組件的時候,MTS就將保存着的對象交給它。通過這種方式,MTS減少了在服務器源實例化的次數。   
    
    
   MTS允許開發者用安全措施來組裝他們的組件,以使其具有識別請求它的服務的客戶的能力。這能夠確保未經授權的客戶不能夠使用組件的功能。   
    
    
   MTS以COM+的名義被完整地整合到了微軟公司的Windows    2000操作系統中,但是COM+不僅僅只有MTS,它還包括一些其它的服務。MSMQ(Microsoft    Message    Queue    Server),一個與MTS一同發佈的服務,也被以COM+的名義整合到了Windows    2000中。MSMQ允許服務器端和客戶端進行同步的通訊。事件服務(Event    Service)也被加了進來,它使服務器能夠與客戶端同步地交流事件的發生。負載平衡服務(Load    Balancing)自動地實例化機器上的具有最多資源的服務器上的請求對象。   
    
  Top

學習COM+的筆記   
   1.COM+介紹   
   可能有許多人已經用COM設計過應用程序並知道它有很多侷限性。實際上,這項技術的一個主要問題是它不太適用於通常通過公司的局域網(LAN)或廣域網(WAN)進行發佈的企業級應用程序。   
   MS很久以前就意識到了這種限制,並試圖通過分佈式COM(DCOM)來彌補這個缺陷。   
   但是DCOM也存在一些限制,所以MS在Windows2000中提出了COM+.   
     COM+不是一項新技術,它是對當前技術的一個擴充。   
     COM+中增加的主要東西包括兩種已有的技術,微軟事務服務器(MTS)和微軟消息對列(MSMQ)。MTS通過事務增加了COM的可靠性。它確保每次COM數據傳輸至少發生一次,而且只有一次。另一方面MSMQ還改正了另一個與COM有關的問題,就是緊密連接的應用程序的問題。當使用位於本地機器上的應用程序時,客戶和服務器同時存在。但是分佈式應用程序就不能保證這一點。用戶可能在沒有連接到服務器上但同時又創建了新的工作。分佈式應用程序需要提供一個強健的環境,允許用戶在服務器處於不可用狀態時仍然可以工作。   
     1.1    COM+的歷史   
   DDE和OLE是MS早期的東東。後來OLE發展成了ActiveX(一種特殊類型的組件技術)。ActiveX實際上包含有DDE和OLE中的多種概念和技術,它增加了一種思想,既可以將ActiveX控件(獨立的專用程序或庫,通常很小)用於傳統的應用程序或嵌入到HTML文檔中在internet上使用。   
   DCOM在分佈式計算中所起的作用   
   DCOM它依賴於開放軟件基金會(OSF)分佈式計算環境(DCE)的遠程程序調用網絡協議獲得了成功。它可以使應用程序通過網絡以DDE、OLE和COM進行通信。另外,DCOM創建的鏈接即安全又持久。如果移動了服務器端的組件,則客戶機無論如何也找不到它。不過,排除掉那些不合理的東西DCOM還是十分可靠的。   
   DCOM的問題在於它與協議結合的臺緊密了。這意味着客戶和服務器必須同時存在並且在他們之間有連接。   
   DCOM還存在其他的問題。對於一次通信至少要發生一次而且只能發生一次來說DCOM就不能提供任何保證。   
   那麼COM+有多好呢?實際上COM+是三種技術的結合:DCOM、MTS和MSMQ。DCOM有一個並且只有一個問題,就是信息的傳輸。將MTS加進來就解決了這個問題。現在每次數據傳輸都將作爲一個事務而發生,這就意味着每次傳輸將只發生一次,而且至少發生一次。DCOM不能在非連接的環境中工作。MSMQ使用一個消息協議解決了這個問題。   
   1.2    COM+要點   
   1.2.1連通性   
   COM+有兩種連通性。第一,COM+所包含的MTS確保了通信的可靠性。每一次通性都保證發生且僅發生一次。第二,非連接的應用程序的開發意味着無論在何處都可以產生數據,即使沒有直接連接到服務器也可以。   
   1.2.2用戶   
   無論是對用戶還是對程序員,COM+都設計有可靠的連通性和簡易的使用性。   
    
   1.2.3用戶界面   
   1.2.4程序員   
   大多數開發人員能夠從COM+中得到的好處   
   快速的開發時間、更少的調試時間、更多的自動功能、更加可靠   
    
   1.3    COM+和COM的比較   
   從創建組件的角度來講,COM和COM+是相同的。實際上,在談及組件時COM+僅是對現存COM技術的一個擴充。COM+是COM的一個超集,所以在應用程序中用COM+代替COM不會丟失任何東西。   
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章