"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:
- Cross-platform and multi-vendor. Very strong support in Unix and mainframe systems.
- Is an industry standard.
- Some really excellent implementations are available for free.
- Many free versions are OpenSource
- A wider range of programming language bindings.
- Simpler programming interface.
- ALL objects/interfaces can be called dynamically at run time through a data-driven interface: CORBA DII (DynamicInvocationInterface?).
- Multiple inheritance in interfaces. (COM has single inheritance between interfaces, but discourages its use, favoring multiple interfaces instead.)
Strengths of COM:
- Strong versioning support of interfaces; one can "easily" support upward and/or backward compatible interfaces on an object.
- Good support for fine-grained objects, with in-process activation and no >requirement< for persistence support. (Yes, CORBA can do in-process activation -- but with limitations.)
- Separation of "class" from "interface" -- each object/class/instance will normally support multiple interfaces, and it's easy to switch between them.
- MicroSoft backs it. They have lots of money, and widely used tools (on Windows platforms). MS is now encouraging use of .NET/SOAP, but COM is still supported.
- Price: Comes with Windows -- and so is perceived as being "free" on that platform.
- Tool support (like within VB, VC++, J++) -- but only with MicroSoft tools on the Windows platform. (Untrue: some non-Microsoft tools, such as Python (an excellent language for working with COM), also have tool support for COM on the Windows platform -- AlexMartelli; DelphiLanguage has very nice COM support, with built-in reference counting -- JoeOtten)
- More flexible pointers; CORBA object references can only be to whole objects (as in Java), whereas COM pointers can point into the middle of structures (as in C++).
- Strong definition of object identity: COM has a clearly-defined way to determine if two different interface pointers really refer to the same object; even if the two interfaces aren't related to each other in any way by inheritance. (Query IUnknown & compare pointers.)
- Better SeparationOfConcerns. COM components can be used locally without incurring the overhead of distribution or ORBs.
Both Have...
- Reflection: COM's TypeLibrary? and ITypeInfo. CORBA's InterfaceRepository?. Support for Reflection is optional in both. COM's TypeLibrary? cannot encode everything that can be expressed in MIDL.
- Actual support for asynchronous processing is weak or absent in both. CORBA provides "oneway" operations that are so unspecified as to be practically useless (they are not guaranteed to be reliable, or asynchronous!), but does allow asynchronous calls of synchronous methods through the DII.
- This was true a few years ago, but no longer. Recent versions of the CORBA specification provide very rich asynchronous invocation mechanisms. And COM+ has support for asynchronous invocation as well.
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).
- There is no standard way to do it, but it is not prohibited by the CORBA standard. Location independence is a fundamental part of the CORBA model. But different implementations do put different kinds of restrictions on intra-process (co-located) communications.
[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
Com Vs Corba