Promoting Linux Requires Advertising. It Matters to Me. TM
GnuCash Personal Finance Manager
GnuCash!

Linux DCE, CORBA and DCOM Guide

Key Resource
There is a rich selection of implementations of CORBA for Linux, including one that is focused on real-time operation, two more on fault-tolerance, and another two aimed at embedded systems. If these features are not important to you, but Microsoft's name is, then take a look at DCOM & ActiveX for Linux. Yep, its available!

Technologies Similar to CORBA

DCE
DCE, short for the Distributed Computing Environment, is a technology that is a bit older than CORBA, but a good bit more stable and scalable. Not only does it offer the basic RPC mechanisms and IDL stub compilers needed to create distributed applications, but it also offers security & authentication through Kerberos (an area that still exhibits weakness in CORBA). Unlike CORBA, it is not a ground-up redesign of the principles of distributed computing, is rather a tightly integrated package of existing technologies. Quietly but powerfully popular in true large-scale, enterprise-class applications, its the package of choice for the big boys.

FreeDCE is a port of DCE to Linux and is now in beta. Please note that the use of Kerberos is restricted outside of the US, due to US encryption export laws. Note also that the distribution of pre-compiled binaries is made difficult by these same issues as well as a license restriction. To use FreeDCE, you must be prepared to compile it yourself. The DCE FAQ provides a good overview of what DCE is, how its used, and how to use it.

DCOM/ActiveX
Microsoft's DCOM & ActiveX for Linux is being ported by Software AG and is available for beta-testing. Software AG, better known as the makers of the AdabasD SQL database, has a deal with Microsoft to support DCOM on a variety of Unix OS platforms. (Note: the Software AG web site is not only difficult to navigate, but is also frequently reorganized. If you can't find the Linux DCOM beta, try here.)

Note: DCOM is *not* CORBA compliant, and it doesn't even try to be. In fact, its pretty much totally and completely different. It is listed here because it provides some of the features that CORBA provides, and because Microsoft is attempting to market it as a competitor to CORBA. Note that the popular industry analyst position is that DCOM is not as advanced as CORBA, nor anywhere near as robust or stable.

DCOM and CORBA Side by Side, Step by Step, and Layer by Layer provides just what its title suggests. Thorough and detailed.

RPC's, PVM, Java-RMI
There are a variety of other distributed technologies not covered here, but deserve mention. RPC's (Remote Procedure Calls) are the intellectual grand-daddy of CORBA and DCE, and are a standard part of the GNU C library. Because RPC facilities are installed be default everywhere, RPC's may well be ideal for the task.

XML-RPC is collection of projects that implement the RPC protocol in XML, thus allowing for the easy debugging of network sessions. There are XML-RPC implementations for most popular programming languages and environments.

PVM (Parallel Virtual Machine), MPI (Message Passing Interface), (see also MPI), LAM-MPI (Local Area Multicomputer) are used in the scientific community to solve large memory and cpu-intensive numerical simulation problems. PVM, MPI, and their relatives and cousins don't seem to be used by the general business computing community. Note, however, that the new high-performance cluster-computing, SAN-fabric VIA message-passing architecture is slowly gaining ground in the business world, and is available on Linux in the form of M-VIA. Unfortunately, a bit kiboshed by Microsoft, though.

Sun's Java-RMI (Remote Method Invocation) is more-or-less a commonly available part of Java, familiar to all Java programmers. It will someday soon inter-operate with CORBA by supporting CORBA's IIOP protocol.

CORBA Packages

AdaBroker (New Listing!)
AdaBroker is a set of tools and libraries for developing applications in the Ada programming language. It provides an IDL parser, Ada code generator, the CORBA-defined Ada mapping support packages. AdaBroker is released under the GPL.

