Using CORBA

Outlines how to use CORBA to distribute applications. Differs by CORBA implementation and whether you are using DNS names or IP addresses. Examples below support the ACE/TAO and OmniORB CORBA implementations.

Sample system:

  • Deploying components in demo.xml with deployer-corba, on machine1.me.home with IP address 192.168.12.132
  • Running a GUI program demogui to connect to deployer components, on machine2.me.home with IP address 192.168.12.133
  • Use a name server without multi-casting[1], on machine1.me.home.
  • Using a bash shell.
  • Both machines are gnulinux (though this has been verified with macosx, and mixing macosx and gnulinux)

Working DNS

If you have working forward and reverse DNS entries (ie dig machine1.me.home returns 192.168.12.132, and dig -x 192.168.12.132 returns machine1.me.home)

ACE/TAO

machine1 \$ Naming_Service -m 0 -ORBListenEndpoints iiop://machine1.me.home:2809 \
-ORBDaemon &
machine1 \$ export NameServiceIOR=corbaloc:iiop:machine1.me.home:2809/NameService
machine1 \$ deployer-corba-gnulinux -s demo.xml
 
machine2 \$ export NameServiceIOR=corbaloc:iiop:machine1.me.home:2809/NameService
machine2 \$ ./demogui

OmniORB

OmniORB does not support the NameServiceIOR environment variable

machine1 \$ omniNames -start &
machine1 \$ deployer-corba-gnulinux -s demo.xml  
 
machine2 \$ ./demogui -ORBInitRef NameService=corbaloc:iiop:machine1.me.home:2809/NameService

Note that if you swap which machines run the deployer and demogui, then change the above to

machine1 \$ omniNames -start &
 
machine2 \$ deployer-corba-gnulinux -s demo.xml  -- \
-ORBInitRef NameService=corbaloc:iiop:machine1.me.home:2809/NameService
 
machine1 \$ ./demogui

Non-working DNS or you must use IP addresses

If you don't have DNS or you must use IP addresses for some reason.

ACE/TAO

machine1 \$ Naming_Service -m 0 -ORBDottedDecimalAddresses 1 \
-ORBListenEndpoints iiop://192.168.12.132:2809 -ORBDaemon &
machine1 \$ export NameServiceIOR=corbaloc:iiop:192.168.12.132:2809/NameService
machine1 \$ deployer-corba-gnulinux -s demo.xml -- -ORBDottedDecimalAddresses 1
 
machine2 \$ export NameServiceIOR=corbaloc:iiop:192.168.12.132:2809/NameService
machine2 \$ ./demogui -ORBDottedDecimalAddresses 1

For more information on the ORBListenEndPoints syntax and possibilities, see http://www.dre.vanderbilt.edu/~schmidt/DOC_ROOT/TAO/docs/ORBEndpoint.html

OmniORB

machine1 \$ omniNames -start &
machine1 \$ deployer-corba-gnulinux -s demo.xml  
 
machine2 \$ ./demogui -ORBInitRef NameService=corbaloc:iiop:192.168.12.132:2809/NameService

And the reverse

machine1 \$ omniNames -start &
 
machine2 \$ deployer-corba-gnulinux -s demo.xml  -- \
-ORBInitRef NameService=corbaloc:iiop:192.168.12.132:2809/NameService
 
machine1 \$ ./demogui

Localhost

Certain distro's and certain CORBA versions will exhibit problems even with localhost only scenarios (demonstrated with OmniORB under Ubuntu Jackaloupe). If you can not connect to the name service running on the same machine, substitue the primary network interface's IP address for localhost in any NameService value.

For example, instead of 

machine1 \$ omniNames -start &
 
machine2 \$ deployer-corba-gnulinux -s demo.xml

or even

machine1 \$ omniNames -start &
 
machine2 \$ deployer-corba-gnulinux -s demo.xml  -- \
-ORBInitRef NameService=corbaloc:iiop:localhost:2809/NameService

use

machine1 \$ omniNames -start &
 
machine2 \$ deployer-corba-gnulinux -s demo.xml  -- \
-ORBInitRef NameService=corbaloc:iiop:192.168.12.132:2809/NameService

NB as of RTT v1.8.2 and OmniORB v4.1.0, programs like demogui (which use RTT::ControlTaskProxy::InitOrb() to initialize CORBA) do not support -ORBDottedDecimalAddresses (in case you try to use it).

Multi-homed machines

Computers that have multiple network interfaces present additional problems. The following is for omniORB (verified with a mix of v4.1.3 on Mac OS X, andv v4.1.1 on Ubuntu Hardy), for a system running a name server, a deployer, and a GUI. The example system has a 192.168.1.0 wired subnet and a 10.0.10.0 wireless subnet, and you have a mobile vehicle that has to communicate over the wireless subnet but it also has a wired interface.

The problem may appear as one of

  • The vehicle can not contact the name server when the wired interface is disconnected but it is up (NB on rare occasions, we've seen this even with the wired interface disconnected and down!)
  • Your GUI can connect to the deployer, but then locks up or throws a CORBA exception when trying to connect to certain remote Orocos items (we had this happen specifically for methods with parameters).

The solution is to forcibly specify the endPoint parameter to the name server. In the omniorb.cfg file on the computer running the name server, add (for the example networks above) 

endPoint = giop:tcp:10.0.10.14:
where 10.0.10.14 is the IP adrs of that computer. This forces the name server to publish end points on the wireless network first. Despite this, it will still publish the wired interface but it will come after the wireless. Specifying the endPoint parameter on the command line (instead of the config file) will not work, as then the name sever publishes the wired network first, and then the wireless network second.

If the above still does not work, then set the endPoint parameter in all computer's config files (note that the end point is the IP adrs of each computer, so it will be (say) 10.0.10.14 for the computer running the name server and the deployer, and (say) 10.0.10.21 for the computer running the GUI). This will force everyone onto the wireless network, instead of relying on what the name server is publishing.

To debug this problem see the debugging section below, but after starting the name server you will see it output its published endpoints (right after the configuration dump). Also, if you get the lockup then adding the debug settings will cause the GUI or deployer to output each message and what direction/IP it is going on. If they have strayed on to the wired network it will be visibly obvious.

NB we found that the clientTransportRule and serverTransportRule parameters had no affect on this problem.

NB the above solution works now matter which computer the name server is running on (ie with the deployer, or with the GUI).

Debugging

Add the following to the omniorb.cfg file 

dumpConfiguration = 1
traceLevel = 25
and get ready for lots of output.

See also

[1] http://people.mech.kuleuven.be/~orocos/pub/stable/documentation/rtt/current/doc-xml/orocos-components-manual.html#id479277

ACE/TAO http://www.cs.wustl.edu/~schmidt/TAO.html

OmniORB http://omniorb.sourceforge.net/