POSA 1 - Part 4

View Handler Der View Handler ist zuständig für die Anordnung der Views. Über den View Handler können Views geöffnet, geschlossen, oder in deren Grösse verändert werden. Der View Handler stellt auch eine Registry für sämtliche aktiven Views dar. Der View Handler ist auch für die Anordnung der Views zuständig. Der View-Handler ist der Mediator zwischen den Views.

Abstract View Schnittstelle für sämtliche Views. Definiert Methoden für das Anzeigen, aktualisieren sowie schliessen. Erlaubt der View, die Präsentation zu implementieren. 

Specific View Konkrete implementierte View, welche dargestellt werden kann. 

Supplier Der Supplier stellt die Daten für die View zur Verfügung. Zudem benachrichtigt dieser sowohl die View wie auch den View Handler bei Änderungen. Der View Handler muss benachrichtigt werden, falls die Änderung der Daten ggf. eine Anordnung der Fenster erfordert. Die Views werden benachrichtigt, damit diese sich selbst neu zeichnen können.

View Handler mit Command Objects Damit der View-Handler unabhängiger von der View-Schnittstelle zu gestalten kann ein Command Objekt verwendet werden. Die View-Handler Methoden wie das Anzeigen werden durch ein Command gekapselt. Der View-Handler ruft dann nur noch das Command auf.
View Handler mit Command Processor Wie View Handler mit Command Objects, jedoch wird die Ausführung an ein Command-Processor delegiert. Dadurch können zusätzliche Operationen wie Undo bewerkstelligt werden.

Das Forwarder-Receiver Design Pattern stellt eine transparente Interprozesskommunikation für Softwaresysteme mit einem Peer-To-Peer Interaktionsmodell zur Verfügung. Es führt Forwarders und Receivers ein, um die Peers von ihrem Kommunikationsmechanismus zu entkoppeln.

Problem Low-level Mechanismen (TCP/IP, Sockets, Message Queues) für die Interprozesskommunikation sind effizient. Jedoch sind sie vom Betriebssystem und den Netzwerkprotokollen abhängig. Somit wird die Portabilität und die Unterstützung von heterogenen Umgebungen eingeschränkt. Auch das Ändern des IPC (Interprocess Communication) Mechanismus ist zu einem späteren Zeitpunkt schwierig, da die Anwendungslogik an die Kommunikationsmechanismen gekoppelt wurde.

Forces
• Der Kommunikationsmechanismus muss austauschbar sein
• Die Komponenten sollen in einem Peer-to-Peer Modell miteinander Kommunizieren. Der Sender kennt nur die Namen der Empfänger.
• Die Kommunikation zwischen den Peers soll keine grossen Performanceauswirkungen haben.

Lösung Die Peers arbeiten zusammen um ein bestimmtes Problem zu lösen. Sie können als Clients agieren und Anfragen versenden oder als Server einen bestimmten Service anbieten. Sie können auch gleichzeitig beide Rollen einnehmen. Die Details des IPC-Mechanismen sollen für die Peers transparent sein (Verbindungaufbau, Marshalling und Unmarshalling von Messages).

Peer Ein Peer stellt entweder einen Dienst zur Verfügung oder möchte einen solchen von einem anderen System konsumieren. Die anderen Peers können innerhalb von anderen Prozessen oder Systemen sein (müssen jedoch nicht). Der Peer kennt die Namen der anderen Peers und kommuniziert mit diesen über die Forwarder und Receiver.

Forwarder Der Forwarder stellt dem Peer die Schnittstelle für das Versenden einer Nachricht an einen anderen Peer zur Verfügung und abstrahieren den IPC-Mechanismus wie das Marshalling und der Verbindungsaufbau. Der Forwarder kann mittels eines Name-to-Address Mapping die physikalische Adresse des Ziel-Peers bestimmen. Der Forwarder schreibt in jede versendete Nachricht seinen eigenen Peer-Namen, dieser kann für die Antwort notwendig sein.

