這些組件對象可以互相通訊與交互，而與它們的語言、分布及原始平台無關。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有以下幾個特點：
- 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來達到同樣的效果：多個組件在不同的線程或者不同的進程中執行。這種方法在以后可以簡化擴展，我們可以將線程分布到一個帶多處理器的機器上，或者可以將進程配置到不同的機器上。