[omniORB] Implementation Repository

[pesco@gmx.de]

--RnlQjJ0d97Da+TV1
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Wed, Jan 15, 2003 at 01:53:09PM +0000, Duncan Grisby wrote:
> On Tuesday 7 January, Thomas Lockhart wrote:
> 
> > Hmm. I'd like to try this, but would like the discussion to be on-list 
> > to see if we can get one or two other folks volunteering before we crank 
> > up for the work. OK?
> 
> Yes, I think the discussions should be on the list.

:) This is volunteer one.


> A quick summary of my thoughts on the matter:
> 
> The ImR should only use standard features that can be implemented with
> all ORBs.

Wonderfull.


> 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.

Can you elaborate that? I've looked at the way MICO does it and they have
their PERSISTENT POAs register automatically with the ImR if an ORB
arg to that effect is given. I think that's actually a nice idea. But
you're right that it should be possible to do it explicitly to support
any ORB.

But speaking of that, there's the problem of how to create the
necessary references. The servers must "imbue" their objects' keys
onto the ImR reference. Is there any way to do that without ORB-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.

Hm, why would the ImR want to autostart particular objects? This can
be handled by a servant activator or similar in the server, no?
Managing each individual object would have the benefit that the ImR
doesn't need to construct the object references from host/port or
such.


> If all of this is well defined, it should be easy to use it with any
> ORB. There's plenty of scope for support libraries, too, so
> applications don't have to deal with it all directly.

I'll attach the IDL I have for my ImR so far. Please bear with me if
it is very simplistic, but I designed it to match my current personal
requirements.


Regards,
Sven Moritz

--RnlQjJ0d97Da+TV1
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="omniImR.idl"

#include <corbaidl.idl>

module omniImR {

    interface ImR {

        struct Entry {
            CORBA::OctetSeq adapter_id;
            string start_command;
            string host;         // Empty if adapter is not running.
            unsigned short port; // 0 if adapter is not running.
        };

        exception Unknown_Adapter {};
        exception No_Command {};

        void add_entry(in CORBA::OctetSeq adapter_id, in string start_command);
        void remove_entry(in CORBA::OctetSeq adapter_id);
        Entry get_entry(in CORBA::OctetSeq adatpter_id)
            raises(Unknown_Adapter);

        void start(in CORBA::OctetSeq adapter_id)
            raises(Unknown_Adapter, No_Command);

        void notify_running(in CORBA::OctetSeq adapter_id,
                            in string host, in unsigned short port);
        void notify_stopped(in CORBA::OctetSeq adapter_id);
    };

};

--RnlQjJ0d97Da+TV1--