Ubiquitous Computing. (Ubiquitäre Informationstechnologien) Vorlesung im WS 06/07

Transkript

1 Ubiquitous Computing (Ubiquitäre Informationstechnologien) Vorlesung im WS 06/07 Christian Decker Universität Karlsruhe Institut für Telematik Telecooperation Office

2 Übersicht Vorlesung Ubicomp Geräte und Umgebungen Kommunikation Grundlagen Kabelgebundene Kommunikation Kabellose Kommunikation Kommunikation Sensorknoten Middleware Kontext HCI Ubiquitous Computing WS 06/07 Christian Decker, TecO 8-2

3 Middleware Einführung Kommunikationsparadigmen Jini Service Infrastruktur Bluetooth Salutation OBEX Object Exchange Protokoll HAVi AV Kontrolle UPnP Plug&Play Ubiquitous Computing WS 06/07 Christian Decker, TecO 8-3

4 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

5 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

6 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

7 Middleware Anwendung Anwendung Anwendung APIs Dienst Dienst Dienst Dienst Middleware Plattform (BS, Netz) Plattform (BS, Netz) Platform Interface Ubiquitous Computing WS 06/07 Christian Decker, TecO 8-7

8 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

9 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

10 Middleware Einführung Kommunikationsparadigmen Jini Service Infrastruktur Bluetooth Salutation OBEX Object Exchange Protokoll HAVi AV Kontrolle UPnP Plug&Play Ubiquitous Computing WS 06/07 Christian Decker, TecO 8-10

11 Kommunikationsparadigmen Ablauf einer Kommunikation Initiierung: Auswahl der Kommunikationspartner Wie Auswahl Durchführung: Austausch von Daten Grund Kommunikation Beendigung Auswahl Kom.Grund ID Dienst Kontext Info HTTP IrOBEX Dienst Jini, UPnP, HAVi,Salutation Forschung Kontext Forschung Ubiquitous Computing WS 06/07 Christian Decker, TecO 8-11

12 Kommunikationsparadigmen Ablauf einer Kommunikation Initiierung: Auswahl der Kommunikationspartner Wie Auswahl Durchführung: Austausch von Daten Grund Kommunikation Beendigung Auswahl Kom.Grund ID Dienst Kontext Info HTTP IrOBEX Dienst Jini, UPnP, HAVi, Salutation Kontext Ubiquitous Computing WS 06/07 Christian Decker, TecO 8-12

13 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

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 Ubiquitous Computing WS 06/07 Christian Decker, TecO 8-14

15 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

16 Middleware Einführung Kommunikationsparadigmen Jini Service Infrastruktur OBEX Object Exchange Protokoll UPnP Plug&Play Weiterführende Middlewareansätze Bluetooth Salutation HAVi AV Kontrolle Ubiquitous Computing WS 06/07 Christian Decker, TecO 8-16

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 Ubiquitous Computing WS 06/07 Christian Decker, TecO 8-17

18 Jini Lookup Service Lookup Service lookup Jini Federation register Client use Service Ubiquitous Computing WS 06/07 Christian Decker, TecO 8-18

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 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 IP- Adresse schon kennt Multicast Announcement: LUS meldet sich per Multicast, z.b. nach Ausfall Ubiquitous Computing WS 06/07 Christian Decker, TecO 8-19

20 Discovery Ubiquitous Computing WS 06/07 Christian Decker, TecO 8-20

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 Ubiquitous Computing WS 06/07 Christian Decker, TecO 8-21

22 Join Ubiquitous Computing WS 06/07 Christian Decker, TecO 8-22

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 Ubiquitous Computing WS 06/07 Christian Decker, TecO 8-23

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 Ubiquitous Computing WS 06/07 Christian Decker, TecO 8-24

25 Lookup Ubiquitous Computing WS 06/07 Christian Decker, TecO 8-25

26 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

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 Ubiquitous Computing WS 06/07 Christian Decker, TecO 8-27

28 Jini Architektur Ubiquitous Computing WS 06/07 Christian Decker, TecO 8-28

29 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

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 Ubiquitous Computing WS 06/07 Christian Decker, TecO 8-30

31 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 Quelle: Ubiquitous Computing WS 06/07 Christian Decker, TecO 8-31

32 Middleware Einführung Kommunikationsparadigmen Jini Service Infrastruktur OBEX Object Exchange Protokoll UPnP Plug&Play Weiterführende Middlewareansätze Bluetooth Salutation HAVi AV Kontrolle Ubiquitous Computing WS 06/07 Christian Decker, TecO 8-32

