Ubiquitous Computing

Ubiquitous Computing
(Ubiquitäre Informationstechnologien)
Vorlesung im WS 06/07
Christian Decker
Universität Karlsruhe
Institut für Telematik
Telecooperation Office
www.teco.uni-karlsruhe.de
Übersicht
Vorlesung Ubicomp
oGeräte und Umgebungen
oKommunikation
o Grundlagen
o Kabelgebundene Kommunikation
o Kabellose Kommunikation
o Kommunikation Sensorknoten
o Middleware
oKontext
oHCI
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-2
Middleware
nEinführung
nKommunikationsparadigmen
nJini Service Infrastruktur
nBluetooth
nSalutation
nOBEX Object Exchange Protokoll
nHAVi AV Kontrolle
nUPnP Plug&Play
Ubiquitous Computing WS 06/07 Christian Decker, TecO
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‘n‘Play, mobile Netze,
kurzlebige Verbindungen
Ubiquitous Computing WS 06/07 Christian Decker, TecO
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 kommuniziert man 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
Ubiquitous Computing WS 06/07 Christian Decker, TecO
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,...
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-6
Middleware
Anwendung
Anwendung
Anwendung
APIs
Dienst
Dienst
Dienst
Plattform
(BS, Netz)
Middleware
Dienst
Plattform
Platform
Interface
(BS, Netz)
Ubiquitous Computing WS 06/07 Christian Decker, TecO
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
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-8
Middleware für Ubicomp
Integration heterogener Geräte
§ Gateways für kohärenten Zugang zu heterogenen Umgebungen
§ Service Paradigma: abstrahierte, beschriebene Funktionalität; 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)
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-9
Middleware
nEinführung
nKommunikationsparadigmen
nJini Service Infrastruktur
nBluetooth
nSalutation
nOBEX Object Exchange Protokoll
nHAVi AV Kontrolle
nUPnP Plug&Play
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-10
Kommunikationsparadigmen
Ablauf einer Kommunikation
§ Initiierung: Auswahl der Kommunikationspartner
Wie Auswahl
§ Durchführung: Austausch von Daten
Grund Kommunikation
§ Beendigung
Kom.Grund
Auswahl
ID
Info
Dienst
Dienst
Kontext
HTTP
IrOBEX
Jini, UPnP, HAVi,Salutation
Kontext
Ubiquitous Computing WS 06/07 Christian Decker, TecO
Forschung
Forschung
8-11
Kommunikationsparadigmen
Ablauf einer Kommunikation
§ Initiierung: Auswahl der Kommunikationspartner
Wie Auswahl
§ Durchführung: Austausch von Daten
Grund Kommunikation
§ Beendigung
Kom.Grund
Auswahl
ID
Info
Dienst
Dienst
HTTP
Kontext
IrOBEX
Jini, UPnP, HAVi, Salutation
Kontext
Ubiquitous Computing WS 06/07 Christian Decker, TecO
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, ...
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-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
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-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
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-15
Middleware
nEinführung
nKommunikationsparadigmen
nJini Service Infrastruktur
nOBEX Object Exchange Protokoll
nUPnP Plug&Play
Weiterführende Middlewareansätze
nBluetooth
nSalutation
nHAVi AV Kontrolle
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-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
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-17
Jini Lookup Service
Client
Jini
Federation
use
Ubiquitous Computing WS 06/07 Christian Decker, TecO
er
ist
reg
loo
ku
p
Lookup
Service
Service
8-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
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-19
Discovery
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-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
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-21
Join
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-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
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-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
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-24
Lookup
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-25
Service Invocation
§ Client kann nun auf Service zugreifen
§ Protokoll zwischen Client und Service nicht festgelegt
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-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
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-27
Jini Architektur
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-28
Programmiermodell
Leases
§ Client fordert Lease für die Nutzung einer Ressource 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
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-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
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-30
Jini Surrogates
Motivation
§ Anbindung von Geräten, die nicht direkt Jini unterstützen
§ Für Geräte, die
§ Kein Code Download unterstützen
§ Limitierte Rechen- und Netzwerkressourcen besitzen
Eigenschaften der Surrogate Architektur
§ Device type independence
§ Network type independence
§ Preserve plug-and-work
Ubiquitous Computing WS 06/07 Christian Decker, TecO
Quelle: https://surrogate.dev.java.net
8-31
Middleware
nEinführung
nKommunikationsparadigmen
nJini Service Infrastruktur
nOBEX Object Exchange Protokoll
nUPnP Plug&Play
Weiterführende Middlewareansätze
nBluetooth
nSalutation
nHAVi AV Kontrolle
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-32
(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
Ubiquitous Computing WS 06/07 Christian Decker, TecO
OBEX
IrDA, Bluetooth...
8-33
(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
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-34
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
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-35
Middleware
nEinführung
nKommunikationsparadigmen
nJini Service Infrastruktur
nOBEX Object Exchange Protokoll
nUPnP Plug&Play
Weiterführende Middlewareansätze
nBluetooth
nSalutation
nHAVi AV Kontrolle
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-36
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 P‘n‘P Geräte
§ Service-Konzept
§ Eingesetzt derzeit vor allem für Konfiguration,
Statusabfrage z.B. bei Routern
§ Basiert auf IP, benötigt DHCP, XML, HTTP
Control Point
Device
Service
Device
Control Point
Service
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-37
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
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-38
UPnP <service> Element
Enthält
§ Service-Typ: URI, die Service ident., Standardtypen
§ 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
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-39
Intel Toolkit
Zehn “Tools” zur Unerstützung von UPnP Entwicklungen
§ Z.T. mit Standard-Schnittstelle, 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
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-40
Intel-Tools Einsatz
Control Point
Device Spy
Device Validator
Device
Control
HTTP/SOAP
Ubiquitous Computing WS 06/07 Christian Decker, TecO
Discovery
SSDP
Service Author
Device Sniffer
8-41
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
Ubiquitous Computing WS 06/07 Christian Decker, TecO
Media Renderer
8-42
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
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-43
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 (XML over HTTPMU)
§ 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
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-44
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
§ Control nur über Änderungen von Zustandsvariablen
§ „RPC über HTTP“
Event
§ IETF Draft General Event Notification Architecture (GENA)
§ 3 Kommandos/Events:
Subscribe / Unsubscribe / Notify von Meldungen
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-45
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)
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-46
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)
§ W3C standard
§ Typen definierbar
§ Soap encoding: Envelope bestehend aus Header
(optional) + Body
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-47
SOAP: Typen in Messages
Typen spezifiziert als XML Dokument
Beispiel Integer array
§ <iArray xsi:type=SOAP-ENC:Array SOAPENC:arrayType="xsd:int[3]">
§ <val>10</val>
§ <val>3</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>
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-48
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>
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-50
Weitere Middleware Ansätze
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-51
Middleware
nEinführung
nKommunikationsparadigmen
nJini Service Infrastruktur
nOBEX Object Exchange Protokoll
nUPnP Plug&Play
Weiterführende Middlewareansätze
nBluetooth
nSalutation
nHAVi AV Kontrolle
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-52
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
§
....
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-53
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)
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-54
Bluetooth SDP
Service Discovery Protocol (SDP)
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-55
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)
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-56
Vernetzung: höhere Schichten
nEinführung
nKommunikationsparadigmen
nJini Service Infrastruktur
nOBEX Object Exchange Protokoll
nUPnP Plug&Play
Weiterführende Middlewareansätze
nBluetooth
nSalutation
nHAVi AV Kontrolle
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-57
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
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-58
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
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-59
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)
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-60
Beispiel
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-61
Middleware
nEinführung
nKommunikationsparadigmen
nJini Service Infrastruktur
nOBEX Object Exchange Protokoll
nUPnP Plug&Play
Weiterführende Middlewareansätze
nBluetooth
nSalutation
nHAVi AV Kontrolle
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-62
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
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-63
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
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-64
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
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-65
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)
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-66
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
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-67
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
§Ubiquitous
Code für
(FCMs) für jede funktionale Komponente in Gerät 8-68
Computing WS 06/07 Christian Decker, 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
Ressource Manager
§ Ressource-Sharing und Aufgaben-Scheduling
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-69
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
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-70
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
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-71
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
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-72
Literatur
§ HAVi White Paper
§ Choonhwa Lee and Sumi Helal, PROTOCOLS FOR
SERVICE DISCOVERY IN DYNAMIC AND MOBILE
NETWORKS
Ubiquitous Computing WS 06/07 Christian Decker, TecO
8-73