[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