Ambient Intelligence WS 2014/2015

Transkript

1 Ambient Intelligence WS 2014/2015 Vorlesung 7 Interoperability II Software Interoperability Carsten Stocklöw FB Informatik GRIS Fraunhofer IGD

2 Matrix Vorlesungen Organisation & Einführung Andreas Smart Living Domains Helmi Hardware Interoperabilität Tobias Einführung Interaktion Biying AmI in Praxis universaal Helmi & Carsten Smart Living Automation Helmi Software Interoperabilität Carsten Implizite Interaktion Andreas Kapazitive Systeme Silvia Smart Living Context Awareness Carsten Semantische Interoperabilität Helmi Explizite Interaktion Saied Sicherheit von AmI Saied Zukunft von AmI Tobias Block 1 Block 2 Block 3 Block 4 Block 5 Einführung Smart Environments Interoperabilität User Interaction Vertiefende Themen

3 Agenda Einführung Definition, Grundlagen, Motivation Protokolle Beispiele: Kommunikation, Discovery Interprozesskommunikation RPC, RMI, CORBA, SOAP Architekturen SOA, Webservices, Continua, UPnP Standardisierung Organisationen, Konformität, Middleware FB Informatik GRIS Fraunhofer IGD

4 Definition (Hardware) Interoperability is a property of a product or system, whose interfaces are completely understood, to work with other products or systems, present or future, without any restricted access or implementation. [Wikipedia] ISO/IEC: Interoperability [is] the capability to communicate, execute programs, or transfer data among various functional units in a manner that requires the user to have little or no knowledge of the unique characteristics of those units Wikipedia: Interoperability is a property referring to the ability of diverse systems and organizations to work together (inter-operate) IEEE: [Interoperability is] the ability of two or more systems (or components) to exchange information and to use the information that has been exchanged FB Informatik GRIS Fraunhofer IGD

5 Abgrenzung Man unterscheidet grundlegend zwischen syntaktischer Interoperabilität und semantischer Interoperabilität Syntax (von gr. suntaxiς) Definition des Duden: in einer Sprache übliche Verbindung von Wörtern zu Wortgruppen und Sätzen; korrekte Verknüpfung sprachlicher Einheiten im Satz Semantik (von gr. semantikoς) Definition des Duden: Bedeutung, Inhalt (eines Wortes, Satzes oder Textes) FB Informatik GRIS Fraunhofer IGD

6 Standards Einige der für den AmI-Bereich relevanten Standards und Normen (und nein, müsst Ihr nicht auswendig lernen ;-) ) Kabelgebundene Netzwerke: Ethernet (32 Varianten!), HomePlug, HomePlugAV, Punkt-zu-Punkt: DisplayPort, DVI, FireWire, HDMI, SCART, USB, Feldbusssysteme: BACnet, BatiBUS, EHS, KNX/EIB, LON, Drahtlose Netze: WLAN, ZigBee, Z-Wave, EnOcean, Bluetooth, DECT, HomeRF, Netzwerkprotokolle: AFP, BitTorrent, Bonjour/Zeroconf, CalDAV, CUPS, DHCP, DNS, DPWS, DynDNS, FTP, HTTP, IMAP, IPP, IRC, JetDirect, LDAP, LPR, NAT-PMP, NFS, OMA DM, POP3, RTP, RTSP, SIP, SMB, SMTP, SNMP, SSDP, SSH, TFTP, TR-069, UPnP, WebDAV, CHAIN/AIS, Medizintechnik: aecg, CCD, CCR, CDA, DICOM, EDF, EDIFACT, HL7, IHE, ISO/EN 13606, ISO/IEEE 11073, PHMR, SCP-ECG, xdt, XPHR, ICD-10, ICHI, ICPM, LOINC, OPS, SNOMED, UCUM, UMLS, Laufzeitumgebungen/Betriebssysteme (jeweils verschiedene Versionen): OSGi,.NET, JVM, Android, ios, Windows, MacOs, Linux, Unix, Middleware: Agentensysteme, SOA, Ereignisbasierte, URC, FB Informatik GRIS Fraunhofer IGD Quelle: Dr. Marco Eichelberg, OFFIS-Institut für Informatik, Oldenburg

7 Worum geht s? The beauty of standards is that there are so many to chose from! -- Prof. Andrew Tanenbaum, Betriebssystemguru FB Informatik GRIS Fraunhofer IGD

8 Herausforderungen FB Informatik GRIS Fraunhofer IGD Bildquelle:

9 Herausforderungen Die Lösung des Interoperabilitätsproblems ist zentral für Ambient Intelligence denn hier sollen ja Geräte und Dienste (!) aus vielen verschiedenen Anwendungsbereichen zusammenarbeiten Nachfolgend einige der Hindernisse, die die Interoperabilität der für den AmI-Bereich relevanten Hardware- und/oder Softwarekomponenten erschweren FB Informatik GRIS Fraunhofer IGD

10 Herausforderungen Herausforderung: Mangelnde awareness auf Seiten der Geräte-/Softwarehersteller Es wird nicht berücksichtigt, dass Geräte/Softwarekomponenten sich in einen größeren Verbund einbinden lassen und dabei ggf. auch (sinnvoll) zweckentfremdet werden könnten Daher keine oder nur stark eingeschränkte API, Nutzung eines proprietären Protokolls, FB Informatik GRIS Fraunhofer IGD

