Ambient Intelligence WS 10/11

Präsentation zum Thema: "Ambient Intelligence WS 10/11"—  Präsentation transkript:

1 Ambient Intelligence WS 10/11
V5: Middleware – Teil I Dr.-Ing. Reiner Wichert Fraunhofer-Institut für Graphische Datenverarbeitung IGD Holger Graf Mohammad-Reza (Saied) Tazari

2 Gliederung Problemstellung Definition Middleware Middleware-Kategorien
„Remote Procedure Call“ als einfache Middleware Beispiel: PERSONA Middleware Abstract Physical Architecture The conceptual design of the PERSONA middleware The implementation architecture of the middleware Datenrepräsentation Exkurs: Semantic Web

3 Ambient Intelligence Adaptive UI in AmI

4 Smart Environments as Open Distributed Systems
Adaptive UI in AmI

5 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)?

6 Mögliche Antwort auf Interoperabilitätsherausforderung
Ein Hauptprotokoll für Kommunikation unter Benutzung einer Hauptlösung für Datenrepräsentation “AmI”-Komponenten versus “herkömmliche” Komponenten 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:

7 Gliederung Problemstellung Definition Middleware Middleware-Kategorien
„Remote Procedure Call“ als einfache Middleware Beispiel: PERSONA Middleware Abstract Physical Architecture The conceptual design of the PERSONA middleware The implementation architecture of the middleware Datenrepräsentation Exkurs: Semantic Web

8 Wiederverwendung existierender Software (legacy software)

9 Vermittelnde (Mediation) Systeme

10 Komponentenbasierte Architekturen

11 Adaption durch Proxies

12 Middleware allgemein

13 Middleware Definition

14 Gliederung Problemstellung Definition Middleware Middleware-Kategorien
„Remote Procedure Call“ als einfache Middleware Beispiel: PERSONA Middleware Abstract Physical Architecture The conceptual design of the PERSONA middleware The implementation architecture of the middleware Datenrepräsentation Exkurs: Semantic Web

15 Middlware-Kategorien
Kommunikation Fixe versus variable Topologien Vorhersehbarkeit, insb. bezüglich benötigte Zeit für Nachrichtentransfer open distributed systems: unvorhersehbar mit variablen Topologien Architektur und Schnittstellen Managed entities (z.B. Agenten, Service-Komponenten) Service provision structure (requester/responder, publisher/subscriber) Service provision interfaces (synchron / asynchron)

16 Gliederung Problemstellung Definition Middleware Middleware-Kategorien
„Remote Procedure Call“ als einfache Middleware Beispiel: PERSONA Middleware Abstract Physical Architecture The conceptual design of the PERSONA middleware The implementation architecture of the middleware Datenrepräsentation Exkurs: Semantic Web

17 Remote procedure call: overview

18 Remote procedure call: main components

19 Remote procedure call: thread management on the server side (I)

20 Remote procedure call: thread management on the server side (II)

21 Remote procedure call: specific aspects
Stub generation Parameter marshalling and unmarshalling Serialisierung De-serialisierung Reaktion auf Fehler formulating failure hypotheses (e.g., fail-stop for nodes & message loss for communication) detecting failures (e.g., timeout) reacting to failure detection (e.g., repeat)

22 Remote procedure call: overall flow of control

23 Remote procedure call: locating the server

24 Gliederung Problemstellung Definition Middleware Middleware-Kategorien
„Remote Procedure Call“ als einfache Middleware Beispiel: PERSONA Middleware Abstract Physical Architecture The conceptual design of the PERSONA middleware The implementation architecture of the middleware Datenrepräsentation Exkurs: Semantic Web

25 PERSONA PHYSICAL ARCHITECTURE WHY OPEN & DISTRIBUTED?
The situation in smart environments: Several sensors, actuators, & appliances Several displays, microphones, loudspeakers, & cameras Several software components and computing devices hosting them We cannot assume a static configuration

26 PERSONA PHYSICAL ARCHITECTURE HOW OPEN & DISTRIBUTED?
A dynamic ensemble of networked nodes

27 PERSONA PHYSICAL ARCHITECTURE DEFINITION MIDDLEWARE
The “middleware” is the intermediate piece of software allowing the ensemble to take form by defining high-level protocols and providing uniform interfaces for integrating components into the system enabling the communication between them It hides distribution of components heterogeneity of the various hardware components and their operating systems and networking protocols

28 PERSONA PHYSICAL ARCHITECTURE NODE vs. MIDDLEWARE INSTANCE

29 Gliederung Problemstellung Definition Middleware Middleware-Kategorien
„Remote Procedure Call“ als einfache Middleware Beispiel: PERSONA Middleware Abstract Physical Architecture The conceptual design of the PERSONA middleware The implementation architecture of the middleware Datenrepräsentation Exkurs: Semantic Web

30 PERSONA MIDDLEWARE DESIGN REQUIREMENTS
Integration Node: Seamless connectivity between middleware instances Component: simple API of the shared local middleware instance Communication Semantic interoperability Service orientation Eventing Hiding distribution & heterogeniety Distribution: hidden cooperation between middleware instances Heterogeniety: text-based messaging of middleware instances

31 PERSONA MIDDLEWARE DESIGN THE CHOSEN MODEL
Derived from Sodapop (Self-Organizing Data-flow Architectures suPporting Onotology-based problem decomPosition ) used in the projects EMBASSI & DynAMITE Original spec: Borrowed concepts Virtual buses & components that connect to them A system is mostly defined by determining its set of buses and specifying their protocols and strategies Brokering messages instead of objects Event-based buses (publish/subscribe) vs. call-based buses (request/response)

32 PERSONA MIDDLEWARE DESIGN PERSONA-SPECIFIC DECISIONS

33 PERSONA MIDDLEWARE DESIGN CONCLUSION

34 Gliederung  Teil 2  nächste Woche
Problemstellung Definition Middleware Middleware-Kategorien „Remote Procedure Call“ als einfache Middleware Beispiel: PERSONA Middleware Abstract Physical Architecture The conceptual design of the PERSONA middleware The implementation architecture of the middleware Datenrepräsentation Exkurs: Semantic Web

35 Danke für die Aufmerksamkeit & bis zur nächsten Vorlesung