There seems to be a lot of enmity against DCOM, and I'm curious to understand why. For a company still writing to the Win32 SKD using C++, is there any real reason not to use DCOM in current or future development? Is some future version of Windows not going to support it? Is it too fragile and fails to work often? Is it too complicated to implement compared to other technologies? What's the deal?
+1
A:
Well, DCOM is a distributed version of COM and COM is very complex by itself and it's very easy to do something wrong unintentionally (see this recent question and the answer to it for examples). With DCOM you just have even more ways to hurt yourself.
Other than that it works and is for example a good way for hosting in-proc COM components in a separated process.
sharptooth
2009-12-04 14:27:46
I actually find COM to be quite understandable and rather simplistic if you understand pointers and reference counters.
Charles
2009-12-04 14:51:38
Believe me, IUnknown member functions are just the beginning. Then come apartments, concurrency and other stuff that can cause horrible pain.
sharptooth
2009-12-04 15:10:39
Then what would you recommended for a local win32 SDK only service and client app that need to communicate? Yes DCOM is complicated, but what technology filling these requirements isn't?
Charles
2009-12-04 15:15:41
If you have two processes using RPC directly can often be easier and more reliable. But then you will not have "objects" - you will have to maintain state on the server manually.
sharptooth
2009-12-04 15:26:11
+1
A:
I implemented a large system using DCOM in the late 90's. Although it worked pretty well, there were a couple of issues. For starters it uses unpredictable port numbers for communication. It is not scalable, and you are much better off using WCF than DCOM.
Otávio Décio
2009-12-04 14:28:13
Unfortunately, we are confined to the Win32 SDK - no .NET allowed. I know, I know, but I don't make the rules
Charles
2009-12-04 14:49:48
Still I believe you could use web services - I'm pretty sure there are SOAP packages for C++.
Otávio Décio
2009-12-04 16:45:56
+1
A:
If your trying to build a client server application and want the communication to go across network boundaries (for example the internet) then DCOM can be problematic due to firewalls.
I had worked on a very success server application which was distributed using DCOM, we let the system handle most of the complexity by creating COM+ Server Applications and exporting Application Proxies. In this case it worked very well as long as all of our versions were synched up.
JoshBerke
2009-12-04 14:31:53
I forgot to mention our client and server would be local to the same machine, both written by us and deployed together, so no network or synchronization problems.
Charles
2009-12-04 14:55:39
A:
I think momentum has shifted to SOAP and other web service technology because it is:
- easier to deploy systems in the presence of firewalls
- no vendor lock-in
I've never used DCOM myself, so I can't really comment on its general quality or fitness.
CBFraser
2009-12-04 14:33:27
I guess I should have mentioned my use would be for local DCOM - both client and server on the same machine. Converting everything to ASCII and then wrapping that with more ASCII tags then parsing the ASCII result is extremely ineficient.
Charles
2009-12-04 14:53:39
+1
A:
I dislike COM/DCOM because "Catastrophic failure" is the most unhelpful error message in the history of error messages.
Donnie
2009-12-04 14:41:42
That would be the "feel-good" message for the user. This way they know they are doing it right.
Jrud
2009-12-04 14:45:29
A:
- Security model. Especially when computers are not in the same domain (or aren't in domain at all).
- Auto interfaces modeled for Visual Basic (original, not .NET), obsolete and not pretty to use from other languages.
If you only want to develop in C++ and deploy in controlled network, it may still be a good choice.
ima
2009-12-04 16:11:31