[omniORB] interpreted clients (Python vs. Corbascript)

[Duncan Grisby]

On Tuesday 15 February, "Renzo Tomaselli" wrote:

> - stub generation for an interpreted environment like Python;
> - an interpreted environment like Corbascript with no definite language
> binding but IR (as another way to get signatures) and DII usage instead.

I think it's important to distinguish three independent issues which
you have wrapped up together in your question.


1. The mapping from IDL to the scripting language

Any programming language, scripting or otherwise, needs a mapping from
IDL declarations to programming language declarations. In C++, the
mapping is huge and complex. In Python, it's small and simple. In
CorbaScript, it's trivial because the language is designed
specifically for CORBA. But it's important to realise that the mapping
is still there.


2. How the language gets hold of IDL declarations

To invoke operations on objects, and to implement objects, the
scripting language must have access to the relevant IDL declarations.
There are two possible places it can look: the CORBA Interface
Repository, or the original IDL. Since an interface repository can be
populated from an IDL file, and an IDL file can be created from the
contents of an interface repository, these two routes are essentially
equivalent.

The choice between the two schemes is therefore one of convenience to
the programmer, rather than a more fundamental technical point. I
think that there are two different classes of use for CORBA-enabled
scripting languages. The first is quick experimentation, often on the
command line, for debugging or prototyping ideas. The second is
full-blown clients or servers which are expected to be used more than
once.

For the first class of use, I think both schemes have their
advantages, and it would be nice if both were supported. Personally, I
think that from the user's point of view, having the IDL file is most
useful, since it contains comments explaining the semantics of the
definitions. Comments are not stored within the interface repository,
so the user has to guess (or refer to the IDL!). Note that since
Python is a dynamic language, it is possible to import a new IDL file
at run-time with the omniORB.importIDL() function. It would be
relatively easy to add a means to import declarations from an
interface repository.

For the second class of use, I believe that pre-compiling stubs from
the IDL is the best solution, since it avoids the overhead of
contacting the interface repository each time the program runs, only
to find that the IDL is the same as it was last time. It also means
that your application is not dependent on the single point of failure
of the interface repository.


3. How the scripting language makes and receives CORBA calls

There are three methods by which a scripting language can make and
receive CORBA calls. In all three, the runtime must check that all
calls adhere to the IDL definitions involved, but note that the route
by which the IDL definitions were acquired is unimportant at that
stage.

The first calling method is to implement an entire ORB in the
scripting language. This is the solution used by Fnorb (which is
another Python ORB). This approach has the advantage that it is not
dependent on any other ORB, greatly aiding portability. It also has
the significant disadvantages that it's a lot of work to design a
whole ORB, and that the resulting ORB will almost certainly be very
slow. (Fnorb actually uses a bit of C code to speed it up, but it's
still 15 to 25 times slower than omniORBpy.)

The second method is to interface with an existing ORB, through the
standard Dynamic Invocation Interface and Dynamic Skeleton Interface.
This means that many different ORBs can be plugged in with, in theory,
no modifications to the scripting language interface. This approach is
much easier than implementing a whole ORB, and (hopefully)
significantly faster. CorbaScript uses this method.

The third and final method is to interface to an existing ORB through
an ORB-specific interface. This avoids the rather ugly DII/DSI
interfaces, leading to cleaner and faster code. Of course, this is not
portable between different ORBs, but since ORBs interoperate nicely, I
don't think that is a particular problem. This is the method omniORBpy
uses.


In summary, none of these decisions make any difference to the things
you can do with a scripting language ORB. They are all just
implementation details.

Cheers,

Duncan.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --