Using CORBA
Table of Contents
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:
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
See also
ACE/TAO http://www.cs.wustl.edu/~schmidt/TAO.html
OmniORB http://omniorb.sourceforge.net/