systemarchitekturen zur konstruktion verteilter systeme · is to develop computer systems capable...

Systemarchitekturen zurKonstruktion verteilter Systeme:

KommunikationsartenKommunikationsarten, Architekturen und Paradigmen

vsis inf min uni hh ws 11_12 VIS-1 Arch-1

GliederunggKommunikationsformen

— nachrichtenbasiert— aufrufzentriert— datenzentriert— ereignisbasiertg

Architekturen— Client/Server und Schichtenmodelle— Client/Server und Schichtenmodelle— Peer-to-Peer und Hybridmodelle— Umsetzung: Middleware und Selbstmanagement

Zum Vergleich: Betriebssystemarchitekturen— Zum Vergleich: Betriebssystemarchitekturen

Konstruktionsparadigmenbj kt i ti t— objektorientiert

— komponentenbasiert— dienstorientiert


— agentenorientiert

Kommunikation in VS

• Kommunikation dient der Übertragung von Informa-tionen zwischen Elementen Prozesstionen zwischen Elementen

• Formen der Kommunikation

Prozess

— direkt: Übermittlung von Informationen zu einem (bzw. mehreren) Empfänger(n) Information

?e e e ) p ä ge ( )• Beispiele: Anruf, SMS, Email

i di kt Hi t l I f ti i i I f

Information

— indirekt: Hinterlassen von Informationen in einem Infor-mationsspeicher, der für andere zugänglich ist

• Beispiele: Forum, BlogProzess


Aufrufzentrierte Kommunikation

• stammt aus der objektbasierten WeltEl t A k t El t B (b d Ad )• Element A kennt Element B (bzw. dessen Adresse)

• Element A kennt die Signatur der gewünschten Methode auf B• typischerweise erfolgt der Aufruf der Methode synchron d h der aufru-typischerweise erfolgt der Aufruf der Methode synchron, d.h. der aufru

fende Kontrollfluss wartet auf das Ergebnis des Calls• Die Übergabesemanik von Parametern kann Call-by-Reference oder Call-

b V l iby-Value sein• Ist B nicht im Adressraum von A, so kann ein entfernter Methodenaufruf

durchgeführt werden (Remote Method Invocation – RMI)g ( )• Probleme im verteilten Fall: z.B. Netzwerkfehler, Parameterübergaben,

Kenntnis über Objekte und Schnittstellen, Heterogenität, enge Kopplung, Aufrufsemantiken und idempotente OperationenAufrufsemantiken und idempotente Operationen

AufrufA BAufruf: ret = B.m1(args)


Ergebnis

Nachrichtenbasierte Kommunikation

• Element A kennt Element B (bzw. dessen Adresse)N h i ht äh li h i B i f b t h d t i h i i U• Nachricht ähnlich einem Brief, bestehend typischerweise aus einem Um-schlag und dem eigentlichen Inhalt

• Nachricht asynchron, da A nicht auf eine Antworten von B warten mussy ,• kann auch zum Aufbau synchroner Kommunikation genutzt werden, denn

A kann selbst entscheiden, ob er auf eine Reaktion von B wartetN h i ht kö T il üb d t P t k ll i t i h• Nachrichten können Teil übergeordneter Protokolle sein, typisches Beispiel: Request-Reply

• Probleme in offenen Systemen z.B.: Wie verstehe ich die Nachricht und yderen Inhalt? Wie weiß A, dass B seine Nachricht erhalten hat?

B i i l A t t• Beispiel: AgentensystemeNachricht

A BSenden: send(msg)


( g)

Datenzentrierte Kommunikation• Element A muss B nicht kennen• Elemente kommunizieren über gemeinsames (aktives od. passives) Repository

A hinterlegt seine Information im Datenraum• A hinterlegt seine Information im Datenraum• B wird entweder durch Infrastruktur automatisch informiert, oder muss selbst im

Datenraum nachsehen (push/pull Modelle)• asynchron da A keine (direkte) Antwort erwartet• asynchron, da A keine (direkte) Antwort erwartet• Datenraum kann unterschiedliche Strukturen aufweisen, z.B. DHT, Tuple Space,

Artefakt, …• unterschiedliche Zugriffsarten möglich z B auch Zugriff über deklarative / mengen• unterschiedliche Zugriffsarten möglich, z.B. auch Zugriff über deklarative / mengen-

orientierte Anfragen• zeitliche / räumliche Entkopplung• Beispiele: Vernetzte Anwendungen im Gesundheitswesen kommunizieren über• Beispiele: Vernetzte Anwendungen im Gesundheitswesen kommunizieren über

verteiltes Dateisystem, Ameisen kommunizieren über Pheromone, Blackboards

