Ubiquitous Computing

Transcription

Ubiquitous Computing
(Ubiquitäre Informationstechnologien)
Vorlesung im WS 04/05
Michael Beigl
Universität Karlsruhe
Institut für Telematik
Telecooperation Office
www.teco.uni-karlsruhe.de
Aufbau der Vorlesung
1
2
3
Grundlagen
5 Information
Geräte
6 Interaktion
Vernetzung
7 Anwendungen
Netzwerke
Middleware
4
7
Kontext
Anwendungen
6
Geräte
2
Kontext
Interaktion
3
4
Vernetzung
digitale Welt
reale Welt
(vorverarbeitete)
Information
Ubiquitous Computing WS 04/05 Michael Beigl, TecO
5
8-2
Vernetzung: höhere Schichten
nEinführung
nKommunikationsparadigmen
nJini Service Infrastruktur
nBluetooth
nSalutation
nOBEX Object Exchange Protokoll
nHAVi AV Kontrolle
nUPnP Plug&Play
8-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
8-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
8-5
Middleware
Was ist Middleware ?
§ „der Slash in Client/Server“
§ 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,...
8-6
Middleware
Anwendung
Anwendung
Anwendung
APIs
Dienst
Dienst
Dienst
Plattform
(BS, Netz)
Middleware
Dienst
Plattform
Platform
Interface
(BS, Netz)
8-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
8-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)
8-9
nEinführung
nBluetooth
nSalutation
nHAVi AV Kontrolle
nUPnP Plug&Play
8-10
Kommunikationsparadigmen
Ablauf einer Kommunikation
§ Initiierung: Auswahl der Kommunikationspartner
Wie Auswahl
§ Durchführung: Austausch von Kommunikation
Grund Kommunikation
§ Beendung
Kom.Grund
Auswahl
ID
Info
Dienst
Dienst
HTTP
Kontext
IrOBEX
Jini, UPnP, HAVi,Salutation
Kontext
RAUM
8-11
Kommunikationsparadigmen
Ablauf einer Kommunikation
§ Initiierung: Auswahl der Kommunikationspartner
Wie Auswahl
§ Durchführung: Austausch von Kommunikation
Grund Kommunikation
§ Beendung
Kom.Grund
Auswahl
ID
Info
Dienst
Dienst
HTTP
Kontext
IrOBEX
Jini, UPnP, HAVi, Salutation
Kontext
RAUM
8-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, ...
8-13
Service Federation: Beispiel
Photo
Speicher
Photo-Mail
Service
Digitaler
Bilderrahmen
Netz
Camera
(client)
Druck
Service
8-14
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
8-15
Service Paradigma
Spontane Vernetzung von Services
§ wie werden Services aufeinander aufmerksam ?
§ wie können bestimmte Services in einer fremden Umgebung
gefunden werden ?
§ 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
8-16
nEinführung
nBluetooth
nSalutation
nHAVi AV Kontrolle
nUPnP Plug&Play
8-17
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
8-18
Jini Lookup Service
Client
Jini
Federation
use
er
ist
reg
loo
ku
p
Lookup
Service
Service
8-19
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 (interface ServiceRegistrar)
§ 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
8-20
Discovery
8-21
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
8-22
Join
8-23
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
8-24
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
8-25
Lookup
8-26
Service Invocation
§ Client kann nun auf Service zugreifen
§ Protokoll zwischen Client und Service nicht festgelegt
8-27
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
8-28
Jini Architektur
8-29
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
8-30
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
8-31
nEinführung
nBluetooth
nSalutation
nHAVi AV Kontrolle
nUPnP Plug&Play
8-32
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
§
....
8-33
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)
8-34
Bluetooth SDP
Service Discovery Protocol (SDP)
8-35
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)
8-36
nEinführung
nBluetooth
nSalutation
nHAVi AV Kontrolle
nUPnP Plug&Play
8-37
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
8-38
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
8-39
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)
8-40
Beispiel
8-41
nEinführung
nBluetooth
nSalutation
nHAVi AV Kontrolle
nUPnP Plug&Play
8-42
(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
§ Einfaches Protokoll, deshalb:
Default
Obex-Anwendung
SyncML
§ Darauf aufsetzende Standard-Sync für
PDA, Mobiltelefone
§ Palm, Ericsson, IBM, Psion, Motorola
OBEX
IrDA, Bluetooth...
8-43
(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
§ Paket: Opcode len Objekte
§ 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
8-44
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
8-45
nEinführung
nBluetooth
nSalutation
nHAVi AV Kontrolle
nUPnP Plug&Play
8-46
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
8-47
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
8-48
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
8-49
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
Abilitytotocommunicate
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)
8-50
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
DCM
optional
Level I
UI Engine
Porting Layer
DCM Manager
org.havi...
JVM
Vendor-specific Platform (RTOS)
1394 Device Drivers
Other Device Drivers
8-51
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 Platform
DCM Ausführung
§ Bytecode DCM – DCM implemetiert als Java bytecode
§ Standard DCM – DCM stellt Standard HAVI APIs nativ zur
Verfügung
DCM Inhalt
§ Code für DCM
§Ubiquitous
Code für
(FCMs) für jede funktionale Komponente in Gerät 8-52
Computing WS 04/05 Michael Beigl, TecO
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
Resource Manager
§ Ressource-Sharing und Aufgaben-Scheduling
8-53
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) Adressierungsschma
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
8-54
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: Setzten 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
8-55
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
8-56
nEinführung
nBluetooth
nSalutation
nHAVi AV Kontrolle
nUPnP Plug&Play
8-57
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
§ Eingesetzt derzeit vor allem für „NAT Traversal“
in Firewalls/DSL
§ Basiert auf IP, benötigt DHCP, XML, HTTP
Control Point
Device
Service
Device
Control Point
Service
8-58
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
8-59
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
8-60
Intel Toolkit
Zehn “Tools” zur Unerstützung von UPnP
Entwicklungen
§ 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
8-61
Intel-Tools Einsatz
Control Point
Device Spy
Device Validator
Device
Control
HTTP/SOAP
Discovery
SSDP
Service Author
Device Sniffer
8-62
Intel Tools II
AV Media Controller
AV Media Wizard
AV Media Server
Media Controller
AV Media Renderer
UPnP AV
Media Server
UPnP AV
Media
Stream
Media Renderer
8-63
UPnP Architektur
UPnP Vendor Defined
UPnP Forum Defined
UPnP Device Architecture (DCP)(Presentation)
SOAP (Control)
SSDP
GENA
HTTP Multicast/Unicast
((2)Discovery)
HTTP ((3)Descr.) GENA
UDP
TCP
IP
8-64
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
8-65
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
8-66
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)
8-67
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
8-68
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>
8-69
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>
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>
8-71
Literatur
§ HAVi White Paper
§ Choonhwa Lee and Sumi Helal, PROTOCOLS FOR
SERVICE DISCOVERY IN DYNAMIC AND MOBILE
NETWORKS
8-72

Ubiquitous Computing

Transcription

Similar documents

WWICE Œ An architecture for In

Bitte klickt auf die Fragen um zu den Antworten

Wer bleibt drin, wer fliegt raus?

PlayStation 3 Hands On bei Gamescathedral [Alle Infos zum Launch]

PyBox - A Python approach to sandboxing