CORBA and DCOM – which one is for me?

 

This article discusses CORBA and DCOM.  What they are, why you need them, and how decide which one is for you.

High Availability and server clustering.

 

  My current project involves making servers with high-availability that are fault tolerant.  One way to do this is to have several servers running that communicate with each other.  When one goes down, the others take over its load.  These servers have a number of services that they use from each other. For each service to be used, a process as pictured below takes place.

Every time you add a new service to a server you end up writing code similar to this.  The code for processing parameters must be written in four different places because you have to encode the parameters, decode the parameters, encode the result, and decode the result.   Writing network services this way is very bad because;

 

-         Many chances to introduce an error.

-         Versioning problems.  If you change one side you may forget to change the other.

-         Slow to create. 

-         Hard to maintain.

-         Difficult to test, especially if you have hundreds of services.

 

A Better Way

 

A better way to pass messages and data would be to have some automatic way of encoding our parameters into a network packet and then on the other side an automatic way of decoding them.   One naïve approach to this would be to just stick everything in a struct and do a memcpy.  The first problem with this is that some architectures have different byte orderings in memory.  So, a number passed in as 0x3f12 might look like a 0x123f on the other side.   Somehow the process of packing numbers into packets needs to put numbers into a common format and then decode them from that format.   The second problem of using a simple struct is that the data is limited to a fixed size.  What if we wanted to pass a variable length string or an array of variable length strings?

 

  Clearly the automatic process of packing parameters into a network packet needs to know exactly what kind of data it’s dealing with.  In Java, this is an easy task because the reflection API will tell you what members a class has and what types they are.  In C++, all type information is lost after the source is compiled. Not counting RTI – runtime type information – which only tells you the name of your class and if you can be cast into another class.  So for C++, the solution is to use a different pre-compiler for your classes that can save the type information.  CORBA and DCOM both use this approach with a language called IDL (Interface Definition Language) that looks very similar to C++.   The IDL compiler then parses the .idl file and spits out a C++ header and C++ source file.  The header contains the normal struct you will be using in your program and the source file contains “proxy” code that has information on how to pack and unpack your parameters.

 

What is CORBA?

 

CORBA stands for Common Object Request Broker Architecture.  In plain English terms, this mean a bunch of people got together and decided on a standard for which Object Oriented do-hickeys can talk together.  For an example a Java class running on an x86 Intel machine can make calls to a C++ class object running a sun or sgi box.  The main component that CORBA brings to the table is IIOP (Internet Inter-ORB Protocol).  This protocol specifies a “wire-based” (serial communication) protocol in which two CORBA implementations (also called ORBs) can communicate remote procedure calls and data in a platform independent means.

What is DCOM?

 

DCOM stands for Distributed Component Object Model.  DCOM is built on top of and is compatible with COM.  COM/DCOM were created by Microsoft and DCOM is the main competitor of CORBA.  Microsoft has released (some) control over DCOM to the ActiveX Consortium.  At this point DCOM is probably near the end of it’s “new features” development so the consortium will deal mostly with other ActiveX issues. Ports of DCOM to UNIXs are still occurring and the ones that are finished are still need “evaluation” before big companies will use them in mission critical applications.

 

In what situations would I use CORBA?

 

CORBA is used mostly in C/C++ projects where communication with enterprise (read – really expensive) servers is needed.  For example web servers with 16 or more processors are not going to run on Intel based platforms and are also not going to be running WindowsNT/2000.  In these environments, CORBA has been around many years (1992) while ports of DCOM are relatively new beast (1997+).  Because DCOM ports to UNIX are still new and not heavily supported (no support under Linux) most people are steering clear of it.   I have not used any of the DCOM libraries, but I would guess they are a bit larger than a similar CORBA library.

 

Another situation where you want to use CORBA is with JAVA.  The Sun JDK1.2 and 1.3 support CORBA transparently through the JAVA RMI (Remote Method Invocation).  Java can export CORBA IDLs (Interface Definition Language) and import them very easily.  Most web browsers have this built-in now.

Can I use DCOM under UNIX?

 

