Scott Hanselman

DCOM deserves our respect

February 25, '04 Comments [1] Posted in Web Services
Sponsored By

I thought it was cool that noone commented negatively (as well they shouldn't) when the very prolific Chris Brumme said in his recent post on Apartments and Pumping in the CLR:

In general, I love OLE and the folks who work on it.  Although it is inappropriate for the Internet, DCOM is still the fastest and most enterprise-ready distributed object system out there.  In a few ways the architecture of .NET Remoting is superior to DCOM, but we never had the time or resources to even approach the engineering effort that has gone into DCOM.  Presumably Indigo will eventually change this situation.  I also love COM’s strict separation of contract from implementation, the ability to negotiate for contracts, and so much more.

A lot of folks just knee-jerk and say "DCOM Sucks" and that's not justified.  A while back Clemens said:

Enterprise Services has a very elegant solution for mixing the two models in that it uses Remoting to do almost all marshaling work (with two exceptions: QC and calls with isomorphic call sigs) and then tunnels the serialized IMessage through DCOM transport, which means that you get full CLR type fidelity while using a rock solid transport that has been continuously optimized ever since 1993. I understand that some people consider a 10 year old protocol boring; I just call it "stable".

Preach on my brothers.  In this time where software innovates at lightening speed, some younger and short-sighted developers may thing a 5 year old OS or 10 year old protocol are 'out of date.' 

At Corillian, while our Voyager platform has supported .NET since .NET's inception and supports WS-I compliant Web Services, the core application still uses DCOM for inter-machine communication on the inside of the firewall.  And Voyager still runs [quite possibly] the largest single instance Banking Web site in the world.  It scales quite nicely, thank you, and due to people who came before me.  I poo-pooed DCOM when I came to work at Corillian 3 years ago.  And while I've worked on Voyager these past years, building .NET abstraction layers on top of it, hosting the CLR within the product, and communicating with all breeds of mainframes, DCOM has done it's job nicely as a transport between our distributed services.

Remember my friends (that means you VB guys also) that due to the work of a lot of OLE people 10 years ago, your crown has been paid for.  Now put it on.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by ORCS Web
Wednesday, February 25, 2004 9:39:56 AM UTC
I gave up on DCOM a long time ago. I was working on a project when we wrote a client application that used DCOM to talk to the server. Due to the fact that the proxy/stub dlls (or type lib) needed to be register in the windows register, it was hell to install it on all the PCs each time we did an update. It was also impossible to have both the old and new version installed on the same machine.

We never found a way to link the proxy/stub into our client exe and hence remove the need to update the windows reg. A fast coms system, that does not let you talk to anyone as it is too hard to install in real life is no use! It would have been quicker to write our software with raw sockets, as the time we would have saved sorting out install problem would have more then covered the additional programming time!

Ian Ringrose
ringi at bigfoot dot c0m
Ian Ringrose
Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.