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

[kjin101 at gmail.com]

On Nov 15, 10:12 am, mgi... at motorola.com (Gary Duzan) wrote:
>    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:
>

Firstly, I very appreciate your input and careful code example.

Secondly, I would recommend you to take some readings on what and why
of IoC frameworks (for instance, my articles: <http://
www.pocomatic.com/docs/whitepapers/ioc>). The goal of IoC framework in
particular and component-based frameworks in general is to let users
avoid exactly what you suggested here, namly writting factories,
registries, wrappers, as well as dependency/scope/lifecycle controling
code. These plumbings and their boilerplate code are shifted into the
underlying IoC (or CBD in general) framework. This allow users
(especially domain users) to focus on writting business logic and
deploy their applications in high level declarative models. There are
othre more profound impliciations of using this declarative deployment
solution than resorting to low level design patterns. For instance, it
could support domain-specific-modeling (DSM) and model-driven-
engineering (MDE) without the nightmare of massive code generation of
traditional CASE or MDA tools (see my article: <http://
www.pocomatic.com/docs/whitepapers/dsm>).

Thirdly, you have some misunderstandings on the concept of plain-old-
object. Your IoCModule subclassed objects are indeed plain-old CORBA
objects, but a special kind of plain-old objects.  A qualified IoC
framework can't enforce components to be a special kind of objects
with ad hoc interface pre-defined by the framework. Instead, it should
accept any plain-old-objects as components regardless their base
classes. PocoCapsule/C++ IoC container supports almost any objects as
components without mandating their base classes and without even
assuming they are CORBA servants or stubs. These objects could be
existing legacy or third party implementations that one may not even
has source code to change their hierarchy, and/or too cost to create
and maintain boilerplate wrappers for them in a massive
application.

Hope this clarifies ....

> ===========================================================================
> 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- Hide quoted text -
>
> - Show quoted text -