# Chapter 1 Introduction

omniORB is an Object Request Broker (ORB) that implements version 2.6 of the Common Object Request Broker Architecture (CORBA) [] 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.

## 1.1 Features

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:

- C++ and Python language bindings.
- Support for the complete Portable Object Adapter (POA) specification.
- Support for the Interoperable Naming Service (INS).
- Internet Inter-ORB Protocol (IIOP 1.2) is used as the native protocol.
- The omniORB runtime is fully multithreaded. It uses platform thread support encapsulated with a small class library, omnithread, to abstract away from differences in native thread APIs.
- TypeCode and type Any are supported.
- DynAny is supported.
- The Dynamic Invocation and Dynamic Skeleton interfaces are supported.
- Valuetype and abstract interfaces are supported.
- Asynchronous Method Invocation (AMI) supported, including both polling and callback models.
- Extensive control over connection management.
- Soft real-time features including call deadlines and timeouts.
- A COS Naming Service, omniNames.
- Many platforms are supported, including most Unix platforms and Windows.
- It has been successfully tested for interoperability via IIOP with other ORBs.

### 1.1.1 Multithreading

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.

### 1.1.2 Portability

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 []) 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.

### 1.1.3 Missing features

omniORB is not a complete implementation of the CORBA 2.6 core. The following is a list of the most significant missing features.

- For some very dynamic uses of CORBA, you may need an Interface Repository. omniORB does not have its own one, but it can act as a client to an IfR. The omniifr project (https://github.com/omniorb/omniifr) aims to create an IfR for omniORB.
- omniORB supports interceptors, but not the standard Portable Interceptor API.

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

- 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 / Win64 platforms, 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 HKEY_LOCAL_MACHINE\SOFTWARE\omniORB.

omniORB has a large number of parameters than can be configured. See chapter ?? 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 ?? 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 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.