White Paper: CORBA Applications In GNOME

ORBit



In the early stages of the GNOME project, the MICO ORB was used. While some find it, it caused many problems because of its large resource footprint, long compile times, and C++ specificity. This significantly retarded CORBA integration in GNOME. Therefore, the ORBit project was born to create a thin, fast CORBA implementation with C language bindings. In its present state ORBit stably fulfills all the needs of GNOME.

ORBit has two main advantages. The first is its use of the C language. This is both salvation for fans of the C language, and good news for proponents of other languages. C has the advantage of being the lowest common denominator of almost all other language implementations. Efforts are underway to produce C++ bindings, Python, Eiffel, Ada, and Perl bindings.

A second advantage is the resource friendliness of ORBit. In preliminary performance tests, ORBit came out ahead of ILU, mico, omniORB, and TAO, other well-known free ORB's. The test used to measure performance was ten thousand invocations of the "echoString" operation, part of the ORBit test suite. The IDL for this operation is:
interface Echo {
  Echo echoString(in string astring, out long anum);
};
  

Invoking the operation sends the object implementation a string, and the object implementation returns an object reference (to itself) and a random number in return.

This is not by any means a comprehensive measure of performance one will receive on a particular application, but it does test the overhead of the ORB in general, as well as the speed of object reference creation, basic marshaling/de-marshaling, and network traffic scheduling. Table 1 shows the performance of these ten thousand operation invocations (as timed by the 'time' command, average of best 3 of 6 runs), with the client program running on the same system as the server. These took place on a K6-2 350 running Linux 2.2.2ac1.

Table 1. Overhead and Speed
ORB Time
Mico 2.2.3 22.48 seconds
ILU 2.0alpha13 9.17 seconds
TAO 0.2.42 8.81 seconds
omniORB 2.7.0 5.53 seconds
ORBit 0.4.2 2.93 seconds

ORBit supports collocated servers, aka in-process servers. This means that if the object server and the object ``client'' are located in the same address space, and the object server meets a few basic conditions, ORBit automatically skips sending the data over the network, and runs the object server's implementation function directly, causing performance to increase dramatically.

ORBit also uses less memory than the other ORBs. The top status display, for the "echo-server" process used in the above performance test, indicated the sizes for each ORB represented in Table 2

Table 2. Memory Usage
ORB Size(K) Unshared(K)
ILU 1032 144
ORBit 844 196
omniORB 1124 272
TAO 2876 460
mico 2948 584

In addition to these two main advantages, ORBit also has been tailored to make it easy to use with GUI toolkits such as GTK+. It has hooks to allow custom security—authentication. Other expositions of the ORB internals and extensions allow libraries and applications to leverage ORBit to the fullest advantage. Sample implementations of the event and name services are included in ORBit to make it easy to build more complex applications.

Looking ahead in ORBit development, one can for-see a rewrite of the performance-critical modules, compliance with the upcoming CORBA 2.3 standard, more CORBA services, and documentation. The development tree is available to everyone via anonymous CVS, an ORBit mailing list facilitates interesting discussions, and contributions are welcomed. More information on all of these is available at the ORBit web page.


Prev Table of Contents Next
CORBA   The GNOME CORBA Framework