Komponente KomponenteKomponente KomponenteKomponente KomponenteKomponenteKomponente KomponenteKomponente ABKomponente Komponente

Lieferung

Komponente KomponenteKomponente KomponenteKomponenteKomponente KomponenteKomponente AB

Gemeinsamer (persistenter)

Veröffentlichung


(Tanenbaum 2008)

Gemeinsamer (persistenter)Datenraum

Ereignisbasierte Kommunikationg• Element A muss B nicht kennen• Kommunikation über Propagierung von Ereignissen• ähnlich der nachrichtenbasierten Kommunikation, aber indirekt, d.h. der Erzeuger

eines Ereignisses interessiert sich nicht für die Identität der Empfänger• Vermittlung über Themen

• Beispiel: Message-Oriented Middleware (MOM)— Prozesse wirken als Publisher und/oder Subscriber

Subscriber können Themen abonnieren— Subscriber können Themen abonnieren— Publisher können Nachrichten zu einem Thema veröffentlichen— Vermittlung der Nachrichten erfolgt über Infrastruktur— mögliche Realisierung durch themenspezifische Warteschlangenmögliche Realisierung durch themenspezifische Warteschlangen

Komponente KomponenteKomponente KomponenteKomponente KomponenteKomponenteKomponente KomponenteKomponente KomponenteKomponente

Ereignisbus

V öff tli h

LieferungEreignisbusEreignisbusEreignisbusEreignisbusEreignisbusEreignisbus

vsis inf min uni hh ws 11_12 VIS-1 Arch-7Komponente

Veröffentlichung

KomponenteKomponente (Tanenbaum 2008)

Softwarearchitekturen in verteilten Systemeny• Definition Softwarearchitektur: „describes the sub-systems and components of a

software system and the relationships between the components.“ (Bass et al.)— Entscheidung über Softwarekomponenten ihre Zusammenarbeit und ihre AnordnungEntscheidung über Softwarekomponenten, ihre Zusammenarbeit und ihre Anordnung

• zentralisierte Architekturen:— typischerweise Abarbeitung über einen logischen Prozess

l i h P b h ibt d l i h K t llfl d b t hi t d• logischer Prozess: beschreibt den logischen Kontrollfluss und abstrahiert von der zugrunde liegenden physischen Prozessstruktur

• dezentralisierte Architekturen:— typischerweise Aufteilung in mehrere logische Prozesse

StructureCl ifi tiClassification

Monolithic Peer-to-PeerModular

Centralistic Layered


Client/Server-Architekturen

• Server: Dienstanbieter, d.h. Prozess, der einen bestimmten Dienst imple-mentiert (z B Datei DB)mentiert (z.B. Datei, DB)

• Client: Dienstnutzer, d.h. Prozess der Dienst von einem Server anfordert und auf Ergebnis wartet (request-reply)und auf Ergebnis wartet (request reply)— Verschicken (request) und Empfangen einer Nachricht (reply) erfolgen als

Einheit ermöglicht synchrone Kommunikation über asynchrone Infrastruktur— ermöglicht synchrone Kommunikation über asynchrone Infrastruktur

— Umsetzung z.B. über unterschiedliche Warteschlangen für Request- und Reply-Nachrichten

• vertikale Verteilung der Funktionen mithilfe von Schichten, typischerweise— Benutzungsschnittstelleg— Verarbeitungsebene— Datenebene


Grundlagen Schichenarchitektureng

aus Netzwerktechnik über-nommen:nommen:

• Li ist Dienstnehmer von Li-1

• dient der funktionalen• dient der funktionalen Trennung

• führt zur leichteren Aus-tauschbarkeit

• Steuerung läuft von Schicht zu SchichtSchicht zu Schicht— Anforderungen Ln -> L1

— Ergebnisse L1 -> Ln


[Wikipedia 2008]

Mehrschichtarchitekturen

• Verteilung der Schichten auf Client und Server (physische „2 Tier“-Architektur)• Beispiele:Beispiele:

— endgeräteabhängiges GUI auf Client— Formularüberprüfungen auf den Client verlagern— Web Browser Cacheeb o se Cac e

• Tendenz zu Thin Clients wegen des Verwaltungsaufwandes• physische „3 Tier“-Architektur erlaubt weitere Trennung der logischen Schichten• darüber hinaus gehende NTier“-Schichtmodelle möglichdarüber hinaus gehende „NTier Schichtmodelle möglich

GUI GUI GUI

Client

Anwendung

GUI GUI GUI

Anwendung

Datenbank

Anwendung

Anwendung

Datenbank Datenbank


