Definition von Verteilten Systemen

Die Fachliteratur verwendet eine Vielzahl von Definition, die ungefähr folgendermaßen zusammengefasst werden können.

„Ein Verteiltes System ist ein informationsverarbeitendes System mit vernetzten autonomen Einheiten, welche mittels Nachrichtenaustausch ein (gemeinsames) Ziel verfolgen.“

Der Begriff der autonomen Einheit ist bewusst abstrakt gewählt, weil man darin einerseits die physikalische Sicht, das heißt die Rechner, aber auch die logische Sicht auf Anwendungsebene, zum Beispiel gemeinsam kooperierende Prozesse, zu verstehen hat.

Der Gegenstand der Verteilung kann über Zustände hinaus auch Verhalten beinhalten. So ist die Verteilung und Bereitstellung von Programmlogik durch entsprechende Funktionen oder Prozesse ein wichtiges Merkmal.

Vorteile von Verteilten Systemen

Die Verstreuung autonomer Programmteile oder Daten über ein Netzwerk führt zu einer starken Dezentralisierung und je nachdem zu einem hohen Grad an Redundanz. Die Vorteile dieser Redundanz liegen in einer höheren Verfügbarkeit. Zu erledigende Aufgaben von Einheiten, die vorübergehend nicht funktionstüchtig sind, können auf andere Einheiten verlagert werden.

Die kooperative Arbeit von Einheiten insbesondere bei rechenintensiven Anwendungen resultiert in immenser Leistungssteigerung. Durch Parallelisierung der Prozesse kann Rechenleistung nahezu linear gesteigert werden.

Verteilte

Kommunikationkanäle

Nachrichtenaustausch zwischen Rechnern können betriebliche Abläufe durch guten Datenfluss und der Vermeidung von Medienbrüchen effizienter durchgeführt werden. Diese Tatsache deckt sich auch mit der Forderung nach Wirtschaftlichkeit durch die Unternehmensziele.

Charakteristisch für Verteilte Systeme ist auch deren Skalierbarkeit. Bei Definition einheitlicher Schnittstellen lassen sich Teile des Systems ohne großen Aufwand anfügen, ersetzen oder entfernen. Mitunter gestalten sich solche Operationen sogar einfacher als auf manchen lokalen Systemen.

2

Nachteile von Verteilten Systemen:

Neben den Vorteilen hat die Verteilung aber auch eine Reihe von nachteiligen Effekten aufzuweisen. Je granulierter das Verteilte System nämlich gestrickt ist, desto mehr potentielle Fehlerquellen birgt das System als Ganzes. Denn mit jedem neuen Element vergrößert sich die Angriffsfläche und der Aufwand, Fehler oder Sicherheitslücken zu finden und zu beheben, sofern dies möglich ist.

Aus der Redundanz resultiert für die Datenverwaltung das Problem der Datenkonsistenz. Existieren Daten, die einen gleichen Sachverhalt modellieren, an mehreren Stellen im System, so ist im Falle einer Datenänderung an einer Stelle eine Aktualisierung an sämtlichen anderen Stellen vorzunehmen. Überschneiden sich jedoch

Aktualisierungsvorgänge, kann es zu Konflikten oder Verfälschungen kommen.

Letztlich ist das Phänomen der Heterogenität in Verteilten Systemen gegenwärtig. Da sich verschiedenste Systeme im Bereich der Rechnerarchitekturen und auf Betriebs- und Anwendungsebene im Markt etabliert haben, werden die Stimmen einer Integration dieser immer lauter. Gerade Verteilte Systeme leiden aufgrund ihres integrativen Charakters an der Vielzahl von unterschiedlichen Technologien und Plattformen. Kommunikation, und das ist nichts neues, basiert nun mal auf Vereinbarungen (z.B. Sprache, Codierungsregeln, u.s.w.)

Das Klient/Server Modell

Um gängige Kommunikationsprozesse zu erfassen, hat sich das Klient/Server Modell besonders bewährt. Es sieht vor, allen Kommunikationsteilnehmern die Rolle eines Klienten oder eines Servers zuzuordnen. In diesem Zusammenhang stellt der Server dem Klienten bestimmte Dienste zur Verfügung, welcher ohne weiteres auch selber die Rolle eines Klienten einnehmen kann. Äquivalent zu Verteilten Systemen ist auch hier die Hardwareebene ebenso relevant wie die Softwareebene.

