zusammengesetze Entwurfsmuster
Controller Pattern
Ein System besteht aus mehreren Komponenten, die ihrerseits interne Zustände haben.
Controller-Objekt verwaltet den Gesamtzustand.
Beim Gesamtzustand kann das state-Pattern zum Einsatz kommen.
Aspekte
Multithreading:
Wenn eine aktive Komponente (mit Thread) eine Zustandsänderung an den Controller meldet,
dann befindet sich der Controlleraufruf in diesem Komponetenthread.
Soll nun aufgrund dieses Ereignisses der Thread terminiert oder gar auf ihn gewartet werden,
wird das schnell unübersichtlich.
Beispiel: Komponente meldet Kommunikationsfehler, und der Kontroller beschliest:
herunterfahren aller Kommunikation aller Komponenten, einschschliesslich
termination aller kommunikationsthreads.
Man müßte dann genau verwalten, in welchen Thread man ist ...
Lösung: Controller ist selbst ein actives Objekt,
Thread schläft und je Ereignis wird eine Aktion eingereiht, die
dann der Controllerthread ausführt.
Verwaltung von Komponenten
Das ControllerObjekt kann Referenzen auf andere Subkomponenten verwalten
Entkopplung mit Schnittstellen
Jede Komponente kann ein korrenspondierndes Controller-Interface haben.
Damit braucht eine Komponente nur den Controller zu kennen. Damit müßte man
die Komponenten unabhängig verwenden können.
Eine Komponente könnte ein Protokoll z.B. über eine serielle Schnittstelle
verwalten. In einer Umgebung könnte CORBA und in einer anderen SOAP und ein
einer dritten DCE und in einer vierten COM gewünscht sein.
Für jeweils eine Middleware braucht man eine Komponente, die im wesentlichen
gleich funktionieren. Die serielle Protokoll-Komponente und ggf. der
Controller wiederverwendet werden, es müssen nur die
Middlewareanbindungskomponenten erstellt werden.
Zustandseintrittsbeobacher (State_Entry-Observer)
kann ein Teil des Interfaces sein.
Debugging
Debuging in welchem Zustand, der Controller sich befindet und welche
Transistionvollzogen wird.
Für jede Subkomponente sollte das debugging eingeschaltet werden können.
Anwendungen
- Protokollumsetzer
- Jedes Protokoll wird von einer Komponente abgehandelt. Ein Controller
verwaltet die Komponenten und den Gesamtzustand des Problems.
Zusammenhang mit Komponentensystemen
Bisher war ich der Meinung, daß ein Prozeß, der eine CORBA-Komponente impementiert,
möglichst wenig CORBA wrappen sollte und im main() die Hauptschleife orb->run() aufrufen sollte.
Eine Kommponente im obigen Sinne kann ein einem Kommunikationsmanager auch die
ORB-Hauptschleife aufrufen.
Es ist ja auch denkbar, daß zwei Komponenten auch zwei unabhängige ORB-Objekte haben könnten,
bis dahingehend, daß zwei verschiedene CORBA-Implementierungen/Produkte zum Einsatz kommen.
Informatik- und Netzwerkverein Ravensburg e.V
Rudolf Weber