nORB - Special Purpose Middleware for Networked Embedded Systems

Introduction 
nORB - Development Methodology 
Software Installation 
nORB - Time Simulation

 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.
 

  1. The middleware should be general enough that common abstractions can be re-used across different applications in the same domain.
  2. 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:

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.