GnuCash!

Linux DCE, CORBA and DCOM Guide

• The article CORBA Meets Java in JavaWorld provides a gentle introduction to the concepts and history of CORBA.
• OMG's official CORBA for Beginners web page.
• OMG's Java RMI on CORBA white paper. See also the RMI on CORBA prototype page, and of course, the original Java RMI Page.
• The CORBA FAQ
• Ben Eng's Comprehensive List of CORBA vendors and tools.
• The CORBA Links page provides a large selection of introductory and reference documentation links.
• The Free CORBA Page lists various free implementations.
• ORBnews Online provides headline digests of news surrounding Distributed Object Computing.

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.

• Commercial support

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.

• mico/E is an extension of mico for the Eiffel programming language.

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

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!)

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

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:

• The use of a shared library is nice ... this keeps the executables considerable smaller than they might have been. (100KB for MICO, as compared to 750KB for OmniORB2).
• Comes with a pile of example code, starting with the absolute basics (see demo/account, then demo/account2, etc). Great! I can actually understand this!
• The nice thing was that the mailing list was quick to respond to my requests for assistance.

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

Interoperability

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 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

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

  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

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

module A {
      interface X { void xxx(); };
};

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

module A {
      interface Z : B::Y { void zzz(); };
};

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();
   };
};

class A_X {
   void xxx();
};
class B_Y : virtual public A_X {
   void yyy();
};
class A_Z : virtual public B_Y {
   void zzz();
};

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.

Best viewed with the Beast