RUNES Middleware
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.