[Pipet Devel] Choice of ORB implementations

Brad Chapman chapmanb at arches.uga.edu
Sat Apr 1 12:24:16 EST 2000


Hello all;
    Since we are starting to get into CORBA stuff (Jarl and I are 
going to start working soon on the defintion layer to brokering layer 
CORBA implementations) I wanted to discuss about what ORB 
implementation(s) we should be using to design this system. I guess 
there are two big competitors, omniORB and ORBit. From what little I 
know about speed, these seem to be fast compared to other freely 
available implementations, and both seem to be compliant with 
licensing (from what little I know about that as well).
    However, I think we have some problems if we decide to go with 
either of this independently. Let me give the point by point on the 
things I'm thinking of. If I am being idiotic on any of the following, 
please call me out :-)

1. Bindings: From what I figure, we should need C and python bindings 
for the ORB we use. ORBit, of course, is all about C, and has python 
bindings under development (but still quite early in development). 
omniORB has really nice python bindings, but does not have C bindings 
as far as I know, which is a serious problem.

Advantage: ORBit

2. Threading: I've been trying to read up and learn as much as I can 
about CORBA since I'm really green with it, but still want to 
implement a good distributed system like we need here. Thinking about 
what our needs will be for talking between definition layers (more on 
this in my next post), I think a multithreaded server implementation 
will be a good way to go. I still have a lot to learn about threading, 
but for what I have played with on the current middle I like python's 
threading support and from my reading I like the setup of a threaded 
server. 
    omniORB has support for multithreaded servers, and from what I can 
tell from the list server it has been tested in a number of 
application. From reading the ORBit to-do list, it seems like thread 
safety is not yet implemented (although I hope I can be proven wrong 
on this).

Advantage: omniORB

3. Naming service: It seems like using the naming service might be a 
good bet for maintaining a list of available VSH implmementations (I 
think Jeff has described this before as a kind of domain name service 
that maps vsh implementations to their names (ie. Jeff's computer)). 
As far as I can tell, both ORBit and omniORB have good naming service 
support, but I don't know enough about it to say more.

Advantage: tie (because I am too uninformed to make a decision :)

Alright, that is my list for now. I'm throwing this out because I 
really want to hear people's opinions, not because I am at all an 
expert on this stuff. I'm just trying to think through this and would 
like everyone's help. So:

Are there considerations we should be taking into account?
Are there other orb implementations we should be considering?
Does anyone see a workaround for the threading and binding problems I 
mention above? How can we reconcile this? Do we need, ugh, two 
ORB implementations? 
Other ideas on this?

Thanks for listening.

Brad





More information about the Pipet-Devel mailing list