On Thursday 15 July 2010 09:23:30 rkraml [..] ... wrote:
> This seems to work although the IOR is cumbersome.

One of the outcomes I'd like to have of the RTT developer's workshop is a
'rttwtf' tool that analyses the current system:
* Can CORBA naming be reached ?
* Which (system) settings may cause trouble ?
* What types/plugins are available ?
*...

>
> My question then becomes: I have two networked Ubuntu 10.04LTS machines:
> one at 192.168.0.1 and another at 192.168.0.2. How to I get these two to
> work as in the two console example?
>
> When reading further I quickly get bogged down in what seems to be
> complicated (to me) xml.

I've seen setups where people only use the XML to load the component, and do
everything else in a program.ops script file. For example:

components.xml:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE properties SYSTEM "cpf.dtd">
<properties>
  <struct name="A" type="OCL::HelloWorld"></struct>
  <struct name="B" type="OCL::HelloWorld"></struct>
</properties>

program.ops:

program MyProgram {
   do connectPorts("A","the_data_port", "B","the_data_port");
   // ...
}

deployer-gnulinux -s components.xml
and then load the program.ops script in the Deployer
(scripting.loadPrograms("program.ops") ) and start it with MyProgram.start()

> I would like to be able to show a simple system
> whereby I can command/control a simple component running on machine A from
> machine B.

We do this through the concept of 'component proxies'. These are components in
your process that represent a component in another process. The idea is that
you first create the two processes with component A in one and B in the other.
In the first process, you then create a 'B' that is a proxy of the real B and
the same in the second process, an 'A' that proxies the real A:

All in the taskbrowser (deployer-corba-gnulinux):

Console A:
deployer-corba-gnulinux
loadComponent("A", "OCL::HelloWorld")

Console B:
deployer-corba-gnulinux
loadComponent("B", "OCL::HelloWorld")

Console A:
loadComponent("IOR_of_B", "IOR")
or:
loadComponent("B", "CORBA")
in case the name service works

Console B:
loadComponent("IOR_of_A", "IOR")
or:
loadComponent("A", "CORBA")
in case the name service works

Now both processes are setup and see each other's component. You can now
simply use the 'classical' deployment commmands. For example, to connect two
data ports, in either console type:

connectPorts("A", "the_data_port", "B", "the_data_port")
And do a Get()/Set() on either side to send data from A to B:
Console A:
A.the_data_port.Set( "new test" )
Console B:
B.the_data_port.Get()

The same principles remain in 2.0, but the ports themselves have changed to be
more flexible and robust.

>
> For now, I need to show a simple example, say a component on A with two
> data ports that takes a double number from B in one port, squares it, and
> sends it back to B out the other port.

We are aware that this is an urgently needed example. I'll add such an example
to the rtt-exercises package for 2.0, using the taskbrowser commands I
described above. Since you're not using RTT yet, It's maybe better to start
using/evaluating 2.0, since it has simplified a lot of concepts in RTT.

Peter

On Jul 15, 2010, at 03:23 , rkraml [..] ... wrote:

> This seems to work although the IOR is cumbersome.

I never use IOR's. They are a pain, but at least we know that your setup works now.

> My question then becomes: I have two networked Ubuntu 10.04LTS machines: one at 192.168.0.1 and another at 192.168.0.2. How to I get these two to work as in the two console example?

They need to find the same name server. Hence the additional parameters to the deployers, shown here

http://orocos.org/wiki/rtt/frequently-asked-questions-faq/using-corba

> When reading further I quickly get bogged down in what seems to be complicated (to me) xml. I would like to be able to show a simple system whereby I can command/control a simple component running on machine A from machine B.
>
> For now, I need to show a simple example, say a component on A with two data ports that takes a double number from B in one port, squares it, and sends it back to B out the other port.

1. Create two components
2. Build them into a shared library on each machine
3. Write a deployer file to deploy component A in one deployer
4. Write a deployer file to deploy component B in the other deployer, and also in the deployer file have component B but as a corba component.
5. Deploy A on one machine, as a corba server in this deployer, and supply the command line parameters for a name server on the other machine(e.g. for omniORB, "-ORBInitRef ...")
6. Deploy B on the other machine, with component A as a corba server in the other deployer, and supply the command line parameters for a name server on this machine

The two components should now be talking to each other.

... we should really generate simple examples for cases like this. It is too much knowledge for a newbie to figure out on their own ... I'll try to take a whack at this while on the plane, or in damn airports ...
S

// for component A in deployer A
  <struct name="ComponentA" type="mynamespace::componentA">
 
	<!-- runs as a Corba server in this deployer -->
	<simple name="Server" type="boolean"><value>1</value></simple>
        <simple name="UseNamingService" type="boolean"><value>1</value></simple>
 
	<struct name="Ports" type="PropertyBag">
              <simple name="PortA" type="string"><value>PortA</value></simple>
              ... 
	</struct>
    ...

// for component A in deployer B
  <struct name="ComponentA" type="CORBA">
 
	<!-- runs as a Corba server in remote deployer -->
	<simple name="Server" type="boolean"><value>0</value></simple>
        <simple name="UseNamingService" type="boolean"><value>1</value></simple>
 
	<struct name="Ports" type="PropertyBag">
              <simple name="PortA" type="string"><value>PortA</value></simple>
              ... 
	</struct>
  </struct>