Software AG has ports to the following platforms – DEC Alpha (64-bit), HP, IBM AIX, IBM OS/390, Linux, and Solaris.

 

I contacted Software AG about licensing for their DCOM library.  It starts at $25,000 per CPU!   I expect the price to come down drastically as more ports become available – but that’s pretty crazy.  You can try out their linux version for free, but you need to license it before you can use it in a commercial environment.

 

Mainsoft provides DCOM support as part of their Win32 abstraction layer.  This library is available for Solaris, AIX, Tru64 Unix, HP, and SGI.

 

Microsoft provides a reference implementation based on Software AG’s work – but I have not found it.  Supposedly this port works under HP, SGI, and Solaris with more to come.

 

As mentioned previously, all these libraries are still “fresh paint” so the user is advised against using them in mission critical applications.

 

How does CORBA compare with DCOM?

 

This is a flame-war question, but in my opinion DCOM is better overall than CORBA.  CORBA is more mature, especially on the UNIX side of thing – which is it’s main feature.  Many good CORBA libraries can be had for free on all platforms, a great feature for those like me who are awfully thrifty.  DCOM is free under Windows platforms (Win98,NT,2000) but not so under UNIXs or Mac.

 

DCOM provides platform local binary compatibility while CORBA does not.   This means you can use a software component writing with DCOM on the same local machine no matter what compiler, language, or DCOM library you used.  As far as I know there is only one DCOM library (Microsoft’s) so the last issue is trival.  Binary compatibility means you can call these components without having to go through a marshaling/unmarshaling proxy service. This translates to super-fast calls (the same speed as calling and C++ virtual function) when the DCOM object is local and about the same speed as CORBA when the object is remotely located.  So DCOM components can be distributed and used as libraries (DLLs), but CORBA components cannot.

 

All features in DCOM are implemented everywhere and are standard.  This is because the only person who made DCOM from the start was Microsoft.  CORBA has a very detail specification that is supposed to standardize features.  The problem is many of the services in CORBA have been deemed “optional” in the currently releases of ORBs and interoperability between 2 different ORBs is almost never 100%.  The core part of CORBA (IIOP) is standard and you can pretty much be assured once you’ve located an object on a remote server you will be able to call it and get a reply without any problems.  Going a multi-vendor Orb approach reduces a lot of the power of CORBA down to RPCs (Remote Procedural Calls) with advanced data structures.  If you stick to one Orb vendor then you will always know exactly what features you can count on.  Currently, I am using OmniOrb2 developed by at&t which has good standards support and a large platform base (and free).

 

In my current project I chose to use CORBA instead of DCOM because of the follow factors.

 

-         I do not need binary compatibility.   I have no interest in getting Visual Basic scripts to talk to my servers.  The only languages I am interested in is C++ and Java, both of which have excellent CORBA support.

-         My software needs to run on high in servers in a reliable manner.  CORBA is a better choice for this.  It’s more portable as DCOM relies on Win32 specific features like the system registry which must be emulated by library abstraction.

-         I might need to make optimizations to the proxy layer or debug memory/reference leaks.  CORBA (OmniOrb2) has source code available and can be changed to accommodate my needs.  

-         Having source code also makes learning easier because stepping through the code quickly explains exactly what is going on.  DCOM for Windows has no source so errors are debugged using “guess and retry.”

-         CORBA is free.  DCOM is $25,000 per CPU (‘nuff said).

 

 

The politics.

 

Last but not least.  The decision of DCOM over CORBA is largely a business decision than a technical decision.  The spheres of influence over DCOM and CORBA are fairly disjoint.  DCOM is for those firmly in Microsoft’s camp and CORBA is firmly in the camp of those who are concerned with portability to high end systems.  There are gateway systems in place that can transparently convert CORBA calls into DCOM and back.  These gateways come at the price of some speed and memory – but not that much.   Currently I would estimate DCOM has a much bigger following and it’s definitely more available to the masses.  Visual basic programmers are accustomed to using COM/DCOM and can easily add in a new component to their applications/web server environment while CORBA require a slight more sophisticated developer to be integrated into a project.