next up previous contents index
Next: Designbezogene Anforderungen Up: Anforderungen an die Middleware Previous: Grundlegende Forderungen

Verteilungstransparenz

Verteilungstransparenz  beschreibt die Fähigkeit, sowohl Entwickler und Benutzer als auch die Komponenten einer verteilten Anwendung selbst von der Komplexität und den technischen Details verteilter Systeme abzuschirmen. Man verfolgt hierbei das Prinzip des ,,Information hiding`` , um eine homogene Sicht auf das verteilte System zu gewährleisten, d.h. die Verteiltheit des Systems wird nicht sichtbar. Für Entwickler bedeutet Verteilungstransparenz, daß die Implementierung verteilter Anwendungen auf dieselbe Art erfolgen kann, wie die gewöhnlicher Applikationen. Das ODP-Referenzmodell definiert in [#!iso10746-1!#] insgesamt acht verschiedene Arten von Transparenz, die wir aufgrund ihrer Relevanz für die verteilte Anwendung ,,Management`` bereits an dieser Stelle einführen. Hierbei wird für ODP-konforme verteilte Systeme keinesfalls die vollständige Umsetzung aller Transparenzen gefordert, vielmehr sollte eine selektive Auswahl einzelner Transparenzen in Abhängigkeit des Anwendungsbereichs erfolgen. Die beiden erstgenannten Ausprägungsformen von Transparenz bilden hierbei den Grundstock, auf dem die sechs anderen Arten aufbauen.

1.
Zugriffstransparenz  ( Access transparency)  abstrahiert von den Arten der Datenrepräsentation sowie der Aufrufmechanismen von Prozeduren, um eine Zusammenarbeit von Applikationen, die auf heterogenen Systemen ablaufen, überhaupt zu ermöglichen.
2.
Ortstransparenz  (Location transparency)  zählt - zusammen mit der erstgenannten - zu den wohl wichtigsten Ausprägungsformen von Transparenz. Sie verdeckt den Ort, d.h. das konkrete System, an dem eine Komponente einer verteilten Anwendung sich befindet und gestattet so die Verwendung logischer anstelle von physikalischer Adressierung.
3.
Migrationstransparenz (Migration transparency)  baut auf dem Konzept der Ortstransparenz auf und bedeutet, daß eine Komponente von einem System zu einem anderen transferiert werden kann. Dieses Prinzip ist die Grundvoraussetzung für das in Abschnitt [*] beschriebene Management by Delegation.
4.
Relokationstransparenz (Relocation transparency)  ist erforderlich, wenn die Migration einer Komponente die zu diesem Zeitpunkt offenen Kommunikationsbeziehungen zu anderen Komponenten erhalten soll.
5.
Fehlertransparenz  (Failure transparency)  verschattet das Auftreten sowie die Mittel zur Behebung eines Fehlers mit dem Ziel, fehlertolerante Systeme zu realisieren.
6.
Replikationstransparenz (Replication transparency)  impliziert die Möglichkeit, eine Komponente auf identische Art zu vervielfachen sowie die Existenz geeigneter Mechanismen zur Konsistenzsicherung.
7.
Persistenztransparenz (Persistence transparency)  abstrahiert vom Aktivierungszustand einer Komponente indem geeignete Aktivierungs- bzw. Deaktivierungsmechanismen zur Vefügung gestellt werden.
8.
Transaktionstransparenz (Transaction transparency)  verdeckt die Koordinationsmechanismen zur Erreichung der ACID-Eigenschaften[*]  für Komponenten verteilter Anwendungen.

next up previous contents index
Next: Designbezogene Anforderungen Up: Anforderungen an die Middleware Previous: Grundlegende Forderungen
Copyright Munich Network Management Team