Previous Up Next

Chapter 3  C++ language mapping

Now that you are familiar with the basics, it is important to familiarise yourself with the standard IDL to C++ language mapping. The mapping is described in detail in [OMG03]. If you have not done so, you should obtain a copy of the document and use that as the programming guide to omniORB.

The specification is not an easy read. The alternative is to use one of the books on CORBA programming. For instance, Henning and Vinoski’s ‘Advanced CORBA Programming with C++’ [HV99] includes many example code fragments to illustrate how to use the C++ mapping.

3.1  omniORB 2 BOA compatibility

Before the Portable Object Adapter (POA) specification, many of the details of how servant objects should be implemented and registered with the system were unspecified, so server-side code was not portable between ORBs. The POA specification rectifies that. For compatibility, omniORB 4 still supports the old omniORB 2.x BOA mapping, but you should always use the POA mapping for new code. BOA code and POA code can coexist within a single program.

If you use the -WbBOA option to omniidl, it will generate skeleton code with (nearly) the same interface as the old omniORB 2 BOA mapping, as well as code to be used with the POA. Note that since the major problem with the BOA specification was that server code was not portable between ORBs, it is unlikely that omniORB’s BOA compatibility will help you much if you are moving from a different BOA-based ORB.

The BOA compatibility permits the majority of BOA code to compile without difficulty. However, there are a number of constructs which relied on omniORB 2 implementation details which no longer work.

3.2  omniORB 3.0 compatibility

omniORB 4 is almost completely source-code compatible with omniORB 3.0. There are two main cases where code may have to change. The first is code that uses the omniORB API, some aspects of which have changed. The omniORB configuration file also has a new format. See the next chapter for details of the new API and configuration file.

The second case of code that may have to change is code using the Dynamic Any interfaces. The standard changed quite significantly between CORBA 2.2 and CORBA 2.3; omniORB 3.0 supported the old CORBA 2.2 interfaces; omniORB 4 uses the new mapping. The changes are largely syntax changes, rather than semantic differences.

3.3  omniORB 4.0 compatibility

omniORB 4.2 is source-code compatible with omniORB 4.0, with four exceptions:

  1. As required by the 1.1 version of the CORBA C++ mapping specification, the RefCountServantBase class has been deprecated, and the reference counting functionality moved into ServantBase. For backwards compatibility, RefCountServantBase still exists, but is now defined as an empty struct. Most code will continue to work unchanged, but code that explicitly calls RefCountServantBase::_add_ref() or _remove_ref() will no longer compile.
  2. omniORB 4.0 had an option for Any extraction semantics that was compatible with omniORB 2.7, where ownership of extracted values was not maintained by the Any. That option is no longer available.
  3. The members of the clientSendRequest interceptor have been changed, replacing all the separate variables with a single member of type GIOP_C. All the values previously available can be accessed through the GIOP_C instance.
  4. The C++ mapping contains Any insertion operators for sequence types that are passed by pointer, which cause the Any to take ownership of the inserted sequence. In omniORB 4.0 and earlier, the sequence was immediately marshalled into the Any’s internal buffer, and the sequence was deleted. In omniORB 4.1, the sequence pointer is stored by the Any, and the sequence is deleted later when the Any is destroyed.

    For most uses, this change is not visible to application code. However, if a sequence is constructed using an application-supplied buffer with the release flag set to false (meaning that the application continues to own the buffer), it is now important that the buffer is not deleted or modified while the Any exists, since the Any continues to refer to the buffer contents. This change means that code that worked with omniORB 4.0 may now fail with 4.1, with the Any seeing modified data or the process crashing due to accessing deleted data. To avoid this situation, use the alternative Any insertion operator using a const reference, which copies the sequence.

3.4  omniORB 4.1 compatibility

omniORB 4.2 is source-code compatible with omniORB 4.1 with one exception:

  1. When omniORB 4.1 and earlier detected a timeout condition, they would throw the CORBA::TRANSIENT system exception. omniORB 4.2 supports the CORBA::TIMEOUT system exception that was introduced with the CORBA Messaging specification. Application code that caught CORBA::TRANSIENT to handle timeout situations should be updated to catch CORBA::TIMEOUT instead. Alternatively, to avoid code changes, omniORB can be configured to throw CORBA::TRANSIENT for timeouts, by setting the throwTransientOnTimeout parameter to 1. See section 4.4.

Previous Up Next