Parallele Anwendungen entwickeln mit Erlang/OTP
Seite 5: Mehr als nur eine Programmiersprache
Mehr als nur eine Programmiersprache
Eine Programmiersprache mit ihren Eigenschaften ist nur eine Hälfte dessen, was den Einsatzzweck und den Erfolg einer Plattform ausmacht. Heutzutage beurteilt man eine Sprache immer im Zusammenhang mit ihren Bibliotheken und Laufzeitumgebungen. Dies gilt auch für Erlang. Neben einer Vielzahl hilfreicher Module bietet das System unter dem Namen Open Telecom Platform (OTP) und den dazugehörigen OTP Design Principles spezielle Module und Vorgaben für die komfortable Entwicklung skalierbarer und robuster Anwendungssysteme.
Wesentliche Bestandteile der Design Principles sind Supervisor Trees und Behaviours. Supervisor Trees informieren sich gegenseitig, sollte in einer Umgebung mit verknüpften Prozessen einer der Prozesse ausfallen. Erlang unterscheidet zwei Prozesstypen: Die einen arbeiten (Worker), und die anderen passen auf sie auf (Supervisor). Oftmals kommen in einem Supervisor Tree viele Prozesse mit gleichartigen Strukturen zum Einsatz, zum Beispiel als Server oder als Event Handler. Diese Ähnlichkeiten werden über Behaviours formalisiert.
Beim Aufruf einer Funktion aus einem anderen Modul kann auch eine Variable den Namen des aufrufenden Moduls festlegen. Dies machen sich viele Erlang-Module zu Nutze, um Grundfunktionen ähnlich zu abstrakten Oberklassen in der objektorientierten Programmierung in generische Module auszulagern. Ein eigenes Modul, das ein solch generisches Modul nutzen soll, muss nur vorgegebene Funktionen implementieren und seinen eigenen Namen als Argument an die Funktionsaufrufe des generischen Moduls übergeben. Dieses verwendet für seine Arbeit nun die Funktionen des eigenen Moduls. Der Mechanismus hierfür heißt Callback. Über Behaviours kann ein generisches Modul festlegen, welche Funktionen ein Callback-Modul zu implementieren hat. Fehlen diese, gibt der Compiler eine Warnung aus.
Eine Erlang-Applikation wird über das gleichnamige Modul und seine Konfiguration festgelegt. Ein Callback-Modul definiert die Funktionen für den Start und den Stop der Anwendung, oftmals nur für den Start eines Supervisors. Gleichzeitig definiert eine Konfiguration in der Erlang-typischen Notation aus Tupeln und Listen dieses Callback-Modul. Die Konfigurationsdatei enthält die Beschreibung des Moduls, seine Version, darin registrierte Prozesse sowie in ihm enthaltene weitere Anwendungen und Konfigurationen. Der Start der Applikation erfolgt in der mitgelieferten Shell per application:start(app_name). Über das System-Init lässt sich dieser Vorgang automatisieren.
Für die Erstellung ganzer Distributionen mit einer Teilmenge des Systemumfangs kommen Releases zum Einsatz. Nach der Definition des Release Resource File erzeugt systools das Boot Script sowie die Release Packages. Die resultierende TAR-Datei enthält alle notwendigen Dateien für das System mit den parallel laufenden Applikationen.
Die Callbacks des Supervisor-Moduls zum Aufbau des Prozessbaums definieren nur die Funktion init(Args), die die Konfiguration der verwalteten Supervisor und Worker festlegt. Sie definiert, ob die Prozesse einmalig oder permanent laufen, ob sie einzeln oder alle im Fehlerfall neu gestartet werden, wie sie gestoppt werden und in welcher Frequenz ein Prozess terminieren darf, bevor der Supervisor selbst seine Arbeit beendet. Allein dies sorgt bereits fĂĽr stabile Systeme.
Hingegen werden die Worker als Callbacks für das Modul gen_server ausgelegt. Sie müssen Funktionen für die Initialisierung und Terminierung, für die Verarbeitung synchroner und asynchroner Nachrichten sowie für den Umgang mit Updates im laufenden Betrieb implementieren. Ein Mechanismus zur Verwaltung von Zuständen ist enthalten. Insgesamt entbindet dieses Modul den Entwickler von stupider Low-Level-Arbeit bei der Entwicklung eigener Server-Prozesse.
Weitere interessante Module der OTP bieten eine generische Event Engine inklusive vorgefertigter Handler-Module für Logging und Warnmeldungen sowie einen generischen endlichen Automat. Ferner gibt es Mechanismen für die Verteilung von Applikationen auf unterschiedliche Nodes inklusive eines prioritätsgesteuerten automatischen Takeover und Failover von Prozessen. Schließlich erfolgen über Konfigurationsdateien gesteuerte automatische Updates von Applikationen und Releases. Alles zusammen beschert dem Ericsson AXD301 ATM Switch eine nahezu unglaubliche Verfügbarkeit von 99,9999999 Prozent (9NINES).