DCOM
DCOM allows objects to communicate with one another across a network, enabling the development of distributed applications. It died. There are reasons for things.
- Complicated to understand, develop and troubleshoot in a dev environment.
- Complicated to deploy, configure and troubleshoot in a production environment.
- Uses dynamic ports and puts custom traffic on the network. Whatever your network’s firewall rules are, it’s almost guaranteed to break them. Every application has to be reviewed individually by the security and network teams.
- Vendor lock-in - Windows only.
The essence of DCOM is the remote procedure call. Suppose you have an STA client calling a remote STA server. This is (surprisingly) one of the more complicated scenarios. Here is the machinery that runs behind the scenes:
This graphic came from chapter 4 of Inside COM+, which explains it well. The takeaway is, the RPC involves 4 threads, 2 message loops and the message queue of an invisible window called OleMainThreadWndClass. There are optimizations if the client and server are on the same machine, and the graph for MTA is actually simpler.