Das Klient/Server Modell hat seine Ursprünge in der Mikro-Kernel Architektur, wo der Mikrokernel als Server fungiert und die Klientprozesse im Benutzermodus auf die Dienste des Kernels zugreifen. Man spricht auch häufig von dem aktiven und dem passiven Teil.

Klassifikation der Nachrichtenkommunikation

Der Nachrichtenaustausch zwischen zwei Kommunikationspartnern lässt sich grundlegend wie folgt klassifizieren:

• Mitteilungsorientierte Kommunikation

• Unidirektionale Nachrichtenversand • Klassische Rollenverteilung in Quelle und Senke • Der Nachrichtenempfang wird nicht bestätigt

• Auftragsorientierte Kommunikation

• Bidirektionaler Nachrichtenaustausch • Beide Partner sind Quelle und Senke zugleich • Empfänger quittiert den Empfang einer Nachricht an den Sender

3

• Synchrone Kommunikation:

• Sender wartet (bleibt passiv oder blockiert), bis Nachricht vollständig empfangen ist

• Asynchrone Kommunikation:

• Sender wartet nicht auf den vollständigen Empfang der Nachricht durch den Empfänger. Es kann beispielsweise schon eine zweite Verbindung aufbauen. • Problem: Sender kann schneller Nachrichten schneller versenden, als der Empfänger empfangen kann. Lösung: Nachrichtenpuffer • Sehr gut zur Parallelisierung in Verteilten Systemen geeignet, da Flaschenhälse umgangen werden

Fehlervarianten in der Kommunikation

Mit Blick auf die oben erwähnten Kommunikationsmechanismen ergeben sich mehrere Fehlerkategorien, die an dieser Stelle nicht fehlen dürfen.

• Nachrichtenverlust bei der asynchronen auftragsorientierten Kommunikation

• Möglichkeiten:

• Ausfall des Servers inmitten einer Transaktion

• Wurde eine Transaktion zur Manipulation von Datenbeständen durchgeführt, so kann dies zur Verfälschungen der Daten führen; die Datenintegrität ist gefährdet

4

• Ausfall des Klienten

• Auch hier können unter Umständen Daten verfälscht werden

• Man spricht von einem verwaisten Aufruf

Behandlung von Fehlern

Maßnahmen und Mechanismen zur Behandlung von Fehlern werden unter den sogenannten Fehlersemantiken zusammengefasst.

• Exactly-Once-Semantik

• Unvollständig ausgeführte Aufträge werden durch die Einführung atomarer Transaktionen verhindert

• „Die atomare Transaktion“ gibt in der Praxis leider nicht

• Maybe-Semantik

• Diese Variante wird auch als die „best-effort“ - Semantik bezeichnet. Sie beinhaltet keinerlei Sicherungsmaßnahmen • Eine hohe Fehlerhäufigkeit ist vorprogrammiert

• At-least-Once-Semantik

• Im Falle eines Verlustes einer Nachricht wird diese wiederholt gesendet. • Die Abfrage soll auf jeden Fall mindestens einmal ausgeführt werden • Einzusetzen bei idempotenten Aufrufen

• At-Most-Once-Semantik

• Die Abfrage darf höchstens einmal ausgeführt werden • Es bedarf an komplexer Mechanismen zur Erfüllung dieses strengen Kriteriums

Kommunikations- und Koordinationsmechanismen in Verteilten Systemen Verteilte Systeme kann man auf unterschiedlichen Abstraktionsgraden realisieren. Meist entscheidet der Anwendungsbereich über die konkrete Ausprägung. Nachfolgend sind die Techniken aufgelistet.

• Message Passing

• Dies ist die einfachste Form der Datenübermittlung. Es handelt sich um eine simple mitteilungsorientierte Nachrichtenübertragung.

• Die Übertragung findet synchron oder asynchron zwischen einem Klienten und dem Server statt.

5

• Remote Procedure Call (RPC)

• Diese Technik sieht entfernte Prozeduraufrufe, also die Ausführung bestimmter Programmteile über das Netzwerk vor.

