11. Anlage | ||||||
|
||||||
11.5 Verteilte Systeme (Anlage E)
Diese Anlage definiert durch Kategorisierungspragmas, Attribute und einer Ada-Paketschnittstelle eine sprachkonforme Erweiterung des Ada-Standards für die Unterstützung der Programmierung von homogenen Verteilten Systemen (Verteiltes System). Für das Verständnis des Ada-Verteilungsmodells werden einführende Aussagen zu Verteilten Systemen gemacht:
Für die Interprozeßkommunikation in einer Verteilten Anwendung (Verteilte Anwendung) sieht der Ada-Standard den "Remote Procedure Call (RPC)"-Mechanismus vor (Remote Subprogram Call). Das Partition Communication Subsystem (PCS) enthält die standardisierte Ada-Paketschnittstelle "System.RPC", welche die Mechanismen für die RPC-Kommunikation zwischen den Verteilten Einheiten bereitstellt. Einige wichtige Gründe für den Einsatz einer Verteilten Anwendung sind:
Hierzu gehören die Schritte:
Die Anlage "Verteilte Systeme" legt nur Anforderungen hinsichtlich des Partitionierungsprozesses fest, um die Portabilität von homogenen Verteilten Systemen für unterschiedliche Zielrechnersysteme zu verbessern. Er schließt die Programmierung von heterogen Verteilten Systemen zwar nicht aus, unterstützt sie aber auch nicht explizit. Der Konfigurations- und Zuteilungsprozeß kann von der Ada-Implementation bereitgestellt werden, wie z. B. von dem Lieferanten des Ada-Laufzeitsystems (Übersetzerhersteller) oder von jeder anderen Implementierungsinstanz (sogenannte Drittanbieter). Es werden keine Anforderungen hinsichtlich der Zuteilungsproblematik in fehlertoleranten Systemen gestellt (z. B. Behandlung von Rechnerausfällen etc.). Diese bewußt gewählten Festlegungen und Einschränkungen stellen sicher, daß die Implementierer für ein spezielles Zielrechnersystem immer die anwendungsspezifisch optimalen Kommunikationsmechanismen einsetzen können. Wichtige Eigenschaften des Ada-Verteilungsmodells
Partitionsmodell Unter der Annahme, daß das Verteilte System aus einer Kollektion von Rechnerknoten und gemeinsamen Adreßbereichmodulen besteht, kann man zwischen aktiven Prozessoreinheiten mit lokalem Speicher und passiven Einheiten mit globalem Speicher unterscheiden, die ihrerseits über keine Prozessorkapazitäten verfügen. Hinsichtlich dieses Modells definiert das Ada-Modell verschiedene Partitionsarten: Aktive Partitionen und Passive Partitionen. Beachte: Das Ada-Partitionsmodell für Verteilte Systeme spezifiziert eine Partition als elementare Verteilungseinheit. Partitionen werden nicht durch Basis-Sprachelemente von Ada repräsentiert, d. h. daß Partitionen nicht durch Typdeklarationen oder Objektinstantiierung erzeugt werden können. Statt dessen besteht eine Partition aus einer Ansammlung von Bibliothekseinheiten (separat übersetzte Bibliothekspakete oder Unterprogramme), die gemeinschaftlich auf einem Verteilten Zielsystem ausgeführt werden können. Hierbei bilden die Paketspezifikationen die typischen Schnittstellen zwischen den Partitionen. Die Kategorisierung einer Bibliothekseinheit zu einer Partitionsart erfolgt durch entsprechende Kategorisierungspragmas. Eine Verteilte Anwendung besteht in diesem Zusammenhang aus einer oder mehreren aktiven Partitionen sowie keiner oder mehreren passiven Partitionen. Aktive Partitionen Aktive Partitionen modellieren autonome Prozessormodule. Man unterscheidet zwischen sogenannten "Remote Call Interface (RCI)"-Bibliothekseinheiten und "Remote Types"- Bibliothekseinheiten. In den erstgenannten Bibliothekseinheiten können "Remote Procedure Call (RPC)"- Prozeduren wie lokale Prozeduren deklariert und durch Anwendung einer Kontextklausel von anderen aktiven Partitionen aufgerufen werden. Mit der letztgenannten Bibliothekskategorie können Typdeklarationen vereinbart werden, die für die Kommunikation zwischen aktiven Partitionen einsetzbar sind (z. B. als formale Parameter für RPC-Prozeduren). Jede aktive Partition kann ein eigenes Hauptprogramm besitzen, oder aber aus einer Ansammlung von Bibliothekseinheiten bestehen. Ähnlich einem Ada-83-Hauptprogramm enthält jede aktive Partition einen Umgebungsprozeß, der die Elaborierung, Aktivierung und Deaktivierung der Bibliothekseinheiten der Partition steuert. Aktive Partitionen sind unabhängig voneinander und haben damit keinen Zugriff auf Variable in anderen aktiven Partitionen. Das Laufzeitsystem einer aktiven Partition ist unabhängig von allen anderen Laufzeitsystemen eines aus mehreren Partitionen bestehenden Programms. Dies bedeutet unter anderem, daß keine Eingangsaufrufe von Prozessen oder geschützten Verbundtypen im sichtbaren Teil eines Schnittstellenpakets verwendet werden dürfen und daß die Pakete "Calendar" und "Ada.Real_Time" sowie der Untertyp "Priority" in einer aktiven Partition nur lokale Gültigkeit haben. Es existiert kein Rendezvouskonzept zwischen Prozessen aus verschiedenen aktiven Partitionen. Jede aktive Partition verwaltet ihr eigenes Prozeßsystem und vermeidet dadurch die generell in Verteilten Systemen bekannten Probleme hinsichtlich einer verteilten Zeitverwaltung und der Aktivierung und Terminierung von Prozessen. Passive Partitionen Passive Partitionen stellen Daten und eventuell Code zur Verfügung, die zwischen den aktiven Partitionen geteilt werden können. Aktive Partitionen können auf Daten in passiven Partitionen zugreifen und diese gemeinschaftlich nutzen ("shared data"). Man unterscheidet zwischen sogenannten "Pure"-Bibliothekseinheiten und "Shared Passive"-Bibliothekseinheiten. "Pure"-Bibliothekseinheiten besitzen Datenstrukturen, die über keinen laufzeitabhängigen Status verfügen. Konstantendeklarationen sind typische Beispiele für Datenstrukturen, die keinen laufzeitabhängigen Status besitzen. "Shared Passive"-Bibliothekseinheiten können über Status verfügen, weil diese Bibliotheks-einheiten Objekte enthalten können, die zur Laufzeit veränderbar sind und damit einen Status besitzen, z. B. Variablendeklarationen. Passive Partitionen besitzen kein eigenes Laufzeitsystem (z. B. keine Unterstützung von Prozeßsteuerung und Echtzeituhr). Kategorisierung von Bibliothekseinheiten über Pragmas In Abhängigkeit von der Rolle, die Bibliothekseinheiten in einem Verteilten System spielen, unterscheidet Ada zwischen verschiedenen Kategorien und belegt diese Bibliothekskategorien mit bestimmten Einschränkungen. Diese Einschränkungen sollen die Typkonsistenz und die Erkennung von illegalen Partitionierungen (z. B. direkter Variablenzugriff zwischen Partitionen) in einem Verteilten System sicherstellen. Folgende Kategorien von Bibliothekseinheiten sind durch Angabe eines entsprechenden Kategorisierungspragmas spezifizierbar:
Konsistenz eines Verteilten Systems Konsistenz in einem Verteilten System basiert auf dem Konzept der Version einer Übersetzungseinheit. Diesbezüglich bezeichnet man eine Bibliothekseinheit als konsistent, wenn die gleiche Version ihrer Deklaration in allen Partitionen des Verteilten Systems verwendet wird. Folgende Attribute sieht die Anlage für eine Programmeinheit P vor:
Beim Elaborieren kann die Ausnahme "Program_Error" ausgelöst werden, falls inkonsistente Versionen von Bibliothekseinheiten in den Partitionen erkannt werden. Remote Subprogram Call Ein Aufruf eines fernen Unterprogramms (in Ada semantisch dem "Remote Procedure Call RPC" äquivalent) ist eine Prozedur/Funktion, die in einer "Remote Call Interface"-Paketspezifikation deklariert ist und deren Aufruf in der Regel die Ausführung der Prozedur/Funktion in einer anderen Partition bewirkt. Ein RPC kann auf drei verschiedenen Wege ausgeführt werden:
Die RPC-Implementierung soll über das vordefinierte Paket "System.RPC" erfolgen. Wenn ein Paket durch Anwendung der Kontextklausel der gleichen Partition zugeordnet ist als das "Remote Call Interface"-Paket, dann kann die Implementierung aus Optimierungsgründen die RPC-Aufrufe als lokale Prozeduraufrufe behandeln (unter Umgehung des Partition Communication Subsystem (PCS)). Durch Anwendung des Pragmas "All_Calls_Remote" wird erzwungen, daß alle Aufrufe über das Partition Communication Subsystem (PCS) zu erfolgen haben. Dies ermöglicht z. B. das Testen eines Verteilten Systems auf einer Einprozessoranlage. Syntax des Pragmas: pragma All_Calls_Remote [(library_unit_name)]; Beispiel:
Partition Communication Subsystem Das Partition Communication Subsystem (PCS) ermöglicht den aktiven Partitionen die Kommunikation über den RPC-Mechanismus. Das Kernstück dieser Schnittstelle ist das Paket "System.RPC". Das Paket "System.RPC" spezifiziert eine Standardschnittstelle, mit der die RPC-Prozeduren auf den Client und Server Partitionen implementiert werden sollen. Diese Schnittstelle legt sowohl die Operationen als auch die semantischen Bedingungen fest, mit denen die RPC-Prozeduren generiert werden. Der Rumpf des Pakets wird in der Regel nicht vom Anwender, sondern vom Implementierer realisiert. Der Implementierer kann in diesem Fall entweder der Lieferant des Ada-Laufzeitsystems (Übersetzerhersteller) sein oder aber auch jede andere Implementierungsinstanz (sogenannte Drittanbieter). Eine Implementierung dieses Ada-Pakets darf anwendungsspezifische Erweiterungen enthalten (z. B. für Message-Passing- oder Broadcast-Funktionen), sie muß aber über einen Modus verfügen, in der nur der vorgeschriebene Umfang des Pakets "System.RPC" benutzt wird. Der Programmierer einer Verteilten Ada-Anwendung verwendet in der Regel das Paket "System.RPC" nicht, sondern nur der Übersetzer und Implementierer des PCS-Kommunikationssystems. Für den Programmierer ist das Kommunikationssystem PCS transparent, weil er die Kommunikation zwischen den Partitionen über ferne Prozedur-/Funktionsaufrufe (RPCs) in "Remote Call Interface"-Paketen sprachkonform spezifiziert und abwickelt. Ablauf eines RPCs in einer Verteilten Ada-Anwendung Die folgende Abbildung demonstriert den Ablauf einer RPC-Kommunikation für eine Client-/Server-Anwendung in einem Verteilten Ada-System unter Einbeziehung des Partition Communication Subsystems PCS. Die Grundidee des "Remote Procedure Call"-Konzepts ist einfach. Der Programmierer teilt sein Anwendungsprogramm in zwei oder mehrere Teile: in das Hauptprogramm (Client-Anwendung auf Partition A) und in ein oder mehrere Pakete aus Unterprogrammen (Server-Anwendung auf Partition B). Der Client ruft diese Unterprogramme mittels RPCs auf. Für die Client-Anwendung sieht der Fernaufruf genauso aus wie bei lokalen (Unterprogramm-) Aufrufen. Wenn der Client eine Routine im Server rufen möchte, dann ruft er in Wirklichkeit eine gleichnamige Routine im sogenannten Client-Stub. Dieser Stub schickt über das RPC-Laufzeitsystem ein Datenpaket, bestehend aus einer Kennung für die Routine und den Eingabe-Parametern zum Server. Der Server-Stub empfängt über das lokale RPC-Laufzeitsystem dieses Datenpaket und ruft die gewünschte Routine im Server auf. Gegebenenfalls werden Ausgabeparameter auf gleiche Weise zurückübertragen. Das RPC-Laufzeitsystem übernimmt dabei die Kodierung und Übertragung der Aufrufe und Parameter. Zusammenfassende Darstellung Die Erstellung einer Verteilten Anwendung in Ada läßt sich anhand der zu durchlaufenden SW-Entwicklungsphasen grob folgendermaßen zusammenfassen: In der Übersetzungsphase der Anwendung werden die Bibliothekseinheiten, die für die Partitionierung relevant sind, vom Anwender anhand von Kategorisierungspragmas identifiziert. Für eine eventuelle RPC-Kommunikation zwischen den aktiven Partitionen generiert die Ada-Implementierung die Client- und Server-Stubs. In der Binderphase erfolgt eine Zuordnung der RCI-Pakete und der "Shared-Passive"-Pakete zu den Partitionen durch den Anwender. Die sonstigen Ada-Bibliothekseinheiten werden entsprechend dem vorliegenden Kontext den einzelnen Partitionen zugeordnet. In der Elaborationsphase werden RCI-Pakete und "Shared-Passive"-Pakete in genau einer Partition elaboriert, während die anderen Bibliothekseinheiten überall dort elaboriert werden, von wo aus sie referenziert werden. Ein Umgebungsprozeß ruft nach der Elaboration das Ada-Hauptprogramm (falls vorhanden), und wartet dann auf die Terminierung aller Prozesse, die von den Bibliothekseinheiten der Partition abhängen. |
||||||
|