DatenbankDatenbank Datenbank

Server

Peer-to-Peer-Architekturen

• Horizontale Verteilung der Funk-tionentionen— Systeme können gleichartige

Funktionen besitzen• Jeder Peer agiert gleichzeitig als

Client und Server (Servant)• Overlay-Netzwerk für Kommuni-Overlay Netzwerk für Kommuni

kation der Peers— logisches Netz oberhalb existie-

render Infrastrukturrender Infrastruktur — oftmals eigener Adressraum mit

eigener Adressierung• Mechanismen zum Auffinden

von Ressourcen notwendig

vsis inf min uni hh ws 11_12 VIS-1 Arch-12[Wikipedia 2008]

Arten von Peer-to-Peer-Systemeny

• strukturierte Peer-to-Peer-Architekturendeterministische Generierung des Overlay Netzwerks über z B DHT— deterministische Generierung des Overlay-Netzwerks über z.B. DHT

— Datenelementen werden systematisch bestimmte Konten zugeordnet — Bsp. CAN, räumliche Aufteilung der Teilnehmer und ihrer Verantwortlichkeiten

• unstrukturierte Peer-to-Peer-Architekturen— zufallsgesteuerte Generierung des Overlay-Netzwerks— jeder Knoten besitzt Liste von Nachbarn (partielle Sicht) – Austauschverfah-

ren für Listen— Datenelemente sind zufällig auf Knoten verteilt— Auffinden von Datenelementen über Flooding

• HybridarchitekturenHybridarchitekturen— Super-Peer-Systeme— Edge-Server-Systeme


Umsetzung von Funktionalitäten verteilter Systemeg y

• Einzelne Middleware-Systeme folgen bestimmten Architekturstilen (zum Beispiel: CORBA ist objektbasiert)(zum Beispiel: CORBA ist objektbasiert)

• Damit fördern sie jedoch jeweils genau eine Art verteilter Anwendungen;j j g g ;unterschiedliche Lösungsmöglichkeiten:

— alle Funktionen integrieren

• Problem: aufgeblähte Software

— unterschiedliche Versionen

• Problem: aufwendig zu entwickeln, warten

— änderbare Middleware (am besten sich selbst anpassend)

• Problem: schwierig zu konstruieren, Ziele u.a.: Separation of Concerns, Reflektion, komponentenbasiertes Design


Selbstmanagement von Systemeng y

• Ziel: automatische Anpassung der SoftwareA d A füh h lt— Anpassung des Ausführungsverhaltens

— Anpassung der konstituierenden Softwarekomponenten

• Gründe:— Umgebung ändert sich

verteilte Anwendungen sind z T 24/7— verteilte Anwendungen sind z.T. 24/7

• Eine Lösungsidee: Autonomic Computingg p g— “Autonomic Computing is an initiative started by IBM in 2001. Its ultimate aim

is to develop computer systems capable of self-management, to overcome the rapidly growing complexity of computing systems management, and to reduce p y g g p y p g y g ,the barrier that that complexity poses to further growth.”


Self*(CHOP)-Eigenschaften( ) g


CHOP: configure, heal, optimize, and protect [IBM 2005]

Autonome RückkopplungssteuerungAutonome Rückkopplungssteuerung• Steuerung einer „Managed Resource“ durch „Autonomic Manager“

Z iff üb St d d Z iff kt ( T h i t“)• Zugriff über Standard-Zugriffspunkt („Touchpoint“)• MAPE-Loop (Monitor, Analyze, Plan, Execute)

vsis inf min uni hh ws 11_12 VIS-1 Arch-17(IBM 2005)

Autonome Systeme: Architekturvisiony

vsis inf min uni hh ws 11_12 VIS-1 Arch-18[IBM 2005]

Architektur (verteilter) Systemsoftware

Banksystem Flugreservierung Spiele Anwendungen

RechensystemBanksystem Flugreservierung Spiele ...

Compiler Editoren ... Kommandointerpreter

Anwendungen

System-programmeBetriebssystemBetriebssystemHard-ware

BetriebssystemBetriebssystemMaschinensprache, Mikroprogrammierung

physikalische Geräte

Alternative Sichtweisen eines (verteilten) Betriebssystems...

...als „erweitere / virtuelle“ Maschine„erweitere / virtuelle“ MaschineZiel: zunehmend „komfortable“ Abstraktion von Systemeigenschaften

...als „BetriebsmittelverwalterBetriebsmittelverwalter“Aufgaben: Allokation / Vermittlung / Verwaltung von Ressourcen –d h (u a ) von Speichern Prozessen Geräten Netzschnittstellen etc