• Ein monolithisches Programm wird hierzu in unabhängige Module partioniert und jedes einzelne unter Verwendung eines festgelegten Zugriffsverfahrens freigegeben.

• Die tatsächliche Kommunikation läuft mittels Message Passing zwischen server-und clientseitigen Stubs ab, die den Prozeduraufruf für den Programmierer transparent machen.

• PC-Netzbetriebssysteme

• Das Konzept des Netzbetriebssysteme stammt aus dem LAN-Bereich, welches eine Vernetzung von Arbeitsrechnern zum Zwecke des Dokumentenaustauschs vorsieht. • Der Dokumenten- oder Fileserver ist die zentrale Einheit, welches den Klienten den Zugriff auf gemeinsame Ressourcen ermöglicht.

6

• Entfernte Datenbankzugriffe

• Ein zentraler Datenbankserver ermöglicht Klienten den Zugriff auf seine Daten mittels der standardisierten SQL-Schnittstelle.

• Aufgrund der Mächtigkeit des relationalen Datenmodells hat sich diese Form der Datenverteilung auf breiter Basis durchgesetzt. • Der Hauptaugenmerk liegt aber auf der Verteilung von Daten, nicht auf Anwendungslogik b.z.w. Prozessen.

• Verteilte Objektsysteme

• In Objektsystem ist, wie der Name schon sagt, das Objekt der Gegenstand der Verteilung.

• Die OMG (Object Management Group) ist eine der eifrigsten Verfechter der objektorientierten Modellierung, welche bisher eine Reihe von Spezifikationen verabschiedet hat

• Grundlage für die Verteilung von Objekten ist der Einsatz von sogenannten ORB (Object Request Brokers) • Modellgestützte Anwendungsarchitekturen hoher Komplexität sind hier realisierbar

• Es liegt nahe, dass sich Verteilte Objektsysteme auf das RPC stützen

7

Das Objektmodell

Das Anwenden von Modellen entspringt aus der Notwendigkeit, durch das Verbildlichen und Abstrahieren von Sachverhalten eine gewisse Transparenz und eine einfachere Handhabung zu erzielen. Gerade aus diesem Grund hat sich das Objektmodell in der Anwendungsentwicklung besonders etabliert. Es liefert nämlich im Gegensatz zur prozeduralen Anwendungsentwicklung dem Entwickler eine realitätsnahe Sichtweise auf die Problemstellung.

Die Fachliteratur findet in der Definition folgenden Konsens:

„Das Objektmodell beschreibt die Struktur der Objekte in einem System,

einschließlich ihrer Identität, Relationen zu anderen Objekten, Attribute und Operationen.“

Anders ausgedrückt:

Die ganze Welt besteht aus Objekten unterschiedlicher Ausprägungen, die miteinander in Beziehung stehen und interagieren.

Die Merkmale seien hier nur kurz angerissen:

• Abstraktion

• Durch das Abstrahieren werden irrelevante Eigenschaften aus der realen Welt ausgeblendet (Schaffen einer relevanten Welt - UoD - Universe of Discourse)

• Strukturierung

• Durch die Strukturierung in Objekte werden komplexe Problembereiche leichter händelbar

• Modularität

• Die Modularität ermöglicht die einfache Austauschbarkeit und Erweiterbarkeit • Kapselung

• Das Verbergen der internen Implementation durch einen verbindlichen Zugriff über definierte Schnittstellen unterbindet Abhängigkeiten (Kapselung)

• Hierarchie

• Die Abstrahierung und Spezialisierung wird als Strukturierungsmittel verwendet, um Objekteigenschaften effizient zu verwalten

• Beziehungen zwischen Objekten werden zum Beispiel durch Aggregationen oder Kompositionen beschrieben

8

Kommunikationsarten zwischen Objekten

Kommunikationsarten zwischen Objekten sollen an dieser Stelle nicht unerwähnt bleiben. Äquivalent zu dem Broadcast und dem Multicast aus dem Netzwerkbereich lassen sich Kommunikationsarten nunmehr a uch auf den Nachrichtenaustausch zwischen ausweiten. • 1:1 Kommunikation

• Die klassische Form ist die, dass zwei Objekte miteinander kommunizieren

