RUNES Middleware

RUNES Layers In the RUNES scenarios, traditional solutions such as CORBA, Jini, .NET etc. are ill-matched because they lack sufficient support for heterogeneity, resource scarcity and dynamism. We therefore take a "clean-slate" approach in the shape of the architecture shown in the figure. The foundation for the architecture is provided by a component-based programming model, provided to the programmer through a middleware kernel API. Since the model effectively captures the essence of the required functionality in only a handful of concepts, the kernel supporting it is simple enough to be easily implementable on any of the devices typically found in our target scenarios. This API is then employed to build, at the upper level, a composition of middleware and application-level software components that offer the necessary middleware and application functionality.

Rather than providing a monolithic middleware "layer", we factor orthogonal areas of middleware functionality into self-contained components that can be selectively and individually deployed and composed according to current resource constraints and application needs. For example, some devices might require only a basic communication component that provides unreliable messaging, whereas others might require a more sophisticated publish-subscribe service that can be realised by composing additional components on top of the base one. Crucially, the set of such components can be updated at runtime to provide the basis of a highly dynamic and reconfigurable system.