Threaded Systems = Verteilte Systeme

Verteilte Systeme

Klaro: Distributed Systems = auf Deutsch: Verteilte Systeme. Threaded Systems sind verteilte Systeme, auch wenn die Verteilung “nur” innerhalb eines Computers, genaugenommen innerhalb einer Java-Virtual-Machine verteilt ist.

In ADRELI_2_THREAD haben wir ein verteiltes System in Anlehnung das Architekturmodell MVC entwickelt: verteilte, parallel-ablaufende Threads innerhalb einer JVM (Java-Virtual-Machine).

Beim 3. Sprint werden wir die Verteilung über der Adreli_Bestandteile über das Internet vornehmen. Genaugenommen verteilen wir über per TCP/IP-Protokoll verbunden Computer (also doch Internet oder Intranet).

Dies Verteilung über Intranet und Internet kann schon der gewichtigste Vorteil sein, warum Applikationen verteilt werden. Aber natürlich gibt es noch mehr Gründe dafür. Was auf der einen Seite ein Vorteil ist, kann auf der anderen Seite ein Nachteil sein!

Aus der Erfahrung bei der Modellierung und Programmierung von ADRELI_2_Thread (siehe vorhergehenden Blockpost) werden Sie vielleicht sagen, “… wäre toll, wenn es noch andere Vorteile aus der Verteilung gäbe, ist schließlich eine Menge Arbeit …” 🙂

Vorteile von Verteilten Systemen

Verteilte Systeme
Verteilte Systeme

Im Buch “Verteilte Systeme – Architekturen und Software-Technologien” ist eine Reihe von Vorteilen aufgelistet. Hier nun ausschnittsweise ein paar triftige Gründe.

Wie jede andere Technologie bringt auch die Verteilung von Anwendungen sowohl Vor- als auch Nachteile mit sich. Diese müssen für die jeweilige Situation im Einzelfall bewertet und abgewogen werden, geht nicht holter-ti-pollter.

Die Entwicklung verteilter Anwendungen ist generell durch eine erhöhte Komplexität gekennzeichnet. Deshalb stellt sich unmittelbar die Frage nach den Vorteilen solcher Ansätze und ob der Entwicklungsaufwand technisch und wirtschaftlich zu rechtfertigen ist.

Verteilte Systeme = Schnellere Programmentwicklung!

Durch die Verwendung vorgefertigter Komponenten wird die Anwendungsentwicklung vereinfacht und beschleunigt. Auch die Testphase kann dadurch verkürzt werden, dass auf bewährte, fehlerfreie Einzel-Komponenten zurückgegriffen wird.

Verteilte Systeme = Größere Flexibilität bei Anpassungen! 

Software die aus Komponenten besteht ist häufig einfacher an kundenspezifische Wünsche anzupassen. Es wird i.d.R. einfach eine komplette Komponente ausgetauscht. Sollten dennoch Änderungen nötig sein, dann beschränken diese sich meist nur auf eine vglw. kleine, überschaubare Komponente. Dadurch wird die Anpassung vereinfacht und Folgefehler unwahrscheinlicher als in einem großen, monolithischen Programm.

Geringere Wartungskosten!

Durch die Aufspaltung und Trennung der einzelnen Funktionalitäten sind Fehler leichter zu lokalisieren und zu beheben.

Inkrementell ausbaubar!

Neue Funktionen für ein Programm werden i.d.R. einfach als neue Komponenten hinzugefügt, ohne die restliche Umgebung des Programms zu verändern. Das ermöglicht einen einfachen Ausbau und verhindert, dass durch Hinzufügen einer neuen Funktion plötzlich Fehler bei anderen Funktionen des Programms auftreten.

Bessere Verfügbarkeit!

Der Ausfall einer Teilkomponente führt nicht zum Ausfall der gesamten Anwendung, sondern i.d.R. nur zum Verlust der von der Komponente implementierten Funktionalität. Dies hat den Vorteil, dass andere, evtl. wichtige, Funktionalitäten trotzdem noch verfügbar sind.

Dezentralisierung und Lokalität! 