• 1:n Kommunikation

• Ein Objekt sendet seine Botschaft gleichzeitig an mehrere Objekte. Die Empfängerobjekte können entweder explizite Abonnenten sein oder nicht. • Das Java Messaging Service (JMS) der Sun J2EE enthält Ansätze zur Realisierung dieser Kommunikationsart

9

Definition einer Verteilungsplattform

Eine Verteilungsplattform (zu englisch Middleware: Software zwischen Betriebssystem und Anwendung) bietet allgemein einsetzbare Dienste an, um das Entwickeln, Betreiben und Pflegen von Verteilten Systemen zu realisieren. Verteilungsplattformen bilden also eine Mittelschicht zwischen der Anwendung und dem darunterliegenden Betriebssystem.

Ein weitere Sichtweise von Middleware ergibt sich aus dem modifiziertem OSI-Referenzmodell nach Tanenbaum.

Verteilungsplattformen bilden demnach die Schnittstelle zwischen der Anwendung und dem Internet. Der fundamentale Zweck besteht darin, dass eine Verteilungsplattform die Unterschiede der darunterliegenden Systeme einkapselt, sozusagen den Zugang der Anwendung ins Netz homogenisiert. Die zu überwindenden Heterogenität ist entweder in der verwendeten Programmiersprache zu finden, im Betriebssystem, in der

Netzwerktechnologie oder gar in der Rechnerarchitektur.

10

Sichten auf die Verteilungsplattform

Im Anschluss an die Definition ist eine Klassifikation der Sichten auf eine Verteilungsplattform wichtig.

• Die Sicht des Anwendungsprogrammierers

• Der Anwendungsprogrammierer bemüht sich um die Anwendungslogik. Er nutzt dabei die Verteilungsplattform über definierte Schnittstellen, die in einer API zusammengefasst sind. Diese API stellt den einheitlichen Zugangspunkt her. • Technisches Know-How über die interne Funktionsweise besitzt er nicht.

• Die Sicht des Systemprogrammierers

• Der Systemprogrammierer weiß, wie die Verteilungsplattform funktioniert, ist aber aber über deren Verwendung wenig vertraut.

• Der Systemprogrammierer nimmt dem Anwendungsentwickler dadurch einiges an Arbeit ab.

Quit-Essence: Ein Systemprogrammierer stellt etwas bereit, was der

Anwendungsprogrammierer nutzt.

11

Anforderungen an die Verteilungsplattform

Um den Aufgaben gerecht zu werden, müssen Verteilungsplattform eine Reihe von Anforderungen erfüllen. Diese können von Fall zu Fall unterschiedlich ausgeprägt sein.

• Operationale Interaktion

• Unmittelbar aus der Definition des Objektmodells leitet sich die Forderung nach Interaktion ab. Darunter ist generell die Möglichkeit des Austauschs von Funktionen und Daten innerhalb der Objekte gemeint.

• Entfernte Interaktion (Nachrichtenaustausch mit entfernten Objekten)

• Die entfernte Interaktion erlaubt die Kommunikation zwischen entfernten Objekten. Dies geschieht durch Methodenaufrufe unterschiedlich lokalisierter Objekte mittels Nachrichtenaustausch.

• In diesem Kontext ist die Wichtigkeit der Steuerung des zeitlichen Ablaufs der Interaktionen (Synchronisation) zu nennen. (Siehe Fehlervarianten weiter oben) • Allgemein kann man auch von einem Austausch verteilter Ressourcen reden, wo dann z.B. auch die Peripherie inbegriffen ist.

12

• Transparenz

• Eine Schlüsselstellung nimmt die Transparenz, also das Verbergen der Heterogenität ein. Die Komplexität des Verteilten Systems wird über für den Anwendungsprogrammierer überdeckt, also transparent gemacht. • Ein einfacher und effizienter Umgang erfordert diese „Simulation einer Homogenität“ • Eine hohe und vielfältige Transparenz berücksichtigt verschiedene

Gesichtspunkte, die sich zum Teil überlappen:

Technologietransparenz (Technology Transparency)

• Die verwendeten Technologien bleiben verborgen

Ortstransparenz (Location Transpareny)