11 Herausforderungen Herausforderung: Kein Interesse der Hersteller an Interoperabilität (Stichwort customer lock-in) Vor allem für große Hersteller kann mangelnde Interoperabilität von Vorteil sein, denn sie garantiert Kundenbindung Nachdem eine kritische Investitionsmasse bei einem Hersteller erfolgte, wird der Kunde nur sehr unwillig zu Konkurrenten wechseln Strategie nur möglich für große Hersteller mit entsprechend breiter Produktpalette Schädigt effektiv kleinere Hersteller, die nur Nischen besetzen können FB Informatik GRIS Fraunhofer IGD

12 Herausforderungen Herausforderung: Vorhandene Altgeräte und Kostenfaktor Nicht-interoperable Altgeräte werden vom Kunden nur langsam ersetzt Beispiel: Kühlschrank Lebensdauer ~ 15 Jahre Speziell auf Vernetzung ausgelegte Geräte oftmals deutlich teurer als Standardgeräte Zudem dann auch meist Bestrebung in Richtung customer lock-in FB Informatik GRIS Fraunhofer IGD

13 Herausforderungen Herausforderung: Fehlende Standards IT-Bereich sehr lebendig, ständig neue Entwicklungen und Trends Neue Fragestellungen oft noch nicht ausreichend analysiert wenn erste Lösung benötigt Resultat: proprietäre Ansätze und Hacks Standardisierungsprozess aufwendig ( brauchen wir nicht, bringt uns nichts ) kann zu konkurrierenden Quasi-Standards führen (nächste Folie) FB Informatik GRIS Fraunhofer IGD

14 Herausforderungen Herausforderung: Konkurrierende Standards Idealerweise gäbe es für jeden Schnittstellentyp eine einzige, genau definierte Norm Tatsächlich aber viel zu oft überlappende oder konkurrierende Standards: Gebäudeautomation: KNX/EIB, LON, BACnet Drahtlose Netze: Bluetooth, ZigBee, WLAN, Z-Wave EKG-Dateiformate: DICOM, HL7 aecg, SCP-ECG FB Informatik GRIS Fraunhofer IGD Quelle: Dr. Marco Eichelberg, OFFIS-Institut für Informatik, Oldenburg

15 Agenda Einführung Definition, Grundlagen, Motivation Protokolle Beispiele: Kommunikation, Discovery Interprozesskommunikation RPC, RMI, CORBA, SOAP Architekturen SOA, Webservices, Continua, UPnP Standardisierung Organisationen, Konformität, Middleware FB Informatik GRIS Fraunhofer IGD

16 Protokolle Protokolle gibt es SEHR viele Definition Protokoll in IT: Regeln, die von den Endpunkten einer Kommunikationsverbindung für die Kommunikation verwendet werden (vom griechischen protocollon: ein auf einem Buchband klebendes Stück Papier mit Informationen über Verfasser und Entstehung)

17 Kommunikationsprotokolle Einige Beispiele: ZigBee, Bluetooth (schon gesehen) File Transfer Protocol (FTP) Spezifiziert im RFC 959 von 1985 Netzwerkprotokoll zur Dateiübertragung über TCP/IP-Netzwerke. FTP ist in der Anwendungsschicht (Schicht 7) des OSI-Schichtenmodells angesiedelt. Es wird benutzt, um Dateien vom Server zum Client (Download), vom Client zum Server (Upload) oder clientgesteuert zwischen zwei Endgeräten zu übertragen. Außerdem können mit FTP Verzeichnisse angelegt und ausgelesen, sowie Verzeichnisse und Dateien umbenannt oder gelöscht werden

18 Kommunikationsprotokolle Hypertext Transfer Protocol (HTTP) ist ein Protokoll zur Übertragung von Daten über ein Netzwerk. Es wird hauptsächlich eingesetzt, um Webseiten und andere Daten aus dem World Wide Web (WWW) in einen Webbrowser zu laden. Im Kern ist HTTP ein zustandsloses Protokoll. Das bedeutet auch, dass nach erfolgreicher Datenübertragung die Verbindung zwischen den beiden Kommunikationspartnern nicht aufrechterhalten zu werden braucht. Sollen weitere Daten übertragen werden, muss zunächst eine weitere Verbindung aufgebaut werden. Auch ein zuverlässiges Mitführen von Sitzungsdaten kann erst auf der Anwendungsschicht durch eine Sitzung implementiert werden. (Cookies!) Zur Kommunikation ist HTTP auf ein zuverlässiges Transportprotokoll angewiesen. In nahezu allen Fällen wird hierfür TCP/IP verwendet.

19 Kommunikationsprotokolle Post Office Protocol (POP3) Übertragungsprotokoll, über welches ein Client s von einem E- Mail-Server abholen kann. POP3 ist ein textbasiertes Protokoll, wobei die Steuerung der Datenübertragung durch Kommandos geschieht. Eine ständige Verbindung zum Mailserver ist bei POP3 nicht notwendig. Die Verbindung zum Server wird bei Bedarf vom Client aufgebaut und danach wieder beendet. POP3 ist in der Funktionalität sehr beschränkt und erlaubt nur das Auflisten, Abholen und Löschen von s am -Server. Für weitere Funktionalitäten wie hierarchische Mailboxen direkt am Mailserver, Zugriff auf mehrere Mailboxen während einer Sitzung, Vorselektion der s, usw. müssen Protokolle wie IMAP verwendet werden

