How DCOM actually works<\/h2>\n
DCOM is an extension of COM (Component Object Model), the standard Microsoft framework that lets 2 programs running on the same Windows machine share data and call each other’s functions. DCOM takes that same idea and extends it across a network: a program on one computer can call functions on a component running on a remote computer.<\/p>\n
To make that work, DCOM handles 3 things transparently in the background:<\/p>\n
- \n
- Locating the component <\/strong>using identifiers stored in the Windows Registry (CLSID, ProgID, and AppID) so the client machine knows which component to talk to and on which machine.<\/li>\n
- Authenticating the connection <\/strong>using Windows user accounts, either through Active Directory\/Kerberos in a domain environment or matching local accounts in a workgroup.<\/li>\n
- Transporting the calls <\/strong>over TCP\/IP, using a Remote Procedure Call (RPC) mechanism, with a directory port (TCP 135)<\/a> that tells the client which dynamic port the target component is actually listening on.<\/li>\n<\/ul>\n
![\"Flow](\"https:\/\/integrationobjects.com\/blog\/wp-content\/uploads\/2025\/10\/dcom-connection-establishment-flow.png-1024x546.png\")
How a DCOM connection is established and where it tends to break<\/figcaption><\/figure>\n COM vs. DCOM in one line: <\/strong>COM is local, in-machine communication between software components. DCOM is that same communication extended across a network. An OPC server is a COM server whether it’s accessed locally or remotely. Windows decides which path (local COM or networked DCOM) to use based on whether the client and server are on the same machine.<\/p>\n
This is also why DCOM has a reputation for being difficult: it depends on registry configuration, matching Windows credentials, dynamic port negotiation, and firewall rules all lining up correctly on both the client and server machines. A mismatch in any one of them causes the connection to fail – often silently.<\/p>\n
![\"Diagram](\"https:\/\/integrationobjects.com\/blog\/wp-content\/uploads\/2025\/10\/com-vs-dcom-comparison.png-1024x529.png\")
COM vs. DCOM: same communication, different distance<\/figcaption><\/figure>\n Why do you need DCOM for OPC Classic?<\/h2>\n
OPC Classic DA (Data Access), A&E (Alarms & Events), and HDA (Historical Data Access) communications are based on COM and DCOM technology. Indeed, OPC clients and servers use COM to communicate with each other when deployed on the same machine and use DCOM for the remote communications across a network.<\/p>\n
- Authenticating the connection <\/strong>using Windows user accounts, either through Active Directory\/Kerberos in a domain environment or matching local accounts in a workgroup.<\/li>\n