Ambient Intelligence WS 10/11 V5: Middleware – Teil I Dr.-Ing. Reiner Wichert Fraunhofer-Institut...
-
Upload
ulrich-stocking -
Category
Documents
-
view
104 -
download
0
Transcript of Ambient Intelligence WS 10/11 V5: Middleware – Teil I Dr.-Ing. Reiner Wichert Fraunhofer-Institut...
Ambient IntelligenceWS 10/11
V5: Middleware – Teil I
Dr.-Ing. Reiner WichertFraunhofer-Institut für Graphische Datenverarbeitung IGD
Holger Graf
Fraunhofer-Institut für Graphische Datenverarbeitung IGD
Mohammad-Reza (Saied) Tazari
Fraunhofer-Institut für Graphische Datenverarbeitung IGD
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
Ambient Intelligence
Ad
apti
ve U
I in
Am
I
3
Smart Environments as Open Distributed Systems
Ad
apti
ve U
I in
Am
I
4
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)?
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: http://sardes.inrialpes.fr/~krakowia/MW-Book/
6
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
Wiederverwendung existierender Software (legacy software)
8
Vermittelnde (Mediation) Systeme
9
Komponentenbasierte Architekturen
10
Adaption durch Proxies
11
Middleware allgemein
12
Middleware Definition
13
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
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)
15
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
Remote procedure call: overview
17
Remote procedure call: main components
18
Remote procedure call: thread management on the server side (I)
19
Remote procedure call: thread management on the server side (II)
20
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)
21
Remote procedure call: overall flow of control
22
Remote procedure call: locating the server
23
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
PERSONA PHYSICAL ARCHITECTUREWHY 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
PERSONA PHYSICAL ARCHITECTUREHOW OPEN & DISTRIBUTED?
A dynamic ensemble of networked nodes
middle-ware
middle-ware
router
registrym
iddl
e-w
are
middle-w
are
node node
node
node
node node
node
node
middle-ware
middle-ware
mid
dle-
war
e
middle-w
are
PERSONA PHYSICAL ARCHITECTUREDEFINITION 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
PERSONA PHYSICAL ARCHITECTURE
NODE vs. MIDDLEWARE INSTANCE
Node #1
logical component
#1
middleware
logical component
#2
middleware
Node #2
logical component
#3
middleware
logical component
#4
Node #3
wrapper#1
middleware
legacy node #1(tcp/ip enabled)
Node #4
wrapper#2
middleware
legacy node #2(RS232 enabled)
RS232 cable
Node #5
logical component
#5
middleware
wrapper#3
hosted legacy #3
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
PERSONA MIDDLEWARE DESIGNREQUIREMENTS
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
PERSONA MIDDLEWARE DESIGNTHE CHOSEN MODEL
Derived from Sodapop (Self-Organizing Data-flow Architectures suPporting Onotology-based problem decomPosition ) used in the projects EMBASSI & DynAMITE
Original spec: http://www.igd.fhg.de/igd-a1/projects/sodapop/sodapop.zip
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)
node1
events calls .
publishing
handling
requesting
getting requestresponding
getting response
inter-component communication needs
caller
callee
user input system output .
captured input
input to processgenerated output
output to present
user interaction communication needs
PERSONA MIDDLEWARE DESIGN
PERSONA-SPECIFIC DECISIONS
PERSONA MIDDLEWARE DESIGNCONCLUSION
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