The battle of supremacy between CORBA and DCOM will continue for some time.  With the rise of distributed applications and the popularity of the web the choice between which technology to use will become more important.  As developers are forced to bridge the gap between different platforms such as Unix and Windows understanding these technologies will be an important skill.  To help make those decisions we have provided a comparison of some of the key areas that might help you in making a decision between CORBA and DCOM.  For more information on each topic see full descriptions provided within the rest of Edinburgh project website.

 

Topic

 CORBA DCOM
Supports Re-use of existing code CORBA implementations are fairly new in comparison to COM technology.  In reality most development using CORBA will be new development.  CORBA's ability to re-use existing code comes from it's capability as a cross-platform technology. 

CORBA will allow access legacy data and code but not without writing new objects that interact with CORBA.   

DCOM provides one of the best implementations for code re-use in a distributed architecture.  Any COM DLL or EXE can be converted to a DCOM component by modifing the registry. 

This is a great advantage for creating a N-tier application from an existing 2-tier application.  What used to be a client side component could be moved to a middle tier server.  This could allow the component to be closer to its data store, or move intensive processing from a small client to a higher processing  server.  There are any number of reasons that you might want move a COM component to another server.  What is great about DCOM is that you can do this without any need to recompile code on the client or server.
Location Transparency Yes, the Object Request Broker (ORB) can broker object calls within a single process, multiple processes in a machine or multiple processes dispersed across networks and operating systems. The location of an object is found by using the interface defined for the Naming Service or Trader Service. An object reference is returned that the ORB can use to make the local or remote object calls. Static Transparency

DCOM allows for location transparency in the form of the registry.  A DCOM component contains a server name or ip address in the registry that tells the Service Control Manager where to create the component.  A client doesn't need to know where a DCOM component resides as long as the location is set in the registry correctly.  If there arose a need to perform load balancing of a DCOM component a mechanism could be written to change the registry location dynamically.  While this isn't ideal it would allow for dynamic location transparency.

Dynamic Transparency

Microsoft is banking on MTS or other third party components to provide dynamic location transparency.    DCOM/COM provides the capability of a referral service.   An object reference can be passed from one machine to the other. 

Say a component on machine A contains a reference to a component on machine B.  A component on machine C can call the component on machine A asking for the component on B.   The component on machine B is effeciently marshalled to machine C.  The component on machine C can then call the component on machine B directly (without going through A, even if A dies). 

The referral capability provided by DCOM is a big plus for location transparency and distributed applications.  You could create a factory component that checks a server farm and determines which server currently contains the least load.  Using the referral capability the factory component could control where DCOM components are created, effectively distributing the load across the server farm.
Language Neutrality Yes. CORBA implements language neutrality by separating interface from implementation. CORBA uses language neutral data types that allow objects to be called without regard to language and operating system. DCOM components can be written in any number of languages and with any number of tools.  As long as the implementation of the COM binary specification is followed DCOM components can be written in any language.   DCOM components are written in Java, C++, MS Visual Basic, Delphi, PowerBuilder today. 

One drawback  to COMs language neutrality is that some functionality is not available to all languages.  C++ can provide the most robust implementation of DCOM components but a language such as MS Visual Basic is limited in some functionality.
User Security The Security Service provides a complete framework for distributed object security. It supports authentication, access control lists (acl), confidentiality and non-repudiation." [Orfali, 98]

See Security Description

 DCOM provides one of the most advanced and thus one of the most complicated security capabilities of any distributed system.  DCOM security is tightly integrated with Windows NT security.    This provides a number of advantages over  other OS's because NT security is a fundamental part of the operating system.  NT security is involved in anything from logon/domain security, file system security under NTFS, and DCOM security. 

User security can be implemented throught the use of Access Control Lists.  An ACL contains a list of NT users and groups that are allowed to access a particular resouce (in this case a component).  An ACL can be setup using the Dcomcnfg utility or programmatically with COM API's.  Once the ACL is setup the component doesn't contain any code to enforce security.  If user A wants to create component B but component B doesn't contain user A in its ACL user A will be automatically denied (with Access Denied) by the COM architecture. 

Load Balancing Many vendors have implemented the OMG Trading Object Service specification. The Trader service provides a "Yellow Pages" of objects. This allows clients to query the Trader for all objects that support a specific interface, returning the next object in the list for a service. No.  There is currently no automatic capability within the DCOM architecture for load balancing.  It appears that Microsoft is working towards MTS to provide this capability.  Also from reading various Microsoft literature it looks as if Microsoft is hoping for a large number of third party components to provide this type of functionality.
Platform Neutrality Yes, for example, Iona's Orbix supports Windows NT, many flavors of UNIX (including Solaris, HP-UX, Silicon Graphics IRIX, IBM's AIX and Digital's UNIX), and IBM's MVS. Future. 

Microsoft is currently working with different software and operating system vendors in porting COM to different platforms.  In the future COM will be available on different flavors of Unix, on AIX, and other operating systems.  Microsoft understands that there needs to provide a   bridge to legacy applications and data.  Microsoft is providing the COM port itself for both Sun Solaris, and AIX.  

Check out the article Build Reliable and Scalable N-tier Applications that Run on Both Windows NT and Unix in the 1998 December issue of the  MSJ for more information on Microsofts plans for portability.
Parameter Marshalling Yes, parameter marshalling is accomplished in the stub code that is generated by the IDL compiler. With CORBA, there is a client stub and server skeleton that are responsible for marshalling of parameters. Yes.  DCOM provides automatic marshalling of a number of predefined types.   It also provides automatic marshalling of object references.  DCOM also uses proxy-stubs to provide automatic marshalling.   Custom marshalling is preferred in cases where defined structures, and structured arrays are used. 

For more information on marshalling see the DCOM Architecture document.
Interface Descriptions The CORBA Interface Definition Language (IDL) defines the methods and attributes available in a component interface. Supports multiple inheritance for the interface definition, something that DCOM cannot yet provide. COM interfaces are defined in an IDL file.   The Microsoft Interface Definition Language (MIDL) is used to describe COM and thus DCOM interfaces.  The MIDL compiler supplied by Microsoft creates proxy stubs for the client and server. 
Standard ORB wire protocol CORBA 2.0 specifies a standard wire protocol, the Internet Inter-ORB Protocol or IIOP. Maybe (via the Open Group)
Multiple Vendor Support Yes

Vendor Products Committed to CORBA

CORBA ORB Vendors

 No
Name to Implementation Mapping CORBA provides an interface to the Naming Service that the client application can use to resolve the name to an object reference. DCOM uses the CLSID to consult the Windows Registry to resolve the object's location (pathname).