基本介紹
使用,概念,分散式,結構,組件復用,位置獨立,語言無關,連線管理,可擴展性,靈活配置,執行性能,頻寬問題,共享連線,最佳化網路,安全性,安全設定,編程控制,負載平衡,容錯性,
使用
Microsoft Distributed Component Object Model（DCOM）是Component Object Model（COM）的擴展，它支持不同的兩台機器上的組件間的通信，而且不論它們是運行在區域網路、廣域網、還是Internet上。藉助DCOM你的應用程式將能夠任意進行空間分布。
由於DCOM是COM這個組件技術的無縫升級，所以你能夠從你現有的有關COM的知識中獲益，你的以前在COM中開發的應用程式、組件、工具都可以移入分散式的環境中。DCOM將為你禁止底層網路協定的細節，你只需要集中精力於你的套用。
例如，你可以為一個網站創建套用頁面，其中包括了一段能夠在網路中另一台更加專業的伺服器電腦上處理（在將它們傳送到發出請求的用戶之前）的腳本或者程式。使用DCOM接口，網路伺服器站點程式（以客戶端對象方式發出動作）就能夠將一個遠程程式調用（RPC）傳送到一個專門的伺服器對象，它可以通過必要的處理，並給站點返回一個結果。結果將傳送到網頁瀏覽器上。
DCOM還可以工作在位於企業內部或者除了公共網際網路之外的其他網路中。它使用TCP/IP和超文本傳輸協定。DCOM是作為Windows作業系統中的一部分集成的。DCOM將很快在所有的主流UNIX平台和IBM的大型伺服器產品中出現。DCOM替代了OLE遠程自動控制。
在提供一系列分散式範圍方面，DCOM通常與通用對象請求代理體系結構（CORBA）相提並論。DCOM是微軟給程式和數據對象傳輸的網路範圍的環境。CORBA則是在對象管理組織（OMG）的幫助下，由信息技術行業的其他商家提供贊助的。
概念
Microsoft的分散式COM（DCOM）擴展了組件對象模型技術（COM）,使其能夠支持在區域網路、廣域網甚至Internet上不同計算機的對象之間的通訊。使用DCOM，你的應用程式就可以在位置上達到分布性，從而滿足你的客戶和套用的需求。
因為DCOM是世界上領先的組件技術COM的無縫擴展，所以你可以將你對基於COM的套用、組件、工具以及知識轉移到標準化的分散式計算領域中來。當你在做分散式計算時，DCOM處理網路協定的低層次的細節問題，從而使你能夠集中精力解決用戶所要求的問題。
分散式
將套用分布化並不是問題的結束。分散式套用引入了一個全新的設計和擴展概念，它增加了軟體產品的複雜性，但是帶來了可觀的回報。某些套用本身就帶有分布性，例如多人對戰遊戲、聊天程式以及遠程會議系統等等。因此，一種健壯的分散式計算框架所帶來的好處是不言自明的。很多其它的套用也是分散式的，即它至少有兩個組件運行在不同的計算機上，但是因為它不是為分布性套用而設計的，所以它們的規模和可擴展性就有很大的局限性。任何的工作流或群件應用程式，大多數的客戶機/伺服器應用程式一些桌面辦公系統本質上都控制著它們的用戶的通訊和協作。將這些系統作為分散式系統並能夠在正確的地方運行正確的組件會給用戶帶來好處，並且使人們對網路和計算機資源的運用更加充滿信心。設計應用程式時考慮到分布性，能通過在客戶端運行組件使套用適用於具有不同性能的不同的客戶。
設計套用時考慮分布性能夠使系統在擴展上具有很高的靈活性。
分散式套用與它們的非分散式版本比起來具有更大的可擴展性。如果整個複雜套用的邏輯結構可以用一個簡單的模型來表示，那么僅僅只有一種方法來增加系統的工作效率：用更快的機器，而無需對套用本身進行調整。雖然伺服器和作業系統升級很快，但是買一個同樣性能的機器還是比將伺服器的速度升級為原來的兩倍所花的錢少。有了一個設計適當的分散式套用系統，一台功能不怎么強大的伺服器就能夠運行所有的組件。當負載增加時，可以將一些組件擴展到價格便宜的附加的機器上。
結構
DCOM是組件對象模型（COM）的進一步擴展。COM定義了組件和它們的客戶之間互相作用的方式。它使得組件和客戶端無需任何中介組件就能相互聯繫。客戶進程直接調用組件中的方法。圖1說明了組件對象模型的表示法：
圖1 同一進程中的COM組件
在作業系統中，各進程之間是相互禁止的。當一個客戶進程需要和另一個進程中的組件通訊時，它不能直接調用該進程，而需要遵循作業系統對進程間通訊所做的規定。COM使得這種通訊能夠以一種完全透明的方式進行：它截取從客戶進程來的調用並將其傳送到另一進程中的組件。圖2表明了COM/DCOM運行庫是怎樣提供客戶進程和組件之間的聯繫的。
DCOM
圖2 不同進程中的COM組件
當客戶進程和組件位於不同的機器時，DCOM僅僅只是用網路協定來代替本地進程之間的通訊。無論是客戶還是組件都不會知道連線它們的線路比以前長了許多。
DCOM
圖3顯示了DCOM的整體結構：COM運行庫向客戶和組件提供了面向對象的服務，並且使用RPC和安全機制產生符合DCOM線路協定標準的標準網路包。
圖3 DCOM: 不同機器上的COM組件
DCOM
組件復用
大多數分散式套用都不是憑空產生的。現存的硬體結構、軟體、組件以及工具需要集成起來，以便減少開發和擴展時間以及費用。DCOM能夠直接且透明地改進現存的對COM組件和工具的投資。對各種各樣組件需求的巨大市場使得將標準化的解決方案集成到一個普通的套用系統中成為可能。許多熟悉COM的開發者能夠很輕易地將他們在COM方面的經驗運用到基於DCOM的分散式套用中去。
任何為分散式套用開發的組件都有可能在將來被復用。圍繞組件模式來組織開發過程使得你能夠在原有工作的基礎上不斷的提高新系統的功能並減少開發時間。基於COM和DCOM的設計能使你的組件在現在和將來都能被很好的使用。
位置獨立
當你開始在一個真正的網路上設計一個分散式套用時，以下幾個相互衝突的設計問題會很清楚地反映出來：
相互作用頻繁的組件彼此間應該靠得更近些。
某些組件只能在特定的機器或位置上運行。
小組件增加了配置的靈活性，但它同時也增加了網路的擁塞。
大組件減少了網路的擁塞，但它同時也減少了配置的靈活性。
當你使用DCOM時，這些設計上的限制將很容易解決，因為配置的細節並不是在源碼中說明的。DCOM使得組件的位置對你來說完全透明，無論它是位於客戶的同一進程中或是在地球的另一端。在任何情況下，客戶連線組件和調用組件的方法的方式都是一樣的。DCOM不僅無需改變源碼，而且無需重新編譯程式。一個簡單的再配置動作就改變了組件組件之間相互連線的方式。
DCOM的位置獨立性極大地簡化了將套用組件分布化的任務，使其能夠達到最合適的執行效果。例如，構想某個組件必需位於某台特定的機器上或某個特定的位置，並且此套用有許多小組件，你可以通過將這些組件配置在同一個LAN上，或者同一台機器上，甚至同一個進程中來減少網路的負載。當套用是由比較少的大組件構成時，網路負載並不是問題，此時你可以將組件放在速度快的機器上，而不用去管這些機器到底在哪兒。
圖4顯示了相同的“有效性檢查組件”在兩種不同情況下是如何分別配置的。一種情況是當“客戶”機和“中間層”機器之間的頻寬足夠大時，它是怎樣配置在客戶機上的；另一種情況是當客戶進程通過比較慢的網路連線來訪問組件時，它又是怎樣配置在伺服器上的。
圖4 位置獨立性
有了DCOM的位置獨立性，套用系統可以將互相關聯的組件放到靠地比較近的機器上，甚至可以將它們放到同一台機器上或同一個進程中。即使是由大量的小組件來完成一個具有複雜邏輯結構的功能，它們之間仍然能夠有效到相互作用。當組件在客戶機上運行時，將用戶界面和有效性檢查放在客戶端或離客戶端比較近的機器上會更有意義；集中的資料庫事務應該將伺服器靠近資料庫。
DCOM
語言無關
在設計和實現分散式套用系統時，一個普遍的問題就是為開發一個特定的組件而選擇語言以及工具的問題。語言選擇是一個典型的在開發費用、可得到的技術支持以及執行性能之間的折衷。作為COM的擴展，DCOM DCO具有語言獨立性。任何語言都可以用來創建COM組件，並且這些組件可以使用更多的語言和工具。Java，Microsoft Visual C++，Microsoft Visual Basic，Delphi，PowerBuilder和Micro Focus COBOL都能夠和DCOM很好地相互作用。
因為DCOM具有語言獨立性，套用系統開發人員可以選擇他們最熟悉的語言和工具來進行開發。語言獨立性還使得一些原型組件開始時可以用諸如Visual Basic這樣的高級語言來開發，而在以後用一種不同的語言，例如Visual C++和Java來重新實現，而這種語言能夠更好地支持諸如DCOM的自由執行緒/多執行緒以及執行緒共用這些先進特性。
連線管理
網路連線本身就比同一台機器中的連線更脆弱。當一個客戶不再有效，特別是當出現網路或硬體錯誤時，分散式套用中的組件需要被加以注意。
DCOM通過給每個組件保持一個索引計數來管理對組件的連線問題，這些組件有可能是僅僅只連到一個客戶上，也有可能被多個客戶所共享。當一個客戶和一個組件建立連線時，DCOM就增加此組件的索引計數。同理，當客戶釋放連線時，DCOM就減少此組件的索引計數。如果索引計數為零，組件就可以被釋放了。
DCOM使用有效的地址合法性檢查（pinging）協定來檢查客戶進程是否仍然是活躍的。客戶機周期性地傳送訊息，當經過大於等於三次ping周期而組件沒有收到ping訊息時，DCOM就認為這個連線中斷了。一旦連線中斷，DCOM就減少索引計數，當索引計數為零時就釋放組件。從組件的這一點看來，無論是客戶進程自己中斷連線這種良性情況，還是網路或者客戶機崩潰這種致命情況，都被同一種索引計數機制處理。
在很多種情況下，組件和它的客戶進程之間的信息流是沒有方向性的：組件需要在客戶端進行某些初始化操作，例如一個長進程的結束，用戶所觀看數據的更新，或者諸如電視以及多用戶遊戲這些協作環境中的下一條信息等。許多協定使得完成這種對稱性的通訊十分困難。使用DCOM，任何組件都既可以是功能的提供者，又能是功能的使用者。通訊的兩個方向都用同一種機制來管理使得完成對等通訊和客戶機/伺服器之間的相互作用一樣容易。
DCOM提供了一個對套用完全透明的分散式垃圾收集機制。DCOM是一個天生的對稱性網路協定和編程模型。它不僅提供傳統的單向的客戶機－伺服器之間的相互作用方式，還提供了客戶機和伺服器以及對等進程之間的豐富的交談式的通訊方式。
可擴展性
分散式套用的一個重要因素是它的處理能力能夠隨著用戶的數量、數據量所需性能的提高而增加。當需求比較小時，套用系統就比較小而速度快，並且它要能夠在不犧牲性能和可靠性的前提下處理附加的需求。DCOM提供了許多特性來增強你的套用的可擴展性。
DCOM提高了Windows NT對於多進程處理的支持。對於使用自由執行緒模式的套用，DCOM使用一個執行緒佇列來處理新來的請求。在多處理器機上，執行緒佇列是由可利用的處理器的數量來決定的：太多的執行緒會導致經常性的上下文切換，而太少的執行緒又會使處理器處於空閒狀態。DCOM只提供一個手工編碼的執行緒管理器，從而使開發者從執行緒的細節中解脫出來並獲得最好的性能。
靈活配置
對於無狀態或無需和其它組件共享狀態的組件來說，再配置是再容易不過的事了。對於這樣一些組件來說，可以在不同的機器上運行它們的多個複本。用戶負載可以被平等地分配到各個機器中去，甚至可以考慮到機器的處理能力以及當時負載這些因素來進行分配。使用DCOM，可以很容易地改變客戶進程同組件以及組件之間的連線方式。同一組件無需作別的改動甚至無需重新編譯就可以被動態地重新配置。所有必須做的工作只是更新登記、檔案系統以及所涉及的組件所在的資料庫而已。
例子：一個組織在多個地方有辦工室，例如紐約、倫敦、舊金山和華盛頓等，它可以將組件安裝到伺服器上。兩百個用戶同時在能達到預期的性能的前提下訪問五十個組件。當新的事務套用傳送給用戶時，套用系統中同時在使用一些現存的以及新的組件，伺服器的負載增長到六百個用戶，同時事務組件的數目增加到七十。有了這些附加的用戶和組件後，峰值時間的回響時間變得不能接受。管理員將其中的三十個組件單獨配置在另一台伺服器上，而將二十個組件單獨放在原來的伺服器上，同時剩下的二十個組件同時在兩台伺服器上運行。
圖5 並行配置
絕大多數現實的套用系統都有一個或多個涉及到大多數操作的關鍵性組件。這種組件有資料庫組件或者事務規則組件，它們必須被串列地執行以保證“先來的先服務”這一策略被執行。這些組件不能被復用，因為它們的唯一任務就是為套用系統的所有用戶提供一個單一的時間同步點。為了增強分步式套用系統的整體功能，必須將這些瓶頸組件放到一個專門的、功能強大的伺服器上去。DCOM可以使你早在設計階段就將這些關鍵性組件分開，最初將多個組件放在一台功能簡單的機器上，以後再把關鍵性的組件放到專門的機器上去。這一過程無需組件的再設計，甚至無需重新編譯。
DCOM
圖6 關鍵性組件的分離
DCOM對於這些決定性的瓶頸組件的處理使得整個任務能夠迅速執行。這些瓶頸組件往往是過程執行序列的一部分，例如電子交易系統中的買賣命令，它們必須按照接收的順序執行（先來的先被服務）。對於此問題的一個解決方法是將任務分成許多小的組件，並將這些組件配置到不同的機器上。這種效果類似於當今微處理器中的管道pipelining技術：第一個請求來了，第一個組件執行（例如一致性檢查），然後將請求傳遞給下一個組件（例如，可能是更新資料庫）。一旦第一個組件將一條請求傳遞給下一個組件，它就準備執行下一條請求。實際上有兩台機器在並行的執行多個請求，並且能夠保證按照請求來到的順序執行。也可以在同一台機器上使用DCOM來達到同樣的效果：多個組件在不同的執行緒或者不同的進程中執行。這種方法在以後可以簡化擴展，我們可以將執行緒分布到一個帶多處理器的機器上，或者可以將進程配置到不同的機器上。
DCOM
圖7 Pipelining
DCOM的位置獨立性編程模型使得隨著套用增加而改變配置設計變得容易了。最初，一個功能簡單的伺服器就可以容納所有的組件。隨著需求的增加，其它的機器被添加進來，而組件能夠不做任何代碼上的改動就被分步到這些機器中去。
DCOM
功能的發展：版本化
除了隨著用戶的數量以及事務的數量而擴展規模外，當新的特性加入時套用系統也需要擴展規模。隨著時間的推移，新的任務被添加進來，原有的任務被更新。傳統的做法是或者客戶進程和組件都需要同時被更新，或者舊的組件必須被保留直到所有的客戶進程被更新，當大量的地理上分布的站點和用戶在使用系統時，這就成為一個非常費力的管理問題。
DCOM為組件和客戶進程提供了靈活的擴展機制。使用COM和DCOM，客戶進程能夠動態地查詢組件的機能。一個COM組件不是將其機能表現為一個簡單、統一的方法和屬性組，而是對於不同的客戶進程表現為不同的形式。使用特定特性的客戶進程只需要訪問它所需要使用的方法和屬性。客戶進程也能夠同時使用一個組件的多個特性。當新的特性加入組件時，它不會影響不涉及這些特性的老的客戶進程。
用這種方法來組織組件，使得我們能夠有一種新的方法來發展組件功能：最初的組件表現為諸如COM界面的一套核心特性，這些特性是每個客戶進程都需要使用的。當組件需要新的特性時，大多數（甚至是全部）的界面仍然是必須的，我們根本無須更改原來的界面就可以將新的功能和屬性放到附加的界面中去。老的用戶進程就好像什麼事也沒發生似的繼續訪問核心界面。新的客戶進程既可以測試新的界面是否存在以便能使用它，也可以仍然只使用原來的界面。
圖8 健壯的版本發展
因為在DCOM編程模型中機能被分組放入界面中，你可以設計使用老的伺服器程式的新的客戶程式，也可以設計使用老的客戶程式的新的伺服器程式，或者將這些混合起來以便能夠適合你的需求和編程資源。使用傳統的對象模型時，那怕是對一個方法的細微改動都可能在根本上改變客戶和組件之間的協定。在一些模型中，可以將方法加到方法佇列的隊尾，但是卻不能在老的組件上測試新的方法。從網路發展的前景看來，這些事情將會變得越來越複雜：編碼以及其它的一些功能典型地依賴於方法和參數的順序。增加或改動方法和參數也會顯著地改變網路協定。DCOM為對象模式和網路協定設計了一個簡單、優雅和統一的方法來解決這些問題。
DCOM
執行性能
如果最初的執行性能不能讓人滿意的話，可擴展性就不會帶來太多好處了。經常考慮到更多更好的硬體會使得套用向下發展是非常有益的，但是這些需求是怎樣的呢？這些尖端擴展特性是否有用呢？是否對從COBOL到彙編這每一種語言的支持會危害到系統的執行性能呢？使組件能夠在地球的另一面運行的能力是否妨礙了當它和客戶在同一個進程中時的執行性能呢？
在COM和DCOM中，客戶並不能自己看到伺服器，但是除非是在必要的情況下，否則客戶進程決不會被系統組件將自己同伺服器分開。這種透明性是通過一個簡單的思想來實現的：客戶進程同組件互動的唯一方式就是通過方法調用。客戶進程從一個簡單的方法地址表（一個“vtable”）中得到這些方法的地址。當客戶進程想要調用一個組件中的某個方法時，它先得到方法的地址，然後調用它。在COM和DCOM模型中調用一個傳統的C或彙編函式的唯一開支就是對方法地址的簡單查詢。如果組件是和客戶運行在同一個執行緒中的過程中組件，那么無需調用任何COM或系統代碼就可以直接找到方法的地址，COM僅僅只定義了找到方法地址表的標準。
當用戶和組件不是那么靠近──在另一個執行緒中，在另一個程式中或者在地球另一面的一台機器中時情況又是怎樣的呢？COM將它的遠程過程調用（RPC）框架代碼放到vtable中，然後將每個方法調用打包放到一個標準的緩衝器結構中，這個緩衝器結構將被傳送給組件，組件打開包並且重新運行最初的方法調用。從這方面來說，COM提供了一個面向對象的RPC機制。
這種RPC機制的速度有多快呢？下面是需要考慮的不同的性能尺度：
一個“空”方法調用有多快？
“真正的”需要傳送和接收數據的方法調用有多快？
在網路上轉一圈有多快？
下表顯示了COM和DCOM的一些真實的執行性能參數，使我們能夠對DCOM和其它的協定的相關的執行性能有一定的了解。
開始兩列表示一個“空”方法調用（傳送和接收一個4位元組長的整數）。最後兩列可以認為是一個“真正的”COM方法調用（50位元組長的參數）。
DCOM
此表顯示了進程中組件是怎樣得到零開支的執行性能的（第一排和第二排）。
微軟很快會提供許多平台上的正式的DCOM性能參數，它將顯示出DCOM與客戶數量以及伺服器中處理器數量相關的擴展能力。
頻寬問題
分散式套用利用了網路的優點將組件結合到一起。理論上來說，DCOM將組件在不同的機器上運行這一事實隱藏起來。實際上，套用必須考慮到網路連線帶來的兩個主要限制：
頻寬：傳遞給方法調用的參數的大小直接影響著完成方法調用的時間。
DCOM怎樣幫助套用解決這些局限呢？DCOM自己將網路循環時間最小化，使得避免網路中潛在的擁塞成為可能。DCOM選擇了TCP/IP協定套件中的無連線UDP協定作為自己的傳輸協定。協定的無連線特性使得DCOM能夠將許多低級別的確認包和實際的數據以及地址合法性檢查（pinging）信息混合起來從而改善了性能。即使是運行在面向連線的協定上，DCOM也優於傳統的面向特殊套用的協定。
共享連線
大多數的套用級別的協定需要某種從頭到尾地管理。當客戶機出現了嚴重的硬體故障或者客戶和組件之間的網路連線中斷已經超過一定時間時，應該及時通知組件。
解決這一問題的一個普遍方法是個一段時間（Pinging）傳送保持活躍keep-alive訊息。如果伺服器在一定的時間間隔內沒有收到一條ping訊息，它就斷定客戶進程“死掉了”。
DCOM對每台機器使用一個keep-alive訊息。即使一台客戶機使用了某一台伺服器上的100個組件，僅僅只要一條ping訊息就能使所有這些客戶連線保持活躍狀態。為了將所有的ping訊息組合起來，DCOM使用delta pinging機制來將這些ping訊息的大小最小化。對於這100個連線，它並不是傳送100個客戶標識符，而是創造了一個可變標識符來重複代表這100個引用。當引用集改變時，僅僅只是兩套引用的相交的部分被互相交換。最終，DCOM將所有ping訊息轉化為正常訊息。只有當對於伺服器來說，某台客戶機完全是空閒的時，它才定時傳送ping訊息（每隔兩分鐘一次）。
圖9 組合的生命期管理
COM允許多個套用（甚至來自不同的賣主）共享一個簡單而且最佳化的生命期管理和網路錯誤檢測協定，這樣可以顯著地減少頻寬。如果在一台伺服器上運行使用100個不同的傳統協定的100個不同的套用，對於每一個客戶連線上的每一個套用來說，伺服器都要接收一條ping訊息。只有這些協定當在它們的pinging策略上相互合作時，整個網路的開銷才有可能減少。而DCOM在任意的基於DCOM的協定中自動地提供了這種協作。
DCOM
最佳化網路
設計分散式套用的一個普遍問題是減少不同機器上組件之間在網路上的過度的來迴繞圈數。
在Internet上，每一次網路繞圈就會引入1秒甚至更多的延遲。即使在速度快的區域網路上，旋程時間也是以微秒來計算的──它超過了本地操作所需時間的量級。
減少網路繞圈數的一個普遍的方法是將多個方法調用捆綁起來。DCOM將這種技術擴展使用，用來解決諸如連線一個對象或者創造一個對象查詢對象的機能的任務中。這種技術對於一般組件的不足之處是它在本地和遠程情況下的編程模型差別太大。
例子：一個資料庫組件提供了一個能夠分行或多行顯示結果的方法。在本地的情況下，開發者只需使用這個方法將結果一列一列地加入列表框即可。而在遠程的情況下，每列出一行就會引起一定的網路旋程。使用批量方式的方法需要開發者分配一個能容納查詢出的所有列的緩衝器，然後在一次調用將其取回並將其一列一列地加入到列表框中。因為編程模型變化很大，開發者需要對設計作大的改動以便套用能夠在分散式環境中有效地工作。
DCOM使得組件開發者能夠輕易地執行批量技術而無需客戶端也使用批量形式的API。DCOM的marshling機制使得組件可以將代碼加到客戶端，這叫作“代理對象”，它可以攔截多個方法調用並將其捆綁到一個遠程調用中去。
例子：因為套用系統的邏輯結構的需要（列表框API的要求），上面例子的開發者仍然需要一個一個地列舉方法。然而，為了列舉查詢結果的第一次調用套用中特殊的代理對象，它取得了所有列（或者一批列）並將其快取到代理對象中。後來的調用就自接從這個快取中發出，就避免了網路旋程。開發者仍然使用一個簡單的編程模型，而整個套用卻得到了最佳化。
DCOM同樣允許從一個組件到另一個組件的有效的指引。如果一個組件保存了到另一台機器上的一個組件的索引，它可以將其傳遞給在第三方機器上運行的一個客戶進程（假設此客戶進程正在使用另一台機器上運行的另一個組件）。客戶進程使用此索引就可以直接和第二個組件通訊。DCOM縮短了這種索引，並且使得第一個組件和機器可以完全從這個過程中脫離出來。這使得能夠提供索引的傳統的目錄服務適用於遠程組件的範圍。
例1：一個棋類套用系統能夠使正在等待對手的用戶將自己登錄到一個棋類目錄服務中。其它的用戶可以瀏覽並查詢正在等待對手的用戶的列表。當一個用戶選擇了自己的對手後，棋類目錄服務系統將對手的客戶組件索引返回給該用戶。DCOM自動連線兩個用戶，目錄服務系統無需涉及任何其它的事務處理過程。
例2：一個“經紀人”組件監控著運行著同一個組件的二十台伺服器，它監測伺服器的負載量和伺服器的加入和刪除情況。當一個客戶需要使用該組件時，它連線到“經紀人”組件，此組件返回負載最輕的伺服器上的一個組件的索引。DCOM自動連線客戶和伺服器，此時“經紀人”組件和以後的過程就無關了。
如果需要的話，DCOM甚至允許將組件插入任意一個傳統的協定中，這個協定可以使用不在DCOM機能範圍內的方法。組件可以使用傳統的配置方法將任意的代理對象放到客戶進程中，此進程能夠使用任何協定將信息傳回組件。
例2：一個商業系統需要兩種通訊機制，一種是從客戶端到中央系統的一條安全而經過鑑定的通道，它用來發出和撤消命令；另一種是一條分散式的通道，它用來將命令信息同時傳送給連線在系統上的客戶。使用DCOM的安全而同步的連線方式可以簡單而有效地操作客戶機/伺服器之間的通道，同時廣播通道需要一種更為尖端的機制，它使用多點廣播技術以便容納大量的偵聽者。DCOM允許將傳統的協定（“可靠的廣播協定”）無縫地插入到套用系統的體系結構中：一個數據接收端組件能夠將此協定封裝起來，並使其對客戶和伺服器完全透明。當用戶數量少安裝量小時，標準的DCOM點到點協定就足夠了；而對於有很多用戶的站點來說，就需要使用高級的廣播協定。DCOM將來會提供一個標準的多通道廣播傳輸協定，它能夠無縫地移植到套用系統中。
安全性
使用網路來將套用系統分布化是一個挑戰，這不僅是因為頻寬的物理限制以及一些潛在的問題，而且也由於它產生一些諸如關係到客戶間、組件間以及客戶和組件之間的安全問題。因為許多操作可以被網路中的任何一個人訪問，所以對這些操作的訪問應該被限制在一個高級別上。
如果分散式開發平台沒有提供安全支持，那么每一個分散式套用就必需完成自己的安全機制。一種典型的方法是用某種登錄的方法要求用戶通過用戶名及密碼的檢測，這些一般來說都是被加密了的。套用系統將通過用戶資料庫或者有關目錄來確認以上用戶身份，並返回動態的標識符以便用戶以後用來進行方法調用。以後每次涉及到調用有安全檢查的方法時，用戶都需要通過這種安全認證。每個套用系統都要存儲和管理許多用戶名和密碼，防止用戶進行未授權的訪問，管理密碼的改動以及處理在網路上傳遞密碼而帶來的危險。
因此分散式平台必需提供一個安全性框架來確切地區分不同的用戶或者不同組的用戶以便系統或套用有辦法知道誰將對某組件進行操作。DCOM使用了Windows NT提供的擴展的安全框架。Windows NT提供了一套穩固的內建式安全模組，它用來提供從傳統的信用領域的安全模式到非集中管理模式的複雜的身份確認和鑑定機制，極大地擴展了公鑰式安全機制。安全性框架的中心部分是一個用戶目錄，它存儲著用來確認用戶憑據（用戶名、密碼、公鑰）的必要信息。大多數並非基於Windows NT平台的系統提供了相似或相同的擴展機制，我們可以使用這種機制而不用管此平台上用的是哪種安全模組。大多數DCOM的UNIX版本提供了同Windows NT平台相容的安全模組。
設計在Internet上工作的套用系統時需要面對兩個主要問題。
即使是在最大的公司，在Internet上用戶的數量都會比原來提高好幾個數量級。
安全設定
DCOM通過讓開發者和管理員為每個組件設定安全性環境而使安全性透明。就象Windows NT允許管理員為檔案和目錄設定訪問控制列表（ACLs）一樣，DCOM將組件的訪問控制列表存儲起來。這些列表清楚地指出了哪些用戶或用戶組有權訪問某一類的組件。使用DCOM的設定工具（DCOMCNFG）或者在編程中使用Windows NT的registry以及Win32的安全函式可以很簡單地設定這些列表。
只要一個客戶進程調用一個方法或者創建某個組件的實例，DCOM就可以獲得使用當前進程（實際上是當前正在執行的執行緒）的用戶的當前用戶名。Windows NT確保這個用戶的憑據是可靠的，然後DCOM將用戶名正在運行組件的機器或進程。然後組件上的DCOM用自己設定的鑑定機制再一次檢查用戶名，並在訪問控制列表中查找組件（實際上是查找包含此組件的進程中運行的第一個組件）。如果此列表中不包括此用戶（既不是直接在此表中又不是某用戶組的一員），DCOM就在組件被激活前拒絕此次調用。這種安全性機制對用戶和組件都完全是透明的，而且是高度最佳化的。它基於Windows NT的安全框架，而此框架是Windows NT作業系統中最經常被使用（也是最完美的！）的部分，對每一個對檔案或者諸如一個事件或信號的同步執行緒的訪問都需要經過相同的訪問檢查。Windows NT能夠和同類的作業系統以及網路作業系統競爭並超過它們的事實可以顯示出這種安全性機制是多么有效。
DCOM提供了一個非常有效的預設的安全性機制，它使開發員能夠在無需但心任何安全性問題的情況下開發出安全的分散式套用
編程控制
對某些套用系統來說，僅僅是組件級的訪問控制列表是不夠的，因為一個組件中的某些方法是只能被特定的用戶訪問的。
例子：一個商務結算組件可以有一個方法用來登錄新事務，以及另一個方法用來獲得已經存在的事務。僅僅只有財務組（“Accounting”用戶組）的成員才能夠添加新事務，同時僅僅只有高級管理人員（“Upper Management”用戶組）才能查看事務。
正如上一部分所說，套用系統能夠通過管理自己的用戶資料庫以及安全憑據來達到本身的安全。然而，在一個標準的安全框架下工作將會給最終用戶帶來更多的好處。沒有一個統一的安全性框架時，用戶需要為他們所使用的每一個套用記住和管理相應的登錄憑據。開發者為每一個組件靠慮到安全性問題。
DCOM通過加入Windows NT提供的非常靈活的安全性標準將安全性用戶化的要求簡化為對某些特定組件和套用的需求。
組件也能夠很輕易地得到客戶的用戶名並且利用它在自己的資料庫中查找有關的許可和策略。這一策略使用了Windows NT的安全性框架（密碼/公鑰，傳輸線上加過密的密碼等等）所提供的鑑定機制。套用系統無需為儲存密碼和其它有關的敏感信息擔心。新版本的Windows NT將提供一個擴展的目錄服務，它允許套用系統將用戶信息存儲到Windows NT的用戶資料庫中。
DCOM的做法更為靈活。組件能夠要求不同級別的加密以及不同級別的鑑定，同時可以在自己進行身份認證時阻止組件使用自己的憑據。
解決安全
DCOM使用了Windows NT的安全框架（參看安全性部分）。Windows NT的安全性體系結構提供了多個安全性模組，其中包括：
Windows NT NTLM鑑別協定，它在Windows NT 4.0以及以前版本的Windows NT中使用。
Kerveros Version 5鑑別協定，它在處理Windows NT中以及Windows NT間的訪問時代替NTLM成為最主要的安全性協定。
分散式密碼鑑定（DPA），諸如MSN和CompuServe這些最大的Internet成員組織中的某些公司所使用的共享的密碼鑑別協定。
通道服務
它被用來完成Windows NT 4.0中的SSL/PCT協定。下一版本的Windows NT將加強對支持SSL 3.0客戶鑑定系統的公鑰協定的支持。
一個DCE提出的安全性模組，它可以作為第三方工具加在Windows NT中。
所有這些模組都是在標準Internet協定上工作的，都各有其優缺點。NTLM安全性模組以及在Windows NT 5.0中替代它的基於Kerberos的模組都是私人密鑰基礎協定。它們在集中式管理環境以及使用相互或者單方面信任關係的基於Windows NT伺服器的區域網路中是非常有效而安全的。對大多數UNIX系統來說，都可以使用NTLM來進行商業實現。（例如AT&T的“Unix系統的高級伺服器（Advanced Server for Unix Systems）”）。
使用Windows NT 4.0的目錄服務，可以很好地擴展到大約100000個用戶。使用Windows NT 5.0的擴展目錄服務，一個Windows NT域控制器可以擴展到大約一億個用戶。通過將多個域控制器結合到Windows NT 5.0的目錄樹中，在一個域中所能支持的用戶實際上是無限的。
Windows NT 5.0的基於Kerberos的安全性模組引入了例如在客戶進行身份認證時對組件行為的控制等更先進的安全性概念。它在執行鑑別時比NTLM安全性提供模組所占用的資源更少。
因為有如此多的互不相同的基本的安全性提供模組（私人密鑰，公共密鑰）可以被使用，所以基於DCOM的分散式套用系統可以無需對其進行任何改動就能完成甚至更為先進，對安全性敏感的套用。Windows NT的安全性框架使得無需犧牲靈活性和執行性能就能很容易地擴展套用並保證套用的安全性。
負載平衡
這一問題的一個無法必免的解決方案是將負載分布到多個伺服器中去。在“可擴展性”部分簡要地提到了DCOM怎樣促進負載平衡的幾種不同的技術：並行配置，分離關鍵組件和連續進程的pipelining技術。
靜態負載
解決負載平衡的一個方法是不斷地將某些用戶分配到運行同一套用的某些伺服器上。因為這種分配不隨網路狀況以及其它因素的變化而變化，所以這種方法稱為靜態負載平衡。
基於DCOM的套用可以很容易地通過改變登記入口將其配置到某些特定的伺服器上運行。顧客登記工具可以使用Win32的遠程登記函式來改變每一個客戶的設定。在Windows NT 5.0中，DCOM可以使用擴展的目錄服務來完成對分布的類的儲存，這使得將這些配置改變集中化成為可能。
在Windows NT 4.0中，套用系統可以使用一些簡單的技術達到同樣的效果。一個基本的方法是將伺服器的名字存到諸如資料庫和一個小檔案這樣的眾所周知的集中環境中。當組件想要和伺服器相連線時，它就能很輕易地獲得伺服器的名字。對資料庫或檔案內容的改動也就同時改變了所有的用戶以及有關的用戶組。
一個靈活得多的方法使用了一個精緻複雜的指示組件。這個組件駐留在一台為大家所共知的伺服器中。客戶組件首先和此組件連線，請求一個指向它所需服務的索引。指示組件能夠使用DCOM的安全性機制來對發出請求的用戶進行確認，並根據發出請求者的身份選擇伺服器。指示組件並不直接返回伺服器名，它實際上建立了一個到伺服器的連線並將此連線直接傳遞給客戶。然後DCOM透明地將伺服器和客戶連線起來，這時指示組件的工作就完成了。我們還可以通過在指示組件上建立一個顧客類代理店之類的東西而將以上機制對客戶完全螢幕蔽起來。
當用戶需求增加時，管理員可以通過改變組件而為不同的用戶透明地選擇不同的伺服器。此時客戶組件沒有做任何改動，而套用可以從一個非集中式管理的模式變為一個集中式管理的模式。DCOM的位置獨立性以及它對有效的指示的支持使得這種設計的靈活性成為可能。
動態負載
靜態負載平衡方法是解決不斷增長的用戶需求的一個好方法，但它需要管理員的介入，並且只有在負載可預測時才能很好地工作。
對某些套用來說，連線時的動態負載平衡法可能仍然是不充分的。客戶不能被長時間中斷，或者用戶之間的負載分布不均衡。DCOM本身並沒有提供對這種動態重連線以及動態的方法分布化的支持，因為這樣做需要對客戶進程和組件之間相互作用的情況非常熟悉才行，此時組件在方法激活過程中保留了一些客戶的特殊的狀態信息。如果此時DCOM突然將客戶和在另一台機器上的另一個不同的組件再連線，那么這些信息就丟失了。
然而，DCOM使得套用系統的設計者能夠很容易地將這種邏輯結構清楚地引入到客戶和組件之間的協定中來。客戶和組件能夠使用特殊的界面來決定什麼時候一個連線可以被安全地經過再尋徑接到另一台伺服器上而不丟失任何重要的狀態信息。從這一點看來，無論是客戶還是組件都可以在下一個方法激活前初始化一個到另一台機器上的另一個組件的再連線。DCOM提供了用來完成這些附加的面向特殊套用的協定的所有的豐富的協定擴展機制。
DCOM結構也允許將面向特殊組件的代碼放到客戶進程中。無論什麼時候客戶進程要激活一個方法時，由真實組件組件所提供的代理組件在客戶進程中截取這一調用，並能夠將其再尋逕到另一台伺服器上。而客戶根本無需了解這一過程，DCOM提供了靈活的機制來透明的建立這些“分散式組件”。
有了以上獨特的特性，DCOM使得開發用來處理負載平衡和動態方法尋徑的一般底層結構成為可能。這種底層結構能夠定義一套標準界面，它可以用來在客戶進程和組件之間傳遞狀態信息的出現和消失情況。一旦組件位於客戶端的部分發現狀態信息消失，它就能動態地將客戶重連線到另一台伺服器上。
例子：微軟的事務伺服器（以前叫做“Viper”）使用這一機制來擴展了DCOM編程模型。通過一套簡單的標準狀態信息管理界面，事務伺服器能夠獲得必要的信息來提供高級別的負載平衡。在這種新的編程模型中，客戶和組件之間的相互作用被捆綁到事務中，它能夠指出什麼時候一系列的方法調用所涉及的組件的狀態信息都是清楚的。
DCOM提供了一個用來完成動態負載平衡的強大的底層結構。簡單的指示組件在連線時可以用來透明地完成動態伺服器分配工作。用來將單一的方法調用再尋逕到不同的伺服器的更尖端的機制也能夠輕易地完成，但是它需要對客戶進程和組件之間的相互作用過程有更為深入的了解。微軟的完全基於DCOM建立的事務伺服器（“Viper”）提供了一個標準的編程模型用來向事務伺服器的底層結構傳遞面向這一附加的特殊套用的有關細節問題，它可以用來執行非常高級的靜態和動態的重配置與負載平衡。
容錯性
DCOM在協定級提供了對容錯性的一般支持。前面的“套用系統間的共享式連線管理”部分所描敘的一種高級pinging機制能夠發現網路以及客戶端的硬體錯誤。如果網路能夠在要求的時間間隔內恢復，DCOM就能自動地重新建立連線。
DCOM使實現容錯性變得容易起來。一種技術就是上一部分所說的指示組件的技術。當客戶進程發現一個組件出錯時，它重新連線到建立第一個連線的那個指示組件。指示組件內有哪些伺服器不再有效的訊息，並能提供在另一台機器上運行的這一組件的一個新的實例。當然，在這種情況下套用系統仍然需要在高級別上（一致性以及訊息丟失問題等）處理錯誤的恢復問題。
因為DCOM可以將一個組件分別放到伺服器方和客戶方，所以可以對用戶完全透明地實現組件的連線和重連線以及一致性問題。
例子：微軟的事務伺服器（“Viper”）提供了一個在套用級處理一致性問題的一般性機制。將多個方法調用組合到一個原子事務中就能夠保證一致性，並使套用能夠很容易地避免信息的丟失。
另一技術經常被稱為“熱備份”。同一伺服器組件的兩個複本並行地在不同的機器上運行，它們處理相同的信息。客戶進程能夠明確地同時連線這兩台機器。DCOM的“分散式組件”通過將處理容錯性的服務代碼放到客戶端使得以上過程對用戶套用完全透明。另一種方法是使用另一台機器上運行的一個協作組件，由它代表客戶將客戶請求傳送給那兩個伺服器組件。
當錯誤發生時試圖將一個伺服器組件轉移到另一台機器上經事實證明是失敗的。Windows NT組的最初版本使用了這一方法，當然它可以在套用級完成。DCOM的“分散式組件”使得完成這一機能更容易了，並且它對用戶隱蔽了實現細節。
DCOM使得完成高級的容錯技術變得更為容易。使用DCOM提供的部分在客戶進程中運行的分散式組件技術能夠使解決問題的細節對用戶透明。開發者無需改動客戶組件，甚至客戶機進行重新配置就能夠增強分散式套用系統的容錯性。
輕鬆配置
如果不容易安裝和管理的話，即使是最好的套用系統也是沒有用的。對於分散式套用來說，能夠集中管理和儘可能簡單的客戶安裝過程是非常關鍵的。同時，提供一些辦法使系統管理員能夠在潛在的錯誤造成任何損害之前儘可能早的發現它對於分散式套用也是非常必要的。
DCOM提供了什麼技術能夠讓一個套用更加易於管理呢？
安裝
簡化客戶端安裝的一種普遍方法可以概括為一個詞“稀薄的客戶”，意思是駐留在客戶端的機能越少，安裝以及可能發生的維護問題也就越少。
然而，客戶組件越“稀薄”，整個套用的用戶友好度就越低，對網路和伺服器的需求也就越高。稀薄的客戶還不能充分利用當今桌面辦工系統所能得到的強大的計算能力，而由於諸如字處理軟體以及電子表格軟體這些桌面生產套用系統本身就具有統一而龐大的特性，所以大多數用戶對於這種系統的強大的計算能力的需求也不會減弱。因此在正確的級別實現“濃厚”對於分散式套用的設計來說是一個非常重要的決定。DCOM通過讓開發者甚至管理員來選擇每個組件的位置來促進配置的簡單性和靈活性之間的平衡。可以通過對配置的簡單改動使同一個事務組件（例如數據登錄檢查組件）分別在伺服器和客戶端執行。套用能夠動態地選擇所使用的用戶界面組件（伺服器上的HTML產生器或者客戶端的ActiveX控制項）。
保持“肥胖的”客戶的一個最大的問題是將這些客戶更新到最新版本的問題。通過對代碼下載的支持，微軟的Internet Explorer 3.0提供了解決這一問題的一個非常優雅的辦法。只要用戶在瀏覽一頁頁面，微軟的Internet Explorer就會檢查頁面中所使用的ActiveX控制項，並在必要時自動對其進行更新。套用也可以在不明確使用瀏覽器的時候使用這一被微軟直接支持的特性（ActiveX的CoCreateClassFromURL函式）。
在Windows NT 5.0中，代碼下載的概念將被擴展到本地COM類庫中。這一類庫將使用擴展目錄來儲存組件的配置信息和到實際代碼的索引，它改變了當前使用的本地登記概念。這個類庫將向Intranet（擴展目錄）和Internet（代碼下載，Internet路徑搜尋）提供代碼倉庫，並使它們對已存在的套用完全透明。
安裝和更新伺服器組件通常不是一個嚴重的問題。然而，在一個高度分布化的套用中，同時更新所有的客戶一般來說是不太可能的。如第一部分中“功能的發展：版本化”部分所述的DCOM的健壯的版本化支持允許伺服器在保持向後兼容的基礎上加入新的功能。伺服器組件既可以處理舊客戶進程，又可以處理新客戶進程。一旦所有的客戶都被更新，組件就可以停止對新客戶所不需要的功能的支持。
使用代碼下載技術以及以後它的擴展技術，類庫、管理員能夠有效而安全地集中安裝和更新客戶，並能在不用削減太多功能的情況下將“肥胖的”客戶變為靈巧的客戶。DCOM對於健壯性版本化的支持使得無需先更新所有客戶就可以更新伺服器程式。