ORBit
ORBit is the ORB of choice for the Gnome project. In particular, it is notable and laudable in its attempts to have very high performance when used locally, and to have a small footprint. The decision to pursue the development of ORBit came after poor experiences with three of the ORB's listed below. One proved to have an unacceptable licensing restriction for the GPL'ed Gnome project, another proved too fat and slow, and a third was missing critical "C" language bindings. Of course, your reasons for choosing one package over another will be different than those driving the Gnome decision, and so the rejected packages shall remain unimpunged. Note, however, if you are doing GUI programming in Gnome, and want to write graphical plugins or controls, this will be the ORB that you use. Includes a variety of services, such as OAF for naming, and Bonobo for easy-to-use document and GUI programming interfaces.

OmniORB
OmniORB from Oracle & Olivetti has an explicit Linux port. Features a C++ IDL, uses IIOP and the IIOP has been tested with other ORB's, is multi-threaded, has a COS name server. OmniORB Source is GPL'ed.

MICO
MICO, the recursively named "Mico Is COrba", implements a C++ IDL, DII, DSI, IIOP, IR, a full BOA, a name server, support for "Any" types, support for loadable modules. Includes a graphical IR browser. Source is GPL'ed. Pre-compiled versions are available. Current work focuses on a WinNT port.

ORBacus (OmniBroker)
The ORBacus (OmniBroker) from Object Oriented Concepts, Inc. offers Java and C++ IDL mappings, as well as IIOP, DII, DSI (Dynamic Skeleton Interface), COS, IR, nested method invocation, Dynamic Any. Has an IDL-to-HTML converter for documentation. Supports threads. Includes naming service GUI. Third party tools include a COS Trading Object Service and a scripting language. Supports C++ threads. Source code is available. Free for non-commercial use, commercial use requires a license. Full support contracts offered.

OAK
The OAK CORBA ORB from Paragon Software is unique in that it supports Objective-C bindings,and is thus suitable for use with NeXTStep/GnuStep. Supports IIOP, BOA, DSI, DII, IR, COS. Includes extensions for fault tolerance and load-balancing, among many others. OAK is a commercially supported product; they offer a free trial evaluation period.

COOL ORB
The COOL ORB form Chorus has design features, such as a small footprint (50KB), real-time behavior and synchronization services, that focus on use in embedded systems. Fully CORBAv2 compliant, offers IIOP, DSI, DII and IR. Inter-operates with the other Chorus embedded/real-time products; unlike most other ORB's listed here, this one is commercially supported. N.B. Chorus has been acquired by Sun.

