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 19992.
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 clients.
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 nested classes.
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.
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 (http://omniorb.sourceforge.net/).
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.
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.
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 NT 4.0,2000,XP | __x86__ __NT__ __OSVERSION__=4 __WIN32__ |
| Windows NT 3.5 | __x86__ __NT__ __OSVERSION__=3 __WIN32__ |
| Windows 95 | __x86__ __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. 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 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.