[omniORB] Implementation Repository

[Thomas Lockhart]

> The ImR should only use standard features that can be implemented with
> all ORBs. All the other ImR implementations I've seen involve magic
> behaviour by POAs and ORBs, in response to being started by the ImR. I
> think that's a bad thing since it requires ORB changes, and because it
> makes it much harder (impossible, usually) to use more than one ORB
> implementation.

OK. I'm most familiar with TAO which is done as a Bad Thing, and was 
annoyed that I don't have an IDL interface to interact with the ImR. So 
at least exposing the ImR with IDL will be a Good Thing for writing 
programs to manage environments. Which is what I want to do...

In a TAO-implemented server, there is explicit code supporting the ImR 
in the sense that a second POA with explicit policies must be created. 
One annoyance is that TAO does not expose any interface for a server to 
detect whether it was started by the ImR, but servers started by an ImR 
do behave somewhat differently than those started standalone and so have 
some "mode-specific" code.

> The way I see it working is to have a set of ImR interfaces
> implemented in the ImR itself, and a control interface that is
> implemented by servers that are started by the ImR. When the ImR
> starts a server, it passes a reference to itself via an -ORBInitRef
> command line argument. The newly started server can then call back to
> the ImR passing it the control object. The control object would have
> operations to start and stop particular objects, and exit the process.

Hmm. I haven't yet tried supporting multiple server objects in the same 
process via the ImR. As a process starts up it could create multiple 
objects, which each register themselves as "running" in the ImR. I 
haven't thought through what needs to happen to manage these objects 
*and* the containing process, when the ImR may not know that there is an 
explicit relationship between an object and the containing process. 
Sounds ugly, but maybe y'all have this already worked out for other use 
cases :/

I'm wondering if implementing the ImR interface on a server using 
generic CORBA mechanisms can lead to trouble with resource conflicts 
depending on threading policies etc. The ImR should be able to kill a 
moderately misbehaving server (at least at the request of a 
well-intentioned client), and if one is using the wrong threading policy 
then another client could indirectly lock up the ImR interface.

                   - Tom