COM/DCOM簡述

　　這些組件對象能夠互相通信與交互，而與它們的語言、分佈及原始平臺無關。COM規程包括一套標準API、一個標準的接口集以及COM用於支持分佈式計算的網絡協議。而DCOM模型則是一套用於分佈式環境中的COM對象，在DCOM環境中，位於一個網絡上的COM對象能與位於另外一個網絡上的COM對象進行通訊。一般咱們能夠把COM看做是某種（軟件）打包技術，即把它看做是使軟件的不一樣部分按照必定的面向對象的形式，組合成能夠交互的過程和一組支持庫。COM對象能夠用C++、JAVA和VB等任意一種語言編寫，而且能夠以DLL或做爲不一樣過程工做的執行文件的形式來實現。使用COM對象的客戶端，無需關心對象是用什麼語言寫的，也無需關心它是以DLL、仍是以另外的過程來執行的。從速度上來看，COM(動態鏈接庫形式)與客戶共同存在於同一內存空間,調用速度快,DCOM的速度只有COM的萬分之一。 其實，DCOM自己就是COM的一種表現形式,可是因爲你們聽見COM通常就把它當成在本地執行的COM,而DCOM固然就是分佈的COM,在網絡上的另外一臺計算機上執行。COM有兩種存在形式,動態鏈接庫和可執行程序,但DCOM必須是可執行程序。由於DCOM不可能在客戶程序的內存空間運行,因此不能是動態鏈接庫。從另外一方面來講，DCOM爲面向對象的分佈式計算定義了跨平臺服務（或抽象），其中包括鏈接組件、建立組件、組件的定位、激活組件的方法以及一個安全性框架。除了這些以外，DCOM僅僅使用了每個平臺上都有的服務來完成多線程化和併發控制、用戶界面、文件系統之間的相互做用、非DCOM網絡的相互做用以及實際的安全性模塊。

　　

DCOM有如下幾個特色：

1. DCOM的結構特色。

　　DCOM是組件對象模型（COM）的進一步擴展。COM定義了組件和它們的客戶之間互相做用的方式，它使得組件和客戶端無需任何中介組件就能相互聯繫。當客戶進程和組件位於不一樣的機器時，DCOM僅僅只是用網絡協議來代替本地進程之間的通信。不管是客戶仍是組件都不會知道鏈接它們的線路比之前長了許多。

　　2.組件與複用。

　　就目前的應用狀況來看，大多數的分佈式應用都不是憑空產生的，現存的硬件結構、軟件、組件以及工具須要集成起來，以便減小開發和擴展時間以及費用。DCOM可以直接且透明地改進現存的對COM組件和工具的投資。對各類各樣組件需求的巨大市場使得將標準化的解決方案集成到一個普通的應用系統中成爲可能。許多熟悉COM的開發者可以很輕易地將他們在COM方面的經驗運用到基於DCOM的分佈式應用中去。任何爲分佈式應用開發的組件都有可能在未來被複用。圍繞組件模式來組織開發過程使得你可以在原有工做的基礎上不斷的提升新系統的功能並減小開發時間。基於COM和DCOM的設計能使你的組件在如今和未來都能被很好到使用。

 　　3.DCOM位置獨立性。

　　你開始在一個真正的網絡上設計一個分佈式應用時，如下幾個相互衝突的設計問題會很清楚地反映出來：(1)相互做用頻繁的組件彼此間應該靠得更近些。(2)某些組件只能在特定的機器或位置上運行。(3)小組件增長了配置的靈活性，但它同時也增長了網絡的擁塞。(4)大組件減小了網絡的擁塞，但它同時也減小了配置的靈活性。若是咱們使用DCOM組件技術，這些設計上的限制將很容易解決，由於配置的細節並非在源碼中說明的。DCOM使得組件的位置對你來講徹底透明，不管它是位於客戶的同一進程中仍是位於地球的另外一端。在任何狀況下，客戶鏈接組件和調用組件的方法的方式都是同樣的。DCOM不只無需改變源碼，並且無需從新編譯程序。一個簡單的再配置動做就可改變組件與組件之間相互鏈接的方式。 DCOM的位置獨立性極大地簡化了將應用組件分佈化的任務，使其可以達到最合適的執行效果。例如，設想某個組件必須位於某臺特定的機器上或某個特定的位置上，而且此應用有許多小組件，你能夠經過將這些組件配置在同一個LAN上，或者同一臺機器上，甚至同一個進程中來減小網絡的負載。當應用是由比較少的大組件構成時，網絡負載並不