20 Kommunikationsprotokolle Internet Message Access Protocol (IMAP) Das Anwendungsprotokoll erlaubt den Zugriff auf und die Verwaltung von s, die sich in einem Postfach auf einem Mailserver befinden. IMAP wurde mit dem Ziel entworfen, den Zugriff auf Mailboxen und Nachrichten so bereitzustellen, als befänden sich diese auf dem lokalen Rechner. Im Gegensatz zu POP3 verbleiben die s auf dem Server und werden dort verwaltet. Für das Versenden von Mails muss ein anderes Protokoll (z. B. SMTP) verwendet werden Lightweight Directory Access Protocol (LDAP) Anwendungsprotokoll, welches die Abfrage und die Modifikation von Informationen eines Verzeichnisdienstes (eine im Netzwerk verteilte hierarchische Datenbank) über das TCP/IP-Netzwerk erlaubt. Die aktuelle Version ist in IETF RFC 4511 spezifiziert

21 Kommunikationsprotokolle Secure Shell (SSH) bezeichnet sowohl ein Netzwerkprotokoll als auch entsprechende Programme, mit deren Hilfe man auf eine sichere Art und Weise eine verschlüsselte Netzwerkverbindung mit einem entfernten Computer herstellen kann. Die neuere Protokoll-Version SSH2 bietet weitere Funktionen wie Datenübertragung per SFTP (Secure File Transfer Protocol). Auf diese Weise kann SSH sowohl für die Datenbzw. Dateiübertragung. Dynamic Host Configuration Protocol (DHCP) ermöglicht die Zuweisung der Netzwerkkonfiguration an Geräte durch einen Server. Durch DHCP ist die automatische Einbindung eines neuen Computers in ein bestehendes Netzwerk ohne dessen manuelle Konfiguration möglich

22 Kommunikationsprotokolle General Event Notification Architecture (GENA) Mit dem XML-basierten GENA können Kontrollpunkte Informationen zum Gerätestatus abonnieren; somit werden sie bei jeder Änderung einer Statusvariablen automatisch informiert. Dazu werden event messages verschickt, die den Zustand der abonnierten Variablen enthalten, die sich geändert haben. SUBSCRIBE to notifications UNSUBSCRIBE NOTIFY Of device availability; NOTIFY Of state variable changes

23 Discovery Protokoll Service Location Protocol (SLP) Protokoll zum Auffinden von Netzdiensten, definiert als RFC Einteilung der Kommunikationspartner in drei Klassen: Dienstagent service agent register Verzeichnisagent directory agent discover 1 2 Benutzeragent user agent Es gibt sehr viel mehr Protokolle, teilweise als Teil eines größeren Systems

24 Agenda Einführung Definition, Grundlagen, Motivation Protokolle Beispiele: Kommunikation, Discovery Interprozesskommunikation RPC, RMI, CORBA, SOAP Architekturen SOA, Webservices, Continua, UPnP Standardisierung Organisationen, Konformität, Middleware FB Informatik GRIS Fraunhofer IGD

25 Interprozesskommunikation (1/3) Methoden zum Informationsaustausch zwischen nebenläufigen Prozessen oder Threads Kommunikation zwischen Prozessen auf dem selben Computer, deren Speicherbereiche strikt getrennt sind Kommunikation zwischen Prozessen in einer verteilten Umgebung Sehr allgemein gehalten, sehr viel fällt in diesen Bereich Oft abhängig vom Betriebssystem Beispiele: Pipes: ls -R Bilder grep -ci \.jpg$ Listet alle jpg-dateien im Verzeichnis Bilder (Pipe-Symbol ) Sockets (speziell in heterogenen und verteilten Systemen)

26 Interprozesskommunikation (2/3) Beispiele: Dynamic Data Exchange (DDE) Kommunikation nach dem Client/Server Modell Kommunikation über SendMessage Funktion an das andere Fenster Format: Windows Zwischenablage Beide Programme müssen laufen Object Linking and Embedding (OLE) Verknüpfung oder Einbettung von Objekten in ein anderes Programm Support für Verbunddokumente z.b. Excel-Tabelle in Word

27 Interprozesskommunikation (3/3) Funktionsaufrufe (Remote Procedure Call) CORBA Remote Method Invocation - RMI (Distributed) Component Object Model - COM/DCOM XML-RPC WebServices.. Einige Details auf den nächsten Slides

28 CORBA (1/3) Common Object Request Broker Architecture Entwickelt von Object Management Group (OMG) Plattformunabhängig Kern ist der Object Request Broker (ORB), der zwischen Client und Server vermittelt Jeder Client/jeder Server hat eine direkte Verbindung zum ORB Kommunikation zwischen ORB's mittels IIOP Internet Inter-ORB Protocol (Binärformat, Common Data Representation (CDR)) Client Client ORB IIOP Server ORB Server

