[omniORB] porting from IONA Orbix2.3c on HP-UX

[Duncan Grisby]

On Wednesday 31 January, "Geil, Martin F" wrote:

> > 	I am researching the options for porting a large software project
> > written in C/C++ from IONA Orbix2.3c to MICO/TAO/OmniORB/???.  The goals
> > are to move to an opensource CORBA implementation that is complete and
> > interoperable with existing Orbix2.3c servers.  Our development/deployment
> > platform is exclusively HP-UX, currently 10.20/native cfront C++ but
> > moving to 11i/aCC as part of this port.  Our current implementation uses
> > BOA, and I'm not sure how hard it is to move to POA or how interoperable
> > we will be with old Orbix servers afterwards.  Any thoughts and
> > suggestions would be welcome.

How easy it is to port to omniORB (or any other ORB, for that matter)
depends on how many Orbix proprietary features are used in the
application. If it only uses standard facilities, it should be
relatively straightforward; if it uses Orbix-specific things like
bind() and the implementation repository, it might be a lot more work.

To migrate from BOA code to any other ORB, BOA or POA, will involve
changing a fair bit of code. omniORB 3 has a BOA compatibility mode
which is (largely) compatible with omniORB 2's BOA, but differs from
Orbix's BOA. I would recommend ditching the BOA altogether, and moving
to use the POA interfaces, even if switching to a different BOA
implementation seems easier at first. The long-term benefits will
outweigh any initial extra work.

Unfortunately, Orbix has a history of having some serious
interoperability bugs (like the one I just posted about, for example).
omniORB has work-arounds for most of these bugs, but you would really
have to try your application to see whether it worked or not.

Hope that helps,

Duncan.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --