Com Vs Corba

"What's the difference between MicroSoft's COM (ComponentObjectModel) and OMG's CommonObjectRequestBrokerArchitecture (CORBA)?"

Both solve the problem of "object oriented communication between computers."


Strengths of CORBA: Strengths of COM: Both Have... See also:
CORBA has no need for a special "automation" interface: Scripting languages can use the DII (DynamicInvocationInterface?) to against any CORBA interface, so all objects are scriptable without the implementor needing to provide explicit scripting support. This also means that the mapping between language and CORBA type models is standardised, rather than implemented (differently) by each object. The DSI allows scripting languages to implement and use any CORBA interface.

CORBA in-process activation restricts your choices for client DynamicInvocationInterface? (DII) and server DynamicSkeletonInterface? (DSI): Some combinations don't work.

Does the CORBA standard support in-process activation? I think that may be a non-standard extension provided by some ORBs (such as Gnome's ORBIT). [I don't have my CORBA documentation handy; does a dynamic server make non-DII client calls impossible?]

No, there is no difference at the protocol level between static and dynamic invocation or static and dynamic servers.


This was listed under 'Strengths of COM':

Sophisticated data structures can be passed between objects. CORBA objects can only pass tree-structured data.

It's not true: CORBA objects (and we're talking about by-value objects here) can form all sorts of graphs, which are transmitted isomorphically over the wire. The bullet point has thus been refactored. Does anyone wish to come back on this?


How far the COM Components will be useful in other platforms? and also is that any possible way to use the COM Components particularly in Unix environment using some sort of bridge? At the same time how flexible is the Corba will support Microsoft Applications? - Vijay.

There are implementations of COM for Unix, but I haven't heard good things about them. If you need cross-platform support, CORBA clearly makes life easier than COM does.

There are lots of CORBA implementations for Windows, and they work fine. The biggest problem is that Microsoft doesn't support CORBA in any of its development tools, so you often have to do more work than you do with COM. You may also hit issues with multithreading and with DllHell, but that's typical of anything in Windows, CORBA or not.

There are some products that will automatically bridge COM and CORBA (IONA has one called Comet, I believe). My preference is to write COM-CORBA bridge code by hand - it's not that hard, and the result is cleaner.

-- KrisJohnson


Strengths of CORBA: Simpler programming interface

This is debatable. The current generation of Microsoft tools makes use of COM almost trivial. And not too many people would say that the CORBA C++ mapping is simple. I prefer CORBA over COM for distributed applications, but API simplicity is not its strength. --KrisJohnson


CategoryComparisons CategoryComponentObjectModel CategoryCorba

EditText of this page (last edited February 26, 2006) or FindPage with title or text search