Durch die Verteilung der Module wird eine weitgehende dezentrale Verarbeitung möglich. Damit kann eine hohe Lokalität in Bezug auf die Zuordnung der Daten und bearbeitenden Operationen erzielt werden. Dies wiederum verbessert die Laufzeiteigenschaften und erleichtert die organisatorische Verwaltung. (Hinweis: solange die Verteilung ausschließlich über Threads läuft, sind für die Verbesserung der Laufzeiteigenschaften Prozessoren notwendig die mehrere Kerne besitzen und Threading auf der HW-Ebene unterstützen.)

Parallele Verarbeitung! 

Da jeder beteilige Computer eigene Betriebsmittel, insbesondere Prozessor und Speicher, bereitstellt, können die einzelnen Module stark parallel arbeiten. Dadurch wird die Gesamtbearbeitungszeit eines Auftrags verkürzt. Voraussetzung für die Parallelisierung sind allerdings eine genaue Planung und Konstruktion, sowie eine entsprechende System- und Anwendungsarchitektur.

Fehlertoleranz!

Die beteiligten Computer sind weitgehend autonom. Dies gilt auch für Systemausfälle, d.h. bei Ausfall eines Rechners bleibt der übrige Teil der Anwendung auf anderen Rechnern funktionsfähig. Explizite Fehlertoleranz kann zusätzlich durch Replikation von Daten und Operationen erzielt werden. Die Entwicklung und Implementierung entsprechender Replikations- und Konsistenzerhaltungstechniken ist natürlich die Voraussetzung.

Gemeinsame Betriebsmittelnutzung!

Da verschiedene Rechner über ein Kommunikationsnetz gekoppelt sind, können sie auch gemeinsam auf Resorucen eines bestimmten Rechners zugreifen. Dadurch wird die gemeinsame Nutzung teurer Peripherie (Plotter, Speichergeräte, usw.) sowie komplexer Softwarekomponenten (z.B. Datenbanken) ermöglicht.

Integration von Teilanwendungen!

Die Gesamtheit vorhandener Teilanwendungen kann oft durch ihre Integration zu einer verteilten Gesamtanwendung gesteigert werden. Beispielsweise kann eine Managementdatenbank mit einem Spreadsheet-System gekoppelt werden, um automatisch Datenauswertungen durchzuführen. Dieser Punkt stellt in sehr vielen Fällen die wichtigste Motivation für den Einsatz verteilter Systemtechnologie in der industriellen Praxis dar. Die Integration von Teilanwendungen lässt sich vergleichsweise einfach erreichen und kann rasch zu einer realen Kostenreduktion führen, die zudem auch relativ genau gegenüber dem zu erwartenden Entwicklungsaufwand abgeschätzt werden kann.


Nachteile von Verteilten Systemen

Verteilte Systeme
Verteilte Systeme

OK – Und wie sieht es mit Nachteilen aus? Was könnte man als den “zu zahlenden Preis” für die Verteilung betrachten?

Im Buch “Verteilte Systeme – Architekturen und Software-Technologien” ist ist eine Reihe von Nachteilen aufgelistet (Im Kapitel 3.11)

Folgen Sie dem Link auf Google-Books und Sie können die Nachteile dort nachlesen und darüber nachdenken – Vor- und Nachteil liegen oft dicht nebeneinander.

Bist du fit für die Vorteil-Nachteil-Diskussion?

Vorteile / Nachteile mit der  Think-Pair-Share-Methode diskutieren? So funktioniert Think-Pair-Share – Ioannis erklärt das im  youtubeVideo:

Thank You – and have fun storming the castle!
Thank You – and have fun storming the castle!
Benutzer-Avatar

Autor: Prof. Illik Hans

Studium der Wirtschaftsinformatik an der TUM Technischen Universität in München. Berufliche Stationen: Hardwarehersteller in München - Softwarehäuser in München - eigene Firmen in München, Stuttgart und Birmingham/UK- mehrere Bücher zum Programmieren und eCommerce -Lehraufträge an verschiedenen Hochschulen in München, Stuttgart, Frankfurt - Professur an der HFU - Softwareentwickler (Ada/C/C++/C#/PHP/Python/Java) - Berater - Coach - Betriebsystemen (Unix-Portierungen) und Implementierung von eShops (Magento u.a.).

Schreibe einen Kommentar

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.