Chapter 1 Introduction

omniORBpy is an Object Request Broker (ORB) that implements the CORBA 2.3 Python mapping [OMG00b]. It is designed for use with omniORB 3, but it can also be used with omniORB 2.8. If you use omniORB 3.0, the full POA functionality is available; with omniORB 2.8 many POA functions are not supported.

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 CORBA 2.3 compliant

omniORB implements the Internet Inter-ORB Protocol (IIOP). This protocol provides omniORB the means of achieving interoperability with the ORBs implemented by other vendors. In fact, this is the native protocol used by omniORB for the communication amongst its objects residing in different address spaces.

Moreover, the IDL to Python language mapping provided by omniORBpy conforms to the 2.3 Python mapping specification¹.

1.1.2 Multithreading

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

1.1.3 Missing features

omniORBpy is not a complete implementation of the CORBA 2.3 core. The following is a list of the missing features.

omniORB does not have its own Interface Repository. However, it can act as a client to an IR³.
The IDL types wchar, wstring, fixed, and valuetype are not supported in this release.
The PortableServer.Current interface is not yet supported.
DII and DSI are not supported. However, since both Python code and IDL can be generated and used at run-time, this is not a significant restriction.

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://www.uk.research.att.com/omniORB/).

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

For Python to find omniORBpy, 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 i586_linux_glibc or 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.
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\ORL\omniORB\2.0.

The configuration file is used to obtain an object reference for the Naming Service, via either a stringified IOR or an Interoperable Naming Service URI. When using omniORB 3, the entry in the configuration file should be specified in the form:

   ORBInitRef NameService=<URI for the Naming Service>

The easiest way of specifying the Naming Service is with a corbaname: URI, as described in section 4.1.2.

Comments in the configuration file should be prefixed with a `#' character.

On Win32 platforms, the naming service reference can be placed in the system registry, in the (string) value ORBInitRef, under the key HKEY_LOCAL_MACHINE\SOFTWARE\ORL\omniORB\2.0.

omniORB 2.8 configuration file entries

ORBInitRef is new with omniORB 3. Under omniORB 2.8, you must use the older format (which is still supported by omniORB 3):

   NAMESERVICE <IOR for the Naming Service>

Two other entries are also supported, but with omniORB 3 are made obsolete by the Interoperable Naming Service URIs:

   ORBInitialHost <hostname string>
   ORBInitialPort <port number (1-65535)>

The corresponding entries under the Win32 system registry are the keys named ORBInitialHost and ORBInitialPort.

The two entries provide information to the ORB to locate a (proprietary) bootstrap service at runtime. The bootstrap service is able to return the initial object reference for the Naming Service and others.

1: As detailed in section 1.1.3, a number of features are missing.
2: This means that your Python interpreter must have been built with thread support.
3: See section 3.3 for a note about using an interface repository.