雖然在遊戲開發中，很少使用DCOM/COBRA分散式元件技術。但是作為一種分散式技術，這裡也分析一下存在的問題。

分散式元件技術是一種CS結構，其出現，是為了簡化網路程式設計，開發者不再需要關心具體如何進行底層通訊。目前比較有代表性的有兩種：DCOM和COBRA。DCOM使用ORPC機制，COM伺服器建立物件類的例項，一個COM物件可以具有多個介面，分別代表不同的觀察角度和不同的物件行為。客戶端獲取物件介面的指標，通過指標呼叫相關的方法。

COBRA是由OMG（Object Manage Group）提出的，其核心是ORB（Object Request Broker）。作為一個透明的匯流排式模型，可以與本地或者遠端的物件進行互動。COBRA物件對外呈現一組介面，客戶端獲取物件的引用，通過引用進行方法的呼叫。ORB負責查詢物件的實現，傳送請求並處理返回結果。

兩種元件模型都採用CS模式的通訊。為了呼叫一個服務，客戶端需要呼叫遠端物件實現的方法。伺服器端提供的服務，封裝成為一個物件，物件的介面使用IDL（Interface Definition Language）描述。客戶端通過呼叫IDL中定義的方法與伺服器端進行互動，不用關心實際物件的實現。支援面向物件的一些特性，例如：資料封裝，多型，繼承。COBRA支援多重繼承，DCOM不支援，但是一個物件可以有多個介面。

       為了呼叫一個遠端的方法，客戶端呼叫本地的樁函式，樁函式將引數封裝成為請求，將請求傳送給伺服器端。伺服器端將請求傳遞給Server Stub，對引數進行解包，並呼叫實際的函式。

       假設有一種Grid物件服務，Grid物件維護一個二維的整數，支援兩組方法：第一組是get和set，可以設定某個格子上的數值；第二組是reset，復位某個格子上的數值。則對於COBRA，需要定義三個介面，介面Grid1支援get和set；介面Grid2支援reset；介面Grid繼承Grid1,Grid2。使用DCOM，則定義兩種IGrid1和IGrid2。

       採用DCOM呼叫，則客戶端端的處理步驟如下：

1．  客戶端呼叫COM庫函式CoCreateInstance，使用CLSID_Grid和IID_IGrid1作為引數。

2．  COM庫請求伺服器建立物件

3．  伺服器端COM獲取指向CLSID_Grid的類工廠指標，呼叫其CreateInstance函式。

4．  類工廠建立一個物件，然後伺服器端呼叫QueryIntreface獲取指向IID_IGrid1介面的指標。

5．  COM庫將指向pIGrid1介面的指標返回給客戶。

6．  客戶端呼叫pIGrid1介面的get方法。

        採用COBRA呼叫，則客戶端端的處理步驟如下：

 1．  客戶端呼叫樁函式grid::_bind()。

2．  ORB向Server發起請求

3．  伺服器端建立例項，呼叫CORBA::BOA::impl_is_ready()，通知ORB物件已經準備好。

4．  ORB向客戶端返回物件的引用

5．  客戶端呼叫物件的方法。

在上面的處理步驟中每個步驟，COM庫或者ORB都需要進行很多操作，因此呼叫的效率不高，只能夠進行粗粒度的呼叫。例如一個服務上有幾十個物件，如果通過上述方法獲取物件的內容並進行顯示，處理和流程將會多麼複雜。

         物件引用在客戶端應用中建立，並且是動態建立的，因此當伺服器端元件是細粒度，物件很多時，這種代價是非常高的。

       相比Web Service，WSDL描述的服務方法引數和返回值，類似於元件對外的介面，但是在進行Web Service進行呼叫時，不需要建立物件，也沒有物件的概念。而是直接使用URL，定位到了需要呼叫的伺服器端的物件。因此，Web Service與元件模型相比，呼叫需要的互動要少一些。

       在DCOM和COBRA中，由於物件的建立導致互動很多，不適合於細粒度的模型。但是如果將伺服器端元件的物件預先建立好，並引入物件管理功能，在客戶端訪問伺服器端時，一次性的在客戶端建立相應的物件，則可以解決這個問題，如下圖：

       DCOM和COBRA在開發和部署上都相對複雜，影響了其發展和應用。