Chapter 1 Introduction

omniORBpy is an Object Request Broker (ORB) that implements the CORBA 2.6 Python mapping [OMG01b]. It works in conjunction with omniORB for C++, version 4.1.

This user guide tells you how to use omniORBpy to develop CORBA applications using Python. It assumes a basic understanding of CORBA, and of the Python mapping. Unlike most CORBA standards, the Python mapping document is small, and quite easy to follow.

This manual contains all you need to know about omniORB in order to use omniORBpy. Some sections are repeated from the omniORB manual.

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

1.1 Features

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.

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.

1.1.2 Portability

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.

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.

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.
omniORB supports interceptors, but not the standard Portable Interceptor API. Interceptor facilities available from Python code are quite limited.

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/).

1.2 Setting up your environment

omniORBpy relies on the omniORB C++ libraries. If you are building from source, you must first build omniORB itself, as detailed in the omniORB documentation. After that, you can build the omniORBpy distribution, according to the instructions in the release notes.

1.2.1 Paths

With an Autoconf build (the norm on Unix platforms), omniORBpy is usually installed into a location that Python will find it.

Otherwise, you must tell Python where to find it. You must add two directories to the PYTHONPATH environment variable. The lib/python directory contains platform-independent Python code; the lib/$FARCH directory contains platform-specific binaries, where FARCH is the name of your platform, such as x86_win32.

On Unix platforms, set PYTHONPATH with a command like:

   export PYTHONPATH=$PYTHONPATH:$TOP/lib/python:$TOP/lib/$FARCH

On Windows, use

   set PYTHONPATH=%PYTHONPATH%;%TOP%\lib\python;%TOP%\lib\x86_win32

(Where the TOP environment variable is the root of your omniORB tree.)

You should also add the bin/$FARCH directory to your PATH, so you can run the IDL compiler, omniidl. Finally, add the lib/$FARCH directory to LD_LIBRARY_PATH, so the omniORB core library can be found.

1.2.2 Configuration file

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 HKEY_LOCAL_MACHINE\SOFTWARE\omniORB.

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.