是問題，此時你能夠將組件放在速度快的機器上，而不用去過問這些機器到底在哪兒。 下圖顯示了相同的「有效性檢查組件」在兩種不一樣狀況下是如何分別配置的。一種狀況是當「客戶」機和「中間層」機器之間的帶寬足夠大時，它是怎樣配置在客戶機上的；另外一種狀況是當客戶進程經過比較慢的網絡鏈接來訪問

組件時，它又是怎樣配置在服務器上的。

        有了DCOM的位置獨立性，應用系統能夠將互相關聯的組件放到靠地比較近的機器上，甚至能夠將它們放到同一臺機器上或同一個進程中。即便是由大量的小組件來完成一個具備複雜邏輯結構的功能，它們之間仍然可以有效地相互做用。當組件在客戶機上運行時，將用戶界面和有效性檢查放在客戶端或離客戶端比較近的機器上會更有意義；集中的數據庫事務應該將服務器靠近數據庫。

 　　4.DCOM的語言無關性

在設計和實現分佈式應用系統時，一個廣泛的問題就是爲開發一個特定的組件而選擇語言以及工具的問題。語言選擇是一個典型的在開發費用、可獲得的技術支持以及執行性能之間的折衷。做爲COM的擴展，DCOM具備語言獨立性。任何語言均可以用來建立COM組件，而且這些組件可使用更多的語言和工具。Java，MicrosoftVisualC++，MicrosoftVisualBasic，Delphi，PowerBuilder和MicroFocusCOBOL都可以和DCOM很好地相互做用。 由於DCOM具備語言獨立性，應用系統開發人員能夠選擇他們最熟悉的語言和工具來進行開發。語言獨立性還使得一些原型組件開始時能夠用諸如VisualBasic這樣的高級語言來開發，而在之後用一種不一樣的語言，例如VisualC++和Java來從新實現，而這種語言可以更好地支持諸如DCOM的自由線程／多線程以及線程共用這些先進特性。

 　　5.DCOM的鏈接管理

網絡鏈接自己就比同一臺機器中的鏈接更脆弱。當一個客戶再也不有效，特別是當出現網絡或硬件錯誤時，分佈式應用中的組件須要被加以注意。DCOM經過給每一個組件保持一個索引計數來管理對組件的鏈接問題，這些組件有多是僅僅只鏈接到一個客戶上，也有可能被多個客戶所共享。當一個

客戶和一個組件創建鏈接時，DCOM就增長此組件的索引計數。同理，當客戶釋放鏈接時，DCOM就減小此組件的索引計數。若是索引計數爲零，組件就能夠被釋放了。 DCOM使用有效的地址合法性檢查（pinging）協議來檢查客戶進程是否仍然是活躍的。客戶機週期性地發送消息，當通過大於等於三次ping週期而組件沒有收到pinging消息時，DCOM就認爲這個鏈接中斷了。一旦鏈接中斷，DCOM就減小索引計數，當索引計數爲零時就釋放組件。從組件的這一點看來，不管是客戶進程本身中斷鏈接這種良性狀況，仍是網絡或者客戶機崩潰這種致命狀況，都被同一種索引計數機制處理。 在不少種狀況下，組件和它的客戶進程之間的信息流是沒有方向性的：組件須要在客戶端進行某些初始化操做，例如一個長進程的結束，用戶所觀看數據的更新，或者諸如電視以及多用戶遊戲這些協做環境中的下一條信息等。許多協議使得完成這種對稱性的通信十分困難。使用DCOM，任何組件都既可使功能的提供者，有能是功能的使用者。通信的兩個方向都用同一種機制來管理使得完成對等通信和客戶機／服務器之間的相互做用同樣容易。 DCOM提供了一個對應用徹底透明的分佈式垃圾收集機制。DCOM是一個天生的對稱性網絡協議和編程模型。它不只

提供傳統的單向的客戶機－服務器之間的相互做用方式，還提供了客戶機和服務器以及對等進程之間的豐富的交談式的通信方式。

 　　6.DCOM的可擴展性

