nORB - Special Purpose Middleware for Networked Embedded Systems
Introduction
General purpose middleware is increasingly taking the role that operating
systems held three decades ago. Middleware based on standards such as CORBA,
EJB,
COM
and Java RMI now cater to the requirements
of a broad range of distributed applications such as banking transactions,
on-line stock trading, and avionics mission computing. Different kinds
of general purpose middleware have thus become key enabling technologies
for a variety of distributed applications. To meet the needs of diverse
applications, general purpose middleware has tended to support a breadth
of features. In large-scale applications, layers of middleware have been
added to provide different kinds of services. However, simply adding features
breaks down for certain kinds of applications. In particular, features
are rarely innocuous in applications with requirements for real-time performance
or small memory footprint. Instead, every feature of an application is
likely to either contribute to or detract from the application in those
dimensions. Therefore, careful selection of features is crucial. As middleware
is applied to a wider range of distributed real-time and embedded applications,
a fundamental tension between breadth of applicability and customization
to the needs of each application becomes increasingly important. To resolve
this tension, special purpose middleware must address the following two
design forces.
-
The middleware should be general enough that common abstractions can be
re-used across different applications in the same domain.
-
We should then be able to make fine-grained modifications to tailor the
middleware to the requirements of each specific application.
To balance these design forces, two approaches to developing special purpose
middleware must be considered:
-
Top-down: sub-dividing existing general purpose middleware frameworks,
e.g., TAO, or
-
Bottom-up: composing special purpose middleware from lower level
infrastructure, e.g., ACE.
Both approaches seek to balance reuse of features with customization to
application-specific requirements. The top-down approach is preferred when
the number and kinds of features required are close to those offered by
a general purpose middleware implementation. In this case strategies can
be selected for, possibly after being added to, the general purpose middleware
to fit the requirements of the application. This has been in general the
approach used to create and refine features for realtime performance in
TAO. On the other hand if the number or kinds of middleware features required
differs significantly from those in available general purpose middleware,
then a bottom-up approach is preferable. This is based largely on the observation
that in our experience lower-level infrastructure abstractions are less
inter-dependent and thus more easily decoupled than higher-level ones.
It is therefore easier to achieve highly customized solutions by composing
middleware from primitive infrastructure elements than trying to extract
the appropriate subset directly from a general purpose middleware implementation.
Clearly, these approaches are complementary. Given a single application
with divergent requirements and an available lower-level infrastructure
framework, it may be better to apply the bottom-up approach as we have
done using ACE to developing a small-footprint real-time ORB middleware
framework called nORB.
nORB - Development Methodology
We used a bottom-up composition approach to get only the features that
we need. We initially considered a top-down approach to avoid creating
and maintaining an open source code base separate from TAO. However, this
approach proved infeasible due to several factors. First, the degree of
implementation-level inter-dependence between features in TAO made it arduous
to separate them.Second, the scarcity of mature tools to assist in identifying
and decoupling needed and unneeded features made it difficult to acheive
the decomposition in a timely manner. Third, absent better tools it was
also infeasible to validate that during refactoring we had correctly retained
functional and real-time properties for the large body of TAO applications
deployed outside our DOC middleware research consortium. Therefore, we
ultimately took a bottom-up compositional approach, starting at the ACE
level and reusing as much as possible from it. By building on ACE, we reduced
duplication between the TAO and nORB code bases, while achieving a tractable
development approach.Figure 1 illustrates our approach. The selection of
features for our special purpose middleware implementation was strictly
driven by the unique requirements of the application.
As in TAO, ACE components serve as primitive building blocks for nORB.
Communication between nORB endsystems is achieved via the CORBA model:
the client side marshalls the parameters of a remote call into a request
object and sends it to a remote server, which then demarshalls the request
and calls the appropriate servant object; the reply is thenmarshalled into
a reply object and sent back to the client, where it is demarshalled and
returned to the caller. Although we did not retain strict compliance to
the CORBA specification, wherever possible we have re-used concepts, interfaces,
mechanisms and formats from TAO and its implementation of the CORBA standard.
Software Installation
nORB requires an installation of ACE and TAO. Even though nORB does not
use TAO, the nORB IDL compiler uses the same front-end module as the TAO
IDL compiler. To download ACE and TAO click
here.
To download nORB, click here.
Building nORB on Unix platforms
Before building nORB, ACE needs to be built. Click
here for instructions on how to build ACE.
Make sure that $ACE_ROOT is set to the appropriate ACE installation
directory. Also ensure that the static library for ACE is built by entering
the following line in $ACE_ROOT/include/makeinclude/platform_macros.GNU.
static_libs_only=1
The following steps should be used to build the nORB library.
$cd nORB
/* nORB is the directory where nORB is installed */
$./autogen.sh
$cd src
$make
The following steps should be used to build the nORB IDL compiler. Note
that this step compiles the front end module files in the TAO IDL compiler,
apart from the back-end module specific to nORB.
$cd nORB
$cd nest_idl
$make
The following steps should be used to build an nORB example.
$cd nORB
/* nORB is the directory where nORB is installed */
$cd examples
$cd Simple
$make
Building nORB on Win32
Make sure that the ACE_wrappers directory and nORB directory are sibling
directories having a common parent.
Before building nORB, ACE needs to be built. Click
here for instructions on how to build ACE.
Using MSVC++, open nORB/src/nestORB.dsw workspace and
build it. This will build the nORB library.
To build the nORB IDL compiler, open nORB/nest_idl/nest_idl.dsw
workspace
and build it. Note that this step compiles the front end module files in
the TAO IDL compiler, apart from the back-end module specific to nORB.
To build an example, open nORB/examples/examples.dsw
and build the appropriate client and server projects.
nORB - Time Simulation
Section 6 of this document explains the
motivation for implementing simulated time in nORB.
To download, the version of nORB with simulated time, please click
here. Note that the above version is not meant for general purpose
use. It contains code which is very specific to the Boeing OEP for which
nORB was originally developed.