Receiver Der Receiver stellt die Gegenkomponente zum Forwarder dar und ist für das Empfangen von Nachrichten zuständig. Der Empfänger ist für das Unmarshalling zuständig. Der Receiver stellt eine Schnittstelle für den Peer bereit, damit dieser Nachrichten abrufen kann.

Das Client-Dispatcher-Server Pattern führt eine Schicht (Dispatcher) zwischen Client und Server ein. Die Schicht bietet einen dynamischen Namensdienst an, damit eine örtliche Transparenz des Servers erreicht wird. Dadurch wird das Problem der «nicht dynamisch rekonfigurierbaren» Server-Locations beim Forwarder-Receiver Pattern gelöst.

Problem In einem verteilten Software-System müssen die Endpunkte miteinander kommunizieren (Verbindungsaufbau, Kommunikation) können. Der Ort des Servers sollte für den Client transparent sein. Dies ermöglicht es den Ort des Server jederzeit zu ändern, ohne dass die Clients davon betroffen sind. Dies erhöht die Fehlertoleranz im Falle, dass Server oder Dienste ausfallen.

Forces
• Eine Client soll in der Lage sein, einen Service unabhängig von der Örtlichkeit des Service-Providers verwenden zu können.
• Der funktionale Kern eines Service-Consumer soll unabhängig vom Code für den Verbindungsaufbau sein.

Lösung Füge eine Zusatzkomponente zwischen Client und Server ein (Dispatcher). Der Dispatcher implementiert einen Namensdienst, sodass Clients die Server über Namen ansprechen können. Dies führt zu Ortstransparenz der Server. Zusätzlich ist der Dispatcher für den Aufbau von Kommunikationskanälen zwischen Client und Server zuständig. Im Gegensatz zu üblichen Client-Server Architekturen kann die Rolle von Clients und Servern dynamisch ändern.

Client Der Client möchte einen Dienst des Servers konsumieren. Für die Kommunikation verlangt der Client vom Dispatcher einen Kommunikationskanal zum Server (DNS Request). Dieser liefert dem Client ein Handle (IP-Adresse), mit welchem er mit dem Server kommunizieren kann.

Server Der Server stellt einen Dienst zur Verfügung. Dieser Dienst registriert der Server beim Dispatcher. Der Dispatcher merkt sich bei der Registrierung den Dienst sowie die physikalische Adresse des Servers.

Dispatcher Der Dispatcher stellt eine zentrale Registry für Server dar. Der Server registriert sich beim Dispatcher und der Client verwendet den Dispatcher um die physikalische Adresse eines Server aufzulösen. Der Dispatcher ist zuständig die
Kommunikation zwischen Client und Server herzustellen und liefert das Handle an den Client. Dies ermöglicht es dem Dispatcher auch die Verteilung der Anfragen auf mehrere Server, welche den selben Service anbieten (oder Failover).

Distributed Dispatcher Durch die Verteilung der Dispatcher à la DNS kann eine höhere Fehlertoleranz erreicht werden. Die Dispatcher verwenden in diesem Fall eine hierarchische Struktur.

Client-Dispatcher-Server with communication managed by clients Bei dieser Variante erstellt der Dispatcher nicht die Verbindung und gibt das Handle zurück, sondern gibt dem Client die physikalische Adresse bekannt (z.B. DNS). Der Client ist dann zuständig für die Herstellung der Verbindung. Dadurch kann die Performance verbessert werden.

Client-Dispatcher-Server with heterogeneous communication In einem System müssen nicht sämtliche Server das selbe Protokoll verwenden (Sockets / Pipes). Der Server gibt bei der Registration zusätzlich noch das unterstützte Protokoll an. Dadurch weiss der Dispatcher beim Herstellen der Verbindung, mittels welchem
Protokoll er dies tun muss.

Client-Dispatcher-Service Bei dieser Variante adressieren die Clients Services und nicht Server (RMI). Der Dispatcher stellt dann eine Registry von Diensten dar. Beim Herstellen einer Verbindung sucht der Dispatcher einen Server, welcher den Dienst anbietet und stellt dann die Verbindung her. Dies erlaubt mehrere Server für ein und denselben Dienst.