提供傳統的單向的客戶機－服務器之間的相互做用方式，還提供了客戶機和服務器以及對等進程之間的豐富的交談式的通信方式。 6.DCOM的可擴展性 分佈式應用的一個重要因素是：它的處理能力可以隨着用戶的數量、數據量所需性能的提升而增長。當需求比較小時，應用系統就比較小而速度快，而且它要可以在不犧牲性能和可靠性的前提下處理附加的需求。DCOM提供了許多特性來加強你的應用的可擴展性。

　　7.對稱的多進程處理（SMP）

 　　DCOM提升了WindowsNT對於多進程處理的支持。對於使用自由線程模式的應用，DCOM使用一個線程隊列來處理新來的請求。在多處理器機上，線程隊列是由可利用的處理器的數量來決定的：太多的線程會致使常常性的上下文切換，而太少的線程又會使處理器處於空閒狀態。DCOM只提供一個手工編碼的線程管理器，從而使開發者從線程的細節中解脫出來並得到最好的性能。DCOM經過使用WindowsNT對於對稱性多進程處理的高級支持功能就能輕易地將應用從一個單處理機擴展到龐大的多處理機系統上去。

 　　8.靈活的配置

　　當負載增長時，即便你的預算支持你買一臺最快的多處理機，它也有可能不能適應需求。DCOM的位置獨立性提供了一個簡單而便宜的方法來提升擴展性，那就是將分佈性的組件放到其它的機器上。 對於無狀態或無需和其它組件共享狀態的組件來講，再配置是再容易不過的事了。對於這樣一些組件來講，能夠在不一樣的機器上運行它們的多個複本。用戶負載能夠被平等地分配到各個機器中去，甚至能夠考慮到機器的處理能力以及當時負載這些因素來進行分配。使用DCOM，能夠很容易地改變客戶進程同組件以及組件之間的鏈接方式。同一組件無需道別的改動甚至無需從新編譯就能夠被動態地從新配置。全部必須作的工做只是更新登記、文件系統以及所涉及的組件所在的數據庫而已。 舉個例子來講：一個組織在多個地方有辦公室，例如紐約、倫敦、舊金山和華盛頓等，它能夠將組件安裝到服務器上。兩百個用戶同時在能達到預期的性能的前提下訪問五十個組件。當新的事務應用發送給用戶時，應用系統中同時在使用一些現存的以及新的組件，服務器的負載增加到六百個用戶，同時事務組件的數目增長到七十。有了這些附加的用戶和組件後，峯值時間的響應時間變得不能接受。管理員將其中的三十個組件單獨配置在另外一臺服務器上，而將二十個

組件單獨放在原來的服務器上，同時剩下的二十個組件同時在兩臺服務器上運行。 絕大多數現實的應用系統都有一個或多個涉及到大多數操做的關鍵性組件。這種組件有數據庫組件或者事務規則組件，它們必須被串行地執行以保證「先來的先服務」這一策略被執行。這些組件不能被複用，由於它們的惟一任務就是爲應用系統的全部用戶提供一個單一的時間同步點。爲了加強分佈式應用系統的總體功能，必須將這些瓶頸組件放到一個專門的、功能強大的服務器上去。DCOM可使你早在設計階段就將這些關鍵性組件分開，最初將多個組件放在一臺功能簡單的機器上，之後再把關鍵性的組件放到專門的機器上去。這一過程無需組件的再設計，甚至無需從新編譯。 DCOM對於這些決定性的瓶頸組件的處理使得整個任務可以迅速執行。這些瓶頸組件每每是過程執行序列的一部分，例如電子交易系統中的買賣命令，它們必須按照接收的順序執行（先來的先被服務）。對於此問題的一個解決方法是將任務分紅許多小的組件，並將這些組件配置到不一樣的機器上。這種效果相似於當今微處理器中的管道pipelining技術：第一個請求來了，第一個組件執行（例如一致性檢查），而後將請求傳遞給下一個組件（例如，多是更新數據庫）。一旦第一個組件將一條請求傳遞給下一個組件，它就準備執

行下一條請求。實際上有兩臺機器在並行的執行多個請求，而且可以保證按照請求來到的順序執行。也能夠在同一臺機器上使用DCOM來達到一樣的效果：多個組件在不一樣的線程或者不一樣的進程中執行。這種方法在之後能夠簡化擴展，咱們能夠將線程分佈到一個帶多處理器的機器上，或者能夠將進程配置到不一樣的機器上。