• Der Zugriff auf lokale oder entfernte Objekt erfolgt gleichermaßen

Zugriffstransparenz (Access Transparency)

• Auf alle Objekte wird auf die selbe Art und Weise zugegriffen.

Ausfalltransparenz (Failure Transparency)

• Fehler im Netz werden möglichst vom System maskiert

Prozesstransparenz (Process Transparency)

• Der Ausführungsort einer Methode hat keinen Einfluss auf die

Ressourcentransparenz (Resource Transparency)

• Die verwendeten Resourcen sind einheitlich freigegeben

Migrationstransparenz (Migration Transparency)

Skalierungstransparenz (Scaling Transparency)

Leistungstransparenz (Performance Transparency)

• Die dynamische Konfigurierung (Lastverteilung) des Systems zur

Synchronisationsstransparenz (Synchronisation Transparency)

Replikationstransparenz (Replication Transparency)

Es ist zu erwähnen, dass eine absolute Transparenz nicht möglich ist, da in der Praxis öfters Situationen eintreten, die auf die Verteiltheit hindeuten. Dies können sein eine schlechte Netzverbindung, oder ein temporäre Abwesenheit von Objekten während einer „Off-line“ Migration.

• Unabhängigkeit (Integration verschiedener Technologien und Hersteller) • Die Zugriffs- und Technologietransparenz erfordert eine große Unabhängigkeit seitens der Verteilungsplattform.

• Die Unabhängigkeit von Technologien und Herstellern ist daher entscheidend für die Akzeptanz und die Verbreitung. Heutzutage sind weltumspannende Verteilte Systeme keine Vision mehr, sondern Realität. Ein Verteiltes System entgegnet dieser Tatsache mit einer möglichst großen Akzeptanz von Bestehendem aber auch einer möglichst großen Offenheit gegenüber Neuem. • Unabhängigkeit gibt es auf folgenden Ebenen:

Die Notwendigkeit einer Standardisierung

Aus der Tatsache heraus, dass ein Hersteller alleine kein Produkt für sämtliche Plattformen bereitsstellen kann, entsteht die Idee der Standardisierung. Ein Standard wird meißt von einer unabhängigen non-profiten Organisation eingereicht, die eine Spezifikation für einen konkretes Problem enthält. Diese Spezifikationen kann dann von Herstellern implementiert werden, so dass die Kompatibilität zwischen den Produkten gewahrt bleibt. Insellösungen werden vermieden; der Markt wird durch die Konkurenz belebt, genauso wie er es durch die Kunden tut, weil diese eine zukunftsträchtige Technologie investiert haben

14

Zu den Eigenschaften eines Standards zählen:

• Nicht proprietär: Beim Enstehungsprozess stehen keine kommerziellen Interessen im Vordergrund

• Freie Verfügbarkeit: Alle Hersteller können sich an der Implementierung beteiligen • Technologieunanhängigkeit: Meißt enstehen Produkteauf unterschiedlichen Plattformen realisiert

• Abstraktion: Das abstrakte Vorgehen im Entstehungsprozess erlaubt es, „meist“ einen großen gemeinsamen Nenner zu finden

• Portabilität und Interoperatibilität

Heterogenität ist in einer Verteilungsplattformen an zwei Schnittstellen angesiedelt.

Horizontale Schnitstelle

• Diese Schnittstelle liegt zwischen der Anwendung und der Verteilungsplattform. • Die Kompatibilität der umliegenden Schichten wird als Portierbarkeit bezeichnet • Durch Verwendung einer gemeinsamen API wird das Problem herangegangen. Man spricht hier häufig auch über „portierbaren Code“.

Vertikale Schnittstelle

• Können zwei Instanzen einer Verteilunsplattformen miteinander „reden“, benutzen diese ein gemeinsames Protokoll. Ein Beispiel für ein solches ist das Internet Inter-ORB Protokoll (IIOP) • Die Kompatibilität zwischen zwei Instanzen einer Verteilungsplattform

ermöglicht die "Interoperabilität zwischen Anwendungen" • Um die Integration mehrerer Plattformen bemüht sich SOAP (Simple Object Access Protocoll)

Zu erkennen Beispielsweise Schnittstellen hinweg.

15

