Migration Services

A Quick Self-Audit!

Your legacy CORBA systems will most likely fall into one of these three categories:

A pre-CORBA 2.2 code base employing the BOA and many of the features that at that stage of CORBA were, of necessity, provided by the ORB vendor and thus became proprietary as subsequent standards activities addressed those initial shortcomings.
A post-CORBA 2.2 code base where the POA has supplanted the BOA and the applications now have has substantial portability. However there still are many areas where the application code requires review to ensure full advantage is being taken of later enhancements to the specification, and could position the applications for the CORBA Component Model (CCM) which will be CORBA 3.0.
A mixed application suite, with both BOA and POA code, utilizing your ORB vendor-provided mechanisms to support BOA/POA co-existence (i.e. to avoid rewrites.)

There may also be other software technologies from your legacy ORB vendor, such as gateways, firewalls, message-queuing services etc. all of which will demand some thought, and may be candidates for replacement.

Each of the three situations requires a plan to help make the migration smooth and expeditious. Over the years OCI has developed migration experiences which can be leveraged to help you take on this task. Two of the most common implementations of CORBA are Orbix and Visibroker. The experiences listed are similar for other CORBA products.

Orbix to TAO

Here are a list of issue that typically arise when OCI consultants are reviewing Orbix installations

Implementation Class Inheritance
Servant is not a CORBA::Object
Incarnating Servants for CORBA Objects
When to use _duplicate()
Application Initialization
Object Activation
The Event Loop for Processing Requests
Application Shutdown
Finding and Binding to CORBA Objects in Servers
Garbage Collection of Server Objects
IDL Compiler and Case Sensitivity
Header Files Generated
CORBA Header File Name
Orbix Filters
Smart Proxies
Object Loaders
Object Locator
Orbix MT

These are mostly C++ issues. Similar architectural issues will exist for the Java implementation of Orbix, except that language specific nuances such as memory management, garbage collection are mitigated by virtue of the language being Java.

Recently OCI engaged with a client, migrating from Orbix, who made heavy use of the IFR. As a result TAO's IFR was tested in a much wider set of situations than previous. Many minor issues were found and fixed. There should be fewer problems encountered with applications that are IFR intensive.

Visibroker to TAO

The same issues exist here as with Orbix and are mostly BOA to POA concerns. Variations from the Orbix situation are noted.

Implementation Class Inheritance
Servant is not a CORBA::Object
Incarnating Servants for CORBA Objects
When to use _duplicate()
Application Initialization
Object Activation
The Event Loop for Processing Requests
Application Shutdown
Finding and Binding to CORBA Objects in Servers: Called "_bind()". This capability works with Visibroker's OSAgent to retrieve objects.
Garbage Collection of Server Objects: Visibroker calls this the “automatic rebind capability”.
IDL Compiler and Case Sensitivity
Header Files Generated: This is also an issue with Visibroker due to the fact that file names are not standardized.
CORBA Header File Name: This is also an issue with Visibroker due to the fact that file names are not standardized.

Again, for the Java ORB the architectural issues are common, those related to memory management are not as serious because of the language features.