COM/DCOM/COM+的思考

從 COM(Component Object Model) 時代到 DCOM(Distributed COM) ，微軟扮演了一個推動者的角色。如果說 COM 提供了一個 Windows 平台上的對象通訊技術，並且逐漸成為應用程式之間彼此通訊及互動的技術主流，那麼 DCOM 則是解決了電腦的通訊和互動技術。
COM 的著眼點是在於同一台電腦上不同應用程式之間的通訊需求，跨到另外一台電腦之外，就不是一開始 COM 所設想到的領域。所幸跨程式的通訊和跨電腦的通訊差異僅在於通訊協議的處理 ( 也就是定位問題 ) ，對於資料交換上型別差異的處理並不會因此而有區別。所以要讓 COM 的環境能更進一步延伸到跨電腦的領域，只要妥善解決電腦定位的需求，就有機會克服。同樣幸運的是， COM 在一開始的設計中完全不去碰觸跨電腦的問題，使得要在 COM 的架構之上再架上一層跨電腦的處理環境並不會去破壞到原本的架構。於是 COM 的網路延伸版本 DCOM(Distributed COM) 就此出現，負責讓 COM 組件可以在網路環境下持續提供服務。 DCOM 最主要處理的是兩個議題，第一個議題是網路通訊能力，第二個議題則是許可權的問題。之前 COM 是在同一台電腦中找特定的組件，而 DCOM 則要更進一步去找網路上的某台電腦，之後沿用 COM 的機制找到電腦上的組件。

      COM+倡導一種新的設計概念，把COM組件提升到應用程式層，把底層細節留給作業系統，使COM+與作業系統的結合更加緊密。COM+的底層結構仍然以COM為基礎，但在應用方式上則更多地繼承了MTS（Microsoft Transaction Server）的處理機制，包括MTS的對象環境、安全模型、組態管理等。COM+把COM、DCOM和MTS三者有機地統一起來，同時也新增了一些服務，如Server Load Balancer、記憶體資料庫、事件模型、佇列服務等，形成一個概念新、功能強的組件體繫結構，使得COM+形成真正適合於公司專屬應用程式的組件技術。

到了 .NET 當中，跨電腦的問題同樣也需要對應的技術進行處理， .NET Remoting 就是一個對應於 DCOM 的技術，它讓存活在不同應用程式定義域 (AppDomain ，一個 .NET 中的新概念 ) 、不同執行程式、以及不同電腦上的對象能夠順暢的進行溝通協作。在累積了長期以來分布式應用的經驗之後，微軟沒有理由把東西設計的更難用。從某種意義來說， .NET Remoting 提供了比過去更便於使用的開發架構，用來來支援跨電腦的溝通作業，省卻開發人員建立分布式應用程式時必須花費的心力，不過這樣一個“出色”的分布式應用應用程式框架並沒有得到本來應該得到的“待遇”。相對於 Java 的 RMI 而言，它更加簡單同時保持設計方面的彈性，同時擯棄了 DCOM 的一些缺點，在對於一個前後端必須以有狀態緊密結合方式進行互動作業，同時又期望呼叫和資料交換的動作上能以最有效方式進行的環境而言， .NET Remoting 是一個比較恰當的選擇方案。
可是問題在於微軟本身對於 XML Web Services 的狂熱推崇讓 .NET Remoting 迷失了本來屬於它自己的陣地，也就是說 XML Web Services 的過火讓 .NET Remoting 忘記了自己應該承擔的角色，於是在開發人員眼中成為了一個“可有可無”的作品，至少對於很多開發人員而言，在需要建立分布式應用程式的時候首先考慮的是 XML Web Services ，而在於企業內部應用，特別是在可以控制伺服器和用戶端平台的情況下（比如完全基於 .NET 平台的應用）， Web Service 因為效率等等各個方面的原因並無法體現出優勢。從技術本身來講， .NET Remoting 是一個非常出色的架構，但在商業方面，這是一個失敗，畢竟，設計一個出色的產品然後束之高閣難免“不像話”。
.NET Remoting 恰恰是這個戰略的犧牲品，雖然擁有與生俱來的優點，不過依然生不逢時。