Document Type

Technical Report

Publication Date

2003-12-04

Filename

wucse-2003-78.pdf

Technical Report Number

WUCSE-2003-78

Abstract

The rather large feature set of current Distributed Object Computing (DOC) middleware can be a liability for certain applications which have a need for only a certain subset of these features but have to suffer performance degradation and code bloat due to all the present features. To address this concern, a unique approach to building fully customizable middleware was undertaken in FACET, a CORBA event channel written using AspectJ. FACET consists of a small, essential core that represents the basic structure and functionality of an event channel into which additional features are woven using aspects so that the resulting event channel supports all of the features needed by a given embedded application. However, the use of CORBA as the underlying transport mechanism may make FACET unsuitable for use in small-scale embedded systems because of the considerable footprint of many ORBs. In this thesis, we describe how the use of CORBA in the event channel can be made an optional feature in building highly efficient middle-ware. We look at the challenges that arise in abstracting the method invocation layer, document design patterns discovered and present quantitative footprint, throughput performance data and analysis. We also examine the problem of integrating FACET, written in Java, into the Boeing Open Experimental Platform (OEP), written in C++, in order to serve as a replacement for the TAO Real-Time Event Channel (RTEC). We evaluate the available alternatives in building such an implementation for efficiency, describe our use of a native-code compiler for Java, gcj, and present data on the efficacy of this approach. Finally, we take preliminary look into the problem of efficiently testing middleware with a large number of highly granular features. Since the number of possible combinations grow exponentially, building and testing all possible combinations quickly becomes impractical. To address this, we examine the conditions under which features are non-interfering. Non-interfering features will only need to be tested in isolation removing the need to test features in combination thus reducing the intractability of the problem.

Comments

Permanent URL: http://dx.doi.org/10.7936/K7PK0DH0

Download

Share

COinS