omniORB is an Object Request Broker (ORB) that implements version 2.6 of the Common Object Request Broker Architecture (CORBA) [OMG01] specification. Where possible, backward compatibility has been maintained back to specification 2.0. It 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 1999.
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 set up your environment to run omniORB.
omniORB is quite feature-rich, but it does not slavishly implement every last part of the CORBA specification. The goal is to provide the most generally useful parts of the specification in a clean and efficient manner. Highlights are:
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.
omniORB also supports a flexible thread pool 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 clients.
omniORB 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 small exception is the mapping of IDL modules, which can use either namespaces according to the standard, or nested classes for truly ancient C++ compilers without namespace support.
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.
Partly for historical reasons, and partly to support users with archaic compilers, omniORB does not use the C++ standard library.
The omniORB IDL compiler, omniidl, requires Python version 3.5 or later or, for people stuck in the past, version 2.7.
omniORB is not a complete implementation of the CORBA 2.6 core. The following is a list of the most significant missing features.
To get omniORB running, you first need to install omniORB according to the instructions in the installation notes for your platform. See README.FIRST.txt at the top of the omniORB tree for instructions. 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 setup. 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.
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 8.1.5 for full details of corbaname URIs.
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 following defines:
| Platform | CPP defines |
| Windows | __x86__ __NT__ __OSVERSION__=4 __WIN32__ |
| Windows NT 3.5 | __x86__ __NT__ __OSVERSION__=3 __WIN32__ |
| Sun Solaris 2.5 | __sparc__ __sunos__ __OSVERSION__=5 |
| HPUX 10.x | __hppa__ __hpux__ __OSVERSION__=10 |
| HPUX 11.x | __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 |
| ATMos 4.0 | __arm__ __atmos__ __OSVERSION__=4 |
| NextStep 3.x | __m68k__ __nextstep__ __OSVERSION__=3 |
| Unixware 7 | __x86__ __uw7__ __OSVERSION__=5 |
The preprocessor defines for new platform ports not listed above can be found in the corresponding platform configuration files. The preprocessor defines to identify a platform are in the make variable IMPORT_CPPFLAGS.
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.