29 CORBA (2/3) Schnittstellen werden mit der Interface Definition Language (IDL) definiert (ebenfalls von OMG entwickelt) Beispiel: module finance { interface account { // The account owner and balance. readonly attribute string owner; readonly attribute float balance; }; }; // Operations available on the account. void makelodgement(in float amount, out float newbalance); void makewithdrawal(in float amount, out float newbalance);

30 CORBA (3/3) IDL-Kompiler erstellen Stubs und Skeletons Für jede Programmiersprache muss es einen entsprechenden IDL- Kompiler geben (z.b. Java, C++) IDL-Kompiler erstellt Skeleton-Klasse für Server, deren Methoden implementiert werden müssen IDL-Kompiler erstellt Stub für Client, dessen Methoden aufgerufen werden können Discovery durch corbaloc unter Angabe eines Endpunktes, z.b. corbaloc::localhost:34893/nameservice

31 RMI Remote Method Invocation Java-basiert Eigenes, offenes Protokoll (RMI) oder basierend auf CORBA (RMI-IIOP = Internet Inter-ORB Protocol) Naming.lookup() Client 2 Registry 3 Funktionsaufruf Rückgabe 4 1 Naming.rebind() Server

32 (D)COM (Distributed) Component Object Model, von Microsoft Unabhängig von Programmiersprache Interfacedefinition muss bekannt sein Interface Definition Language IDL Kompiler MIDL erstellt daraus Code (ähnlich CORBA) Beispiel: [object, uuid( )] interface IFindSum : IUnknown { import "unknown.idl" HRESULT SumOfNumbers([in] long num1, [in] long num2, [out,retval] long* sum) }

33 XML-RPC (1/3) Extensible Markup Language - Remote Procedure Call Definition zum Methodenaufruf Vorgänger zu SOAP (mehr zu SOAP in den nächsten Slides) Benutzt HTTP für Transport und XML zur Repräsentation Festdefinierte Datentypen (komplexe als array oder struct) Tag Type Example <i4> or <int> four-byte signed integer -12 <boolean> 0 (false) or 1 (true) 1 <string> string hello world <double> <datetime.iso8601> date/time double-precision signed floating point number T14:08:55 <base64> base64-encoded binary ew91ignhbid0ihjlywqgdghpcye=

34 XML-RPC (2/3) Beispiel-Anfrage: <?xml version="1.0"?> <methodcall> <methodname>warenkorb.addposition</methodname> <params> <param> <value><string>monitor</string></value> </param> <param> <value><int>10</int></value> </param> </params> </methodcall>

35 XML-RPC (3/3) Beispiel-Antwort: <?xml version="1.0"?> <methodresponse> <params> <param> <value><string>ok</string></value> </param> </params> </methodresponse>

36 SOAP (1/2) Ursprünglich Simple Object Access Protocol Seit Version 1.2 nicht mehr, da es nicht simple ist und nicht nur für Objektzugriff dient Nachfolger von XML-RPC Transport meist über HTTP, Repräsentation in XML SOAP Header ist optional, kann z. B. Anweisungen zur Weiterleitung oder kontextbezogene Informationen zur Bearbeitung der Nachricht sein

37 SOAP (2/2) Beispiel: <?xml version='1.0' encoding='utf-8'?> <SOAP-ENV:Envelope xmlns:soap-env=" xmlns:xsi=" xmlns:xsd=" <SOAP-ENV:Body> <ns1:babelfish xmlns:ns1="urn:xmethodsbabelfish SOAP-ENV:encodingStyle=" <translationmode xsi:type="xsd:string">de_en</translationmode> <sourcedata xsi:type="xsd:string">hallo Welt, Guten Tag</sourcedata> </ns1:babelfish> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

38 Agenda Einführung Definition, Grundlagen, Motivation Protokolle Beispiele: Kommunikation, Discovery Interprozesskommunikation RPC, RMI, CORBA, SOAP Architekturen SOA, Webservices, Continua, UPnP Standardisierung Organisationen, Konformität, Middleware FB Informatik GRIS Fraunhofer IGD

39 SOA (1/4) Service Oriented Architecture Spezifikation von OASIS - Organization for the Advancement of Structured Information Standards: SOA Referenzmodell SOA Referenzarchitektur Definition: SOA is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains

40 SOA (2/4) Eigenschaften von Diensten Standardized service contract: standardisierte Service-Beschreibung Loose coupling: minimale Abhängigkeiten zwischen Kommunikationspartnern, nur Awareness nötig Abstraction: abgesehen vom contract wird die interne Logik versteckt Reusability: Dienste werden erstellt mit der Intention zur Wiederverwendung Autonomy: Dienste haben die Kontrolle über die interne Logik, die sie kapseln

41 SOA (3/4) Eigenschaften von Diensten Statelesness: Skalierbarkeit durch Design von Diensten ohne Zustand (wenn möglich), der Zustand sollte vom Aufrufer verwaltet werden Discoverability: Meta-Daten für Dienste für Discovery Composability: Ein Dienst kann intern mehrere andere Dienste benutzen

42 SOA (4/4) Building blocks 2 Suche Service Verzeichnis 1 Publizieren Service Konsument Anfrage 3 Antwort 4 Service Anbieter Beispiele: OSGi (schon gesehen) Webservices (auf den folgenden Slides) universaal ;-)

43 Webservice (1/7) Ein Webservice oder Webdienst ist eine Software-Anwendung, die mit einem Uniform Resource Identifier (URI) eindeutig identifizierbar ist und deren Schnittstelle als XML-Artefakt definiert, beschrieben und gefunden werden kann Universal Description, Discovery and Integration (UDDI): Verzeichnisdienst zur Registrierung von Webservices WSDL zur Beschreibung der unterstützten Methoden SOAP (oder XML-RPC) zur Kommunikation

44 Webservice (2/7) - WSDL Web Services Description Language (WSDL) Plattform-, programmiersprachen- und protokollunabhängige Beschreibungssprache für Netzwerkdienste XML-basiert funktionelle Angaben zu: Operationen, die der Webdienst durchführen kann Format der Nachrichten, die verarbeitet werden können Protokoll, die unterstützt werden

45 Webservice (3/7) - WSDL WSDL 1.1: Web Service Definition Language WSDL 2.0: Web Service Description Language Ähnlichkeit zu OOP: Interface ~ Interface Operation ~ Methode Input ~ Parameter Output ~ Rückgabewert Quelle: Wikipedia

46 Webservice (4/7) WSDL XML-Hauptelemente 1. types (Datentypen): Definition der Datentypen; Benutzung von XML Schema <types> <xs:element name="request"> <xs:complextype> <xs:sequence> <xs:element name="header" maxoccurs="unbounded"> <xs:complextype> <xs:simplecontent> <xs:extension base="xs:string"> <xs:attribute name="name" type="xs:string" use="required"/> </xs:extension> </xs:simplecontent> </xs:complextype> </xs:element> <xs:element name="body" type="xs:anytype" minoccurs="0"/> </xs:sequence> <xs:attribute name="method" type="xs:string" use="required"/> <xs:attribute name="uri" type="xs:anyuri" use="required"/> </xs:complextype> </xs:element> </types>

47 Webservice (5/7) WSDL XML-Hauptelemente 2. interface: Definition der Operationen <interface name="restfulinterface"> <operation name="get" pattern=" <input messagelabel="in" element="tns:request"/> <output messagelabel="out" element="tns:response"/> </operation> <operation name="delete" pattern=" <input messagelabel="in" element="tns:request"/> <output messagelabel="out" element="tns:response"/> </operation> </interface>

48 Webservice (6/7) WSDL XML-Hauptelemente 3. binding (Bindung): Bestimmt das konkrete Protokoll und Datenformat für die Arbeitsschritte und Nachrichten, die durch einen bestimmten Port-Typ/Interface gegeben sind <binding name="restfulinterfacesoapbinding" interface="tns:restfulinterface" type=" wsoap:protocol=" wsoap:mepdefault=" <operation ref="tns:get" /> <operation ref="tns:delete" /> </binding>

49 Webservice (7/7) WSDL XML-Hauptelemente 4. service: <service name="restfulservice" interface="tns:restfulinterface"> <endpoint name="restfulservicehttpendpoint" binding="tns:restfulinterfacehttpbinding" address=" <endpoint name="restfulservicesoapendpoint" binding="tns:restfulinterfacesoapbinding" address=" </service>

50 Universal Plug n Play UPnP

51 Universal Plug n Play UPnP UPnP ist ein Standard für die Integration von Geräten in kleine lokale Netzwerke Weitestgehend unabhängig von Programmiersprachen und Technologien UPnP basiert auf einer Reihe von standardisierten Netzwerkprotokollen und Datenformaten: IP-basiert: alle physikalischen Medien, welche IP-Kommunikation unterstützen, können verwendet werden, z. B. Ethernet, Funk (Bluetooth, Wireless LAN), FireWire (IEEE 1394). Es werden standardisierte Technologien wie IP, UDP, Multicast, TCP, HTTP, XML, SOAP, etc. eingesetzt, um UPnP zu realisieren. UPnP bietet Möglichkeiten für herstellerspezifische Erweiterungen.

52 Universal Plug n Play UPnP Basisabstraktionen der UPnP Gerätearchitektur: Geräte (Devices) Dienste (Services) Kontrollpunkte (Control Points) Client-Server-Konzept: UPnP-Geräte (Server) Netzwerkfähiges Gerät, auf dem die von der UPnP-Architektur geforderten Protokolle implementiert sind Bieten ihre UPnP-Dienste in einem Netzwerk an Z.B.: Internet-Gateway, PC oder eingebettetes System UPnP-Kontrollpunkte (Client) Können nach Geräten/Diensten suchen, sie benutzen und Ereignisse abonnieren Kann die Geräte ohne Interaktion des Benutzers finden Z.B.: Fernbedienung, ein Handheld, ein PC oder ein anderes Heimgerät

53 Universal Plug n Play UPnP 0 Control point and device get addresses 1 Control point finds interesting device 2 Control point learns about device capabilities 3 Control point invokes actions on device 4 Control point listens to state changes of device 5 Control point controls device and/or views device status using HTML UI

54 UPnP die Schritte im Einzelnen (1) Adressierung (Addressing): Da die Basis von UPnP ein IP- Netzwerk ist, muss ein Gerät oder Kontrollpunkt zuerst über eine gültige IP-Adresse verfügen. Dies kann nach dem UPnP- Standard einerseits via DHCP erfolgen oder via Auto-IP. Lokalisierung (Discovery): Sobald ein UPnP-Gerät über eine IP- Adresse verfügt, muss es seine Existenz im Netzwerk an die Kontrollpunkte melden. Dies erfolgt via UDP über die Multicast- Adresse :1900 auf der Basis des Simple Service Discovery Protocol (SSDP). Ebenso können Kontrollpunkte nach UPnP-Geräten im Netzwerk suchen. In beiden Fällen enthält die discovery message nur die wichtigsten Angaben über das Gerät und seine Dienste, wie z. B. den Gerätenamen, Gerätetyp und eine URL zur genauen Beschreibung des Gerätes.

55 UPnP die Schritte im Einzelnen (2) Beschreibung (Description): Nachdem ein Kontrollpunkt ein Gerät gefunden hat, holt er sich per HTTP über TCP/IP die Beschreibung des Gerätes von der URL, welche ihm bei der Lokalisierung mitgeteilt wurde. Diese stellt das Gerät in Form eines XML-Dokumentes zur Verfügung. Die Beschreibung beinhaltet Informationen über den Hersteller, die Seriennummer, URL-Adressen für die Steuerung, Ereignisse und die Präsentation. Für jeden Service, den ein Gerät anbietet, werden Kommandos und Aktionen sowie Datentypen und Datenbereiche spezifiziert. Die Beschreibung beinhaltet neben den Diensten, die es anbietet, auch alle eingebetteten Geräte mit deren Diensten.

56 UPnP die Schritte im Einzelnen (3) Steuerung (Control): Anhand der Informationen, die der Kontrollpunkt aus dem Beschreibungsdokument des Gerätes erhalten hat, kann er nun SOAP-Mitteilungen an die Steuerungs- URL des Gerätes schicken, um dieses zu steuern. Ereignismeldungen (Eventing / Event Notification): Damit ein Gerät nicht dauernd den Zustand eines Dienstes bzw. einer Statusvariablen abfragen muss (enthalten im Beschreibungsdokument des Gerätes), nutzt UPnP die XMLbasierte General Event Notification Architecture (GENA). Mit GENA können Kontrollpunkte Informationen zum Gerätestatus abonnieren; somit werden sie bei jeder Änderung einer Statusvariablen automatisch informiert. Dazu werden event messages verschickt, die den Zustand der abonnierten Variablen enthalten, die sich geändert haben.

57 UPnP die Schritte im Einzelnen (4) Präsentation (Presentation): Die Präsentation ist eine Alternative zur Steuerung und den Ereignismeldungen. Über die Presentation- URL, welche bei der Beschreibung (Description) bekannt gegeben wird, kann mittels Webbrowser auf das Gerät zugegriffen werden. Dies gibt dem Hersteller die Möglichkeit, neben dem standardisierten Zugriff via UPnP eine alternative Benutzeroberfläche zur Verfügung zu stellen.

58 Universal Plug n Play UPnP 0 Control point and device get addresses 1 Control point finds interesting device 2 Control point learns about device capabilities 3 Control point invokes actions on device 4 Control point listens to state changes of device 5 Control point controls device and/or views device status using HTML UI IPv4 autoconfig (Protocol), DHCP SSDP Simple Service Discovery Protocol XML based device and service descriptions SOAP Simple Object Application Protocol GENA General Event Notification Architecture Presentation Service Web based User Interface to devices and services Device and Service Profiles include: Internet Gateway Device and WLAN Access Points Printers and Scanners, Media Servers and Players Lighting and Home Heating QOS, Security and Remote User Interface

59 UPnP Protokoll-Stack und Ablaufschemata Standardized DCPs (by UPnP Forum) UPnP Device Architecture (Addressing, Discovery, Description, Control, Eventing, Presentation) SSDP HTTPU HTTPMU UDP IP GENA SOAP HTTP TCP DCP: Device Control Protocol Standardisierung spezieller Dienste UPnP - Stack Bsp: Audio/Video, Home Automation, Printer, Scanner, Telephony,

60 UPnP Device-Beschreibung Teil 1 <?xml version="1.0"?> <root xmlns="urn:schemas-upnp-org:device-1-0"> <URLBase>base URL for all relative URLs</URLBase> <device> <friendlyname>short user-friendly title</friendlyname> <manufacturer>manufacturer name</manufacturer> <manufacturerurl>url to manufacturer site</manufacturerurl> <modeldescription>long user-friendly title</modeldescription> <modelname>model name</modelname> <modelnumber>model number</modelnumber> <modelurl>url to model site</modelurl> <serialnumber>manufacturer's serial number</serialnumber> <UDN>uuid:UUID</UDN> <UPC>Universal Product Code</UPC>

61 UPnP Device-Beschreibung Teil 2 <devicetype>urn:schemas-upnp-org:device:devicetype</devicetype> <servicelist> <service> <servicetype>urn:schemas-upnp-org:service:servicetype:v</servicetype> <serviceid>urn:upnp-org:serviceid:serviceid</serviceid> <SCPDURL>URL to service description</scpdurl> <controlurl>url for control</controlurl> <eventsuburl>url for eventing</eventsuburl> </service> Declarations for other services (if any) go here </servicelist> <devicelist>description of embedded devices (if any) go here</devicelist> <iconlist> <icon> <mimetype>image/format</mimetype> <width>horizontal pixels</width> <height>vertical pixels</height> <depth>color depth</depth> <url>url to icon</url> </icon> XML to declare other icons, if any, go here </iconlist> <presentationurl>url for presentation</presentationurl> </device> <specversion> <major>1</major> <minor>0</minor> </specversion> </root>

62 UPnP Service-Beschreibung Teil 1 <?xml version="1.0"?> <scpd xmlns="urn:schemas-upnp-org:service-1-0"> <actionlist> <action> <name>actionname</name> <argumentlist> <argument> <name>formalparametername</name> <direction>in xor out</direction> <retval /> <relatedstatevariable>statevariablename</relatedstatevariable> </argument> Declarations for other arguments (if any) go here </argumentlist> </action> Declarations for other actions (if any) go here </actionlist> <servicestatetable> <statevariable sendevents= yes xor no > <name>variablename</name> <datatype>variable datatype</datatype> <defaultvalue>default value</defaultvalue>

63 UPnP Service-Beschreibung Teil 2 <allowedvaluerange> <minimum>minimum value</minimum> <maximum>maximum value</maximum> <step>increment value</step> </allowedvaluerange> </statevariable> <statevariable sendevents= yes xor no > <name>variablename</name> <datatype>variable data type</datatype> <defaultvalue>default value</defaultvalue> <allowedvaluelist> <allowedvalue>some value</allowedvalue> <allowedvalue>some value</allowedvalue> </allowedvaluelist> </statevariable> Declarations for other state variables (if any) go here </servicestatetable> <specversion> <major>1</major> <minor>0</minor> </specversion> </scpd>

64 Continua Health Alliance* Our Mission is to establish an ecosystem of interoperable personal health systems that empower people & organizations to better manage their health and wellness * Selected slides from Rick Cnossen s presentation at AAL Forum 2010

65 Continua Non-profit Industrieoriganisation > 220 member companies Ziel: improve the quality of personal healthcare System von interoperablen Lösungen/Produkten im Health- Bereich Baut auf vorhandenen Protokollen und Standards auf Bietet Zertifizierung von Geräten ( Continua certified )

66 Interfaces & Standards Personal Device Independent Living Activity Pulse Oximeter Pulse / Blood Pressure Interfaces & Standards Aggregation Manager Pendant/Panic event Smoke detector Fall detector Movement detector Property exit sensor Carbon monoxide Temperature sensor Enuresis sensor Bed occupancy sensor Chair sensor Medication minder Health Records Weight Scale Glucose Meter Cardio / Strength Thermometer Local Area Network (LAN) Interface Telehealth Service Center Peak Flow Adherence Monitor Physical Activity Insulin Pump Personal Area Network (PAN) Interface Wide Area Network (WAN) Interface Health Record Network (HRN) Interface EHR PHR 8

67 HL7 Health Level Seven Bemerkung: Die sieben im Namen bezieht sich auf Ebene 7 ( Anwendungsschicht ) des ISO/OSI-Referenzmodell für die Kommunikation (ISO7498-1). Ziel von HL7 ist die Vereinfachung der Umsetzung der medizinischen Prozessabläufe zwischen den beteiligten Systemen; in Deutschland vor allem für die Kommunikation von Softwaresystemen im Krankenhaus. Beispiele für Nachrichten sind die Aufnahme, Verlegung oder Entlassung eines Patienten, die Bereitstellung von Labordaten, Befunddaten oder Abrechnungsdaten, die Erzeugung oder Bearbeitung eines Auftrags (etwa zu einer spezifischen Untersuchung eines Patienten in einem Funktionsbereich eines Krankenhauses).

68 HL7 Health Level Seven V2 Segment Inhalt MSH (Message Header) PID (Patient ID) PV1 (Patient Visit)

69 Agenda Einführung Definition, Grundlagen, Motivation Protokolle Beispiele: Kommunikation, Discovery Interprozesskommunikation RPC, RMI, CORBA, SOAP Architekturen SOA, Webservices, Continua, UPnP Standardisierung Organisationen, Konformität, Middleware FB Informatik GRIS Fraunhofer IGD

70 Normungs- und Standardisierungsorganisationen International Organization for Standardization (ISO) mit nationalen Mitgliedern: Deutsches Institut für Normung (DIN) ANSI - American National Standards Institute European Committee for Standardization (CEN) World Wide Web Consortium (W3C) Organization for the Advancement of Structured Information Standards (OASIS) Object Management Group (OMG) ITU International Telecommunication Union IEEE - Institute of Electrical and Electronic Engineers

71 Normungs- und Standardisierungsorganisationen The Internet Engineering Task Force (IETF) The mission of the IETF is to make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet. Entertaining Request For Comments (RFC's):

72 Entertaining RFC s (1/3) RFC 3514: The Security Flag in the IPv4 Header, Firewalls, packet filters, intrusion detection systems, and the like often have difficulty distinguishing between packets that have malicious intent and those that are merely unusual. We define a security flag in the IPv4 header as a means of distinguishing the two cases. Definiert ein "evil bit" "..the option contains a 128-bit strength indicator, which says how evil the packet is.."

73 Entertaining RFC s (2/3) RFC 2795: The Infinite Monkey Protocol Suite (IMPS), determine when they have either produced the entire works of William Shakespeare or a good television show Definition: A SIMIAN (Semi-Integrated, Monkey-Interfacing Anthropomorphic Node) is a device that is physically attached to the monkey. It provides the communications interface between a monkey and its ZOO Security Considerations: Finally, no security considerations are made with respect to the fact that over the course of infinite time, monkeys may evolve and discover how to control their own SIMIAN interfaces and send false requests, or to compose and submit their own transcripts. There are indications that this may already be happening [18]. [18] All issues of TV Guide published between 1956 and the date of this document.

74 Entertaining RFC s (3/3) RFC 2324: Hyper Text Coffee Pot Control Protocol, Protokoll zur Kontrolle und Überwachung vernetzter Kaffeemaschinen, Erweiterung zu HTTP, URI schema: coffee:// Erweiterungen zu den Standard-HTTP-Methoden: BREW oder POST: bittet den HTCPCP-Server Kaffee zu kochen. GET: fordert den Kaffee vom HTCPCP-Server an. PROPFIND: Fragt diverse Metainformationen zum Kaffee ab. WHEN: unterbricht die Zugabe von Milch zum Kaffee HTCPCP return codes: 418 I'm a teapot Security Considerations: Anyone who gets in between me and my morning coffee should be insecure. Implementierung als Modul für Emacs (Texteditor) verfügbar 1998 noch Aprilscherz..

75 Konformitätserklärung (Conformance Statement) Hersteller dokumentieren die Konformität ihrer Produkte zu bestimmten Richtlinien, Standards oder Normen Unterstützte Anwendungsprofile typischerweise Bestandteil der Konformitätserklärung Selbsterklärung versus Zertifikat einer unabhängigen Drittstelle Hilfsmittel bei der Beschaffung neuer Produkte Käufer nimmt z.b. an, dass das Produkt sich in eine bereits bestehende Infrastruktur integrieren lässt Versärkung der Annahme: Konformitätserklärung ist durch unabhängige Tests bestätigt Problem: das Lesen von Konformitätserklärungen setzt häufig detaillierte Kenntnisse der zugrundeliegenden Schnittstellenstandards voraus

76 Konformitätsprüfung (Conformance Testing) (1/2) Verfahren, die mittels eines aktiven Tests überprüfen, ob die Implementierung einer Schnittstelle sich gemäß einer Schnittstellenspezifikation verhält. Häufig Konformitätsprüfung der übertragenen Daten oder Nachrichten neben dem Kommunikationsprotokoll einer Schnittstelle Die Norm ISO 9646 gibt z.b. im Bereich der Netzwerkprotokolle die Methodik solcher Tests vor. Wichtiges Mittel der Zertifizierung: schnittstellenbezogene Produkteigenschaften werden durch eine neutrale Stelle geprüft und mit einem Zertifikat bestätigt Ein dediziertes Testsystem ( Tester ) kommuniziert mit dem Prüfgegenstand, beobachtet dessen Verhalten an einem oder mehreren wohldefinierten Kontrollpunkten Bsp: spezielle Werkzeuge zur Prüfung der Qualität und Gültigkeit eines XML- Datensatzes anhand XML-Schemata

77 Konformitätsprüfung (Conformance Testing) (2/2) Die Güte der Ergebnisse einer Konformitätsprüfung hängt wesentlich von der Testabdeckung geeignete Testfälle für die Erhöhung der Wahrscheinlichkeit der Entdeckung möglicher Fehler durch den Tester Automatische Erzeugung von Testsuites aus formalen Protokollspezifikationen Konformitätsprüfungen können prinzipiell nur die Fehlerhaftigkeit eines Produkts nachweisen, nicht jedoch seine Korrektheit (Konformität). ISO [ISO94a] : However it should be borne in mind that the complexity of most protocols makes exhaustive testing impractical on both technical and economic grounds. Also, testing cannot guarantee conformance to a specification since it detects errors rather than their absence. Thus conformance to a test suite alone cannot guarantee interworking. What it does do is give confidence that an implementation has the required capabilities and that its behaviour conforms consistently in representative instances of communication.

78 Interoperabilitätsprüfung (Cross-vendor Testing) (1/2) Obwohl die Konformität eines Systems keine Garantie für die Interoperabilität mit anderen konformen Systemen bietet, funktionieren dennoch fehlerhafte (d. h. nicht-konforme) Schnittstellen in der Praxis häufig relativ problemlos, weil der Empfänger den fehlerhaften Teil der Daten gar nicht auswertet, oder den Fehler erkennt und stillschweigend korrigiert Bsp: Systeme eines bestimmten Herstellers übertragen immer W wie weiblich statt des erwarteten F wie female erkennen und stillschweigend korrigieren Es ist daher sinnvoll, die Systeme direkt miteinander zu verbinden und zu prüfen, ob eine Interoperabilität aus Anwendersicht besteht, d. h. ob die Systeme gemeinsam die Aufgaben erfüllen können, für die der Anwender sie einsetzen möchte

79 Interoperabilitätsprüfung (Cross-vendor Testing) (2/2) Definition: Geräte unterschiedlicher Hersteller zusammenschalten und zusammen testen Connect-a-thons (Analogie Marathon ) oder Plug-fests mit neutralen Schiedsrichtern auch komplexe Anwendungsfälle, an denen mehrere Anwender und Geräte beteiligt sind, können durchgespielt werden. Nur eingeschränkt möglich wegen kombinatorischer Explosion kein Ersatz für den tiefgehenden Charakter einer Konformitätsprüfung, sondern eine Ergänzung

80 Herausforderung: Interoperabilität Unabhängige Entwicklung / Produktion Fähigkeit, dennoch Funktionen & Daten auszutauschen [Netzwerkprotokoll] Zugriffsprotokoll Datenrepräsentation mehrere Anwendungsdomänen z.b. Home Automation, Energiemanagement, Medizin jede Anwendungsdomäne mehrere Standards z.b. in HA: KNX, ZigBee jeder Standard mehrere Anwendungsprofile Was tun wenn alles relevant (wie in AmI)?

81 Mögliche Antwort auf Interoperabilitätsherausforderung 1. Ein Hauptprotokoll für Kommunikation unter Benutzung einer Hauptlösung für Datenrepräsentation AmI -Komponenten versus herkömmliche Komponenten 2. Einbindung herkömmlicher Komponenten durch Adapter Netzwerkebene: protokoll-spezifische Gateways Zugriffsmethoden & Datenrepräsentation: komponentspezifisches Wrapping Die Lösungen diesbezüglich in AmI nennt man Middleware-Lösungen Eine gute Referenz:

82 Middleware als Exchange Bus [