AVAILABLE TOPICS
Building middleware for instrumented environments is not the focus of our research. It is, however, an interesting step on the way. When we started building our instumented environments, we were faceing the decision whether to use an existing software infrastructure or to build our own. We opted for the latter. These are our results so far.
The current focus of our middleware is device management, e.g. device classification, orchestration and communication. We have a stable, working prototype (the device manager) on which we investigate general principles that could also be applied to other resource management tasks, e.g. service lookup and management. The goal is to provide an API which allows application developers to easily use devices in the room without having to worry about hardware, network or driver details.
The task of classifying devices and designing a taxonomy for them is rather
difficult. Especially when taking all possible future (and obviously yet unknown)
devices into consideration. We decided not to try this, but to take a more
pragmatic approach instead. Devices in FLUIDUM are not classified in a hierarchie
or taxonomy, but instead described by a list of their properties. Properties
might include for instance in the case of a digital camera the capability
to take a high resolution photo and the capability to provide a low resolution
video stream. We currently have a description of 13 such properties that cover
all current devices in our instrumented environments. If a device with a new
property needs to be included, the list of properties can easily be extended.
So even a "flux compensator" or a Star Trek transporter can be included in
our system. To make things even more pragmatic, these properties are not just
implemented to provide a description of themselves; they are fully remotely
accessible objects. If we know about the property of a device, we can access
it.
Our current prototype uses a central server, the device manager. Both devices
and applications register with this device manager which serves as a match
maker between them and keeps the applications updated on changes in the devices
currently registerd. Furthermore, we have a proxy server which registers as
an application to the device manager and is capable to answer questions such
as "Which devices can take photos?"
The device manager is running as a command line process on our linux cluster.
It prints out all important information, which is not necessarily well suited
for debugging or exploring the currently connected devices. To fill this gap,
we implemented a GUI, the device manager monitor. This monitor application
connects to the device manager, displays all available devices and enables
the user to browse the devices' parameters, properties, interface, and implementation.
It also offers some simple tools to directly access and use the devices.
A short research video is presenting the device manager and its monitor gui. If you are interested in a demonstration, you can download this movie here.
Some research questions concerning the device manager still need to be solved. We are aware of the fact, that a centralized architecture presents a potential bottleneck and will not scale very well. Although the device manager is running stable without restart for months at a time (i.e. until the computer is rebooted), there is always the chance of a network problem or hardware failure. A second, decentralized version of the device manager (using the same infrastructure and codebase) using peer to peer networks is currently built. A homogenous approach using a centralized server as default and a peer to peer network as fallback solution in case of a failure and automatically repairing and switching back to the central approach will also be investigated. Other issues include device lease, time stamps, device locking, priority handling and authentication/security.
The work described on this page is part of the PhD thesis of Christoph Endres. For feedback or comments, please send email to [email protected].