[omniORB] educate me ...

[Richard Hardgrave]

	Thanks for all the tips, but I am going to try to
preserve the current architecture and just replace Iona's
Orbix ORB.  So we don't have to be concerned with concurrency,
we have a manager servant for all the CLIPS servants.  When
a request comes from the client (a standard, session-based,
multi-threaded, C++ server), the manager finds an available
servant to run the CLIPS interpreter and hands the client
its object reference.  The manager is, then, out of the loop
until it gets notified, from the client, that the session is
over.  The client/server "roles" actually get reversed (an
approach I was not the designer of and have had issues with)
after the initial connection is made.  The CLIPS servant
becomes the client and the original client goes into an
event-response loop until the production system is ready
to give its final answer.
	Basically, I'm just trying to find the most straight
forward replacement ORB for what we need to do.  The issues
I, most likely, will be dealing with are how much I might
need to change our IDL such that it does the same things in
omniORB CORBA.  The Orbix ORB is CORBA 2.2.  I know we have
an 'orbixd' daemon running, but I doubt that it's necessary.
We never use any Implementation Repository functionality. I
believe one of the conveniences it gave us (we thought we
might need but didn't) was the ability to start up additional
servants (unique processes, not additional threads) on demand.
	I'll probably be creating a prototype just to test
the communications and session transitions between a dummy
client and servants, initially without CLIPS - later with it.
It's just that I'm such an novice with CORBA that I don't yet
know what's the most elegant way to implement what was done
in Orbix CORBA or how much of what was done is non-standard
CORBA.  (I know the Implementation Repository is non-standard.)
	Perhaps, the BOA compatibility is also something I
need to look at very closely.

> You will need to create a process that is linked with both CLIPs
> and omniORB, and that process needs to initialize the omniORB
> library and start listening for requests. 

These are the object servants - 30 of them to start ...
Even under the heaviest loads, we've never seen more than
5-10 being used at once.

> You may need mutexes to serialize access to clips.
> 
We use a complete, autonomous, CLIPS environment for each
client thread.

Regards,

Richard Hardgrave

> From cobrien@saltmine.radix.net Tue May 15 12:55 CDT 2001
> From: "Cary O'Brien" <cobrien@Radix.Net>
> Subject: Re: [omniORB] educate me ...
> To: hardgrav@ttd.teradyne.com (Richard Hardgrave)
> > 
> > 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
> 
> Hmmm  CLIPS...  I was just thinking about this last week...
> 
> > (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.
> > 
> > 	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"?
> > 
> 

> 
> One idea to speed this up would be to use OmniORBPy (python
> interface to OmniORB) and a python interface to CLIPS that
> I found at:
> 
>    http://starship.python.net/crew/gandalf/DNET/AI/
> 
> If this (clips<->python) works you should be able to get
> things up and running pretty quickly.
> 

> -- cary
> 
> > Regards,
> > 
> > Richard Hardgrave
> > 
>