With the advent of real ubiquitous environments, new methodologies to develop distributed applications need to be investigated and developed. Those environments tend to be ad-hoc ensembles of co-located devices which change over time. Nonetheless, the different components need to communicate with each other. Many middleware solution have been proposed before to address this issue, but to our knowledge none is explicitly tailored to the needs of teaching and research within heterogeneous and dynamic smart environments. In particular, while developing new technologies for adaptive systems supporting users in real ambient environments, the underlying middleware needs to be as flexible as possible. This results from the fact that the architecture of such systems itself is subject to frequent changes. To support our research in this area, we developed our own middleware system – the helferlein-system.

The helferlein system satisfies the following nine requirements which we identified:

1. Ad-hoc connectable: In particular in smart meeting rooms, devices are added and removed quite frequently, because people carrying them enter and leave often. Therefore, we need an infrastructure that supports ad-hoc assemblies.
2. Loosely coupled: We would like to connect the different objects only loosely. There must be no need to know the interface of all devices completely. And the communication should not be established directly between the different devices, but rather by using the middleware.
3. Multi-Paradigm Communication: While developing distributed systems the choice of the communication paradigm influences the design. Different communication paradigms should be offered by the middleware: e.g. remote procedure calls, asynchronous event distribution, persistence, ...
4. Human readable protocol: In particular while debugging and while teaching distributed systems, human readable protocols are a big advantage.
5. Persistence: If needed, a state-full representation should be supported, in contrast to purely event based approaches. This allows for example the integration of non-real time components and to observe the full state of the environment.
6. Extensibility: A middleware should not only be open to new devices, but also to new patterns of communication.
7. Debug-ability: It is sometimes necessary to observe the communication between different devices on the byte level. Therefore, we need a simple, human readable and still formally specified protocol.
8. Platform independence: To be able to use different operation systems with different advantages, we need a platform independent infrastructure.
9. Programming language independence: We also need to be able to use different languages: it is usually simpler to talk to low-level devices using C or C++. On the other hand, we would like to use the full power of languages like Haskell and Prolog.