Introduction

OmniORB2 is an Object Request Broker (ORB) that implements the 2.0 specification of the Common Object Request Broker Architecture (CORBA) [OMG96a]. This user guide tells you how to use omniORB2 to develop CORBA applications. It assumes a basic understanding of CORBA.

In this chapter, we give an overview of the main features of omniORB2 and what you need to do to setup your environment to run omniORB2.

Features

CORBA 2 compliant

OmniORB2 implements the Internet Inter-ORB Protocol (IIOP). This protocol provides omniORB2 the means of achieving interoperability with the ORBs implemented by other vendors. In fact, this is the native protocol used by omniORB2 for the communication amongst its objects residing in different address spaces. Moreover, the IDL to C++ language mapping provided by omniORB2 conforms to the latest revision of the CORBA specification.

Multithreading

OmniORB2 is fully multithreaded. To achieve low IIOP call overhead, unnecessary call-multiplexing is eliminated. At any time, there is at most one call in-flight in each communication channel between two address spaces. To do so without limiting the level of concurrency, new channels connecting the two address spaces are created on demand and cached when there are more 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 maximize 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.

Portability

At ORL, the ability to target a single source tree to multiple platforms is very important. This is difficult to achieve if the IDL to C++ mapping for these platforms are different. We avoid this problem by making sure that only one IDL to C++ mapping is used. We run several flavours of Unices, Windows NT, Windows 95 and our in-house developed systems for our own hardware. OmniORB2 have been ported to all these platforms. The IDL to C++ mapping for these targets are all the same.

OmniORB2 uses real C++ exceptions and nested classes. We stay with the CORBA specification's standard mapping as much as possible and do not use the alternative mappings for C++ dialects. The only exception is the mapping of modules to C++ classes instead of namespaces.

OmniORB2 relies on the native thread libraries to provide the multithreading capability. A small class library (omnithread [Richardson96a]) is used to encapsulated the (possibly different) APIs of the native thread libraries. In the 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.

Missing features

OmniORB2 is not (yet) a complete implementation of the CORBA core. The following is a list of the missing features.

• The Typcode and the Any type is not supported. Support for these types will be added shortly.
• The BOA only support the persistent server activation policy. Other dynamic activation and deactivation policies are not supported.
• The Dynamic Invocation Interface is not supported.
• The Dynamic Skeleton Interface is not supported.
• OmniORB2 does not has its own Interface Repository.

These features may be implemented in the short to medium term. It is best to check out the latest status on the omniORB2 home page (http://www.orl.co.uk/omniORB/omniORB.html).

Setting Up Your Environment

After you have unpacked the distribution, read all the README files at the top level of the directory tree. These files contain essential information on installing, building and using omniORB2 on the supported platforms.

The following is a checklist of what you have to do:

1. Setup the naming service. An implementation of the COS Naming Service, called omniNames, is provided in this distribution. If you want to use the service, you have to start it up first. Consult the document ``The OMNI Naming Service'' for details. When omniNames starts up, it writes the stringified object reference for its root context on standard error. This is needed by the omniORB2 runtime. See below for how to configure the runtime. You can also use other naming service implementations provided that you can obtain the stringified object reference for its root context.

2. Configure the omniORB2 runtime. At startup the omniORB runtime tries to read the configuration file omniORB.cfg to obtain the object reference to the root context of the Naming Service. This object reference is returned by the call resolve_initial_references("NameService").
   1. On Unix platforms, omniORB2 looks for the environment variable OMNIORB_CONFIG. If this variable is defined, it contains the pathname of the omniORB2 configuration file. If the variable is not set, omniORB2 will use the compiled-in pathname (/etc/omniORB.cfg) to locate the file.

   2. On Win32 platforms (Windows NT, Windows '95), omniORB2 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_MACHINESOFTWAREORLomniORB2.0

   The format of the entry is the word NAMESERVICE followed by space and the stringified IOR all on one line. For example:

   NAMESERVICE IOR:000000000000002049444c3a436f734e616d696e672f4e616d696e674
   36f6e746578743a312e300000000001000000000000002c0001000000000012776962626c
   652e776f62626c652e636f6d0004d20000000c3371b8c09528a18700000001
   

   Aternatively, the stringified IOR can be placed in the system registry on Win32 platforms, in the (string) value NAMESERVICE, under the key HKEY_LOCAL_MACHINESOFTWAREORLomniORB2.0.

3. Compiler flags. You should be able to build the whole distribution using the makefiles provided. The makefiles are configured to supply a set of preprocessor defines that are necessary to compile omniORB2 programs. The preprocessor defines are needed because the same set of header files are used for all platforms. If you are to incorporate omniORB2 into your own development environment, these are the necessary preprocessor defines:

   

   The makefiles are good examples on how omniORB2 programs are built. Please study them before you try to incorporate omniORB2 into other development environments.