Re: omniORBpy implementation principles

On Tuesday 11 October, "J rgen" Weber wrote:

> I am playing with the idea of writing an IDL to COBOL mapping for
> TinyCOBOL. Therefore I am interested how the implementation of
> omniORBpy is done. Please forgive that I chose to ask here instead of
> digging deep in its code.
> 
> I can imagine three ways:
> 
> Write everything from scratch using only a small C part for socket
> handling. Ouch.

I don't imagine that would be a good idea...

> From the IDL generate a C++ Servant that fills COBOL data structures
> and delegates to COBOL. This seems the most easy way to me, but it
> unnecessarily creates temporary C++ stub objects, only to pass them
> through to COBOL.

You're going to have to have some C++, and since COBOL is a compiled
language, it's maybe not such a bad idea. omniORBpy doesn't work that
way because it would be really bad to have to compile C++ for each
interface when Python itself is not compiled.

> Somehow hook into omniORB (portable(?) interceptors?)  and delegate
> either the IIOP stream to COBOL (but GIOP parsing in COBOL should be a
> mess and why reinvent the wheel?) or publish the CDRInputStream to
> COBOL (and have COBOL call read_short() and friends), i.e. somehow
> replace the code that feeds the POA. No idea however, how this could
> be done.

Interceptors, portable or otherwise, can't do that.

However, omniORBpy works kind-of along those lines. Marshalling of data
is based on TypeCodes represented in Python tuples. The code that
actually does the marshalling is written in C++, using the Python C API
to access Python data. Look at modules/pyMarshal.cc in the omniORBpy
distribution to see the code. You might be able to do a similar thing
for COBOL.

Aside from the marshalling code, you need to handle objects and servants
and things like that. omniORBpy works by maintaining C++ "twins" for
Python objects, so the C++ bits of omniORB can use them.

The way omniORBpy works relies on the internal structure of omniORB. The
alternative would be to use DII and DSI, and do everything via standard
APIs. That is about the same complexity but slower because you have to
deal with Anys for all the type management. It does have the advantage
that it would work with any C++ ORB, not just omniORB.

Cheers,

Duncan.

-- 
 -- Duncan Grisby         --
  -- [email protected]     --
   -- http://www.grisby.org --