Middleware Design and Implementation for Networked
2.2 Middleware Solution Space
General-purpose CORBA implementations like TAO [] offer generic CORBA implementations, whose feature sets are determined a priori. Furthermore, faithful implementation of the entire CORBA standard increases the number of features supported by ORBs and hence results in increased footprint for the application. In the case of memory-constrained networked embedded applications, this can become prohibitively expensive.
We instead want to get “only” the features that we need. The selection of features for our special-purpose middleware implementation was strictly driven by the unique requirements of the application domain. Two approaches to developing special-purpose middleware must then be considered:
• Top-down: subdividing existing general-purpose middleware frameworks, e.g., TAO []
• Bottom-up: composing special-purpose middleware from lower level infrastructure, e.g., ADAPTIVE Communication Environment (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
Richard Zurawski/Networked Embedded Systems K_C Finals Page -- #
2-6 Networked Embedded Systems
TABLE . Challenges and Potential Solutions
Challenge Framework
Infrastructure reuse ACE, TAO
Real-time assurances Kokyu, TAO
Robust DOC middleware TAO, e∗ORB Reduced middleware footprint UIC-Core, e∗ORB Simulated real-time behavior (TAO? Kokyu?)
are close to those offered by a general-purpose middleware implementation. In this case, provided policy and mechanism options can be adjusted in the general-purpose middleware to fit the require-ments of the application. In general, this has been the approach used to create and refine features for real-time performance in TAO.
On the other hand, if the number or kinds of middleware features required differs signifi-cantly from those available in general-purpose middleware, as is the case with many networked embedded systems applications, 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 ele-ments [,] than trying to extract the appropriate subset directly from a general-purpose middle-ware implementation.
Modern software development relies heavily on reuse. Given a problem and a space of possible solutions, we try first to see whether the problem can be solved directly from an existing solution to a similar problem. Taking this view, we compared the challenges described in Section .. to existing middleware solutions, as shown in Table ..
TAO [,] and e*ORB [,] appeared to be the most suitable candidate solutions based on the requirements of our target application described in Section ... TAO is a widely used standards-compliant ORB built using the ACE framework [,]. In addition to a predictable and opti-mized [,] ORB core [], protocols [,], and dispatching [,] infrastructure, TAO offers a variety of higher level services [,]. e*ORB is a customized ORB that offers space-efficient implementation of a reduced set of features, with a corresponding reduction in footprint.
2.2.1 Problem: We Get More and/or Less Than We Need
Unfortunately, faithful implementation of the CORBA standard increases the number of features supported by TAO, e*ORB, and other similar CORBA implementations and hence results in increased footprint for the application. In the case of memory constrained applications, this becomes prohibitively expensive.
Although ACE reduces the complexity of the programming model for writing distributed object-oriented applications and middleware infrastructure, it does not “directly” address the challenges of real-time assurances, reduced footprint, or inter-operation with standards-based distribution mid-dleware. Kokyu [] is a low-level middleware framework built on ACE, for flexible multi-paradigm scheduling [] and configurable dispatching of real-time operations. Thus, Kokyu can supplement the capabilities of another DOC middleware framework, but cannot replace it.
The UCI-Core approach supports different DOC middleware paradigms. It offers significant reuse of infrastructure, patterns, and techniques by generalizing features common to multiple DOC middleware paradigms and providing them within a minimal metaprogramming framework, thus also addressing the challenge of reducing middleware footprint. However, it is unsuited to meet other challenges described in Section .., e.g., it does not directly support real-time assurances or simulation of real-time behavior.
Richard Zurawski/Networked Embedded Systems K_C Finals Page -- #
Middleware Design and Implementation for Networked Embedded Systems 2-7
nORB ACE
Network programming Primitives Patterns
Portability
Kokyu Dispatching model
Real-time QoS assurance
Priority lanes
TAO
IDL compliation strategies ORB concurrency patterns ORB core mechanisms
UCI-Core Minimum ORB
feature set
FIGURE . Reuse from existing frameworks.
2.2.2 Solution: Use a Bottom-Up Composition Approach to Get “Only” the Features That We Need
Figure . illustrates our approach. The selection of features for our special-purpose middleware implementation was strictly driven by the unique requirements of the application described in Section ...
We initially considered a top-down approach, to avoid creating and maintaining an open-source code base separated from TAO. However, this approach proved infeasible due to several factors. First, the degree of implementation-level interdependence between features in TAO made it difficult to separate them. Second, the scarcity of mature tools to assist in identifying and decoupling needed vs.
unneeded features made it unlikely we would be able to achieve such a top-down decomposition in a reasonable amount of time. 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, which led to the development of nORB [],∗starting with the ACE framework and reusing as much as possible from it with trans-parent refactoring of some ACE classes to avoid unneeded features. By building on ACE, we reduced duplication between the TAO and nORB code bases, while achieving a tractable development process.
As in TAO, ACE components serve as primitive building blocks for nORB. Communication between nORB endsystems is performed according to the CORBA [] model: the client side mar-shals the parameters of a remote call into a request message and sends it to a remote server, which then demarshals the request and calls the appropriate servant object; the reply is then marshaled into a reply message and sent back to the client, where it is demarshaled and its result returned to the caller. Although we did not retain strict compliance to the CORBA specification, wherever possible
∗nORB is freely available as open-source software at http://deuce.doc.wustl.edu/nORB/
Richard Zurawski/Networked Embedded Systems K_C Finals Page -- #
2-8 Networked Embedded Systems
we reused concepts, interfaces, mechanisms, and formats from TAO’s implementation of the CORBA standard.
2.2.3 Problem: No Explicit Support for Temporal Coordination in the Simulation Environment
As the last row of Table . suggests, none of the potential middleware solutions we found was able to support the kind of temporal coordination between simulated and actual infrastructure that is needed in the simulation environment described in Section ...
Because TAO is open-source, it would be possible to integrate special-purpose mechanisms that intercept GIOP messages exchanged between simulated nodes, and perform accounting of simulation time whenever a message is sent or received. However, TAO does not explicitly address time-triggered dispatching of method invocations, which also must be subject to simulation time accounting.
Kokyu is designed for time- and event-triggered dispatching, but does not intercept messages exchanged through the ORB without transiting a dispatcher. Therefore, neither TAO nor Kokyu alone is able to provide the kind of temporal coordination needed in the simulation environment.
2.2.4 Solution: Virtual Clock Integrated with Real-Time Dispatching and Distribution Features
In the target system, both time-triggered local method invocations and remote method invocations must be dispatched according to real-time constraints. Those constraints and the corresponding tem-poral behavior of the application and middleware must be modeled and enforced effectively in the simulation environment as well.
To support both the target and simulation environments, we integrated a dispatcher based on the Kokyu model with distribution features based on TAO, in nORB. We then used the dispatcher as a single point of real-time enforcement, where both local upcalls and method invocation request and reply messages are ordered according to dispatching policies. Within that single point of control, we then integrated a virtual clock mechanism that is used only in the simulation environment, to enforce both causal consistency and real-time message and upcall ordering on the simulation’s logical time-line.