Download - FESG - Technische Universität München

4.3 UMSETZUNGSDESIGN: EXTENDED CORBA FILE TRANSFER (ECFT) 107
und vervollständigt werden. Jeder Befehl ist deshalb entweder atomar oder in solche
eindeutigen Teilschritte zerlegbar, welche auf erfolgte Abarbeitung überprüft
werden können oder idempotent sind.
Beispiel 4.2 für „Annahme einer neuen Version“
Die Annahme besteht aus den Teilen „Umbenennen der alten Version in Archivdatei“,
„Umbenennen der neuen Version in die gültige“ und evtl. „Löschen der Archivdatei“. Jeder
Zustand kann dabei separat geprüft werden. Existiert noch die alte Version? Existiert
noch die temporäre Version? usw. Jede Überprüfung kann dabei auch auszulösenden Aktionen
zugeordnet werden (alte Version in Archiv umbenennen oder neue Version als neues
Original umbenennen).
Nach einem Befehl wird ein Checkpoint geschrieben, auf den nachfolgende
Aktionen aufsetzen. Der neue Status einer Transaktion wird übernommen (OK)
und der Befehl aus dem Logbuch entfernt. Abstürze innerhalb dieser Sequenz haben
keine Auswirkungen auf die korrekte Arbeitsweise, da bei Wiederanlauf die
Überprüfung der Einträge konsistente Zustände erzeugt.
Bei einem Wiederanlauf wird das System in den Zustand des letzten, gültigen Wiederanlaufszenario
Checkpoints hochgefahren, worauf alle unvollständigen Aktionen überprüft und
vervollständigt werden. Dies führt zu einem stabilen Zustand. Nach einem Wiederanlauf
sind alle Registrierungen gelöscht. Ein Client muss sich deshalb wieder neu
anmelden und entsprechend seiner Aktion eine Klärungsphase starten, in der er die
abgelegten Transaktionsnummern auf ihre Zustände prüft. Kann ein Wiederanlauf
nicht erfolgen, wird ein Alarm ausgelöst und der Knoten in diesem Zustand eingefroren.
Kein Zugang wird mehr erlaubt, bis ein manueller Eingriff erfolgt ist.
Bei dem geschilderten Vorgehen handelt es sich um einen relativ unkomplizierten
Algorithmus. Er hat sich in der Praxis als praktikabel herausgestellt und
funktionierte in den Testaufbauten tadellos.
4.3.4 Besonderheiten von ECFT
ECFT wurde entwickelt, um Funktionalität für ein zukünftiges Produktionssystem
zu stellen. Deshalb beinhaltet es zusätzliche Erweiterungen, welche die Dienstqualität
und die komfortable Handhabung erleichtern. Der Client ist jedoch von seiner
Struktur vorerst noch auf zwei Interfaces begrenzt worden, wobei eines mit der
Remote-Verbindung und das andere mit dem lokalen Dateisystem belegt ist. Diese
Einschränkung stammt aus der Überlegung, FTP nachzubilden.
Der restliche Ausbau wurde stufenweise dem Prototyp hinzugefügt. Da er eine
wichtige Basis für ein stabiles System darstellt, werden nachfolgend die wesentlichsten
Besonderheiten beschrieben.
Authentizität und Autorisierung
Ein großer Mangel in CFT ist, dass keine exklusive Authentifizierung auf dem Ser- Übernahme der Nutzerrech-
verrechner möglich ist. Das Einbinden von SSL lockert diese Beschränkung zwar
etwas, die Nutzer haben jedoch weiterhin dieselben Rechte, welche von den Zuordnungen
zum Serverprozess abhängig sind. Deshalb sind in ECFT ein geeigne-
te aus dem Betriebssystem
durch Authentifizierung und
Autorisierung