Components & Aspects for Embedded Middleware

Abstract

Distributed, real-time, embedded (DRE) systems frequently need to satisfy complex requirements, and the implementations of such systems need to deal with crosscutting concerns including performance, predictability, concurrency, and memory constraints. DRE systems must also be configurable for different scenarios, enabling lower-cost and speedier development and deployment. Component-based software development (CBSD) and aspect-oriented programming (AOP) are two approaches that promise to dramatically improve the modularity and configurability of DRE systems.

Our research will lead to an improved understanding of (1) how crosscutting concerns can be modularized across a DRE application and middleware boundaries and (2) how CBSD and AOP interact with typical real-time requirements and scale to support DRE middleware product lines. We are using four main tools in our research. RTZen (a real-time CORBA 2.3 ORB) and RTJava provide the middleware and real-time features needed in DRE applications. AspectJ (an aspect-oriented extension to Java) provides language support for modularizing the implementation of crosscutting concerns. Finally, Jiazzi (a component language for Java, created at Utah) provides the management of the various components in the system. Using these tools, our research goals are to support both component-like encapsulation and controlled exposure to aspects, to enable type-checking within composed systems, and to allow flexible middleware configuration. Accomplishing these goals will mean addressing performance, predictability, concurrency, and memory-capacity concerns, placing industry-quality middleware in the hands of DRE developers.

Progress

I have been attempting to refactor RTZen for RTSJ aspect. I am converting all the memory allocations to be heap allocations (effectively removing support for RTSJ). Then, RTSJ can be woven in with an aspect file. Originally, I debated whether I should weave in RTSJ or "weave out" them. The current approach rolls back the realtime compatibility. Then, there are aspects that weave in the realtime compatibility. This may seem a little backwards, but I found the advantages out-weighed the disadvantages.
Advantages:

Starting from a non-RTSJ-compliant source should make simulated testing easier.
Many embedded devices are not realtime constrained.
The "clean slate" should be based on proven Java compilers, frameworks, and VMs.
Types are clean. If done in reverse (i.e., taking RTSJ-compliant to non-realtime), the resulting memory allocations would lose their typeness.

Disadvantages:

Each allocation statement type requires a matching aspect.
The advice file is somewhat fragile because of the specific aspect.
Advising array allocations not directly possible in AspectJ.

Here is the current archived work.

Additionally, I have been working on some theories about features.


Copyright © 2001-2006 Intelligent Algorithmic Solutions and Sean Walton	eMail