omniORB is an Object Request Broker (ORB) that implements the 2.6
specification of the Common Object Request Broker Architecture
(CORBA) [OMG01]1. It has
passed the Open Group CORBA compliant testsuite (for CORBA 2.1) and
was one of the three ORBs to be granted the CORBA brand in June
This user guide tells you how to use omniORB to develop CORBA
applications. It assumes a basic understanding of CORBA.
In this chapter, we give an overview of the main features of omniORB
and what you need to do to setup your environment to run omniORB.
omniORB is fully multithreaded. To achieve low call overhead,
unnecessary call-multiplexing is eliminated. With the default
policies, there is at most one call in-flight in each communication
channel between two address spaces at any one time. To do this without
limiting the level of concurrency, new channels connecting the two
address spaces are created on demand and cached when there are
concurrent calls in progress. Each channel is served by a dedicated
thread. This arrangement provides maximal concurrency and eliminates
any thread switching in either of the address spaces to process a
call. Furthermore, to maximise the throughput in processing large call
arguments, large data elements are sent as soon as they are processed
while the other arguments are being marshalled. With GIOP 1.2, large
messages are fragmented, so the marshaller can start transmission
before it knows how large the entire message will be.
From version 4.0 onwards, omniORB also supports a flexible thread
pooling policy, and supports sending multiple interleaved calls on a
single connection. This policy leads to a small amount of additional
call overhead, compared to the default thread per connection model,
but allows omniORB to scale to extremely large numbers of concurrent
omniORB has always been designed to be portable. It runs on many
flavours of Unix, Windows, several embedded operating systems, and
relatively obscure systems such as OpenVMS and Fujitsu-Siemens BS2000.
It is designed to be easy to port to new platforms. The IDL to C++
mapping for all target platforms is the same.
omniORB uses real C++ exceptions and nested classes. It keeps to the
CORBA specification's standard mapping as much as possible and does
not use the alternative mappings for C++ dialects. The only exception
is the mapping of IDL modules, which can use either namespaces or
omniORB relies on native thread libraries to provide multithreading
capability. A small class library (omnithread [Ric96]) is used
to encapsulate the APIs of the native thread libraries. In application
code, it is recommended but not mandatory to use this class library
for thread management. It should be easy to port omnithread to any
platform that either supports the POSIX thread standard or has a
thread package that supports similar capabilities.
1.1.3 Missing features
omniORB is not (yet) a complete implementation of the CORBA 2.6 core.
The following is a list of the most significant missing features.
These features may be implemented in the short to medium term. It is
best to check out the latest status on the omniORB home page
- omniORB does not have its own Interface Repository. However, it
can act as a client to an IfR. The omniifr project
(http://omniifr.sourceforge.net/) aims to create an IfR for
- omniORB supports interceptors, but not the standard Portable
1.2 Setting up your environment
To get omniORB running, you first need to install omniORB according to
the instructions in the installation notes for your platform. Most
Unix platforms can use the Autoconf configure script to
automate the configuration process.
Once omniORB is installed in a suitable location, you must configure
it according to your required set-up. The configuration can be set
with a configuration file, environment variables, command-line
arguments or, on Windows, the Windows registry.
omniORB has a large number of parameters than can be configured. See
chapter 4 for full details. The files
sample.cfg and sample.reg contain an example
configuration file and set of registry entries respectively.
- On Unix platforms, the omniORB runtime looks for the environment
variable OMNIORB_CONFIG. If this variable is defined, it
contains the pathname of the omniORB configuration file. If the
variable is not set, omniORB will use the compiled-in pathname to
locate the file (by default /etc/omniORB.cfg).
- On Win32 platforms (Windows NT, 2000, 95, 98), omniORB first
checks the environment variable OMNIORB_CONFIG to obtain the
pathname of the configuration file. If this is not set, it then
attempts to obtain configuration data in the system registry. It
searches for the data under the key
To get all the omniORB examples running, the main thing you need to
configure is the Naming service, omniNames. To do that, the
configuration file or registry should contain an entry of the form
InitRef = NameService=corbaname::my.host.name
See section 6.1.2 for full details of corbaname URIs.
1.3 Platform specific variables
To compile omniORB programs correctly, several C++ preprocessor defines
must be specified to identify the target platform. On Unix
platforms where omniORB was configured with Autoconf, the
omniconfig.h file sets these for you. On other platforms, and
Unix platforms when Autoconf is not used, you must specify the
|Windows NT 4.0,2000,XP
__x86__ __NT__ __OSVERSION__=4 __WIN32__
|Windows NT 3.5
__x86__ __NT__ __OSVERSION__=3 __WIN32__
|Sun Solaris 2.5
__sparc__ __sunos__ __OSVERSION__=5
__hppa__ __hpux__ __OSVERSION__=10
__hppa__ __hpux__ __OSVERSION__=11
|IBM AIX 4.x
__aix__ __powerpc__ __OSVERSION__=4
|Digital Unix 3.2
__alpha__ __osf1__ __OSVERSION__=3
|Linux 2.x (x86)
__x86__ __linux__ __OSVERSION__=2
|Linux 2.x (powerpc)
__powerpc__ __linux__ __OSVERSION__=2
|OpenVMS 6.x (alpha)
__alpha__ __vms __OSVERSION__=6
|OpenVMS 6.x (vax)
__vax__ __vms __OSVERSION__=6
|SGI Irix 6.x
__mips__ __irix__ __OSVERSION__=6
|Reliant Unix 5.43
__mips__ __SINIX__ __OSVERSION__=5
__arm__ __atmos__ __OSVERSION__=4
__m68k__ __nextstep__ __OSVERSION__=3
__x86__ __uw7__ __OSVERSION__=5
The preprocessor defines for new platform ports not listed above can
be found in the corresponding platform configuration files. For
instance, the platform configuration file for Sun Solaris 2.6 is in
mk/platforms/sun4_sosV_5.6.mk. The preprocessor defines to
identify a platform are in the make variable
In a single source multi-target environment, you can put the
preprocessor defines as the command-line arguments for the compiler.
If you are building for a single platform, you can edit
include/omniconfig.h to add the definitions.
- Most of the 2.6 features have
been implemented. The features still missing in this release are
listed in section 1.1.3. Where possible, backward
compatibility has been maintained up to specification 2.0.
- More information can be found at