Middleware für Mobile Systeme
Werbung
Mobile Middleware Context Awareness vs. Transparenz Vortrag im Seminar „Informationsverwaltung in Netzen“ Uli Raffel 19.06.2003 Uli Raffel Mobile Middleware 1/22 Gliederung Mobile Systeme Anwendungen für Mobile Systeme Zum Vergleich: Middleware f. Verteilte Systeme Bei Middleware f. Mobile Systeme: Entscheidung: Transparenz vs. Context Awareness Context Awareness bei Mobilen Systemen: Anwendungsspezifische Strategien zum Datenabgleich replizierter Daten (data reconciliation) Metadaten Reflection Uli Raffel Beispiel: verteilter Einkaufswagen Beispiel: Route Aggegation Mobile Middleware 2/22 Mobile Geräte Uli Raffel Laptop Handy PDA Chips (ohne GUI) ... Mobile Middleware 3/22 Mobile Ad-hoc-Netze Mobile Geräte... haben begrenzte Reichweite bilden Ad-Hoc-Netze sind hochgradig mobil betreten und verlassen das Netz häufig haben knappe Ressourcen: Batterie, CPU, Speicher, Bandbreite Jeder Knoten ist zugleich Endpunkt und Router Keine Infrastruktur, die Routing unterstütz i.a. Broadcast nötig => Ähnlichkeiten zu Peer-to-Peer-Netzen Uli Raffel Mobile Middleware 4/22 Anwendungen für Mobile Systeme Uli Raffel Verkehrswarnsystem Spiele Militär Tauschbörsen Tierbeobachtung Katastrophenschutz Touristeninformationssystem: mobile Teilnehmer in begrenzter Umgebung (Stadt, Museum, Messe) Informationsanfrage zu Gegenständen (Gebäude, etc.) bei Näherung Direkte oder indirekte Antwort(en) von Teilnehmer(n) im räumlichen Umfeld Mobile Middleware 5/22 Uli Raffel Mobile Middleware 6/22 Middleware für Mobile Systeme Uli Raffel soll helfen, mobile Anwendungen zu entwickeln muss leichtgewichtig sein soll asynchrone Kommunikation unterstützen soll technische Aspekte für die Anwendung transparent machen (?) Mobile Middleware 7/22 Middleware für Verteilte Systeme Zum Vergleich: Middleware für Verteilte Systeme soll helfen, verteilte Anwendungen zu entwickeln versteckt technische Aspekte vor der Anwendung Uli Raffel Heterogenität Fehlertoleranz Ressourcenverteilung bietet dem Anwendungsentwickler das Bild eines großen zentralen Systems (-> Verteilungstransparenz) Mobile Middleware 8/22 Verteilungstransparenz für Mobile Systeme (?) Uli Raffel Middleware wäre dann schwergewichtig Middleware müsste stabile Verbindung voraussetzen Middleware müsste dann Verteilungsentscheidungen für die Anwendung treffen hat aber keine applikationsspezifischen Informationen, wann wo welche Daten benötigt werden Anwendung könnte aber entscheidende Informationen haben Lösung: Context Awareness Mobile Middleware 9/22 Context Awareness Es gibt keine sinnvolle statische Strategie, die eine Anwendung der Middleware mitteilen kann Anwendung muss also mit Middleware kommunizieren z.B. kann die Anwendung besser wissen, auf welchem Host Daten zu replizieren sind, damit sie nicht verloren gehen Anwendung kann wissen, wie mit Inkonsistenzen bei replizierten Daten umzugehen ist (siehe nachfolgendes Beispiel) Uli Raffel Mobile Middleware 10/22 Verteilter Einkaufswagen Uli Raffel 3-Personen-Familie mit 1 PC und 3 PDAs PC enthält Produktpalette eines Shops und einen Einkaufswagen (Datenaustausch übers Internet) Daten werden auf PDAs repliziert Bei Verbindung PC <-> PDA oder PDA <-> PDA werden Daten abgeglichen (data reconciliation) Mobile Middleware 11/22 Verteilter Einkaufswagen (2) Daten auf PDA A Daten auf PDA C Daten auf PDA A nach lokalem Update des Einkaufswagens Uli Raffel Mobile Middleware 12/22 Verteilter Einkaufswagen (3) Bspl. 1: Bspl. 2: Uli Raffel Auf PC wird durchs Internet Preis für Käse aktualisiert (nur noch 3,25) PDA B übernimmt neuen Preis PDA A hat noch alten Preis (3,50) PDA A und PDA B begegnen sich Sinnvolles Verhalten beim Abgleich: Preis 3,25 Auf PDA A wird 1 Milch in den Einkaufswagen gelegt Auf PDA C werden 2 Milch in den Einkaufswagen gelegt PDA A und PDA C begegnen sich Sinnvolles Verhalten beim Abgleich: 3 Milch im Einkaufswagen => Abgleich von Daten vom Kontext abhängig Mobile Middleware 13/22 Abgleich von replizierten Daten ... am Beispiel XMIDDLE Uli Raffel bei Begegnung zweier Geräte: gemeinsam genutzte Daten werden ermittelt letzte gemeinsame Version dieser Daten wird ermittelt Änderungen seit dieser Version werden ermittelt Änderungen, die keinen Konflikt erzeugen, werden jeweils übernommen bei Änderungen, die Konflikt erzeugen (Änderung der gleichen Elemente/Attribute) wird Konflikt aufgelöst Mobile Middleware 14/22 Abgleich von replizierten Daten (2) Konfliktauflösung Uli Raffel Anwendung kann Auflösungsstrategien vorgeben: add, last, random, first, greatest beide Anwendungen haben gleiche Strategie vorgegeben: sie wird verwendet beide Anwendungen haben unterschiedliche Strategien vorgegeben: dominante Strategie wird verwendet Anwendungen haben keine Strategie vorgegeben: Default-Strategie: last Mobile Middleware 15/22 Metadaten Anwendung gibt der Middleware Informationen, wie sie sich zu verhalten hat Passive Information Aktive Information Uli Raffel Middleware soll auf Veränderungen im Ausführungskontext reagieren z.B. Verbindung trennen bei niedrigem Batteriestand Middleware soll für jeden Dienst, den sie erbringt, bestimmte Policy verfolgen. z.B. bei viel verfügbarem Speicherplatz eine lokale Kopie von Daten anlegen, bei wenig Speicherplatz und guter Verbindung nicht. Mobile Middleware 16/22 Reflection Reflection erlaubt es einem Programm, auf seine eigene Interpretation zuzugreifen, über sie nachzudenken und sie zu verändern. Reflection hier: Verbreitung von Umweltinformationen an Applikationsschicht erreichbare Hosts/Dienste Batteriestand Speicherplatz CPU-Auslastung Ort Relativer Ort zu Diensterbringern (z.B. Drucker) Bandbreite Uli Raffel Mobile Middleware 17/22 Route Aggregation Netzwerk wird in Gruppen organisiert Gruppen werden von Aggregation Point Anfragen gehen an AP AP kann cachen Uli Raffel Mobile Middleware (AP) verwaltet 18/22 Route Aggregation (2) Voraussetzung: Jeder Peer kann jeden (über mehrere Hops) erreichen (Multihop-Konnektivität) bei mehr als N Nachbarn: Wahl eines AP Knoten neu im Netz: Auswahl eines geeigneten AP -> hier kann Reflection verwendet werden Uli Raffel Mobile Middleware 19/22 Route Aggregation (3) Anfrage an AP, AP liefert Adresse des Zielknotens Content direkt vom Zielknoten reguläre Abmeldung an AP Ausschluss bei Ausfall durch Heartbeat-Nachrichten Rücktritt eines AP bei zu vielen Knoten (-> Group Splitting) zu wenigen Knoten (-> Group Merging) „persönlichen Gründen“ (z.B. Batterie knapp, CPU-Überlastung) Uli Raffel Mobile Middleware 20/22 Route Aggregation - Kritik Uli Raffel Multihop-Konnektivität unrealistisch Rücktritt des AP bei Group Splitting unintuitiv problematisch bei homogenen Netzen bei hoher Dynamik/Mobilität ungeeignet AP selbst sollte nicht mobil sein Mobile Middleware 21/22 Zusammenfassung Middleware für Mobile Systeme Entscheidung: Transparenz vs. Context Awareness Bei Verteilten Systemen: Transparenz Bei Mobilen Systemen: Context Awareness Context Awareness: Anwendungsspezifische Strategien zum Datenabgleich replizierter Daten (data reconciliation) Metadaten Reflection Uli Raffel Beispiel: verteilter Einkaufswagen Beispiel: Route Aggegation Mobile Middleware 22/22