d.h. (u.a.) von Speichern, Prozessen, Geräten, Netzschnittstellen etc.

Zum Vergleich: Betriebssystem-Architektureng y

5 OperateurA) Geschichtetes SystemB THE (Dijk t 68) 4 Benutzerprogramme

3 Ein-/Ausgabeverwaltung

2 Prozesskommunikation

Bsp: THE (Dijkstra 68)

1 Speicherverwaltung

0 Prozessorvergabe/Multiprogrammierung

B) Virtuelle MaschineBsp: IBM /370 mit VMS (80er) CMS CMS CMS

Virtuelle /370 Virtuelle /370 Virtuelle /370

VM / 370/370 Hardware

C) Client/Server-Modell ClientKern

ServerKern

ServerKern

zentralBS-(micro)Kern(el)


Inter-Prozesskommunikationzentral

modularer Aufbau, flexibel, erweiterbar, ...

Betriebssystemunterstützung: Systemalternativen y g y

A) Mono-Prozessor:MicrokernelMicrokernel ArchitekturMicrokernelMicrokernel-Architektur User

Applic.MemoryMangmt.

ProcessModule

...OS Interface OS Interface OS Interface

Microkernel

Hardware

OS Interface

System call

OS Interface OS Interface

DOS (Di t ib t d OS) k l BS fü M l i PB) Multi-Prozessor: • DOS (Distributed OS): eng gekoppeltes BS für Multi-Prozessoren und homogene Multi-Computer

• NOS (Network OS): lose gekoppeltes BS für heterogene ( ) g g

Multi-Computer (LAN und WAN)

• Middleware: zusätzliche Ebene oberhalb des NOS zur Implemen-ti ll i Di t


tierung allgemeiner Dienste

Verteilte Betriebssystem-Alternativen (1)

Distributed ApplicationsA) Netzwerk-BS:

NetworkOS services ...

NetworkOS services

+ Autonomie- Transparenz

NetworkOS services

Kernel Kernel Kernel

Rechner A Rechner B Rechner C

Di t ib t d A li tiB) Multiprocessor/

Netzwerk

Distributed ApplicationsMulticomputer /Verteiltes BS:

Distributed OS System Services


Rechner A Rechner B Rechner C...

+ Transparenz- Autonomie


Netzwerk

Verteilte Betriebssystem-Alternativen (2)

C) Middleware-basiertes verteiltes (Betriebs-) System:

Distributed Applications

Network NetworkNetwork

Middleware Services

NetworkOS

services

NetworkOS

services

NetworkOS

services


Net erk

Rechner A Rechner B Rechner C...

Netzwerk

Basis: Client/Server- (Dienste-) Kooperation auf Anwendungs und Systemebene!


auf Anwendungs- und Systemebene!

Vergleich der Betriebssystem-Alternativeng yDistributed OSMultiprocessor

Distributed OSMulticomputer

Network OS Middleware-based DSMultiprocessor Multicomputer

Degree of transparency

Very high High Low High

S OS Y Y N NSame OS on all nodes ?

Yes Yes No No

Number of 1 N N Ncopies of OSBasis for com-munication

Shared memory Messages Files Model specificmunicationRessource management

Global, central Global, distributed

Per node Per node

Scalability No Moderately Yes Varies

Openness Closed Closed Open Open


Paradigmen für die Konstruktion verteilter Systemeg y

Softwareparadigma• bestimmt die Konzepte für die Beschreibung und Realisierung von• bestimmt die Konzepte für die Beschreibung und Realisierung von

Softwaresystemen• legt den Abstraktionsgrad für die Beschreibung fest („Weltmodell“)• fördert / behindert bestimmte Architekturen• entwickelt sich stetig weiter in Richtung abstrakterer Konzepte

• Historische Entwicklung Programmierparadigmen als Beispiel:— von der imperativen zur objektorientierten Programmierung

imperativ: Computerprogramm als lineare Folge von Befehlen— imperativ: Computerprogramm als lineare Folge von Befehlen— objektorientiert: Kapselung von Daten und Methoden zu Klassen/Objekten

k ti ll V bild— konzeptionelle Vorbilder:• imperativ: von-Neumann-Rechner• objektorientiert: reale Welt bestehend aus (realen/virtuellen) Objekten


Objektorientiertes Paradigmaj g

• Objekte als Einheiten für Daten und Verhaltenb i t f th d b i t K ik ti d d Cli t/S• basiert auf methodenbasierten Kommunikation und dem Client/Server-Modell für den Aufbau

• Diensterbringer/ -nehmer sind dabei Objekte beliebiger Granularitätg j g• Durch Objektidentitäten ist systemweite Identifizierung von Dienster-

