CORBA: Can a CORBA IDL type be an attribute of another?

Question

Before I start using CORBA I want to know something.

It would seem intuitive to me that you could use an IDL type as an attribute of another, which would then expose that attribute's methods to the client application (using ".") as well.

But is this possible?

For example (excuse my bad IDL):

interface Car{ 
      attribute BrakePedal brakePedal; 
      //... 
}



//then.. (place above) 

interface BrakePedal{ 
      void press(); 
      //... 
} 

//... 

Then in the client app, you could do: myCar.brakePedal.press();

CORBA would seem crappy if you couldn't do these kind of multi-level object interfaces. After all, real-world objects are multi-level, right? So can someone put my mind at ease and confirm (or try, if you already have CORBA set up) if this definitely works? None of the IDL documentation explicitly shows this in example, which is why I'm concerned. Thanks!

Answer 1

Declaring an attribute is logically equivalent to declaring a pair of accessor functions, one to read the value of the attribute, and one to write it (you can also have readonly attributes, in which case you would only get the read function).

It does appear from the CORBA spec. that you could put an interface name as an attribute name. I tried feeding such IDL to omniORB's IDL to C++ translator, and it didn't reject it. So I think it is allowed.

But, I'm really not sure you would want to do this in practice. Most CORBA experts recommend that if you are going to use attributes you only use readonly attributes. And for something like this, I would just declare my own function that returned an interface.

Note that you can't really do the syntax you want in the C++ mapping anyway; e.g.

server->brakePedal()->press();   // major resource leak here

brakePedal() is the attribute accessor function that returns a CORBA object reference. If you immediately call press() on it, you are going to leak the object reference.

To do this without a leak you would have to do something like this:

BrakePedal_var brakePedal(server->brakePedal());
brakePedal->press();

You simply can't obtain the notational convenience you want from attributes in this scenario with the C++ mapping (perhaps you could in the Python mapping). Because of this, and my general dislike for attributes, I'd just use a regular function to return the BrakePedal interface.

Answer 2

You don't understand something important about distributed objects: remote objects (whether implemented with CORBA, RMI, .NET remoting or web services) are not the same as local objects. Calls to CORBA objects are expensive, slow, and may fail due to network problems. The object.attribute.method() syntax would make it hard to see that two different remote calls are being executed on that one line, and make it hard to handle any failures that might occur.