URBI Developer Blog

Thanks to the interpreted nature of the language, Urbi is very well suited for automatic mappings between interfaces, as it allow to create/delete object methods at run time. We will use this to give a few guidelines on how to design a generic UObject capable of creating a proxy to most distributed object architectures. We will take Corba as an illustration, but other component architectures like WebServices, Microsoft Robotics Studio or RT Middleware could in principle be interfaced using the same approach.

Let’s introduce the ‘corba’ UObject. The ‘init’ constructor will take only one parameter which is the identifier of the Corba object that must be mapped to Urbi. So, to create a new object that will provide a direct and transparent access to the underlying Corba object named “objectId”, you would type:

myobj = new corba(objectId);

This will create ‘myobj’, a clone of the corba UObject which will reflect all exported methods in the Corba IDL. We will limit ourselves to methods taking simple types like numbers, strings or lists, as this is a current limitation of Urbi 1.x (Urbi 2.x will support object oriented structured types when UObject 2.0 will be released).

The ‘init’ constructor of the corba UObject will read the Corba IDL according the the object ID and list all the methods to be mapped to Urbi. Each method will be assigned a unique identifier. There is one generic method caller in the corba UObject which is called ‘genericCall’. This generic method takes two arguments: the identifier of a method from the IDL and a list containing the arguments of the method call itself. For example, let’s say we have a ’setValue(float)’ method in the IDL, which is given the number 3 by the constructor. When the corba UObject constructor reads this, it will create a mapping between ’setValue’ on the Urbi side and the ‘genericCall’ method like this:

function myobj.setValue(v)
{
var result = genericCall(3,[v]);
return result;
}

This Urbi code will be sent to the Urbi engine using the UObject::send method, effectively creating a wrapping for the ’setValue’ method. The ‘genericCall’ method of course is in charge of properly relaying the method call to Corba and get the result in return.

This wrapping will be done for every methods read from the Corba IDL found with the ‘objectId’ Corba object. At the end, ‘myobj’ will mirror the ‘objectId’ Corba object.

The same principle can be applied to other distributed object architectures, as long as it contains an Interface Description Language usable to automatically create bindings in the newly created Urbi object. As a result, you can imagine to control heterogeneous distributed object architectures from Urbi, having all objects interact with each other transparently in a parallel and even-driven way.