donBox on DCOM

 

Yesterday I saw Dbox talking about service orientation, he was comparing different transport mechanisms as:

 

• HTTP / HTTPS (ASMX approach)
• DCOM (Com +)
• MSMQ (NT Service)

 

Note Remoting is not in the list, this is because Don didn't like Remoting for different reasons, Performance, Security and Versioning.

 

Some years ago, maybe in the TechEd  I've heard DCOM it's not a good approach for the future, and Remoting it's the best way to connect two machines running the .Net Fx.

 

There are different articles in MSDN comparing Remoting vs. Web Services, but I didn't found anything about Remoting vs DCOM or WS vs DCOM. And this is because the marketing machinery of MS talked about Remoting as  the "substitution / evolution" of DCOM.

 

 But now Don is talking about DCOM as a reasonable approach, and his comments about Remoting were ridicule saying sentences like

 

".. Remoting is a funny and little Technology to build funny and little apps"…

 

Now don works as architect in the Indigo team, and of course they promise this will be the definitive solution for the Distributed Object, should we trust Don?

Comments

• Anonymous
  July 02, 2004
  
  DBox is pushing DCOM again? I don't understand. Why ?
• Anonymous
  July 02, 2004
  It does seem confusing, doesn't it? But, having worked on both sides of the fence over the last year (using Enterprise Services w/ DCOM and Remoting), I can better understand why and what Don is saying. When you compare Remoting and ES/DCOM, Remoting is easy to work with (especially if you use IIS as your host), but it is not as performant, and it certainly is not secure natively. ES is much harder to work with, but you do have security and performance (DCOM is the fastest protocol bar none). ES does have some problems though, which I have elaborated on my blog over the last year, so I can only hope and expect that Don is referring to the next generations of ES and not to the current versions of 1.0 and 1.1.
• Anonymous
  July 02, 2004
  
  Robert am I right in thinking that DCOM sits on top of RPC at some level? Or am I mis-remembering something I read previously ?
• Anonymous
  July 02, 2004
  DCOM uses RPC Services (ala port 135) to make its method calls.
• Anonymous
  July 02, 2004
  Check out Rich Turner's explanation for Remoting's position now and in the future in his post "Is Remoting Dead?": http://blogs.msdn.com/richturner666/archive/2004/03/05/84771.aspx
  
• Anonymous
  July 02, 2004
  If you looked at the security of remoting (hint: what security?) you'd understand Don's comments.
  
  Security wasn't a goal in .Net remoting architecture, it was intended for 100% trusted applications.
  
  Security IS a goal in all the other technologies he quoted.
  
• Anonymous
  July 02, 2004
  But what if I WANT to share assemblies between the server and client? With ASMX, there doesn't appear to be a way to do that.
• Anonymous
  July 02, 2004
  Aaron, what do you mean about sharing assemblies?
  
  Do you mean the ability to send serialized classes over the wire between client and server (as you can do with Remoting)? I know with ES, you can send an object as a parameter in a method. Because it is non-isomorphic, ES will use Remoting underneath with DCOM as the Remoting Channel. In that case, you have the best of all worlds: sharing class definitions between client and server (using the features of Remoting, with .Net to .Net), security (through DCOM), and the performance of DCOM.
• Anonymous
  July 02, 2004
  db == fickle == true
• Anonymous
  July 02, 2004
  Robert,
  
  Yes, that's exactly that I was wanting, to serialize classes over the wire where the assembly is shared between the client and server. Can DCOM work over http and still have security?
• Anonymous
  July 03, 2004
  Basically, Lhotka's current CSLA architecture for business objects has the same business objects assembly on the server and the client and using remoting within IIS to take care of the security details. I need to look closer into the security aspects and see what he's doing.
• Anonymous
  July 11, 2004
  First, my post wasn't trying to "push" anything. Rather, I wanted to capture the distinctions between the three "secure" protocols that we support on the platform. Clearly, each of them has strenghts and weaknesses.
  
  With respect to my being fickle, I have always been and continue to be a huge fan of the architecture of .NET Remoting. Moreover, the architect of .NET Remoting (GopalK) has been a good friend for many years and sits two doors down from me.
  
  I've always been lukewarm on the implementation of the TCP/Binary protocol that is often used underneath .NET Remoting.
  
  It lacks any security whatsoever.
  
  It has had at most 1/100th the engineering attention that any of the three protocols (and implementations) I listed on my blog have had. In the case of HTTP or DCOM (whcih is really MSRPC), we're talking 1/1000th or perhaps more.
  
  FWIW, you can very much use HTTP, MSMQ, or DCOM to do "shared assembly" marshal-by-value objects with complete fidelity if you wish. However, none of them mandate it, which is a feature in my book.
  
  DB
• Anonymous
  July 11, 2004
  I think I fixed my own problem. Check out the Url.