Ubicomp: Middleware

Ubiquitous Computing
(Ubiquitäre Informationstechnologien)
Vorlesung im WS06/07
Michael Beigl
TU Braunschweig
Institute of Operating Systems
and Computer Networks
www.ibr.cs.tu-bs.de/dus
Übersicht
Vorlesung Ubicomp
†Geräte und Umgebungen
†Communication
† Grundlagen
† Kabelgebundene Kommunikation
† Kabellose Kommunikation
† Kommunikation Sensorknoten
† Middleware
†Context
†HCI
Michael Beigl
Ubicomp, Wintersemester 06/07
1-2
Middleware
„Einführung
„Kommunikationsparadigmen
„Jini Service Infrastruktur
„Bluetooth
„Salutation
„OBEX Object Exchange Protokoll
„HAVi AV Kontrolle
„UPnP Plug&Play
Michael Beigl
Ubicomp, Wintersemester 06/07
1-3
Einführung: Ubicomp-Netze
Netze für Ubiquitous Computing
ƒ Diversifikation von Endgeräten: mobil, eingebettet, spezialisiert
ƒ Mobilität: mobile Nutzer, mobile Geräte
ƒ Allgegenwart: überall, insbesondere auch im Heimbereich
ƒ Spontaneität: ad hoc Vernetzung von Geräten
ƒ Konvergenz: Daten, Audio/Video, Steuerung
Entwicklungstrends
ƒ Nutzung „alter Infrastrukturen“ und Schaffung neuer
„ trad. LANs, Funk-LANs, Plug&Play-Busse, Bluetooth, IrDA,
Phoneline, Powerline, ...
ƒ Extrem heterogene Umgebungen: Geräte und Netze
ƒ hohes Maß an Dynamik: Hot&Plug Play, mobile Netze, kurzlebige
Verbindungen
Michael Beigl
Ubicomp, Wintersemester 06/07
1-4
Einführung: Ubicomp-Netze
Typische Szenarien und Herausforderungen
ƒ über Mobiltelefone im Haus bedienen
„ heterogene Geräte und Netze (mobil/Heim)
„ kohärente Sicht auf Dienste im Heim
ƒ Kamera sucht Drucker in fremder Umgebung
„ wie kann ein „geeigneter“ Drucker gefunden werden ?
„ wie unterhält man sich mit einem fremden Gerät ?
ƒ Hausregelung
„ Heizung sucht Thermostat und Bewegungsmelder
Wichtigste Herausforderung: Komplexität verbergen
ƒ vor allem vor dem Anwender
ƒ keine manuelle Installation / Konfiguration (ad-hoc)
ƒ Abstraktionen für die Anwendungsentwicklung
Middleware
Michael Beigl
Ubicomp, Wintersemester 06/07
1-5
Middleware
Was ist Middleware ?
ƒ „der Slash in Client/Server“
ƒ Leslie Lamport: You
know you have a distributed
system when the crash of a computer you have
never heard of stops you from getting any work
done.”
ƒ Komponenten für Entwicklung und Einsatz verteilter Systeme
ƒ angesiedelt zwischen Netzwerktechnologie(n) und Anwendung
Wofür ?
ƒ Abstraktion von Netzwerkprogrammierung
ƒ Interoperabilität: Zwischenschicht über unterschiedlichen Geräteund Netzwerkplattformen
ƒ Komponenten für allgemeine Aufgaben in verteilten Systemen:
z.B. Name Service, Security Service,...
Michael Beigl
Ubicomp, Wintersemester 06/07
1-6
Middleware
Anwendung
Anwendung
Anwendung
APIs
Dienst
Dienst
Dienst
Plattform
(BS, Netz)
Michael Beigl
Middleware
Dienst
Plattform
Platform
Interface
(BS, Netz)
Ubicomp, Wintersemester 06/07
1-7
Middleware
RPC: Remote Procedure Call (80er Jahre)
ƒ Prozedurales Paradigma
ƒ entfernter Prozeduraufruf analog zu lokalem Aufruf
ƒ Code für die Kommunikation wird automatisch erzeugt
Objekt-orientierte Middleware (90er Jahre)
ƒ Objekt-orientierte Programmierung
ƒ Kommunikation mit entfernten Objekten über automatisch
erzeugte lokale Proxies (z.B. „stubs“ in CORBA)
ƒ Vermittlungsdienste (z.B. Object Broker)
Java Remote Method Invocation
ƒ Java‘s Middleware für Methodenaufrufe von Objekten, die in
verschiedenen VM ablaufen
Michael Beigl
Ubicomp, Wintersemester 06/07
1-8
Middleware für Ubicomp
Integration heterogener Geräte
ƒ Gateways für kohärenten Zugang zu heterogenen Umgebungen
ƒ Service Paradigma: dynamischer Verbund von Geräten ohne zentrale
Komponente; spontane Bildung verteilter Systeme
Service Gateways
ƒ Bündelung von Diensten über Gateways
ƒ Residential Gateways: Verbindung zwischen Heimnetz und Außenwelt (=
Internet)
„ bietet Geräten im Haus Zugriff auf Internet-Dienste
„ bietet externen Dienstanbietern kohärenten Zugang zu
Geräten/Infrastruktur im Haus (z.B. für Fernwartung,
Sicherheitsüberwachung,...)
„ Administration durch Gateway Operator
„
Standardisierung: Open Service Gateway Initiative (OSGi)
Michael Beigl
Ubicomp, Wintersemester 06/07
1-9
Middleware
„Einführung
„Kommunikationsparadigmen
„Jini Service Infrastruktur
„Bluetooth
„Salutation
„OBEX Object Exchange Protokoll
„HAVi AV Kontrolle
„UPnP Plug&Play
Michael Beigl
Ubicomp, Wintersemester 06/07
1-10
Kommunikationsparadigmen
Kom.Grund
Ablauf einer Kommunikation
ƒ Initiierung: Auswahl der Kommunikationspartner
Wie Auswahl
ƒ Durchführung: Austausch von Kommunikation
Grund Kommunikation
ƒ Beendung
Auswahl
ID
Info
Dienst
Kontext
Michael Beigl
Dienst
Kontext
HTTP
IrOBEX
Jini, UPnP, HAVi,Salutation
Forschung
Forschung
Ubicomp, Wintersemester 06/07
1-11
Kommunikationsparadigmen
Kom.Grund
Ablauf einer Kommunikation
ƒ Initiierung: Auswahl der Kommunikationspartner
Wie Auswahl
ƒ Durchführung: Austausch von Kommunikation
Grund Kommunikation
ƒ Beendung
Auswahl
ID
Info
Dienst
Dienst
HTTP
Kontext
IrOBEX
Jini, UPnP, HAVi, Salutation
Kontext
Michael Beigl
Ubicomp, Wintersemester 06/07
1-12
Service Paradigma
Everything is a Service
ƒ Geräte ebenso wie Software
ƒ vgl. Objekt-orientierung: „everything“ is an object
ƒ Services werden durch Interfaces definiert, über die sie ihre
Funktionalität zur Verfügung stellen
ƒ Services werden beschrieben durch Typ und Attribute
ƒ Services können sich zu Systemen verbünden („federation“)
Beispiele für Services
ƒ Kamera, Drucker, Fax, Scanner, Speicher, Rechenleistung
ƒ Türöffner, Beleuchtung, Alarmanlage, Stromzähler, ...
ƒ Rechtschreibprüfung, Formatkonvertierung, ...
ƒ Online Banking, Aktienhandel, ...
ƒ Hotelführer, Stadtplan, ...
Michael Beigl
Ubicomp, Wintersemester 06/07
1-13
Service Paradigma
Netzwerk-zentrisch
ƒ „the network is the computer“
ƒ Netzwerk = Hardware und Softwareinfrastruktur für Dienste
ƒ Sichtweise: „Netzwerk, an das Geräte angeschlossen sind“
(statt „Geräte, die vernetzt werden“)
„ Netzwerk existiert immer, Geräte/Dienste sind transient
„ Komponenten und Kommunikationsbeziehungen kommen und gehen
Spontane Vernetzung
ƒ Services finden sich in der offenen Netzwerkumgebung zu zeitweiligen
Verbundsystemen zusammen
ƒ müssen sich dazu nicht a priori kennen
ƒ typisches Szenario: Client wacht auf und fragt nach Diensten in der
lokalen Umgebung
Michael Beigl
Ubicomp, Wintersemester 06/07
1-14
Service Paradigma
Spontane Vernetzung von Services
ƒ wie werden Services aufeinander aufmerksam ?
ƒ wie können bestimmte Services in einer fremden Umgebung gefunden
werden (Flexibilität!)?
ƒ wie verständigen sich Services, wenn sie sich gefunden haben ?
ƒ Werden Dienstinfo. in Infrastruktur gehalten oder ad-hoc ermittelt?
Infrastruktur für Service Discovery
ƒ „Registry“: Verzeichnis/Vermittlung von Services
ƒ Protokolle zum Registrieren und zum Anfragen von Services
ƒ Protokolle für Client-Zugriff auf Service, und für die Nutzung von Services
durch Clients
ƒ z.B. Sun‘s Jini aufbauend auf Java/RMI, Microsoft‘s UPnP (Universal Plug
& Play)
ƒ z.B. HAVi (Home Audio/Video interoperability) aufbauend auf IEEE.1394
für Home Entertainment Dienste
Michael Beigl
Ubicomp, Wintersemester 06/07
1-15
Middleware
„Einführung
„Kommunikationsparadigmen
„Jini Service Infrastruktur
„Bluetooth
„Salutation
„OBEX Object Exchange Protokoll
„HAVi AV Kontrolle
„UPnP Plug&Play
Michael Beigl
Ubicomp, Wintersemester 06/07
1-16
Jini Service Infrastruktur
Hauptkomponenten
ƒ Lookup Service (LUS): „Registry“ für Services
ƒ Protokolle basierend auf TCP/UDP/IP
„ Discovery & Join, Lookup von Services
ƒ Proxy Objekte
„ als lokale Vertreter für Services
Lookup Service
ƒ Verzeichnis ähnlich RMI Registry
ƒ Aufgabe: „Helpdesk“ für Services/Clients
„ Registrierung von Services, die angeboten werden
„ Verteilung von Diensten an anfragende Clients
Michael Beigl
Ubicomp, Wintersemester 06/07
1-17
Jini Lookup Service
loo
ku
Michael Beigl
Jini
Federation
r
te
Client
gi s
re
p
Lookup
Service
use
Ubicomp, Wintersemester 06/07
Service
1-18
Discovery: Finden eines LUS
Finden eines Lookup Services
ƒ ... ohne a priori Kenntnis des Netzwerks
ƒ Service Provider sucht LUS um Service anzumelden (register)
ƒ Client sucht LUS um einen Service anzufragen (look up)
Discovery Protokoll
ƒ Multicast-Anfrage an bekannten Port
ƒ Lookup Service lauscht auf entsprechendem Port und antwortet mit
Proxy Objekt
„ Proxy Objekt wird in die anfragenden Service geladen
„ Kommunikation mit LUS dann über den Proxy
ƒ weitere Discovery-Protokolle
„ Unicast: Service kann LUS direkt ansprechen, wenn er die IPAdresse schon kennt
„ Multicast Announcement: LUS meldet sich per Multicast, z.B.
nach Ausfall
Michael Beigl
Ubicomp, Wintersemester 06/07
1-19
Discovery
Michael Beigl
Ubicomp, Wintersemester 06/07
1-20
Join: Registrieren eines Services
Join Protokoll
ƒ Service Provider hat einen Proxy des LUS für die Kommunikation
empfangen
ƒ Provider registriert über den Proxy seinen Service: register()
ƒ Provider übergibt dabei dem LUS
„ den eigenen Service Proxy
„ Attribute, die den Dienst beschreiben
(z.B. „600 dpi“, „version 21.1“, ...)
ƒ Service tritt mit dem Join in den Jini-Verbund ein
„ Provider kann nun über den LUS gefunden und von anderen
Services genutzt werden
Michael Beigl
Ubicomp, Wintersemester 06/07
1-21
Join
Michael Beigl
Ubicomp, Wintersemester 06/07
1-22
Lookup: Suchen von Services
Lookup Protokoll
ƒ Client sucht bestimmten Service
ƒ kennt LUS und verfügt über Proxy für die Kommunikation
(via Discovery Protokoll)
ƒ sendet Anfrage an LUS in Form eines „Service Template“
„ ID, Typ, Attribute
ƒ LUS antwortet mit keinem/einem/mehreren passenden Services
„ ggf. Auswahl im Client
ƒ Client erhält vom LUS Proxy des vermittelten Services
ƒ Client nutzt Proxy für direkte Kommunikation mit dem Provider
„ beliebiges Protokoll
„ Proxy: Gateway zu Service-Funktionalität beim Provider
„ Proxy kann aber auch (Teil der) Service-Funktionalität
implementieren, d.h. Ausführung beim Client
Michael Beigl
Ubicomp, Wintersemester 06/07
1-23
Lookup: Service Matching
Service Template
ƒ Service ID (Registration Number): kann angegeben werden, falls
Dienst bereits bekannt ist (durch frühere Nutzung)
ƒ Service Typ: definiert durch die Schnittstelle
ƒ Attribute (sog. Entries), die den Service beschreiben
Service Matching
ƒ Übereinstimmung via Attribute: Mehrwert gegenüber
traditionellem Naming Service: Service-Auswahl über
beschreibende Merkmale
ƒ aber nur exaktes Übereinstimmung, kein „größer als“, keine
Query-Sprache
„
z.B. Anfrage an „600dpi“ Drucker stimmt nicht mit registriertem
„1200dpi“ Drucker überein
Michael Beigl
Ubicomp, Wintersemester 06/07
1-24
Lookup
Michael Beigl
Ubicomp, Wintersemester 06/07
1-25
Service Invocation
ƒ Client kann nun auf Service zugreifen
ƒ Protokoll zwischen Client und Service nicht festgelegt
Michael Beigl
Ubicomp, Wintersemester 06/07
1-26
Service Paradigma
Spontane Vernetzung von Services: Jini Konzepte
ƒ wie werden Services aufeinander aufmerksam ?
„ Jini: Lookup Services als Vermittlungsstelle, Registrierung von
Services über Discovery & Join
ƒ wie können bestimmte Services in einer fremden Umgebung
gefunden werden ?
„ Discovery von Lookup-Services als Verteiler in fremder
Umgebung
„ Lookup anhand von Service Templates, insbesondere auch
anhand beschreibender Attribute
ƒ wie verständigen sich Services, wenn sie sich gefunden haben ?
„ Service Proxy wird in den anfragenden Client geladen
„ beliebiges Protokoll, kein spezifisches Aushandslungsverfahren
Michael Beigl
Ubicomp, Wintersemester 06/07
1-27
Jini Architektur
Michael Beigl
Ubicomp, Wintersemester 06/07
1-28
Programmiermodell
Leases
ƒ Client fordert Lease von Server für eine spezifische Zeit an
ƒ Client ist für das Erneuern der Lease verantwortlich
ƒ Im Fehlerfall erlöscht die Lease nach Zeitüberschreibung
ƒ Unterstützt werden exklusive und nicht-exklusive Leases (z.B. für
gemeinsame Ressourcen)
ƒ Beispiel: Im Lookup-Service wird mit Lease-Konzept Dienst
registriert
Michael Beigl
Ubicomp, Wintersemester 06/07
1-29
Programmiermodell II
Distributed Transactions
ƒ two-phase commit; 3 Beteiligte
ƒ Clients
„ Initiieren Erstellung des transaction context durch Request an
Transaction Manager
ƒ Transaction Manager
„ implementiert TransactionManager interface
„ Koordiniert two-phase commit Operationen
ƒ Participants
„ Implementieren TransactionParticipant interface
„ Führen Transaktionsoperationen durch
Distributed Events
ƒ Publish/Subscribe Mechanismus
ƒ Erweiterung des Event-Mechanismus von Java Beans
Michael Beigl
Ubicomp, Wintersemester 06/07
1-30
Middleware
„Einführung
„Kommunikationsparadigmen
„Jini Service Infrastruktur
„Bluetooth
„Salutation
„OBEX Object Exchange Protokoll
„HAVi AV Kontrolle
„UPnP Plug&Play
Michael Beigl
Ubicomp, Wintersemester 06/07
1-31
Bluetooth Service/Profiles
Profile
ƒ geben an, welche Funktionalität implementiert ist
ƒ Wichtige Profile sind:
•
GAP Profile: Generic Access Profile for discovery and link
management
•
SDAP Profile: Service Discovery Application Profile for discovering
services and information retrieval
•
SPP Profile: Serial Port Profile for emulating serial cable connections
•
GOEP Profile: Generic Object Exchange Profile (OBEX)
„
CTP Profile: Cordless Telephone Profile for telephony features.
„
IP Profile: Intercom Profile for intercom functionaly also referred to as
the "walkie-talkie" usage
„
HS Profile: Headset Profile
„
LAP Profile: LAN Access Profile for LAN access using PPP
„
....
Michael Beigl
Ubicomp, Wintersemester 06/07
1-32
Bluetooth: L2CAP, PSM
Weitere Dienste
/Anwendungen
OBEX
RFCOMM
TCS
SDP
L2CAP
ƒ logische Verbindung, in Software (nicht auf
BT-Chip)
ƒ Segmentierung von Paketen
ƒ Dienstgütespezifikation
Protocol und Service Multiplexer (PSM)
ƒ dient der Ermittlung des Dienstes z.B.
L2CAP
ƒ Service Discovery Protocol (SDP)
HCI
ƒ RFCOMM
Link,Baseband
RF (Hardware)
ƒ Telephony Control Protocol Specification
(TCS)
Michael Beigl
Ubicomp, Wintersemester 06/07
1-33
Bluetooth SDP
Service Discovery Protocol (SDP)
Michael Beigl
Ubicomp, Wintersemester 06/07
1-34
Service Discovery Protocol
SDP
ƒ dezentrale Dienstnachfrage, kein Repository in einer
„Infrastruktur“, nur Dienste des eigenen Gerätes
ƒ Diensterkennung
ƒ Dienstkommunikation wird vom Dienst selbst
durchgeführt
ƒ keine Zugriffskontrolle
ƒ Interne Datenbank (Service Record DB) besteht aus
AttributID und Attributwert Paaren
ƒ Beinhaltet Beschreibung/ID des Dienstes, Name,
Charakteristik
ƒ Protokoll ist in Attribut ProtocolDescriptorList beschreiben
ƒ Suche via „Search Pattern“ = Liste von UUIDs die
irgendwo in den Attributen auftauchen müssen (UND
verknüpft)
Michael Beigl
Ubicomp, Wintersemester 06/07
1-35
Vernetzung: höhere Schichten
„Einführung
„Kommunikationsparadigmen
„Jini Service Infrastruktur
„Bluetooth
„Salutation
„OBEX Object Exchange Protokoll
„HAVi AV Kontrolle
„UPnP Plug&Play
Michael Beigl
Ubicomp, Wintersemester 06/07
1-36
Salutation
Salutation
ƒ Konsortium vieler Firmen von Adobe-Xerox, aber frei
ƒ Verwendet existierenden Transport, z.B. TCP/IP, Bluetooth, Irda
ƒ Implementierungsvorschläge vorhanden
ƒ Ergänzt System um sehr flexible Aushandlung von
Dienstparametern und Auswahl von Diensten
ƒ leichtgewichtig
Michael Beigl
Ubicomp, Wintersemester 06/07
1-37
Salutation Service Discovery
Aufgaben Salutation Manager (SLM)
ƒ Service Registry
ƒ Service Discovery
ƒ Service Availability
ƒ Service Session Management
Ablauf
Salutation Salutation Protocol Salutation
Client
Manager
slmSearchCapability
call
QueryCapability
call to all known SLM
reply
Manager
Server
slmRegisterCapability
reply
slmQueryCapability
call
QueryCapability
call to one SLM
reply
reply
Michael Beigl
Ubicomp, Wintersemester 06/07
1-38
Salutation Service Discovery
Service Discovery
ƒ slmSearchCapability wird mit Parametern-Muster
aufgerufen
ƒ komplette Übereinstimmung oder Aufruf einer „Compare
Function“
ƒ Compare-Function muß bei Server bekannt sein
ƒ logische Verbindung (AND,OR) im Ausdruck unterstützt
ƒ Vordefinierte Attribute für Standard-Anwendungen:
Drucker, Fax, Voice Message, Personal Information
Management, ....
ƒ Client und Server können auf einem Rechner laufen
ƒ Manager kann auch extern laufen (um Peripherie wie
Drucker, der vom PC als Salutation Dienst angeboten
wird)
Michael Beigl
Ubicomp, Wintersemester 06/07
1-39
Beispiel
Michael Beigl
Ubicomp, Wintersemester 06/07
1-40
Middleware
„Einführung
„Kommunikationsparadigmen
„Jini Service Infrastruktur
„Bluetooth
„Salutation
„OBEX Object Exchange Protokoll
„HAVi AV Kontrolle
„UPnP Plug&Play
Michael Beigl
Ubicomp, Wintersemester 06/07
1-41
(Ir)OBEX: IrDA Object Exchange
Beliebige „Dinge“ austauschen
ƒ Protokoll für den Austausch, das Abfragen, die Anforderung von
Objekten und den damit verbundenen Diensten
ƒ Bei Bluetooth: OBEX, setzt auf RFCOMM auf
ƒ Dienste primär Datenübertragungsdienste
ƒ Spezifikation besteht aus zwei Teilen:
„ Beschreibung der Objekte
Weitere Anwendungen
„ Kommunikationsprotokoll
Default
ƒ Einfaches Protokoll, deshalb:
Obex-Anwendung
SyncML
OBEX
ƒ Darauf aufsetzende Standard-Sync für
PDA, Mobiltelefone
IrDA, Bluetooth...
ƒ Palm, Ericsson, IBM, Psion, Motorola
Michael Beigl
Ubicomp, Wintersemester 06/07
1-42
(Ir)OBEX
Ablauf Kommunikation
ƒ Geräte bieten Dienste in Form von Objekten an
ƒ Client erfragt einen Dienst (request) und erhält vom Server eine
Antwort (response)
ƒ Sitzungsorientiertes Protokoll
ƒ Bsp: Client erfragt, ob er eine vCard ablegen darf
Opcode len Objekte
ƒ Paket:
ƒ Objektmodell definiert Objektbezeichner und Objekte
ƒ Modell besteht aus einer Liste Tupeln der Form
<Bezeichner&Format><Objekt>
ƒ Tupel sind einfach zu parsen
ƒ „Byte“-Kodierung statt Text-Kodierung orientiert sich an
leistungsschwachen Geräten
Michael Beigl
Ubicomp, Wintersemester 06/07
1-43
OBEX
Vereinfachter Ablauf einer Sitzung
Connect
Success
Put(Name=„michael.vcf“,Type=„text/x-vCard“)
Success
Put(Body=„Name=Michael Beigl...“)
Success
Put(End of Body)
Success
Disconnect
Success
Michael Beigl
Ubicomp, Wintersemester 06/07
1-44
Middleware
„Einführung
„Kommunikationsparadigmen
„Jini Service Infrastruktur
„Bluetooth
„Salutation
„OBEX Object Exchange Protokoll
„HAVi AV Kontrolle
„UPnP Plug&Play
Michael Beigl
Ubicomp, Wintersemester 06/07
1-45
HAVi (Home Audio Video
Interoperability)
Eigenschaften HAVi
ƒ Ein Medium für Kontrolle und Daten, insbesondere für
Elektronische Media-Geräte (TV, Stereoanlage etc.)
ƒ Standard von Hitachi, Philips, Sony, Toshiba....
ƒ Verbindungslose Kommunikation basiert auf IEEE1394
via Communication Manager
Ziele
ƒ Nahtlose Interoperabilität zwischen Geräten
verschiedener Hersteller
ƒ Einfache Benutzbarkeit
ƒ Perfomance: mehrfache Echtzeit AV-Ströme
ƒ Vollständige Selbstkonfiguration des Netzwerks
ƒ Vorwärtskompatiblität für alle Geräte
ƒ Verteilte Benutzerschnittstellen möglich
Michael Beigl
Ubicomp, Wintersemester 06/07
1-46
HAVi Charakteristika
ƒ Definiert ein Betriebssystem Middleware für:
„ Mehrdirektionale AV Ströme
„ Ereignis-Scheduling
„ Registrierung
ƒ Speziell für das Management von Funktionen eines
Dedizierten Audio/Video Netzwerksystems
Vorteil
ƒ Automatische Geräteerkennung
ƒ Sofortige Möglichkeit Geräte zu koordinieren
ƒ Jede hinzukommendes Gerät wird sofort automatisch
registriert, Capabilities sind jedem anderen Gerät sofort
ersichtlich
ƒ Vorgegebner Satz von Capabilities sichert
Interoperabilität auch zwischen verschiedenen
Geräteherstellern zu
Michael Beigl
Ubicomp, Wintersemester 06/07
1-47
HAVi
Gerätetypen
ƒ IAVs (Intermediate AV devices) (native implementierung)
ƒ FAVs (Full AV devices): Java Runtime
ƒ BAV (Base Audio/Video Devices): nur bytecode upload
ƒ LAVs (Legacy AV devices): Aufrufe müssen von FAV
umgesetzt werden
ƒ Device Control Module (DCM) und Functional Component
Module (FCM) repräsentieren Device, Funktion des
Device
ƒ Registry: Speichert Geräteeigenschaften
ƒ Java AWT 1.1 und spezielle Klassen, UI Programmierung
(Havlets) auf Anwendungsebene
Michael Beigl
Ubicomp, Wintersemester 06/07
1-48
Device Classes
Full
FullAV
AVdevice
device(FAV)
(FAV)
••Download
Downloadand
andexecute
executeall
allHAVi
HAViapplications
applications
••Download
Downloadand
andexecute
executeDCM
DCM
Controller
Devices
Intermediate
IntermediateAV
AVdevice
device(IAV)
(IAV)
••Ability
Abilityto
tocommunicate
communicatewith
withother
otherHAVi
HAVidevice
device
••Ability
Abilitytotoexecute
executelimited
limitedapplications
applications
••Offers
Offersown
owncontrol
controlservice
service
••Ability
to
host
other
Ability to host otherknown
knowndevice
device
Base
BaseAV
AVdevice
device(BAV)
(BAV)
••Offers
Offersown
owninformation
informationininROM
ROM
Legacy
LegacyAV
AVdevice
device(LAV)
(LAV)
••Conventional
Conventionaldevices
deviceswith
with
NO
NOHAVi
HAViSDD
SDDdata
data(ROM)
(ROM)
Michael Beigl
Ubicomp, Wintersemester 06/07
1-49
HAVi Architecture
Application
havlet
Application
1394 Manager
Resource Mgr
Stream Mgr
Registry
Event Mgr
Messaging
Interoperability API (native binding)
Interop. API (Java binding)
DCM
DCM
DCM
DCM
DCM
optional
Level I
UI Engine
Porting Layer
DCM Manager
org.havi...
JVM
Vendor-specific Platform (RTOS)
1394 Device Drivers
Michael Beigl
Other Device Drivers
Ubicomp, Wintersemester 06/07
1-50
DCM
Control Model / DCMs
ƒ Austausch Kontrollinformation P2P, kein Master auf
Kommunikationsebene
ƒ Kontroller beherbergt “Device Control Module” (DCM) für zu
kontrollierendes; DCM zentrales Konzept
ƒ Kontrollschnittstelle durch API des DCM
DCM Einbettung
ƒ Embedded DCM – generische DCM Implementierung als Teil der
residenten Software auf Kontroller
ƒ Uploaded DCM –DCM wird von externer Quelle geladen (HAVlet)
ƒ Native DCM –DCM für spezifische Plattform
DCM Ausführung
ƒ Bytecode DCM – DCM implementiert als Java bytecode
ƒ Standard DCM – DCM stellt Standard HAVI APIs nativ zur
Verfügung
DCM Inhalt
ƒ Code für DCM
ƒ Code für (FCMs) für jede funktionale Komponente in Gerät
Michael Beigl
Ubicomp, Wintersemester 06/07
1-51
HAVi Architektur
1394 Communication Media Manager
ƒ Async. Und Synchrone Kommunikation via IEEE1394
Messaging System
ƒ Verantwortlich für die Übertragung von Meldungen zwischen
Softwareelementen
Registry
ƒ Speichert Geräteeigenschaften (Directory Service) aller Geräte
im Netz
Event Manager
ƒ Ausliefern von Events. Event: Statusänderung eines Objekts
oder des Netzwerks
Stream Manager
ƒ Verantwortlich für das Managen von Echtzeitkomm. Von AV und
anderen Medien
Ressource Manager
ƒ Ressource-Sharing und Aufgaben-Scheduling
Michael Beigl
Ubicomp, Wintersemester 06/07
1-52
HAVi Architecture
Application Module
ƒ Stellt DDI(Data Driven Interaction) Schnittstelle
und/oder havlet zur Verfügung
Self Describing Device (SDD) data
ƒ Muss jedes Havi Gerät haben
ƒ Enthält Beschreibungsinformation der Geräte und
Funktionalität
ƒ Verwendet festgelegtes (IEEE 1212)
Adressierungsschema für das Konfigurations-ROM
ƒ Kann DCM Code und Herstellerspezifische Daten für die
Präsentation von Benutzerschnittstellen enthalten (BAV),
zur Ausführung auf Fremdrechner
Michael Beigl
Ubicomp, Wintersemester 06/07
1-53
HAVi FCM
Functional component Modules (FCM)
ƒ 1+ innerhalb des Device Control Module (DCM)
ƒ Vordefinition von APIs zu FCM in HAVi Spezifikation
ƒ FCMs setzen abstrakte Info in gerätespezifische
Info/Kommando um
ƒ Von dort wird das Kommando an Hardware
weitergesendet.
FCM definiert für Tuner
ƒ Tuner FCM: Setzen und Erhalten von Kanälen, Auswahl
von Attributen (Musiksender...)
ƒ VCR FCM: PLAY, REC, REW..., Uhrzeit setzen
FCM Beispiele:
ƒ VCR, Clock, Camera, AV Disc, Amplifier, Display, AV
Display, Modem, Web Proxy
Michael Beigl
Ubicomp, Wintersemester 06/07
1-54
Beispiel: AV Disc FCM
AV Disc FCM Standard Transport Controls Beispiele:
ƒ Play, Stop, Insert Media, Eject Media
ƒ Get the State
ƒ Get the Format
ƒ Get the Position (time)
Optional
ƒ Get/Put Item List
ƒ Record
ƒ Variable Forward & Reverse
ƒ RecPause
ƒ Skip
ƒ Erase
Ereignisse
ƒ List Change
ƒ State Change
Minimale Feature-Liste sichert Auf/Abwärtskompatiblität
Michael Beigl
Ubicomp, Wintersemester 06/07
1-55
Middleware
„Einführung
„Kommunikationsparadigmen
„Jini Service Infrastruktur
„Bluetooth
„Salutation
„OBEX Object Exchange Protokoll
„HAVi AV Kontrolle
„UPnP Plug&Play
Michael Beigl
Ubicomp, Wintersemester 06/07
1-56
Universal Plug and Play (UPnP)
Allgemein
ƒ Konsortium zur Dienstkommunikation in Ad-hoc Umgebungen
ƒ Getrieben von Microsoft, Intel
Charakteristik
ƒ Netz zur Ad-hoc Vernetzung von Geräten wie PNP Geräte
ƒ Service-Konzept
ƒ Eingesetzt derzeit vor allem für Konfiguration,
Statusabfrage z.B. bei Routern
ƒ Basiert auf IP, benötigt DHCP, XML, HTTP
Device
Device
Control Point
Service
Control Point
Service
Michael Beigl
Ubicomp, Wintersemester 06/07
1-57
Kommunikationsaufbau
Aufbau von Kommunikation in 4 Schritten
0 Kontrollpoint und Gerät erhalten Adresse zugewiesen
1 Kontrollpoint findet Gerät von Interesse
2 Kontrollpoint erhält die Geräteeingenschaften (<service>)
3 Kontrollpoint ruft “Action” auf Gerät auf
4 Kontrollpoint hört auf Statuswechsel auf Gerät
5 Kontrollpoint kontrolliert Gerät und/oder beobachtet Gerätestatus durch
Webbrowser
Michael Beigl
Ubicomp, Wintersemester 06/07
1-58
UPnP <service> Element
Enthält
ƒ Service-Typ
ƒ Service-ID
ƒ Service URL, um mit dem Service Kontakt aufzunehmen
(für SOAP)
ƒ Event subscription URL, um auf Events zu „subscriben“
(GENA)
ƒ Das Service Description File (auch als URL) mit näheren
Details über den Dienst
„ „Action List“, auf die der Dienst antwortet
„ „Service State Table“ mit Zustandsvariablen, deren
Datentypen und Zuständen des Dienstes
Michael Beigl
Ubicomp, Wintersemester 06/07
1-59
Intel Toolkit
Zehn “Tools” zur Unerstützung von UPnP Entwicklungen
ƒ Z.T. mit Standard-Schnittstelle ähnlich HAVI, z.B. BinaryLight
Switch
ƒ Device Spy & Device Sniffer: Macht Geräte im Netz ausfindig
ƒ Service Author: Unterstützt die Erstellung von
Gerätebeschreibungen
ƒ Device Validator: Überprüft, ob Geräte Standardkonform sind
ƒ Device Relay & Network Light: Einfache
Referenzimplementierungen für Geräte
ƒ AV Media Controller & AV Media Wizard: Für
Medienverschaltung
ƒ AV Media Server: Stellt Dateien im Netz zur Verfügung
ƒ AV Media Renderer: Referenzimplementierung eines UPnP
steuerbaren Players
Michael Beigl
Ubicomp, Wintersemester 06/07
1-60
Intel-Tools Einsatz
Control Point
Device Spy
Device Validator
Michael Beigl
Device
Control
HTTP/SOAP
Discovery
SSDP
Service Author
Device Sniffer
Ubicomp, Wintersemester 06/07
1-61
Intel Tools II
AV Media Controller
AV Media Wizard
AV Media Server
Media Controller
AV Media Renderer
UPnP AV
Media Server
Michael Beigl
UPnP AV
Media
Stream
Ubicomp, Wintersemester 06/07
Media Renderer
1-62
UPnP Architektur
UPnP Vendor Defined
UPnP Forum Defined
UPnP Device Architecture (DCP)(Presentation)
SSDP
GENA
HTTP Multicast/Unicast
((2)Discovery)
SOAP (Control)
HTTP ((3)Descr.) GENA
UDP
TCP
IP
Michael Beigl
Ubicomp, Wintersemester 06/07
1-63
UPnP Schritte
Adressierung
ƒ DHCP oder Auto IP
Discovery von Geräten
ƒ SSDP (Simple Service Discovery Protocol): Meldung der
Anwesenheit (Announce) oder über vorheriges Search
ƒ Optionale Control-Points können Funktionalität ähnlich Jini/LUS
übernehmen
ƒ LAN Broadcasts oder direktes Ansprechen eines
Verzeichnisdienstes (Proxy)
ƒ HTTP/XML basierte verbindungslose Kommunikation z.B. als
UDP
ƒ Melden der eigenen Fähigkeiten durch ANNOUNCE-Kommando,
enthält zudem URL zu XML Beschreibungsdatei
ƒ Abfrage durch OPTIONS Kommando
Zudem: Broadcast-DNS Abfrage, DHCP Erweiterung
Michael Beigl
Ubicomp, Wintersemester 06/07
1-64
UPnP Schritte II
Description
ƒ Beschreibung der Geräteeigenschaften im XML Format
ƒ Vor allem ID, URL, Hersteller...
ƒ Andere Eigenschaften beschreibbar
Control
ƒ Simple Object Access Protocol (SOAP)
ƒ Beschreibung Dienste/Aktionen und Parameter in XML
Format
ƒ „RPC über HTTP“
Event
ƒ IETF Draft General Event Notification Architecture (GENA)
ƒ 3 Kommandos/Events:
Subscribe / Unsubscribe / Notify von Meldungen
Michael Beigl
Ubicomp, Wintersemester 06/07
1-65
Beispielablauf
Device Discovery
NOTIFY (URL oder XML)
Control Point
HTTP Get (XML)
HTTP Response (XML)
Device
Anstoß Aktion
HTTP M-POST (SOAP action)
Control Point
Device
HTTP Response (SOAP response)
Michael Beigl
Ubicomp, Wintersemester 06/07
1-66
SOAP
Simple Object Access Protocol
ƒ SOAP ist ein Kommunikationsprotokoll zwischen
Anwendungen
ƒ Ähnlich RPC, basiert auf XML/Internet
ƒ Ablauf: Sende Template mit Variablen+Konstanten hin,
bekomme ausgefüllte Variablen + Funktionsergebnis
zurück
ƒ Platform-, Sprachunabhängig
ƒ „einfach“ und erweiterbar
ƒ Überwindet Firewalls (HTTP) (gut für Viren!)
ƒ W3C standard
ƒ Typen definierbar
ƒ Soap encoding: Envelope bestehend aus Header
(optional) + Body
Michael Beigl
Ubicomp, Wintersemester 06/07
1-67
SOAP: Typen in Messages
Typen spezifiziert als XML Dokument
Beispiel 2-dim Integer array
ƒ <iArray xsi:type=SOAP-ENC:Array SOAPENC:arrayType="xsd:int[3]">
„ <val>10</val>
„ <val>3</val>
ƒ </iArray>
Klasse Test
ƒ <Test>
„ <sVal xsi:type="xsd:string">wasAuchImmer</sVal>
ƒ </Test>
References (Pointer, URLs möglich!)
ƒ <people> <person person=„muster"> <address
href="#adresse1"/> </person>
ƒ <adress id="adresse1"> <strasse>Hauptstr1</strasse>
<Ort>Berlin</Ort> </address>
Michael Beigl
Ubicomp, Wintersemester 06/07
1-68
SOAP Beispiel Request
<?xml version='1.0' ?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2003/05/soap-envelope"
soap:encodingStyle="http://example.com/encoding" >
<soap:Body>
<m:reservation
xmlns:m="http://travelcompany.example.org/reserv
ation">
<CardNumber xsi:type=„int">
123456789099999 </CardNumber>
<Name xsi:type=„string“> M Muster
</n:Name>
</m:reservation>
</soap:Body>
</soap:Envelope>
Michael Beigl
Ubicomp, Wintersemester 06/07
1-69
SOAP Response
<?xml version='1.0' ?>
<soap:Envelope
xmlns:env="http://www.w3.org/2003/05/soap-envelope" >
soap:encodingStyle=http://example.com/encoding
<soap:Body>
<m:ReservationResponse
xmlns:m="http://travelcompany.example.org/">
<return FT35ZBQ</return>
</m:ReservationResponse>
</soap:Body>
</soap:Envelope>
Michael Beigl
Ubicomp, Wintersemester 06/07
1-70
Literatur
ƒ HAVi White Paper
ƒ Choonhwa Lee and Sumi Helal, PROTOCOLS FOR
SERVICE DISCOVERY IN DYNAMIC AND MOBILE
NETWORKS
Michael Beigl
Ubicomp, Wintersemester 06/07
1-71