I know .net has WCF, which I believe was touted as the replacement for COM when it was codenamed Indigo(?) – but is it actually suitable for use in a .NET app, providing the same functionality as a C++/DCOM application?
A DCOM app on a client-server system can be a pain, but I think it’s quite efficient compared to other options like web-services – which have other issues anyway.
So, is WCF a true successor to (D)COM or does it have different aims?
EDIT: I’m talking specifically about distributed apps and remote controlling – e.g a server can cause a dialog to launch on a workstation, workstations can call methods on the server to send it responses, etc. I added the ‘D’ to my title accordingly.
I’m not aware of any official guidance that names a successor for DCOM, but .NET has two frameworks that can replace usage of DCOM. They are WCF and .NET Remoting.
WCF can be used as a replacement for all of the transport features provided by DCOM and more. If you are in a situation where you can’t use .NET 3.0 or newer versions; you only have .NET remoting available instead. Both frameworks within .NET allow you to issue calls and transfer control of execution to hosts in other threads, processes, and computers. Remoting was likely intended to be the replacement for DCOM, and it can handle nearly all of the transport features as well, but adoption has not been that great.
In general, most people prefer WCF now because everything is well defined and there are tons of features to control the aspects of calls made over WCF. Regular .NET remoting is somewhat in disuse nowadays because you will need to manage type information on both sides of the wire- not a significant improvement in burden compared to DCOM. Also, it does not have a shared-memory transport, so intra-thread/process communication is only setup using socket-based communication and subject to limitations of loopback socket performance.
Regarding the general scenarios you mention, pretty much any application can be made accessible for connectivity to other applications via WCF or Remoting. Most of the tricky issues involve communication with hosted components in web applications. In general, this usually isn’t done- calls are issued from them but rarely accepted outside of http/https web activity. Security and identity management can be tricky too, but is much improved over DCOM’s configuration-based setup.
Overall, both WCF and .NET Remoting are significantly better than DCOM. They’re easier to setup and maintain, and don’t have the same registration headaches as COM components would for use under DCOM. Furthermore, you get intrinsic benefits like natural library exceptions for failure conditions in .NET; whereas in DCOM you would have to worry about gracefully handling failed delivery and timeouts in your application code. This alone should significantly reduce the amount of code you have to write to handle such conditions, and with asynchronous calls you can also back out of a long operation whenever you wish. This is quite tricky to do well in DCOM.