Java Magazin 11/16

Resilient Software Design: Ein Jahr später

Autor:

Vor gut einem Jahr gab es einen Schwerpunkt zu Resilience im Java Magazin. Dazu gehörte unter anderem ein Artikel von Uwe Friedrichsen, der in das Themengebiet eingeführt hat. Uwe hat in der Vergangenheit auch im Business Technology Magazin, auf Informatik Aktuell und im Softwerker Vol. 8 Artikel über Resilient Software Design veröffentlicht. Jetzt, Ende 2016, stellt sich die Frage, was sich seitdem getan hat. Wie hat sich das Thema im Markt entwickelt? Gibt es neue Erkenntnisse? Was fehlt immer noch? Zeit für eine kleine Bestandsaufnahme und ein paar Ergänzungen.

Für alle, die Uwes Einführung in Ausgabe 5.2015 [1] nicht gelesen haben, zum Einstieg eine ganz kurze Erläuterung,
worum es bei Resilient Software Design überhaupt geht: Resilient Software Design lässt sich semi-formal als die Gestaltung und Umsetzung einer softwarebasierten Lösung definieren auf eine Weise, dass der Nutzer bei einer unerwarteten Fehlersituation davon im besten Fall überhaupt nichts bemerkt, und anderenfalls die Lösung in einem definierten, reduzierten Servicelevel weiterarbeitet.

Wichtig ist bei dieser Definition, dass die Lösung mit unerwarteten Fehlersituationen umgehen können muss. In den heutigen verteilten, hochgradig vernetzten Softwarelandschaften ist es nicht mehr möglich, a priori alle möglichen Fehlersituationen vorherzusehen und durch entsprechende Maßnahmen zu vermeiden. Insbesondere kann man sich nicht auf das korrekte Funktionieren von Bausteinen außerhalb des eigenen Prozesskontexts verlassen, sondern muss zu jeder Zeit davon ausgehen, dass sie nicht, nur sporadisch, zu langsam oder falsch reagieren. Tatsächlich kann man sich auch nicht auf das ordnungsgemäße Funktionieren des eigenen Prozesskontexts verlassen. Denn innerhalb eines Prozesses hängt man in der Regel an dem gleichen Lebensfaden wie der aufgerufene Baustein. Stirbt der aufgerufene Baustein oder wird langsamer, geht es einem als Aufrufer genauso. Aufgrund dieser Sondersituation kann man sich im Code deshalb entsprechende Fehlerbehandlungen sparen. Arbeitet man innerhalb eines Prozesses allerdings mit mehreren Threads – was heutzutage häufig der Fall ist –, hat man mit gewissen Einschränkungen die gleichen Probleme wie bei der Nutzung von Bausteinen
über Prozessgrenzen hinweg.

Der zweite wichtige Punkt bei dieser Definition ist das Zurückfallen auf einen definierten Servicelevel, falls man nicht in der Lage ist, einen Fehler so zu kompensieren, dass der Nutzer gar nichts davon merkt. Das Schlüsselwort ist „definiert“. Häufig erlebt man Anwendungen, bei denen im Fehlerfall ein eher zufälliges Verhalten zu beobachten ist, das auf Systemdefaults, gepaart mit der vom Entwickler für die Fehlerbehandlung eher zufällig gewählten Implementierung, basiert. Ein solches Verhalten ist nicht zulässig. Der Nutzer muss stets ein klar definiertes, a priori festgelegtes Verhalten gezeigt bekommen.

Vollständiger Artikel