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