Allgemeine Anforderungen an Middleware Lösungen

Neben den gestellten Anforderungen auf die Verteilungsplattform als Teil eines Verteilten Systems sind weitere Basisdienste notwendig, die das Betreiben von verteilten Anwendungen unterstützen.

• Verzeichnissdienste

Damit sich Objekte untereinander auch finden, wird ein Auskunftsdienst eingeführt. Mittels einfach händelbarer Namen (DNS oder JNDI z.B) wird ein dynamisches Binden

ermöglicht. Das heißt, dass erst zur Laufzeit bekannt wird, welches konkrete Objekt der Begierde nun angesprochen wird.

• Sicherheitskomponente

Die Unterstützung von kryptografische Methoden zur Authentifizierung und Überprüfung der Datenintegrität ist heutzutage unerlässlich.

Durch die zunehmend wachsende Verteilung von unternehmenskritischen Daten ist das Thema Sicherheit wieder in aller Munde (Viele Exponate der Systems in München beschäftigten sich mit dem Thema Sicherheit in unternehmensweiten Netzen)

• Synchronisation der Uhren

Da viele Dienste mit Zeitstempeln arbeiten, ist die Abstimmung der lokalen Uhren auf Klient- und Serverseite unerlässlich

• Management-Komponenten

Lizenzverwaltung und Netzwerkkonfiguration sind hier einige Schlagworte.

• Persistenz-Komponenten

In verteilten objekt-orientierten Umgebungen wird oft ein erweiterter Lebenszyklus für Objekte verlangt. Dieses „Objektrelationale Mapping“ von Objektzuständen, also die Speicherung von Objekteigenschaften auf ein dahinterliegendes Datenbanksystem ist Aufgabe von Persistenz-Frameworks (Führendes Produkt: TopLink)

16

Komponentenmodelle in objektbasierten Verteilungsplattformen Auf dem Markt haben sich grob zwei führende Technologien für Middleware-Architekturen durchgesetzt. Zur Einordnung dieser Komponentenmodelle sei folgendes gesagt:

Eine Komponente definiert sich so:

„Komponenten ist ein eigenständiges Stück Software mit strikter Kapselung und vorgegebenen Schnittstellen.“

Daraus ergibt sich für ein Komponentenmodell:

„Komponentenmodelle legen einen Rahmen für die Entwicklung und Aufsührung von Komponenten fest. Meißtens werden Komponenten objektorientiert durch Klassen implementiert und bestimmen maßgeblich die Architektur der Verteilungsplattform.“

Zu den konkurierenden Standards gehören:

• CORBA (Common Object Request Broker Architecture)

• Wichtiger Bestandteil von OMA (Object Management Architecture) der OMG (Object Management Group)

• EJB (Enterprise Java Beans) mit Java RMI (Suns Remote Method Invocation)

• Verteilte Objekte in Java sind Beans, Bestandteil der J2EE Softwarearchitektur • Entity Beans und Session Beans für Business Logik und Transaktionen • Container übernimmt Transaktionsmanagement, Verteilung und Persistenz

• DCOM (Distributed Component Object Model) von Microsoft

• Schrittweise Weiterentwicklung der COM-Technologie

• Definition von mehreren Schnittstellen für Zugriff auf eine COM Komponente • Zu den neuesten Entwicklungen aus dem Hause Microsoft gehört COM+

17

Abschließender Vergleich der Komponentenmodelle

Trotz ihrer architektonischen Übereinstimmung weisen diese essentielle Unterschiede auf.

Für die Entwicklung von Echtzeitsystemen ist keiner der Komponentenmodelle geeigent da zumal das Zeitverhalten unvorhersehbar und außerdem der Resourcenaufwand enorm hoch ist. Ein breiter Minuspunkt ist die fehlende Unterstützung von Entwicklern, was Tools, wie das Debuggen angeht.

18

Der Borland Application Server als Verteilungsplattform

Der Borland AppServer (Enterprise Java Beans Application Server) ist ein typisches Beispiel für eine Verteilungsplattform mit einer GUI Unterstützung zum Zwecke der Konfiguration. Man erkennt einen Großteil der zuvor besprochenen Merkmale einer Verteilungsplattformen wieder.

M.A.

19