[omniORB] Using python to dynamically divine the contents of a CORBA (omniORB) interface

[Jeff Frontz]

I'm trying to write a self-maintaining test tool that can be used from
the command line against a server via CORBA (omniORB). To start, I'd
be happy with a tool that could describe the interface(s) that the
server implements (e.g., essentially regenerating the IDL that defined
the interfaces to begin with). From there, I'd grow it into something
that could accept parameters, make the CORBA call, and print the
results.

I know that python has introspection that should make it possible to
not have to write (much) code every time an argument changes or a new
method is added [in the IDL]. But I don't understand enough of the
python binding for omniORB (or enough python) to know how to do this
easily (or whether an infrastructure already exists to do this).

I've inherited some code that I'm trying to morph into my test tool.
The problem is that I don't know how much is something that is stock
omniORB python support and how much is homebrew.

From what I'm seeing, it looks like an omniORB CORBA interface appears

in python as a class (that part seems likely standard). The methods of
said interface appear as members of this class--they are each tuples
with naming that appears to be the method name from the IDL prefixed
with _d_. The input parameters for a given interface method are
described by said method's first tuple element; the second element
describes the return values. Each element is another tuple of tuples,
with each describing a successive parameter.

I'm hoping this reflects the implementation of omniORBpy. Assuming
that it does, are there well-defined routines for
interrogating/manipulating these interface class objects?

Thanks,
Jeff

[note: this was originally posted at stackoverflow
http://stackoverflow.com/questions/8840900/using-python-to-dynamically-divine-the-contents-of-a-corba-omniorb-interface
]

[Duncan Grisby]

Post by Jeff Frontz
I'm trying to write a self-maintaining test tool that can be used from
the command line against a server via CORBA (omniORB). To start, I'd
be happy with a tool that could describe the interface(s) that the
server implements (e.g., essentially regenerating the IDL that defined
the interfaces to begin with). From there, I'd grow it into something
that could accept parameters, make the CORBA call, and print the
results.

Assuming you have the IDL, it would probably be easier to start from the
IDL rather than trying to introspect the generated Python code. You
might like to look at the omniidl documentation:

http://omniorb.sourceforge.net/omni41/omniidl.html


[...]

Post by Jeff Frontz

From what I'm seeing, it looks like an omniORB CORBA interface appears

in python as a class (that part seems likely standard).

It's part of the standard that for interface I, there's a Python
class-like thing named I, but there is not much else required in the
standard.

Post by Jeff Frontz
The methods of
said interface appear as members of this class--they are each tuples
with naming that appears to be the method name from the IDL prefixed
with _d_. The input parameters for a given interface method are
described by said method's first tuple element; the second element
describes the return values. Each element is another tuple of tuples,
with each describing a successive parameter.

That's an omniORBpy implementation detail. It is unlikely to change in
future, but it could do.

Post by Jeff Frontz
I'm hoping this reflects the implementation of omniORBpy. Assuming
that it does, are there well-defined routines for
interrogating/manipulating these interface class objects?

The data is there for omniORBpy's own purposes. It's not intended to be
used by other things, although there is nothing that would stop you. As
an implementation detail of omniORBpy, there's no stand-alone
documentation of the data. It's only documented inside the omniORBpy
source, in a combination of the IDL compiler back-end and the C++ code
that makes use of the type descriptor tuples.

Perhaps you could give an example of the kinds of things your code needs
to do?

Cheers,

Duncan.