kommunikation zwischen diensten und geräten stephan caldewei projektgruppe ws 2004 / ss 2005 ag kao...

Kommunikation zwischen Diensten und Geräten

Stephan CaldeweiProjektgruppe WS 2004 / SS 2005AG Kao

Betriebssysteme und Verteilte Systeme

Universität Paderborn

Location Based Servicesfor Wireless Devices

S. Caldewei: PG Location Based Services for Wireless Devices – Kommunikation zwischen Diensten und Geräten

2/27

Übersicht

► Ziele► Anwendungsszenario► Auftretende Probleme

► Beispiele bestehender Lösungen► Mobile People Architecture► Jabber

► Auswahl einer geeigneten Lösung► Stärken der dargestellten Lösungen► Anforderungen an eine geeignete Lösung► Vorschlag für die Projektgruppe


3/27

Ziele

► Möglichst viele Geräte unterstützen

► Möglichst nur ein Client für alle Dienste pro Gerät

► Content abhänging von den Fähigkeiten des Clients darstellen

► Möglichst geringen Aufwand für den Nutzer

► Möglichst geringen Entwicklungsaufwand


4/27

Anwendungsszenario - I

Sie sind hier


5/27

Anwendungsszenario - II

Sie sind hier


6/27

Auftretende Probleme

► Dienste nutzen unterschiedliche Protokolle

► Daten innerhalb eines Protokolls können von unterschiedlichem Typ sein

► Welche Daten überträgt welcher Dienst?

► Unterschiedlich leistungsstarke Geräte / Clients► Speicherplatz► Rechenleistung► Darstellungsvermögen


7/27

Beispiele bestehender Lösungen

► ICQ – Instant Messenger mit proprietärem Protokoll

► Skype – Voice-Over-IP mit proprietärem Protokoll

► IRC – Internet Relay Chat

► Mobile People Architecture (MPA) – Ansatz für personenorientierte Kommunikation

► Jabber – Instant Messenger mit offenem Protokol


8/27

MPA - Überblick

Personal Proxy

Fax

Email

Instant-Messenger

Mobiltelefon

Telefon

Pager / Funkruf


9/27

MPA - Netzwerk-Layer-Modell


10/27

MPA – Personal Proxy – Kommunikationswege

Kommunikations-dienst

Kommunikations-dienst

PersonalProxy

Verzeichnis-dienst


11/27

MPA – Personal Proxy


12/27

MPA – Personal ProxyTracking Agent

► Hält Liste aller derzeit wahrscheinlich verfügbaren Kommunikationsdienste / -kanäle vor

► Registrierung:

► Manuelle An- und Abmeldung durch den Nutzer

► Automatische An- und Abmeldung durch den Dienst bzw. Kanal

► An- und Abmeldung durch zuvor definierte Zeitprofile


13/27

MPA – Personal Proxy


14/27

MPA – Personal ProxyDispatcher


15/27

Jabber - Überblick

► Haupteinsatz als Instant-Messenger mit z.Zt. einigen Millionen Nutzern

► XML als Basis

► Paket von Protokollen

► Streaming von XML-Elementen zwischen 2 Punkten in einem Netzwerk


16/27

Jabber - Kommunikationswege

► Nachrichten werden über ein Servernetzwerk geleitet

► Clients liegen an den Kanten des Netzwerks und kommunizieren mit den Servern

► JID (Jabber ID) ist in der Form: user@server/resource


17/27

Jabber – Beispielnachricht


18/27

Jabber – Sichere Kommunikation

► Zusatzprotokoll „e2e“ End-to-End security

► Funktion analog zu PGP► Signieren und Verschlüsseln► Verwendung von üblichen PGP-Schlüsseln

signieren verschlüsseln entschlüsseln Signaturprüfen


19/27

Jabber – unterstützte Clients

Palm SMS RIM Pocket PC J2ME Symbian WAP

Windows Linux Web


20/27

Stärken der dargestellten Lösungen

► MPA – Mobile People Architecture► Clientabhängige Konvertierung von Content

► Modularer Aufbau

► Auch ohne Anpassungen am Client nutzbar

► Jabber► Einfache Erweiterbarkeit dank XML

► Plattformübergreifend verfügbar

► Verschlüsselung vorgesehen


21/27

Anforderungen an einegeeignete Lösung

► Erweiterbare Struktur

► Gute Wartbarkeit und Erweiterbarkeit

► Unterstützung für verschieden leistungsstarke Clients

► Fähigkeit zur Konvertierung von Content

► Möglichst keine Notwendigkeit für spezielle Clientsoftware


22/27

Vorschlag für die Projektgruppe

► Eigene Lösung entwickeln

► XML als Basisprotokoll verwenden► Kommunikation Dienst -> Client► Kommunikation Dienst -> Dienst

► Konvertierungstechnologie aus MPA übernehmen► Verschiedene Textstufen► verschiedene Bilderstufen► Mulitmedia nur auf leistungsstarken Clients

► Identifizierung der Clients während der Anmeldung


23/27

Transport via http

► XML verfügt über keinerlei Transportschicht

► HTTP ist sehr robust

► HTTP ist für nahezu jede Plattform verfügbar

► HTTP ist sehr schlank und erzeugt wenig Overhead

► Zur Erhöhung der Sicherheit ist alternativ auch HTTPS einsetzbar


24/27

Problem der Uneindeutigkeit

<service=map><body><text>Sie befinden sich hier:</text><image>98475nf98gv75oijtn,mnkjhlkj8s</image></body>

<type=map><content><text/>Sie befinden sich hier:

<map-tile>98475nf98gv75oijtn,mnkjhlkj8s</map-tile></content>

► Unterschiedlicher Inhalt – gleiche Bedeutung

► Zwei Lösungsmöglichkeiten:► A) XML-Gateway mit div. Eingangsfiltern und

definiertem Output► B) Semantic-Web-Ansatz


25/27

Ausgabe auf verschiedenen Geräten

► Client für jede zu unterstützende Geräteklasse festlegen► Möglichst Standard-Clients verwenden► ggf. neu entwickeln und zum Download zur Verfügung

stellen

► Contentanalyse auf dem Server

► Einteilung des Content in Contentkomplexitätsklasse

► Einteilung der Clients in Fähigkeitsklassen

► Falls Contentklasse > Clientklasse => Konvertierung des Content in „kompatible“ Klasse


26/27

Zusammenfassung

► MPA als auch Jabber zu umfangreich und zu weit weg von unserem Anwendungszenario

► XML als Protokoll der Wahl

► Ansatz zur Vermeidung von Mehrdeutigkeiten vorzugsweise via Semantikerkennung

► Anpassung der Daten an Clients auf Serverseite

► Möglichst keine Clients selbst entwickeln


27/27

Danke für die Aufmerksamkeit

kommunikation zwischen diensten und geräten stephan caldewei projektgruppe ws 2004 / ss 2005 ag kao...

Documents