[Ace-users] A CORBA IoC Pattern (was Re: A C++ IoC component framework for CORBA, Event, DDS, RTC, and SDR/JTRS-SCA applications)

Gary Duzan mgi820 at motorola.com
Thu Nov 15 12:12:31 CST 2007


   About 8 years ago I was implementing an IoC pattern using
Plain Old CORBA for C++, Java, and Python. The implementation was
fairly straightforward. Each module in the system would implement
an IoCModule interface (mentally substitute "Component", if you
prefer), something like:

===========================================================================
interface IoCModule
{
    readonly attribute string identity;
    void configuration_complete();
};

interface MyModule : IoCModule
{
    readonly attribute MyService service1;
    readonly attribute MyOtherService service2;
    attribute OtherService req1;
    attribute AnotherService req2;
    attribute long conf1;
    attribute string conf2;
};
===========================================================================

   The readonly attributes represent services the module offers,
while the writeable attributes represent the services and configuration
parameters the module requires.

   To pull it all together, we had a configuration manager which
implemented a Registry interface, something like:

===========================================================================
interface Registry
{
    void register(in ModuleBase m);
};
===========================================================================

   On startup, a module starts each service (object) that it
provides, creates an IoCModule servant, stores service references
in the IoCModule servant to be accessed by the attributes, obtains
a Registry reference (generally by resolve_initial_reference()),
passes its IoCModule object reference to register(), and waits.

   The configuration manager then collects the IoCModule references,
obtains the module identities via the identity attribute, consults
the configuration definition, reads the service attributes,
writes them to the appropriate requirement attributes, and calls
configuration_complete() to allow the modules to proceed.

   Our configuration manager was implemented in Python, so we
could just import the IDL stubs and write code vaguely like:

===========================================================================
>>> import MyStubs
>>> 
>>> def config():
>>> 
>>>     modnames = ["ABCD", "EFGH", "IJKL"]
>>>
>>>     mods = collect_registered_modules(modnames)
>>> 
>>>     abcd = mods["ABCD"]
>>>     efgh = mods["EFGH"]
>>>     ijkl = mods["IJKL"]
>>> 
>>>     abcd._set_svc1(efgh._get_svc1())
>>>     abcd._set_svc2(ijkl._get_svc2())
>>>     ijkl._set_svc3(efgh._get_svc3())
>>>
>>>     efgh._set_conf1("yellow")
>>> 
>>>     for mod in mods: mod.configuration_complete()
===========================================================================

   Of course, something similar could be done with XML, an interface
repository, and DII, but Python was a lot easier to get going.
Either way, you could use the same interfaces.

   It doesn't have nearly as many bells and whistles as CCM, but
it is fairly easy to understand, handles multiple languages, and
is portable.

					Gary Duzan
					Motorola H&NM




More information about the Ace-users mailing list