33 (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 Kommunikationsprotokoll Einfaches Protokoll, deshalb: SyncML Darauf aufsetzende Standard-Sync für PDA, Mobiltelefone Palm, Ericsson, IBM, Psion, Motorola Weitere Anwendungen Default Obex-Anwendung OBEX IrDA, Bluetooth... Ubiquitous Computing WS 06/07 Christian Decker, TecO 8-33

34 (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

35 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

36 Middleware Einführung Kommunikationsparadigmen Jini Service Infrastruktur OBEX Object Exchange Protokoll UPnP Plug&Play Weiterführende Middlewareansätze Bluetooth Salutation HAVi AV Kontrolle Ubiquitous Computing WS 06/07 Christian Decker, TecO 8-36

37 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

38 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

39 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

40 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

41 Intel-Tools Einsatz Control Point Device Device Spy Device Validator Control HTTP/SOAP Discovery SSDP Service Author Device Sniffer Ubiquitous Computing WS 06/07 Christian Decker, TecO 8-41

42 Intel Tools II AV Media Controller AV Media Wizard AV Media Server UPnP AV Media Controller UPnP AV AV Media Rendere Media Server Media Stream Media Renderer Ubiquitous Computing WS 06/07 Christian Decker, TecO 8-42

43 UPnP Architektur UPnP Vendor Defined UPnP Forum Defined UPnP Device Architecture (DCP)(Presentation) GENA SSDP HTTP Multicast/Unicast ((2)Discovery) UDP SOAP (Control) HTTP ((3)Descr.) TCP IP GENA Ubiquitous Computing WS 06/07 Christian Decker, TecO 8-43

44 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

45 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

46 Beispielablauf Device Discovery NOTIFY (URL oder XML) Control Point HTTP Get (XML) HTTP Response (XML) Device Anstoß Aktion Control Point HTTP M-POST (SOAP action) HTTP Response (SOAP response) Device Ubiquitous Computing WS 06/07 Christian Decker, TecO 8-46

47 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

48 SOAP: Typen in Messages Typen spezifiziert als XML Dokument Beispiel Integer array <iarray xsi:type=soap-enc:array SOAP- ENC: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

49 SOAP Beispiel Request <?xml version='1.0'?> <soap:envelope xmlns:soap=" soap:encodingstyle=" > <soap:body> <m:reservation xmlns:m=" ation"> <CardNumber xsi:type= int"> </CardNumber> <Name xsi:type= string > M Muster </n:name> </m:reservation> </soap:body> </soap:envelope>

50 SOAP Response <?xml version='1.0'?> <soap:envelope xmlns:env=" > soap:encodingstyle= <soap:body> <m:reservationresponse xmlns:m=" <return FT35ZBQ</return> </m:reservationresponse> </soap:body> </soap:envelope> Ubiquitous Computing WS 06/07 Christian Decker, TecO 8-50

51 Weitere Middleware Ansätze Ubiquitous Computing WS 06/07 Christian Decker, TecO 8-51

52 Middleware Einführung Kommunikationsparadigmen Jini Service Infrastruktur OBEX Object Exchange Protokoll UPnP Plug&Play Weiterführende Middlewareansätze Bluetooth Salutation HAVi AV Kontrolle Ubiquitous Computing WS 06/07 Christian Decker, TecO 8-52

53 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

54 Bluetooth: L2CAP, PSM 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. Service Discovery Protocol (SDP) RFCOMM Telephony Control Protocol Specification (TCS) HCI Weitere Dienste /Anwendungen OBEX RFCOMM TCS SDP L2CAP Link,Baseband RF (Hardware) Ubiquitous Computing WS 06/07 Christian Decker, TecO 8-54

55 Bluetooth SDP Service Discovery Protocol (SDP) Ubiquitous Computing WS 06/07 Christian Decker, TecO 8-55

56 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

57 Vernetzung: höhere Schichten Einführung Kommunikationsparadigmen Jini Service Infrastruktur OBEX Object Exchange Protokoll UPnP Plug&Play Weiterführende Middlewareansätze Bluetooth Salutation HAVi AV Kontrolle Ubiquitous Computing WS 06/07 Christian Decker, TecO 8-57

58 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

59 Salutation Service Discovery Aufgaben Salutation Manager (SLM) Service Registry Service Discovery Service Availability Service Session Management Ablauf Client Salutation Manager slmsearchcapability call reply slmquerycapability call reply Salutation Protocol QueryCapability call to all known SLM reply QueryCapability call to one SLM reply Salutation Manager slmregistercapability Server Ubiquitous Computing WS 06/07 Christian Decker, TecO 8-59

60 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

61 Beispiel Ubiquitous Computing WS 06/07 Christian Decker, TecO 8-61

62 Middleware Einführung Kommunikationsparadigmen Jini Service Infrastruktur OBEX Object Exchange Protokoll UPnP Plug&Play Weiterführende Middlewareansätze Bluetooth Salutation HAVi AV Kontrolle Ubiquitous Computing WS 06/07 Christian Decker, TecO 8-62

63 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

64 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

65 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

66 Device Classes Controller Devices Full Full AV AV device (FAV) Download and and execute all all HAVi HAViapplications Download and and execute DCM DCM Intermediate AV AV device (IAV) Ability Ability to to communicate with with other other HAVi HAVidevice Ability Ability to to execute limited limited applications Offers Offers own own control control service service Ability Ability to to host host other other known known device device Base Base AV AV device device (BAV) (BAV) Offers Offers own own information in in ROM ROM Legacy AV AV device device (LAV) (LAV) Conventional devices with with NO NO HAVi HAViSDD data data (ROM) (ROM) Ubiquitous Computing WS 06/07 Christian Decker, TecO 8-66

67 HAVi Architecture Application Application havlet Interoperability API (native binding) Interop.. API (Java binding) Messaging Event Mgr Registry 394 Manager Stream Mgr Resource Mgr DCM DCM DCM Manager DCM Porting Layer optional Level I UI Engine DCM DCM org.havi havi... JVM DCM Vendor-specific Platform (RTOS) 1394 Device Drivers Other Device Drivers Ubiquitous Computing WS 06/07 Christian Decker, TecO 8-67

68 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 Ubiquitous Computing WS 06/07 Christian Decker, TecO 8-68

69 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

70 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

71 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

72 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

73 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