A C++ IoC component framework for CORBA, Event, DDS, RTC, and SDR/JTRS-SCA applications
kji...@gmail.com
Event/Notification, OMG-DDS, OMG-RTC, and JTRS-SCA/SDR applications
Like it or not, CORBA is commonly known as a complex technology. The
superfluous CORBA Component Model (CCM) further raised its entry
barrier significantly. The CCM has in fact became a synonym of
dreadful costs and risks, inherent vulunerabilities, and vendor lock-
in. Its Avalon and old pre-3.x EJB resembling techniques (such as the
component context injection, invasive control, and home interface)
have largely been abandoned by the mainstream software industry for
years. Yet, as the old tactic of "if you can't convince them (users),
confuse them!", CCM is still constantly being hyped with buzzwords
such as "leading edge", "advanced", "distributed", "real-time", and
"mission-critical". The favorite equation in defending the heaviness
and complexity claimed that advanced component frameworks for
distributed real-time missioncritical applications were unavoidably to
be heavy, complex, and certainly not meant for average developers and
domain users. Their simplifications could only yield functionality
stripped inferior editions.
In J2EE world, the inversion of control (IoC) and plain-old-java-
object (POJO) component model has been proved to be much superior than
the heavyweight old pre-3.0 EJB with regarding to straightforwardness,
flexibility, and openness. Although their significance had long been
downplayed in the CORBA world by CCM advocates, there is no reason
that these techniques and a plain-old-C++-object component-model could
not be applied in CORBA C++ applications.
PocoCapsule/C++ for CORBA is a framework for component-based C++ CORBA
applications. This framework is based on the open source (under GPL)
PocoCapsule/C++ IoC-and-DSM framework. As out-of-the-box solutions, it
includes assembly and deployment models for the following CORBA
applications:
* CORBA POA server applications. (see examples/corba/poa-server)
* OMG-Event/Notification Service. (see examples/corba/event)
* OMG-DDS applications. (see examples/corba/dds)
* OMG-RTC applications. (see examples/corba/rtc)
* JTRS-SCA applications. (see examples/corba/jtrs-sca)
Based on the plain-old-C++-object support of the underlying IoC
container (e.g. PocoCapsule/C++ IoC), the PocoCapsule/C++ for CORBA
does not enforce any propritary component model. Instead, any C++
objects, such as CORBA remote/local object stubs, POA servants
(extended from IDL skeletons), native TIE servants, etc. are all valid
components. Therefore, it doesn't introduce any CCM-like compliant
barrier and is able to seamlessly and immediately reuse legacy
implementations of POA servants, event suppliers/consumers, DDS
writters/readers, and JTRS-SCA devices/resources, etc. without cost
and resky refactoring and reengineering.
In additional to above out-of-the-box solutions, facilitated by the
underlying domain-specific-modeling (DSM) support (of PocoCapsule/C++
DSM), the PocoCapsule/C++ for CORBA can easily be extended and
customized to support diverse of user-defined application assembly/
deployment models (DSM) that express specific applications at higher
abstraction levels (see <http://www.pocomatic.com/docs/whitepapers/
dsm>).
PocoCapsule/C++ for CORBA is designed with realtime and embedded
applications in mind. Although able to seamlessly support ORBs and
component implementations that heavily use templates, exceptions, STL,
RTTI etc., the PocoCapsule/C++ for CORBA runtime itself is completely
free from these sophisticated and heavyweight C++ sugars. Therefore,
it is able to be portable to the most rigorous realtime/embedded
systems (such as VxWorks and Symbain) where only the primitive and
lightweight C++ features are feasible. For typical applications,
PocoCapsule/C++ for CORBA has a rather small footprint (~200Kbytes on
Linux and VxWorks), negligible generated code, and absolutely zero add-
in performance overhead and realtime latency/jitter.
Contrary to the CCM equation, PocoCapsule/C++ for CORBA is able to
significantly lower the entry barrier of C++ CORBA application
developments without sacrificing, but rather strengthening, its
features and productivity. The learning curve of PocoCapsule/CORBA
(together with DDS, Event/Notification, RTC, and JTRS-SCA, etc.) is
not only shorter than CCM, but also shorter than plain old CORBA, and
even shorter than socket API. As some of CORBA advanced but hard to
use features become easily accessible, PocoCapsule/C++ for CORBA
virtually extends the feasible feature set of the underlying CORBA
implementation to average business logic developers.
With its low entry barrier, superior features, non-intrusiveness and
flexible customizability, PocoCapsule/CORBA is an ideal framework for
enterprises to build mission-critical CORBA applications in a starting
small and thinking big incremental approach.
Articles:
* <http://www.pocomatic.com/articles.html>
Examples:
* <http://www.pocomatic.com/docs/cpp-examples/#corba>
Download:
* <http://www.pocomatic.com/products.html>
Information:
<pr...@pocomatic.com>
Gary Duzan
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
kji...@gmail.com
> 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 ....
> Motorola H&NM- Hide quoted text -
>
> - Show quoted text -