Ubiquitous Computing
Werbung
Ubiquitous Computing (Ubiquitäre Informationstechnologien) Vorlesung im WS 05/06 Michael Beigl Universität Karlsruhe Institut für Telematik Telecooperation Office www.teco.uni-karlsruhe.de Übersicht Vorlesung Ubicomp oGeräte und Umgebungen oCommunication o Grundlagen o Kabelgebundene Kommunikation o Kabellose Kommunikation o Kommunikation Sensorknoten o Middleware oContext oHCI Ubiquitous Computing WS 05/06 Michael Beigl, 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 05/06 Michael Beigl, 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 Play, mobile Netze, kurzlebige Verbindungen Ubiquitous Computing WS 05/06 Michael Beigl, 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 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 Ubiquitous Computing WS 05/06 Michael Beigl, 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 05/06 Michael Beigl, TecO 8-6 Middleware Anwendung Anwendung Anwendung APIs Dienst Dienst Dienst Plattform (BS, Netz) Middleware Dienst Plattform Platform Interface (BS, Netz) Ubiquitous Computing WS 05/06 Michael Beigl, 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 05/06 Michael Beigl, TecO 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) Ubiquitous Computing WS 05/06 Michael Beigl, 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 05/06 Michael Beigl, TecO 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 Kontext HTTP IrOBEX Jini, UPnP, HAVi,Salutation Kontext Ubiquitous Computing WS 05/06 Michael Beigl, TecO Forschung Forschung 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 Ubiquitous Computing WS 05/06 Michael Beigl, 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 05/06 Michael Beigl, 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 05/06 Michael Beigl, 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 05/06 Michael Beigl, TecO 8-15 Middleware nEinführung nKommunikationsparadigmen nJini Service Infrastruktur nBluetooth nSalutation nOBEX Object Exchange Protokoll nHAVi AV Kontrolle nUPnP Plug&Play Ubiquitous Computing WS 05/06 Michael Beigl, 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 05/06 Michael Beigl, TecO 8-17 Jini Lookup Service Client Jini Federation use Ubiquitous Computing WS 05/06 Michael Beigl, 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 05/06 Michael Beigl, TecO 8-19 Discovery Ubiquitous Computing WS 05/06 Michael Beigl, 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 05/06 Michael Beigl, TecO 8-21 Join Ubiquitous Computing WS 05/06 Michael Beigl, 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 05/06 Michael Beigl, 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 05/06 Michael Beigl, TecO 8-24 Lookup Ubiquitous Computing WS 05/06 Michael Beigl, TecO 8-25 Service Invocation § Client kann nun auf Service zugreifen § Protokoll zwischen Client und Service nicht festgelegt Ubiquitous Computing WS 05/06 Michael Beigl, 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 05/06 Michael Beigl, TecO 8-27 Jini Architektur Ubiquitous Computing WS 05/06 Michael Beigl, TecO 8-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 Ubiquitous Computing WS 05/06 Michael Beigl, 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 05/06 Michael Beigl, TecO 8-30 Middleware nEinführung nKommunikationsparadigmen nJini Service Infrastruktur nBluetooth nSalutation nOBEX Object Exchange Protokoll nHAVi AV Kontrolle nUPnP Plug&Play Ubiquitous Computing WS 05/06 Michael Beigl, TecO 8-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 § .... Ubiquitous Computing WS 05/06 Michael Beigl, TecO 8-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) Ubiquitous Computing WS 05/06 Michael Beigl, TecO 8-33 Bluetooth SDP Service Discovery Protocol (SDP) Ubiquitous Computing WS 05/06 Michael Beigl, TecO 8-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) Ubiquitous Computing WS 05/06 Michael Beigl, TecO 8-35 Vernetzung: höhere Schichten nEinführung nKommunikationsparadigmen nJini Service Infrastruktur nBluetooth nSalutation nOBEX Object Exchange Protokoll nHAVi AV Kontrolle nUPnP Plug&Play Ubiquitous Computing WS 05/06 Michael Beigl, TecO 8-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 Ubiquitous Computing WS 05/06 Michael Beigl, TecO 8-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 Ubiquitous Computing WS 05/06 Michael Beigl, TecO 8-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) Ubiquitous Computing WS 05/06 Michael Beigl, TecO 8-39 Beispiel Ubiquitous Computing WS 05/06 Michael Beigl, TecO 8-40 Middleware nEinführung nKommunikationsparadigmen nJini Service Infrastruktur nBluetooth nSalutation nOBEX Object Exchange Protokoll nHAVi AV Kontrolle nUPnP Plug&Play Ubiquitous Computing WS 05/06 Michael Beigl, TecO 8-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 § Einfaches Protokoll, deshalb: Default Obex-Anwendung SyncML § Darauf aufsetzende Standard-Sync für PDA, Mobiltelefone § Palm, Ericsson, IBM, Psion, Motorola Ubiquitous Computing WS 05/06 Michael Beigl, TecO OBEX IrDA, Bluetooth... 8-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 § 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 05/06 Michael Beigl, TecO 8-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 Ubiquitous Computing WS 05/06 Michael Beigl, TecO 8-44 Middleware nEinführung nKommunikationsparadigmen nJini Service Infrastruktur nBluetooth nSalutation nOBEX Object Exchange Protokoll nHAVi AV Kontrolle nUPnP Plug&Play Ubiquitous Computing WS 05/06 Michael Beigl, TecO 8-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 Ubiquitous Computing WS 05/06 Michael Beigl, TecO 8-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 Ubiquitous Computing WS 05/06 Michael Beigl, TecO 8-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 Ubiquitous Computing WS 05/06 Michael Beigl, TecO 8-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 Abilityto toexecute executelimited limitedapplications applications ••Offers Offersown owncontrol controlservice service ••Ability Abilityto tohost hostother 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 05/06 Michael Beigl, TecO 8-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 DCM optional Level I UI Engine Porting Layer DCM Manager org.havi... JVM Vendor-specific Platform (RTOS) 1394 Device Drivers Ubiquitous Computing WS 05/06 Michael Beigl, TecO Other Device Drivers 8-50 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-51 Computing WS 05/06 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 Ressource Manager § Ressource-Sharing und Aufgaben-Scheduling Ubiquitous Computing WS 05/06 Michael Beigl, TecO 8-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 Ubiquitous Computing WS 05/06 Michael Beigl, TecO 8-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 Ubiquitous Computing WS 05/06 Michael Beigl, TecO 8-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 Ubiquitous Computing WS 05/06 Michael Beigl, TecO 8-55 Middleware nEinführung nKommunikationsparadigmen nJini Service Infrastruktur nBluetooth nSalutation nOBEX Object Exchange Protokoll nHAVi AV Kontrolle nUPnP Plug&Play Ubiquitous Computing WS 05/06 Michael Beigl, TecO 8-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 Control Point Device Service Device Control Point Service Ubiquitous Computing WS 05/06 Michael Beigl, TecO 8-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 Ubiquitous Computing WS 05/06 Michael Beigl, TecO 8-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 Ubiquitous Computing WS 05/06 Michael Beigl, TecO 8-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 Ubiquitous Computing WS 05/06 Michael Beigl, TecO 8-60 Intel-Tools Einsatz Control Point Device Spy Device Validator Device Control HTTP/SOAP Ubiquitous Computing WS 05/06 Michael Beigl, TecO Discovery SSDP Service Author Device Sniffer 8-61 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 05/06 Michael Beigl, TecO Media Renderer 8-62 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 Ubiquitous Computing WS 05/06 Michael Beigl, TecO 8-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 Ubiquitous Computing WS 05/06 Michael Beigl, TecO 8-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 Ubiquitous Computing WS 05/06 Michael Beigl, TecO 8-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) Ubiquitous Computing WS 05/06 Michael Beigl, TecO 8-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 Ubiquitous Computing WS 05/06 Michael Beigl, TecO 8-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> Ubiquitous Computing WS 05/06 Michael Beigl, TecO 8-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> 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 05/06 Michael Beigl, TecO 8-70 Literatur § HAVi White Paper § Choonhwa Lee and Sumi Helal, PROTOCOLS FOR SERVICE DISCOVERY IN DYNAMIC AND MOBILE NETWORKS Ubiquitous Computing WS 05/06 Michael Beigl, TecO 8-71