Designing and constructing modifiable middleware using component frameworks

Abstract

Because of the increasingly diverse and dynamic environments in which they must operate, modern middleware platforms need to explicitly support modifiability. Modifiability should encompass change that is both static and dynamic; small scale and large scale. Also, the process of modification should be flexible, easy to perform, and consistency-preserving. To address these needs, this paper proposes a generic component-based modifiability approach, and then uses this approach to build a highly-modifiable middleware framework. The modifiability approach provides design support for building component frameworks-i.e., reusable and extensible component architectures that are targeted at specific domains. In the approach, component frameworks build upon a minimal, technology-independent component model, and can be recursively assembled into more complex frameworks. Our middleware framework-an instantiation of our proposed approach-takes the form of a specific assembly of component frameworks, each of which addresses a distinct middleware-related concern. Our middleware framework supports two styles of modification: First, 'architectural modification' enables large-scale, static, changes, such as customizing the framework to a new application domain or underlying infrastructure. Second, 'system modification' enables changes that are based on specific customisations of the framework; these changes are 2 smaller in scope (e.g. replacing protocol implementations) but are applicable at both deploytime and run-time. A prototype implementation demonstrates the feasibility of our approach and framework, and demonstrates a sufficient degree of supported modifiability. 1 We use the term 'modifiable middleware' rather than 'adaptive middleware' because it is a more general term; in particular, it covers large-scale, static modification, not typically addressed by adaptive middleware.

A generic component model for building systems software

“…This diversity makes it increasingly attractive to approach middleware construction using a framework approach in which tailored platforms can be constructed and customised in terms of a reusable and extensible set of components and CFs. We have built such a framework, called OpenORB [Coulson et al 2002b;Parlavantzas 2005], and have used it to instantiate a number of different middleware platforms as discussed in this section. 7.3.2 Programmer Role Considerations.…”

“…These programmers have applied OpenCom in a diverse range of systems domains including middleware (e.g., OpenORB [Parlavantzas 2005] or ReMMoC [Grace et al 2003]), sensor networks (e.g., Gridkit [Hughes et al 2006]), embedded systems (e.g., RUNES [Costa et al 2007]), programmable networking (e.g., NETKIT ]), and overlay networks (Open Overlays ). Some of these systems have been quite large-for example, OpenORB employs over 40 components and comprises 63,000 lines of code, while ReMMoC employs over 25 components and comprises some 30,000 lines of code.…”

“…We have used this to build a standard CORBA environment [Coulson et al 2002b], a platform for mobile computing [Grace et al 2003] (which employs a Web Services API and a Dynamic Service Discovery CF in the binding layer) and a platform for grid computing . Full details of the overall OpenORB approach are available in Parlavantzas [2005].…”

Refraction

“…In a drive to reduce the complexity of distributed reflective programming and increase the reusability of software components, Parlavantzas et al [18] introduce the concept of a component framework (CF). A CF first enforces a common composition structure and second allows its constituent components to be managed as a single entity.…”

Aspect-Oriented Middleware-Based Real-Time and Embedded Systems Software Process

“…It is addressed from two approaches. One is a dynamic approach, in which the middleware is capable of adapting to the dynamics of the system by reconfiguring itself during runtime [7]. The other is a static approach, which focus on highly customizable middleware architectures [2,8] capable of fulfilling the requirements of different distributed applications.…”