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.
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. Type Any and TypeCode are now supported (introduced in version 2.5.0).
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 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.
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.
OmniORB2 is not (yet) a complete implementation of the CORBA core. The following is a list of the missing features.
These features may be implemented in the medium term. It is best to
check out the latest status on the omniORB2 home page
(http://www.orl.co.uk/omniORB/omniORB.html
).
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:
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")
.
/etc/omniORB.cfg
)
to locate the file.
The format of the entry is the word NAMESERVICE
followed by space
and the stringified IOR all on one line. For example:
NAMESERVICE IOR:00fff71c0000002849444c3a6f6d672e6f72672f436f734e616d696e 672f4e616d696e67436f6e746578743a312e300000000001000000000000002c00010000 00000012776962626c652e776f62626c652e636f6d0004d20000000c34c35a8305a931a2 00000001
Aternatively, the stringified IOR can be placed in the system registry on
Win32 platforms, in the (string) value NAMESERVICE, under the key
HKEY_LOCAL_MACHINESOFTWARE
ORL
omniORB
2.0.
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, you must specify the following preprocessor defines to identify a target platform:
You should also specify the preprocessor defines (e.g. -D_REENTRANT) for compiling multithreaded programs.
In a single source multi-target environment, you can put the preprocessor defines as the command-line arguments for the compiler. Alternately, you could create a sitedef.h file in the same directory as omniORB2/CORBA.h. Write into the file the appropriate set of preprocessor defines and add #include <omniORB2/sitedef.h> at the beginning of omniORB2/CORBA_sysdep.h.