ILU
The ILU (Inter-Language Unification) ORB from XEROX. The latest version includes support for IIOP, kernel threads, encryption, and "Any". Includes IDL compilers for C++, ANSI C, Python, Java, Common Lisp and Modula-3. ILU also includes a self-contained implementation of ONC RPC, making it possible to use existing RPC services as ILU objects. ILU also includes a self-contained implementation of HTTP, allowing CORBA-based web servers and browsers to be developed. (Highly customized, non-generic web servers are becoming increasingly popular in embedded and special-purpose applications.) Code is available as freeware. Beware of the down-level code located on the Linux Sunsite (http://sunsite.unc.edu/pub/Linux/devel/corba/) repository; go to the main site for newest code.

Arachne
Arachne springs out of an effort to develop reusable components for the medical domain; the effort continues and is evolving. Thus, this is not only an implementation; its an implementation in active use by the developers themselves. Arachne runs on a variety of platforms, including 95/NT, Mac, SunOS, HP/UX, but Linux is the primary development platform. It includes a C++ ORB with DII, IR, Any, TypeCode, and IIOP. It includes a subset of COS, and an application development support framework with GUI compnenets. Note, however, the IDL language mapping is currently non-standard. Since this ORB implementation predates CORBA-2 and some work remains to update it. IIOP has been tested against Visigenics and ORBacus (OmniBroker). A python-based application authoring environment is in development.

TAO
The TAO (The Ace ORB) is a research vehicle for defining real-time extensions to CORBA. TAO includes an enhanced C++ IDL compiler, a BOA, and an implementation of standard IIOP on TCP/IP that has undergone limited interoperability testing with ORB's from several vendors. More importantly, it includes RIOP (Real-time IOP) extensions to GIOP, implemented on ATM and multi-gigabit hardware. It also includes deterministic real-time event service, a real-time dispatcher/scheduler and an ROA (real-time object adapter). TAO is affiliated with the ACE (Adaptive Communications Environment), a project that has experience with real-time communications in telecom and avionics environments. The code is currently (Sept 97) alpha-level, and runs on Linux, Solaris, and NT.

Electra
The Electra Object Request Broker provides V2 CORBA support, including BOA, DII, a Tcl/Tk DII, IIOP, a fault-tolerant COS name server, a GUI availability monitor, and an event channel for C++/Java, allowing objects to subscribe to information servers. One of Electra's strong suits are its emphasis on fault-tolerance and high-availability; includes support for reliable multi-cast & synchrony. Electra is not yet (Sept 97) very stable on Linux.

COPE
COPE is an ORB written entirely in Perl. It does not provide an IR (Interface Repository), but can use third-party tools for that purpose (such as ORBacus (OmniBroker)).

JacORB
The JacORB is a CORBA ORB written entirely in Java. Provides a Java IDL compiler, supports threads, IIOP, IR, a COS compliant name service, and an alpha-level implementation of the COS Event service. Reported to run well under Linux, and to be more standards-compliant than some of the big-name CORBA products. Free, under GPL.

Jorba
Jorba is a CORBA implementation written entirely in Java. It includes the ORB, DII, DSI, and an IDL compiler. The web page states that this is alpha-level code, with many functions missing. It is provided in source form under GPL.

CORBAPlus
CORBAPlus from ExpertSoft offers a CORBAv2 implementation written in Java. Includes support for a Java IDL compiler, IIOP, DII, Any and typecodes. The licensing terms are not entirely clear, but it seems to be freely available for any use. Not clear if its been tested on Linux, but should work. Support contracts offered.

JavaIDL
The JavaIDL is a snapshot of SunSoft's Java IDL compiler. Includes a generic ORB core. Ability to run under Linux is uncertain, requires porting ??. May require integration with an ORB core??

Jylu
Jylu implements the Xerox PARC ILU CORBA core in Java. Includes a Java IDL compiler. Does not talk IIOP, but does talk the ILU wire protocol (Sun RPC protocol??)..

Fnorb
The Fnorb is an experimental ORB written in Python. It does not provide an IR (Interface Repository), but can use third-party tools for that purpose (such as ORBacus (OmniBroker)).

ROBIN
ROBIN (RPC and Object Broker Interface) implements a subset of the CORBAv2.1 spec. Supports an IDL and DII, does not currently support IIOP. Deployed in, and focuses on data acquisition and control systems, including embedded computers.

DOME
DOME from Object Oriented Technologies offers threading, callbacks, async operation, location brokering, as well as network monitors & tools. Strengths: runs on a large variety of platforms, and supports many different networking protocols. Weaknesses: This is a pre-CORBA 2.0 ORB, and thus the programming interfaces and protocols are proprietary and non-portable. OOT offers a free version for Linux. The licensing terms are less than clear: although commercial redistribution appears to be prohibited, commercial in-house use appears not to be.

Bionic Buffalo
The Bionic Buffalo offers a basic ORB w/ C bindings. This is a commercial product; A free version of the ORB, stripped of IIOP, is planned.

CORBA Services

CORBA Services are implementations of specific interfaces defined by the OMG. These include things like security, persistence, transactions, query, object trading, naming, events, concurrency control, and collections. More services are being defined regularly. Relatively few of these have yet to appear in commercial products, much less in Open Source or Freeware form. Some of the basic service, such as naming and events, are often included with the base CORBA implementation, and are noted above where applicable. The listing below is for stand-alone implementations.

JTrader
JTrader is an implementation, in Java, of the COS Trading Object Service. Traders are objects that know about services: unlike using the COS naming service to find an object by name, one can use a trader to find an object by the type of service it offers. Comes with graphical tools to manage the service type repository, the service offers, and for performing queries. Requires ORBacus (OmniBroker) for operation, should be (easily?) portable to other ORB's. Implemented in Java, under the GPL.

Examples, Tutorials (New Section!)

A few intro examples to programming with corba. Highly incomplete. Pushes my own efforts.
Gnome-Bonobo
Examples of programming with Bonobo in the gnome environment can be viewed at http://cvs.gnome.org/lxr/source/bonobo/samples/ Include samples of a simple echo server, a compound document, and a GUI control.

Bonobo-Hello-World
Here lies a tar file containing a simple 'hello-world' type client-server implementation using bonobo, oaf and gnome. This is about as basic as you can get in the gnome-bonobo world. It just sends a simple string message from the client to the server. Note that this code is straight-C, not C++ or Java or anything. Browse individual files here

corba-perf
Here lies a simple C++ hello-world example, done up in in basic plain-vanilla corba, for the OmniORB, OmniBroker and Mico ORB's. Discussed further in the 'performance' section below.

Evaluations

Below follows a description of my personal experiences with some of these packages. I am not a testing & evaluation laboratory. I am a fallible individual, and cannot avoid subjective comments. Your actual experiences will vary. Recently (October 97), I tried to download and use some of these; the experiences are not all positive.
DCOM/ActiveX
Not Attempted. I really am interested in Corba and Java RMI, not by also-rans. I am also frustrated by Microsoft's by turns juvenile and malicious behavior. Concern has also been expressed that support for Linux/Unix will fade away after an initial flurry of activity, leaving developers with no choice but to migrate to Microsoft platforms. This concern is enlivened by the fact that the Linux "beta" has been that since before October 97 -- an awfully long time.

OmniORB2
This is my initial favorite. Comes pre-compiled, installs easily, and it works. Comes with several simple "Hello World" examples, together with documentation for the examples, that are just right for the novice CORBA user. Gets you going and fast, gives you the feeling that you are in command, and can start being productive creating corba apps.

One important strike against OmniORB2 is the lack of support for some of the more advanced features like DSI and DII. However, (1) they're working on it, and (2) chances are good that you won't need these features until you start getting to stratospheric complexity levels in your application.

MICO
Doesn't come pre-compiled, and thus requires you to build it. This leads to build problems for the unwary. In my case, I have a rather mangled (ahem, "highly modified") Linux system due to years of hacking. As a result, I experienced build problems, all of which I was eventually able to overcome by upgrading to recent versions of gcc, g++-devel, and binutils. For those who experience similar problems: a strong recommendation to upgrade to a newer g++-devel package (you need the newer header files in /usr/include).

Built MICO. Expect over an hour on a P133 ... this package, w/examples, is huge.

Now, moving on to things that I enjoyed:

ORBacus (OmniBroker)
Doesn't come pre-compiled, and thus requires you to build it. This leads to build problems for the unwary. In my case, I have a rather mangled (ahem, "highly modified") Linux system due to years of hacking. As a result, I experienced build problems, all of which I was eventually able to overcome by upgrading to recent versions of gcc, g++-devel, and binutils. For those who experience similar problems: a strong recommendation to upgrade to a newer g++-devel package (you need the newer header files in /usr/include).

Like OmniORB2 and MICO, ORBacus comes with some nice and easy to understand examples. The "hello world" example is nicely documented in the the postscript documentation, although it would have been nice to see a few comments embedded in the source, directly.

The nice thing was that the mailing list was quick to respond to my requests for assistance.

ILU
Doesn't come pre-compiled, and thus requires you to build it. The build worked, but the documentation is horrific. Feeling emboldened by my success with OmniORB, I dived right in, and hit a submerged rock. There are no beginner examples that I could find, and the documentation was less than helpful, throwing around big words and big concepts that immediately sent me scurrying out of the pool. Hey, I have a PhD, and twenty++ years of programming experience, and oodles of intestinal fortitude. If I can't hack this, who can?

This is unfortunate, since ILU offers the broadest language support of all the packages. The tutorial program is reasonably well documented, although quite obtuse, with it's factories and all. Yes, I know what an object factory is, but given how dramatically different the tutorial is from the other CORBA implementations, it makes me wonder if any code developed on ILU would ever have a chance of being ported to a different CORBA implementation.

(A reader wrote in to remind me: ILU is not CORBA, its an ORB with CORBA support. This means that while the same concepts may apply, the actual philosophies and approach can be quite different.)

COOL ORB
Haven't gotten around to trying this yet.

TAO
Didn't try this. The web site states that this is alpha code, and I am not ready for that.

Electra
Didn't try this. The author of the code stated that it wasn't stable on Linux, and doesn't use Linux as a development platform. This scared me off.

Overall Comments

One frustration that I see right away with CORBA is the instance that it use the CORBA types, like CORBA::Long instead of "long", or CORBA::String_var instead of "char *". While this may be what the CORBA standard calls for, and possibly more precise than the somewhat loose C++ types, it certainly does make the code harder to read. And readability is extremely important for building simple to use & debug systems.

Interoperability

The three packages OmniORB2, ORBacus and Mico were put through a very simple "Hello, World" interoperability test. A simple server was written; the server can echo back whatever string is sent to it. Similarly, a simple client was written that can contact the server, send a message and receive a reply. Differences in implementation between the three different packages were surrounded by #ifdef's so that a single source could be compiled for all three ORB systems.

Examining the sources, it becomes obvious how nearly-identical, and yet pervasively different each of the packages is. Most frustratingly, ORBacus chooses to implement the CORBA namespace as CORBA_ rather than CORBA::. Although this is technically the more correct solution (arguably the only correct solution, see footnote), it leads to broad source incompatibilities with the other implementations. OmniORB2 implements a few extensions to support threading, which is nice, but unfortunately requires the use of the extensions to operate. Mico appears to be the most standards-compliant. The code can be browsed here, or downloaded as a tar.gz here.

All three implementations passed the inter-operability test. Each of the three clients were able to talk contact and exchange messages with each of the three servers. Anything less would have been unacceptable, as this is the whole point of IIOP. Note that this test was extremely simple & basic: Not only are the server and client bare-bones minimal, but also the COS naming services were not tested: the stringified IOR was passed in a file.

Performance

The performance of three different CORBA implementations were compared on a simple "Hello World" application. The code can be examined here and can be downloaded as corba-perf.tar.gz here. This code is interesting not only for measuring performance, but also for comparing the differences between different implementations. A quick survey will show how similar, and yet frustratingly different, the two implementations are.

The following results were obtained on a Pentium 133 w/ Linux 2.0.30 kernel & gcc 2.7.2.1, OmniORB2 version 2.2.0, ORBacus version 2.0b4, and Mico version 0.93b3, in October 1997:

CORBA           millisecs    compile time  binary size
Implementation   per call     (seconds)    (kiloBytes)
-------------------------------------------------------
OmniORB2          0.80           26         752
ORBacus        1.10           70        2100
Mico              4.20           60         102
Note that these measurements were taken in October 1997, and may no longer be valid.

Clearly, OmniORB2 holds both the raw performance record, as well as the compile time record. Note that both ORBacus and OmniORB used statically linked libraries, while Mico uses a shared library. This results in both smaller binaries for Mico, as well as possibly affecting performance. One reason why the ORBacus binaries are considerably larger is that ORBacus includes considerably more function than OmniORB. I believe that OmniORB can be built as a shared library, and, by the time you read this, ORBacus will be as well. Note: the shared-library version of ORBacus results in binaries in the 100K ballpark, and improves performance nearly ten percent, probably (almost certainly) due to improved cache hit ratios.

Many readers have written in to note that ORBacus can be compiled as a shared lib. Try the following in /config/Make.rules.in:

    CXX=g++
    CXXFLAGS= --no-implicit-templates -fhandle-exceptions -Wall
    AR=g++
    ARFLAGS= -shared -o
    RANLIB=:
    LIBEXT=.so
and in the shell,
  export LD_LIBRARY_PATH="`pwd`/lib:`pwd`/idl:`pwd`/naming:$LD_LIBRARY_PATH"
  configure
  make

The above table shows performance for a client and server running on the same machine. The table below shows performance over the network. One of the network machines is an Intel 486DX4 w/ Linux 2.1.26, the other a Pentium-133 with Linux 2.0.30. Both machines have cheap NE2000 10Base2 Ethernet cards. The column labelled "fastclient" has the client running on the faster machine, and "slowclient" is vice-versa.

     ------ NETWORK PERFORMANCE ---------
CORBA                 milliseconds per call
Implementation   local     fastclient     slowclient
-------------------------------------------------------
OmniORB2          0.80        2.30           2.30
ORBacus           1.10        3.00           3.15
Mico              4.20        8.50           7.90
Note that in all of the network tests, CPU usage did not exceed 60%, indicating that the performance is bottle-necked in the Ethernet hardware. Note that the 2.1.x series of kernels are reputed to have significantly improved TCP-IP performance.

Disclaimer: performance is something that almost all implementors care about, and performance measurements are by necessity dated. The above tests were performed in October 1997, and newer versions may have significantly improved performance characteristics.

Important Note: Before making rash assumptions about the relative performance of these ORB's, please note that some (many?) commercial implementations appear to be a full order of magnitude slower than Mico!. See, for example, the JacORB Performance Comparison. The figures there indicate a ten-millisecond ping time for some popular commercial packages, which is very surprising, given that the above tests are not much more than a ping, run on slow machines with bad Ethernet cards. See also a hint that Linux holds the world speed record for CORBA. A thorough, scientific investigation of CORBA performance is being performed by D. Schmidt.

Footnotes

Currently, Only the egcs-1.1.1 compiler supports namespaces; GNU C++ versions 2.7 and 2.8.1 do not. Unfortunately, egcs is not (yet) widespread or widely supported. Lack of namespace support puts a constraint on how the CORBA spec is interpreted, and how it can be implemented. What many (most) CORBA implementations do in the face of this compiler limitation is to map CORBA modules to C++ classes (instead of C++ namespaces, as they should have). This leads to a technical violation of the CORBA spec. Consider the example:
module A {
      interface X { void xxx(); };
};

module B {
      interface Y : A::X { void yyy(); };
};

module A {
      interface Z : B::Y { void zzz(); };
};
This example breaks any implementation that confuses classes with namespaces. Let's consider the code that would be generated:
class A {
   class X {
      void xxx();
   };
};
class B {
   class Y : virtual public A::X {
      void yyy();
   };
};
class A {         // oops -- re-declaration -- a C++ syntax error
   class Z : virtual public B::Y {
      void zzz();
   };
};
This problem cannot be solved with a smarter IDL processor, since the various modules may be defined in different files, and not be compiled at the same time. An example of a more technically correct implementation, the one which ORBacus uses, is:
class A_X {
   void xxx();
};
class B_Y : virtual public A_X {
   void yyy();
};
class A_Z : virtual public B_Y {
   void zzz();
};
This implementation is supported in the CORBA spec:

3.13 Names and Scoping
[...]
An identifier can only be defined once in a scope. However, identifiers can be redefined in nested scopes. An identifier declaring a module is considered to be defined by its first occurrence in a scope. Subsequent occurrences of a module declaration within the same scope reopen the module allowing additional definitions to be added to it. [...]

Thanks to Marc Laukien of Object-Oriented Concepts, Inc. for clarifying this.


Last updated October 2001 by Linas Vepstas (linas@linas.org)
Copyright (c) 1996-2000 Linas Vepstas.
All trademarks on this page are property of their respective owners.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included at the URL http://www.linas.org/fdl.html, the web page titled "GNU Free Documentation License".

Go Back to the Enterprise Linux(TM) Page
Go Back to Linas' Home Page

Best viewed with the Beast