3.2 Definition einer Fallback-Strategie (Ausweichstrategie für Fehlerfall)

Im Gegensatz zu lokalen Anwendungen können durch den Einsatz eines Netzwerkes systembedingte Fehler zur Programmlaufzeit auftreten. Dadurch kann es z.B. nicht möglich sein, alle eigentlich für die Anwendung benötigten Funktionen zu benutzen, da andere Rechner oder das Netzwerk ausgefallen sind. Aus diesem Grund können in verteilten Anwendungen solche Fehler erkannt und teilweise umgangen bzw. behoben werden. Um nun auf solche Fehler zu reagieren, stehen verschiedene Möglichkeiten zur Verfügung:

• Dynamisches Ändern des Namens eines Rechners oder Programms in den Namen eines anderen Rechners/anderen Programms, auf den/das der Zugriff während des Programmlaufs erlaubt ist.

  Danach erneutes Starten der Anwendungsteile.

• Anwendungsteile lokal starten bzw. anbinden. Dies erfolgt durch das Setzen des Attributs .local auf true. Diese Methode ist nur dann sinnvoll, wenn die lokale Anwendung die benötigten Funktionsaufrufe beinhaltet, im Normalfall aber aus Performanz-Gründen nicht nutzt. Wird eine Anwendung lokal gestartet, wird die zugehörige Regel on <application> start ausgeführt. In dieser Start-Regel kann dann die Funktion aufgerufen werden, die die lokal zur Verfügung gestellten Funktionen an den DM übergibt.

  Danach kann wie bisher weitergearbeitet werden.

Beispiel

Im Fall des Beispiels list soll die Variante b, d.h. die lokale Anbindung verwendet werden. Dazu wird die Start-Regel so geändert, dass - falls der Start der remote-Anwendung nicht gelingt - die lokale Anwendung auf lokal umgesetzt wird.

Durch die zusätzliche Funktion InitTestAppl werden die Namen der nun lokal verfügbaren Funktionen an den DM übergeben. Dies erfolgt durch den Funktionsaufruf in der Start-Regel der Anwendung:

on TestAppl start

Mit diesen Änderungen sind alle notwendigen Änderungen im Dialogskript abgeschlossen.

Zusätzliche Änderungen sind noch in den Anwendungssourcen notwendig.