Is DCOM still relevant / used in modern application ?

[Claude Moore]

Hi there,

just a general question... As far as I know, DCOM is roughly speaking the equivalent of RMI for Microsoft-based technology. RMI has already got a foot in the grave, just wondering if the same may be told about DCOM.

Thanks for you replies.

[Karthik Shiraly]

DirectX - Microsoft's framework for games and graphics - used to be a heavy user of COM.
Since I haven't touched DirectX from a loooong time, I went looking for C++ sample code for the latest DirectX version (v12) out of curiosity if it's still using COM.
And sure enough, it's still using ComPtr safe pointer wrappers over DirectX COM interfaces!

It also looks like WinRT - the successor to Win32 API - is also based on COM according to its wikipedia article .
So yeah, COM seems to be doing surprisingly well in the Windows ecosystem, both at the system layers and at the application layers. Or atleast a lot better than RMI.

Edit:
It occurs to me that system and game programming are both rather specialized areas and represent relatively lesser number of developers.
What about the majority of Windows application developers?
I suspect they are using higher level technologies like C# / VB.NET on .NET and don't use COM much. Just like the average Java developer doesn't use RMI much directly.

[Claude Moore]

Thanks for your kind answer! I would have said that DCOM had faded away in favour of .NET remoting....but if WinRT is built upon DCOM, I think I was wrong.

[Tim Holloway]

I'd debate that RMI has one foot in the grave. It's not only useful in its own right, but the RMI-IOOP implementation is used with Enterprise Java Beans, and we've actually had some very active discussions recently on remoting EJBs, even though EJBs themselves are somewhat of a niche these days.

The biggest reason that DCOM or indeed any of the Microsoft-proprietary remoting interfaces isn't something to invest heavily in is that Windows is no longer a given once you leave your local LAN (and sometimes even within the LAN, thanks to Apple's recent growth).

To do remote method invocation of any kind where you don't have a strictly captive audience, you need 2 things:

1) A common protocol on both client and server

2) An Internet-approved infrastructure supporting that protocol.

DCOM fails #1, because it's Windows only. CORBA failed #2 because, while it was OS/machine independent, its lack of easily firewalled ports made it unsuitable for general Internet routine (attempts to change that were too little, too late). RMI-IOOP was an adaptation to allow RMI to be Internet-friendly, but Java RMI requires compatible versions of Java on both ends, so often fails #1. Even though Java, unlike .Net, is fully supported on virtually all modern OS platforms, it's not an essential OS service and usually has to be explicitly installed.

The primary agency for remote processing these days is AJAX and Web Services. The idea of "remote objects" and "remote method calls" over the Internet is deprecated because experience taught us that low-level interfacing was too much at the mercy of Internet latencies. So the generally-preferred alternative is to communicate with services, not functions.