A generative programming framework for adaptive middleware

Component middleware technologies such as the CORBA component model (CCM), J2EE (Alur et al., 2001), and .NET, were developed to address many limitations like interdependencies between services and object interfaces, limited re-use, of first-generation middleware technologies such as CORBA 2.x, XML, and SOAP (Snell and McLeod, 2001). These component technologies have addressed a wide range of application domains, but unfortunately for distributed real-time and embedded (DRE) systems, the focus of these technologies has been primarily on functional and not quality of service (QoS) properties. Research on QoS-aware component models such as the CIAO project (Wang et al. 2003) shows that there is a fundamental difference between configuration of functional and QoS properties even within such a unified component model: the dominant decomposition of functional properties is essentially object-oriented, while the dominant decomposition of QoS properties is essentially aspect-oriented. In this paper, we describe how a focus on aspect frameworks for configuring QoS properties both complements and extends QoS-aware component models. This paper makes three main contributions to the state of the art in DRE systems middleware. First, it describes a simple but representative problem for configuring QoS aspects that cut across architectural layers, system and distribution boundaries, which motivates our focus on aspect frameworks. Second, it provides a formalization of that problem using first order logic nfrastructure configuration logic - which both guides the design of aspect configuration infrastructure, and offers a way to connect these techniques with model-integrated computing (Ledeczi et al. 2001) approaches to further reduce the programming burden on DRE system developers. Third, it describes alternative mechanisms to ensure correct configuration of the aspects involved, and notes the phases of the DRE system lifecycle at which each such configuration mechanism is most appropriate.