• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 595
  • Last Modified:

What more does COM/DCOM do for me than RPC?

I'm new to COM/DCOM. I'm trying to transfer event data from clients to a single server. These events may contain data such as (<64-bit-datetime>, "SERVICE_STARTED", "PARAMS"), so they're individually pretty small and they get queued on the client, and then transferred in batches every 1-48 hours (depending on preferences).

Can anyone explain what (if any) benefits I'd get by using COM/DCOM to transfer the data to the server rather than RPC or raw sockets? I've done sockets before but not RPC or COM, so I'm looking for pointers in the right direction to save me some research time. I understand that RPC allows procedure calls rather than just raw sockets data transfer, but that doesn't help me understand the RPC/COM differentation. Thanks for any info.
4 Solutions
The basic differentiation is that COM/DCOM is based on Microsofts own version of RPC called (MSRPC) . If you write an application using COM (which is now replaced with using .NET), and you create COM objects, that contain methods (and the object itself would be in a separate file). This same object can reside onthe same machine as the calling application or on a remote machine. Then if you moved the COM object to another machine, your application would not necessarily need to know that.

Here is a tutorial on DCOM that has some source code you can play with. This will give you a taste of the COM/DCOM coding involved.
>>I've done sockets before but not RPC or COM

The main benefit of DCOM/RPC is that it provides a well-defined interface for marshalling data. It it the protocol overhead in "hey, I am passing an 'int' now, add some value and return it" that you don't have to implement yourself like in a plain socket connection. On the other hand it indtroduces IDL and the requirement for an OO design (at least DCOM) which I would not count as a disadvantage.
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

In your place I would use RPC with soap envelopes for the fallowing reasons:

1. You can see the data send and received
2. In C#.Net you can create a webservice with multiple functions in matter of minutes
3. It is very scalable and easy to change and the client can be written in any language on any platform (as long it uses soap/xml)
If you use sockets the code has a chance of running on any machine, any OS, anytime in the future.

If you use COM, you're tying yourself to Microsoft OS, using old, clunky, complex,  slow, proprietary and obsolescent technology, which could easily be deprecated anytime soon.

jimstarAuthor Commented:
Thanks for all of the comments. Looks like everyone has a little different opinion. :) From what I can tell, MS is saying to use the .NET framework's communication mechanisms rather than COM for new development. I wasn't sure what the MS site meant until I started reading about SOAP, which I suspect is MS' new solution from cross-machine communication. It's not clearly called out though. Perhaps they just mean .NET and all of the Socket, SOAP, etc options available in general.

"COM and .NET can achieve similar results. The .NET Framework provides developers with a significant number of benefits including a more robust, evidence-based security model, automatic memory management and native Web services support. For new development, Microsoft recommends .NET as a preferred technology because of its powerful managed runtime environment and services." http://www.microsoft.com/com/default.mspx

I'll probably be writing my server in managed code / C#, but my clients in C++ to reduce client dependencies. SOAP looks interesting, I'll have to do more research on it.

Featured Post

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now