seits durch die große Anzahl an unterschiedlichen Sensortechnologien für diese. Deshalb ist es notwendig, ein derartiges System durch eine Systemarchitek- tur geeignet zu strukturieren und auf diese Weise die Erfassung des Kontex- tes von der eigentlichen Anwendung zu trennen. So kann der Entwicklungs- aufwand gesenkt werden, da vorhandene Komponenten zur Kontexterfassung, -modellierung und -verarbeitung leicht wiederverwendet und neue einfach in- tegriert werden können. Eine einheitliche Systeminfrastruktur und Modellie- rungen der Kontextinformationen ist außerdem wichtig für den Austausch von Kontextinformationen zwischen verschiedenen Systemen. 3.3.1   Grundmodelle für die Systeminfrastruktur Für die Systeminfrastruktur gibt es grundsätzlich zwei Modelle. Zentralisiertes Modell   Am einfachsten kann eine Trennung von Kontexter- fassung und Kontextverarbeitung mit einem zentralen Kontextserver umgesetzt werden. Dieser sammelt alle Kontextinformationen von den kontexterfassenden Komponenten ein und stellt sie interessierten Anwendungen zur Abfrage bereit. Für die Abfrage der Kontextinformationen gibt es grundsätzlich zwei Möglich- keiten: Die Anwendung stellt bei Bedarf eine Anfrage an den Kontextserver (pull Modell) oder der Kontextserver benachrichtigt die Anwendung  über die aktuellen Werte (push Modell). Diese Mechanismen können im ersten Fall mit entfernten Funktionsaufrufen (Remote Procedure Calls, RPC) und im zweiten Fall durch das Verschicken von Ereignis-Benachrichtigungen (events) durch den Server oder Callback-Funktionen (Funktionen, die vom Server aufgerufen wer- den, wenn sich bestimmte Kontextdaten geändert habe) realisiert werden. Zur E zienzsteigerung  können  sich  die  Anwendungen  beim  Server  für  die  Arten von Kontextinformationen registrieren, über die sie informiert werden möchten (publish-subscribe Modell). Problematisch bei diesem zentralisierten Ansatz ist vor allem die beschränk- te Skalierbarkeit, bedingt durch eine maximale Anzahl von Anwendungen, die vom Server versorgt werden können. Außerdem stellt sich hier wieder das Pro- blem des Datenschutzes, da alle Kontextinformationen des Einflussbereiches an einem Ort gebündelt und gespeichert werden. Verteiltes Modell   Anstatt  alle  Kontextinformationen  an  einem  zentralen Ort  bereitzuhalten,  werden  sie  bei  einem  verteilten  Modell  an  verschiedenen Orten vorgehalten. Das wird zum Beispiel dadurch erreicht, dass mobile Komponenten den für ihre Anwendungen benötigten Kontext selbst erfassen und direkt verarbeiten. Dazu muss die mobile Komponente zwar mit den notwendigen Sensoren aus- gestattet  werden,  wobei,  wie  bereits  beschrieben,  Einschränkungen  bezüglich des  Platzbedarfs,  des  Gewichts,  des  Energiebedarfs  usw.  bestehen.  Auf  diese Weise wird jedoch das Problem eines potenziellen Flaschenhalses zum Server, das heißt die mangelnde Skalierbarkeit, umgangen. Außerdem fallen auf diese Weise  alle  Kontextinformationen  bei  der  jeweiligen  mobilen  Komponente  an und werden dort vorgehalten, wodurch der Benutzer steuern kann, ob und wie 11