Download - FESG - Technische Universität München

3.3 UMSETZUNGSDESIGN: CORBA FILE TRANSFER (CFT) 57
Der gesamte Zugangspunkt dazu für Verwaltung und erstmalige Referenzierung
von Basisobjekten wird in der endgültigen Anwendung gekapselt und durch verallgemeinerte
Methoden aktiviert. Die Erweiterungen werden schichtenweise darübergelegt,
so dass der Grad der Abstrahierung frei gewählt werden kann. Das
resultierende System ist eine erweiterte Middleware, welche proprietäre Anforderungen
löst.
Um dynamische Verbindungen ohne vorherige Kenntnisse der Örtlichkeiten zu Festlegung:
ermöglichen, ist zumindest ein Verzeichnisdienst erforderlich, bei dem sich die Server
registrieren lassen. Hier wird zur Vereinfachung auf den Naming Service von
CORBA zurückgegriffen. Dieser kann zentral angesiedelt sein und eine Vielzahl
von Klienten bedienen. Um den Austausch der Serverreferenz bei einer Punktzu-Punkt-Verbindung
zwischen Client und Server ebenfalls möglichst einfach zu
gestalten, ist auf den Plattformen der Server zusätzlich ein solcher Dienst zu realisieren.
Dieser trägt im Allgemeinen nur die Referenzen der lokalen Dienstleister.
Betrachtet man sich die Abläufe in der Fundamentalstation Wettzell, ist festzu- Festlegung:
stellen, dass es sich meist um zentralistische Systeme handelt. Diesem Punkt wird
durch vorgenannte Festlegungen ebenfalls entsprochen. Ein zentraler Server dient
als Anlaufpunkt für aktive Messklienten. Kann das Messsystem nur aktiv angesprochen
werden, so muss sich dort ein Server befinden, welcher über einen Client
mit dem zentralen Server Datenaustausch betreibt. Unterschiedliche Multi-Tier-
Modelle (vgl. zur Erklärung ODBC in Abschnitt B.4 auf Seite 213) sind denkbar.
Nutzung des Naming Service von
CORBA
Strikte Trennung des aktiven Klienten
vom passiven Server
Für die Nutzerinteraktion soll ein Konzept des „Look&Feel“ umgesetzt wer- Festlegung:
„Lock&Feel“-Prinzip
den. Dieses besagt, dass genutzte Komponenten in ihren Nutzerzugangsstellen nachgebildet
werden, so dass der Anwender direkt keinen Unterschied zum vorherigen
System erkennen kann, was eine rudimentäre Forderung für Innovationstransparenz
(vgl. dazu Abschnitt 2.4 auf Seite 31) darstellt.
Mit diesen Festlegungen kann nun zur Entwicklung der Schnittstelle zwischen
Client und Server übergegangen werden.
3.3.2 Die Schnittstelle zwischen Client und Server in CFT
Die pragmatische Vorgehensweise beim Entwurf einer verteilten Middleware ist in FTP als Ausgangspunkt der Betrachtungen
erster Annäherung das Design einer Schnittstelle. Die nachfolgende Schnittstelle
zum Datenaustausch entstand aus einer Betrachtung der Funktionalität herkömmlicher
FTP -Clients. FTP kann als eines der meist genutzten Protokolle zum Datenaustausch
angesehen werden. Die Clients implementieren darauf aufbauend unterschiedliche
Befehlsfunktionalität über die entweder elementare Kommandozeileninterpreter
oder graphische Werkzeuge platziert sind. Die gemeinsame Schnittmenge
aller Befehle der einzelnen FTP -Programme kann somit als grundlegender
Befehlsumfang für den Datenzugang angesehen werden (vgl. für nachfolgende Betrachtungen
Abb. 3.7 auf Seite 58).
Eine erste Betrachtung zeigt, dass es Anweisungen gibt, welche eine Verbin- Grobgliederung: Rahmenanwei-
dung initiieren oder beenden bzw. grundlegende Verwaltungsaufgaben übernehmen
(z.B. „open“, „close“, „user“). Sie wirken auf den allgemeinen Kontext einer
Kommunikation ein. Erst wenn diese Anweisungen ausgeführt wurden, wird ei-
sungen und Sitzungsanweisungen