[omniORB] educate me ...

[Gary D. Duzan]

In Message <200105151506.KAA13962@poe.ttd.teradyne.com> ,
   hardgrav@ttd.teradyne.com (Richard Hardgrave) wrote:

=>
=>Hi,
=>	I'm still at the investigation stages of finding a
=>replacement for Orbix in our system. We're currently only
=>using CORBA between a C++ process (client) and the CLIPS
=>(Lisp-based production system)(servant).  We do not yet
=>use CORBA for our networking mechanisms.  BTW, the
=>production system is NOT re-entrant code, so we generally
=>have a whole flock of servants waiting around to service
=>test requests.

   When I did something similar long ago, I set up mutex protected
queues for incoming and outgoing messages, and it seemed to work
fairly well. BTW, what ORB are you using for CLIPS? We actually
linked omniORB (2.2.0) into our CLIPS application and used it to
feed the input queues. We then had the CLIPS event loop call out
to the omniORB code to forward the output. Seemed to work fairly
well.

=>	Orbix appears to use this "orbixd" daemon for both
=>object activation and managing the Implementation Repository.
=>The omniORB 3.0.3 is just a shared library, correct?  I can
=>see omniNames sitting around, waiting for requests, but the
=>omniORB is not an independent process or daemon, right? What
=>occasionally makes me pause is the mention of the "runtime ORB".
=>What sort of distinction is the author trying to make with
=>"runtime"?

   Presumably, the intended distintion is between the pieces needed
to run the application (libraries) and the pieces needed to build
the application (IDL compiler, header files). OmniORB does set up
a number of threads in your application to manage connections and
such, but no external process is required.

					Gary Duzan
					Verizon IT