bringern möglichMi ti Obj kt ö li ht t t L f it d• Migration von Objekten ermöglicht transparente Laufzeitanpassung der Anwendungskonfiguration

• Probleme: Wiederverwendbarkeit der Objekte zumeist gering, da keine j g g,Trennung der Querschnittsaspekte möglich ist (wie z.B. Persistenz- oder Sicherheitseigenschaften)

O1

Rechner 1

O2

O3 O4

O5


Rechner 2O5

Komponentenbasiertes Paradigmap g• Erweiterung des objektorientierten Paradigmas• Komponenten sind grob-granulare Einheiten auf fachlicher Ebene mit

klaren Schnittstellenklaren Schnittstellen• Komponenten in sich abgeschlossen (self contained) bzw. definieren

genau ihre Abhängigkeiten• Idee: Komponenten Repositories zur bausteinartigen Komposition von• Idee: Komponenten-Repositories zur bausteinartigen Komposition von

Software aus vorgefertigten Komponenten• Komponenten umfassen im Wesentlichen nur die Anwendungslogik, sie

sind getrennt vom Einsatzkontext d h sie werden erst beim Deploymentsind getrennt vom Einsatzkontext, d.h. sie werden erst beim Deployment genau konfiguriert (Sicherheit, Transaktionen, Persistenz, …)

• Komponenten besitzen einheitliches Deployment-Modell• Komponenten werden oftmals in speziellen Containern ausgeführtKomponenten werden oftmals in speziellen Containern ausgeführt • Beispiel: Enterprise Java Beans, .NET-Komponten

Container 1Rechner 1

K1K2

K3


Container 1Rechner 2

Dienstorientiertes Paradigmag

• SOA – Service Oriented Architecture• prozessorientierte Sicht mit fachlichen Diensten als Basiskonzept• prozessorientierte Sicht mit fachlichen Diensten als Basiskonzept• Dienste sind grob-granulare Bausteine von Softwaresystemen, die in loser

Kopplung zu Geschäftsprozessen / Abläufen integriert werden können— Orchestrierung— Orchestrierung— Choreografie

• Dienste zeichnen sich wohl-definierte Schnittstellen ausDienste können sowohl synchron als auch asynchron verwendet werden• Dienste können sowohl synchron als auch asynchron verwendet werden

• Ziel: Interoperabilität durch Standards (Technologieunabhängigkeit)

S2S1I1

Rechner 1

Rechner 2

S2I2

I1S3I1


Rechner 2

Agentenbasiertes Paradigmag g

• System wird als Zusammenspiel unabhängiger Akteure (Agenten) gesehen (Multiagentensystem)gesehen (Multiagentensystem)

• Kommunikation ist grundsätzlich asynchron (nachrichtenbasiert)• Basiskonzept Agent als in einer Umgebung situierte Einheit, die über

Aktuatoren und Effektoren verfügt• Agenten entscheiden grundsätzlich autonom, wie sie Nachrichten inter-

pretierenp et e e• Verhaltensspezifikation eines Agenten über interne Architekturen• Verhaltensspezifikation eines Multiagentensystems über Koordination der

i l A ( l h i l A hit kt )einzelnen Agenten (vgl. auch soziale Architekturen)

A1

Plattform 2

Plattform 1

Rechner 1

A2A1

A3


Plattform 2Rechner 2

Überblick über Paradigmen für VSg

CommunicationCommunicationAbstractness

Peer Negotiations

Asynchronous Calls

S i O i t ti

AgentOrientation

Synchronous Calls ImperativeProgramming Object

Service-OrientationComponentOrientation

Modelling EntitiesAbstractnessData and Procedures Objects Actors

Orientation


Zusammenfassungg• Kommunikationsarten

— direkt vs. indirekt und die Realisierungskonzepte• Prozeduraufruf• Prozeduraufruf• Nachrichten• Ereignisse• gemeinsamer Datenraumg

• Architekturen— von zentral bis vollständig dezentral – auch im Vergleich mit Betriebssystemenvon zentral bis vollständig dezentral auch im Vergleich mit Betriebssystemen

• Client/Server • netzwerkorientiert• Schichten • vollständig verteilt• Peer-to-Peer • Middleware-basiert

• Paradigmen für die Konstruktion verteilter Systeme— Versuchen, die Realität in Software abbildbar zu machen— VS sind charakterisiert durch die Art der Kommunikation und der Entitäten— Paradigmen bestimmen die Beschreibungsmöglichkeiten und damit das „Weltbild“


systemarchitekturen zur konstruktion verteilter systeme · is to develop computer systems capable...

Documents