POSA 1 - Part 2
Patterns of Software Architecture
Patterns of Software Architecture
MVC-Pattern
Das Model-View-Controller (kurz MVC) teilt die Applikation in die folgenden drei Komponenten:
Model beinhaltet die Hauptfunktionalität und Daten
View Zeigt dem Benutzer Informationen an
Controller Verarbeitet die Benutzereingaben
Problem
User Interfaces sind sehr anfällig auf Änderungen in der Applikation. Wenn beispielsweise die Funktionalität einer Applikation erweitert wird, dann muss diese neue Funktion im User Interface ersichtlich sein. Auch das Portieren der Applikation auf ein anderes System oder ein neuer Release des Fenstersystems führt zu Änderungen im User Interface.
Unterschiedliche Benutzer besitzen unterschiedliche Anforderungen an das User Interface. Unterschiedliche User Interface Paradigmen müssen daher integriert werden können. Ist das User Interface stark an den Programmkern gebunden, sind Änderungen schwer durchzuführen.
Forces
• Die selben Informationen werden in unterschiedlichen Fenstern unterschiedlich präsentiert.
• Die Applikation muss Änderungen an den Daten sofort anzeigen.
• Änderungen am User Interface durchzuführen sollte einfach und auch zur Laufzeit möglich sein.
• Das Unterstützen von unterschiedlichen «look and feel» Standards oder das Portieren des User Interfaces sollte den Kerncode der Applikation nicht beeinflussen.
Lösung
Model-View-Controller teilt die Applikation in die drei Komponenten Model, View und Controller (oder in die Bereiche: Verarbeitung, Output und Input). Dies erlaubt es, mehrere Views für das selbe Models zu erstellen. Das Model benachrichtigt alle Views, wenn sich die Daten verändert haben.
MVC Struktur
Model Kapselt die Kerndaten, Kernfunktionalität und stellt Prozeduren zur Verfügung. Diese können vom Controller durch den Benutzer aufgerufen werden. Daneben stellt das Model Funktionen für den Zugriff auf die Daten zur Verfügung, welche von den View Komponenten benutzt werden. Das Model ist unabhängig von der spezifischen Repräsentation und dem Benutzer-Eingabeverhalten. Werden Änderungen am Zustand des Models durchgeführt, so benachrichtigt das Model die Views mittels einem «change-propagation» Mechanismus.
View Präsentiert dem Benutzer die Informationen aus einem Modell. Jede View definiert eine Aktualisierungsprozedur, welche durch den «change-progragation» Mechanismus aufgerufen wird. Wird diese Prozedur aufgerufen, so holt sich die View die aktuellen Daten aus dem Modell und aktualisiert die Ansicht. Jede View hat eine Controller Komponente. Views stellen dem Controller häufig Funktionen zur Verfügung, damit er Operationen, die das Model nicht beeinträchtigen, durchführen kann.
Controller Verarbeitet die Eingaben und delegiert die Logik an das Model oder die View. Der Benutzer interagiert nur über den Controller mit dem System. Wenn das Verhalten des Controllers von dem aktuellen Status des Models abhängig ist, registriert sich der Controller auch mittels «change-propagation» Mechanismus beim Modell. Somit kann der Controller auf Änderungen eingehen. Der Controller wird von der View instanziiert. In dieser Variante hat jede View ihren eigenen Controller.
PAC-Pattern
Das Presentation-Abstraction-Control (kurz PAC) Pattern definiert eine Struktur für Interaktive Softwaresysteme in Form einer Hierarchie von kooperierenden Agenten. Jeder Agent ist für einen spezifischen Aspekt der Applikationsfunktionalität zuständig und besitzt folgende Komponenten: Presentation, Abstraction und Control.
Beispiel: Ein Programm für politische Abstimmungen, welches eine Tabelle als Dateneineingabe und unterschiedliche Darstellungsformen für die Daten wie Charts und Tabellen besitzt.
Problem
Interaktive Systeme können oft als Gruppe kooperierender Agenten angesehen werden. Agenten, die für die Interaktion mit dem Menschen spezialisiert sind, werden für die Eingabe und das Darstellen der Daten verwendet. Andere Agenten unterhalten das Datenmodell des Systems und offerieren Funktionalitäten, um die Daten zu verändern.
Daneben kann es Agenten geben, die für andere Aufgaben wie z.B. die Fehlerbehandlung zuständig sind. Jeder Agent ist für eine spezielle Aufgabe spezialisiert. Sämtliche Agenten zusammen stellen die Systemfunktionalität zur Verfügung. Dies erlaubt eine vertikale sowie auch horizontale Aufteilung des Systems.
Forces
• Agents besitzen einen eigenen Status, es braucht Mechanismen um Daten, Nachrichten
und Events zwischen den Agents auszutauschen.
• Agents stellen ein eigenes User Interface zur Verfügung.
• Änderungen an Agenten oder Erweiterungen des Systems sollte das System als
Ganzes nicht beeinflussen
Lösung
Die interaktive Applikationen als Baum ähnliche Hierarchie aus PAC Agenten strukturieren. Die Hierarchie wird aufgeteilt in Top, Intermediate sowie Bottom-Level-Agenten. Jeder Agent ist für einen Teil der Applikationsfunktionalität zuständig und beinhaltet die Komponenten: Presentation, Abstraction und Control. Die Präsentationskomponente ist für das sichtbare Verhalten des Agenten zuständig. Die Abstraktionskomponente verwaltet das Datenmodell und stellt Funktionalität für das Manipulieren der Daten zur Verfügung. Die Controlkomponente verbindet die Präsentation
und die Abstraktionskomponente und erlaubt die Kommunikation mit anderen Agenten.
PAC-Struktur
Top Level Agent Dieser stellt die Kernfunktionalität des Systems zur Verfügung. Die meisten anderen Agenten sind von diesem abhängig. Dieser Agent besitzt den Teil des User Interfaces, der den einzelnen Subtasks nicht zugeteilt werden kann (z.B. Menüleisten, Dialogboxen mit Applikationsinformationen, etc.). Die Kontrollkomponente des Top Level Agenten hat die folgenden Zuständigkeiten:
• Erlaubt tiefer liegenden Agenten das Zugreifen und Manipulieren des globalen Datenmodells.
• Koordiniert die Hierarchie der PAC Agenten. Verwaltet die Informationen über die Verbindungen zwischen den Agenten.
• Unterhält Informationen über die Interaktion mit dem Benutzer (z.B. das Prüfen, ob eine Operation durchgeführt werden darf, Undo, Redo, etc.).
• Fehlerbehandlung
Bottom Level Agents Repräsentierten abgeschlossene, semantische Konzepte, mit welchen der Benutzer interagieren kann (z.B. Tabellen und Charts). Die Präsentation stellt eine spezifische View und Zugriff auf alle Funktionen, die der User triggern kann, zur Verfügung. Die Abstraktionskomponente ist für den Unterhalt der spezifischen Daten des entsprechenden Konzeptes zuständig. Für das Koppeln der Präsentations- und Abstraktionskomponente ist die Kontrollkomponente zuständig. Somit gibt es keine direkten Abhängigkeiten. Daneben ist sie für die Kommunikation
mit anderen Agenten zuständig.
Intermediate Level Agents Repräsentieren Kombinationen oder Abhängigkeiten zwischen Bottom Level Agents (z.B. das Manipulieren von Daten, welche von mehreren Views benutzt werden). Diese Agenten sind für die Komposition oder Koordination zuständig. Sie können zusammenhängende Agenten gruppieren, um einen neuen Abstraktionslevel zu generieren. Daneben können sie auch für die Koordination von gemeinsamen Daten zuständig sein (Mediator?).
MVC und PAC
Unterschied zu MVC
Das Model-View-Controller-Muster (ebenfalls ein Architekturmuster für interaktive Softwaresysteme) reicht für diese Anwendungen nicht aus und so geht PAC über dieses hinaus. Es teilt ein System in zwei Richtungen auf, einmal in die drei Einheiten grafische Benutzungsschnittstelle (Presentation), Vermittlung und Kommunikation (Control) und das Datenmodell (engl. Abstraction) – dies ist ähnlich dem MVC – und darüber hinaus noch hierarchisch in verschiedene Teile, die, wie eingangs gefordert, jeweils einen Teil der Aufgaben des Systems anbieten. Diese Teile nennt man im PAC-Muster „Agenten“ und sie stellen die erste Stufe der Strukturierung während des Architekturentwurfes dar. Das heißt, man beginnt den Entwurf mit der Aufteilung der gesamten Anforderungen auf einzelne Agenten und baut die hierarchische Struktur darauf auf. Für jeden Agenten wird dann im zweiten Schritt des Entwurfes eine Aufteilung in die besagten Komponenten, Darstellung, Abstraktion und Steuerung, vorgenommen.
Microkernel-Pattern
Das Microkernel Pattern ist für Systeme, die sich an verändernde Systemanforderungen anpassen müssen, nützlich. Dabei wird ein minimaler funktionaler Kern von der erweiterten Funktionalität und kundenspezifischen Elementen separiert. Der Microkernel dient zudem als Schnittstelle für Erweiterungen und zur Koordination der Kollaboration ebendieser Erweiterungen.
Kontext
Die Entwicklung von Anwendungen, die gleiche (oder zumindest ähnliche) Programmierschnittstellen nutzen, welche auf der gleichen Kern-Funktionalität aufbauen.
Problem
Bekannte Beispiele für die Problem-Domain sind Applikationsplattformen (OS, DBMS, usw.). Solche Systeme haben eine lange Lebensdauer (10+ Jahre) und müssen neue Technologien (Hardware/Software) integrieren können.
Forces
• Die Applikationsplattform muss immer die neuste Hardware- und Software-Generation unterstützen.
• Die Applikationsplattform muss portabel, erweiterbar und einfach in neue Systeme integrierbar sein.
• Der Kern der Applikationsplattform soll eine separate Komponente mit minimaler Speicherbelegung sein und seine Services sollen so wenig Rechenleistung wie möglich in Anspruch nehmen.
Lösung
Das Microkernel Pattern schafft Abhilfe für die oben erwähnten Probleme. Dabei werden die fundamentalen Services einer Applikationsplattform in eine Microkernel Komponente gepackt. Der Microkernel bietet anderen Komponenten die in separaten Prozessen laufen, die Möglichkeit miteinander zu kommunizieren. Er verwaltet ausserdem systemweite Ressourcen, und er bietet Interfaces an, die anderen Komponenten Zugriff auf seine Funktionen bieten.
Microkernel-Structure
Client Ein Client ist eine Applikation, die sich mit einem External Server assoziiert.
Adapter Der Adapter entkoppelt den Client vom Externen Server. Versteckt z.B. die Kommunikationsmechanismus des Microkernels vom Client. Der Adapter wird im Client-Prozess ausgeführt und bietet eine definierte Schnittstelle an. Der Adapter kann auch mehrere externe Server unterstützen und dadurch die Emulation einer Anwendung auf verschiedenen Systemen vornehmen. Ein Beispiel hierfür ist die C-Api, welche z.B. für das File-Handling identisch ist für sämtliche Systeme. Die konkreten Implementierung rufen dann intern die Interrupt-Services auf.
External Server Jeder externe Server läuft in seinem eigenen Prozess. Der externe Server stellt eine Schnittstelle bzw. eine spezielle Sicht für den Client bereit. Er nimmt die Client-Anforderungen an, führt den Dienst aus und antwortet dem Client. Der externe Server verwendet hierfür die Infrastruktur des Microkernels. Der externe Service stellt die Programmierschnittstelle für die Clients zur Verfügung. Ein Beispiel hierfür ist die Interrupt-Service-Routine, welche von den Clients für die Ausführung von Betriebssytem-Funktionalitäten genutzt werden kann.
Microkernel Der Microkernel stellt die Basisfunktionalitäten des System bereit. Hierbei geht es um die Adressierung von Ressourcen (z.B. Files) sowie die Kommunikation zwischen den einzelnen Komponenten. Der Microkernel stellt die Infrastruktur zur Verfügung, damit die Internen sowie Externen Server miteinander kommunizieren können.
Internal Server Stellen erweiterte Funktionen bereit, welche nicht im Microkernel implementiert werden. Diese Dienste werden vom Microkernel erst bei Bedarf geladen. Ein Beispiel hierfür sind Gerätetreiber.
Broker-Pattern
Try to imagine that 10 people have messages they need to deliver. Another 10 people are expecting messages from the previous group. In an open environment, each person in the first group would have to deliver their message to the recipient manually, so each person has to visit at least one member of the second group. This is inefficient and chaotic.
In broker, there is a control class (in this case the postman) who receives all the messages from group one. The broker then organizes the messages based off destination and does any operations needed, before visiting each recipient once to deliver all messages for them. This is far more efficient.
Problem
Es ist erforderlich, dass zwischen den verteilten Komponenten eine Art Interprozess-Kommunikation besteht. Falls die Komponenten diese Kommunikation selbst regeln, resultiert das in unnötigen Abhängigkeiten. Es werden Services für das Hinzufügen, Entfernen, Austauschen, Aktivieren und das Auffinden von Komponenten benötigt. Die Programmierschnittstelle sollte sich von der Programmieren von nicht verteilten Anwendungssystemen möglichst nicht unterscheiden.
Forces
• Es soll Komponenten möglich sein, auf die Services anderer Komponenten mittels remote service invocations zuzugreifen.
• Es soll möglich sein, Komponenten zur Laufzeit hinzuzufügen, zu entfernen oder auszutauschen.
• Die Architektur soll system- und implementationsspezifische Details vor den Nutzern von Komponenten und Services verbergen.
Lösung
Es wird eine Broker Komponente eingeführt. Diese ist für die Auffindung von Diensten zuständig. Server registrieren ihre Serviceinterfaces beim Broker, wodurch diese für Clients verfügbar sind. Die Clients können den Broker für die Auflösung eines spezifischen Serviceinterfaces anfragen. Die Broker Komponente regelt dabei die Lokalisierung der Server, die Weiterleitung von Requests und die Übertragung von Resultaten oder auch Exceptions zu den Clients. Durch den Broker wird der Client und der Server räumlich entkoppelt. Kann der Broker Anfragen zwischenspeichern, dann erfolgt auch eine
zeitliche Entkoppelung.
Broker-Structure
Server Der Server stellt eine Dienstleistung über ein Schnittstelleninterface zur Verfügung. Der Server implementiert das Schnittstelleninterface und registriert sich selbst beim Broker.
Broker Der Broker stellt eine zentrale Registry für das Auffinden von Server-Diensten dar. Die Server können sich beim Broker (de-) registrieren. Clients können mittels der Registry die gewünschten Schnittstellen abfragen. Der Broker stellt zusätzlich einen Kommunikationsmittelpunkt zwischen Client und Server dar. Der Broker definiert ein Protokoll sowie Nachrichtenformat, welches von sämtlichen Clients und Server eingehalten werden muss. Dadurch ist sichergestellt, dass die Implementierung auch mit heterogenen Systemen funktioniert.
Client Ein Client ist eine Anwendung, welche eine Serverschnittstelle nutzen möchte. Der zugehörige Dienst kann der Client über den Broker abrufen. Der Client kennt die Lokalität des Servers nicht, da die Kommunikation über den Broker erfolgt.
Client-Side-Proxy Der Client-Proxy wrappt die Server Schnittstellen-API und gestaltet die Client-Aufrufe für den Client transparent. Der Proxy leitet die lokalen Anfragen an den Broker weiter und nimmt das notwendige (Un-) Marhsalling vor.
Server-Side-Proxy Der Server-Proxy stellt den Eingangspunkt in die Server-Logik dar. Sie entkoppelt die Server-Implementierung von der Interprozess-Kommunikation. Der Proxy ist somit zuständig für das (Un-) Marshallling und Dispatchen der Anfragen auf die korrekte Server-Komponente.
Bridge Die Bridge ist optional. Diese wird für die Kommunikation zwischen den einzelnen Broker benötigt, falls diese dezentral betrieben werden.
-
- 1 / 9
-
Lernkarten
MVC-Pattern
Das Model-View-Controller (kurz MVC) teilt die Applikation in die folgenden drei Komponenten:
Model beinhaltet die Hauptfunktionalität und Daten
View Zeigt dem Benutzer Informationen an
Controller Verarbeitet die Benutzereingaben
Problem
User Interfaces sind sehr anfällig auf Änderungen in der Applikation. Wenn beispielsweise die Funktionalität einer Applikation erweitert wird, dann muss diese neue Funktion im User Interface ersichtlich sein. Auch das Portieren der Applikation auf ein anderes System oder ein neuer Release des Fenstersystems führt zu Änderungen im User Interface.
Unterschiedliche Benutzer besitzen unterschiedliche Anforderungen an das User Interface. Unterschiedliche User Interface Paradigmen müssen daher integriert werden können. Ist das User Interface stark an den Programmkern gebunden, sind Änderungen schwer durchzuführen.
Forces
• Die selben Informationen werden in unterschiedlichen Fenstern unterschiedlich präsentiert.
• Die Applikation muss Änderungen an den Daten sofort anzeigen.
• Änderungen am User Interface durchzuführen sollte einfach und auch zur Laufzeit möglich sein.
• Das Unterstützen von unterschiedlichen «look and feel» Standards oder das Portieren des User Interfaces sollte den Kerncode der Applikation nicht beeinflussen.
Lösung
Model-View-Controller teilt die Applikation in die drei Komponenten Model, View und Controller (oder in die Bereiche: Verarbeitung, Output und Input). Dies erlaubt es, mehrere Views für das selbe Models zu erstellen. Das Model benachrichtigt alle Views, wenn sich die Daten verändert haben.
MVC Struktur
Model Kapselt die Kerndaten, Kernfunktionalität und stellt Prozeduren zur Verfügung. Diese können vom Controller durch den Benutzer aufgerufen werden. Daneben stellt das Model Funktionen für den Zugriff auf die Daten zur Verfügung, welche von den View Komponenten benutzt werden. Das Model ist unabhängig von der spezifischen Repräsentation und dem Benutzer-Eingabeverhalten. Werden Änderungen am Zustand des Models durchgeführt, so benachrichtigt das Model die Views mittels einem «change-propagation» Mechanismus.
View Präsentiert dem Benutzer die Informationen aus einem Modell. Jede View definiert eine Aktualisierungsprozedur, welche durch den «change-progragation» Mechanismus aufgerufen wird. Wird diese Prozedur aufgerufen, so holt sich die View die aktuellen Daten aus dem Modell und aktualisiert die Ansicht. Jede View hat eine Controller Komponente. Views stellen dem Controller häufig Funktionen zur Verfügung, damit er Operationen, die das Model nicht beeinträchtigen, durchführen kann.
Controller Verarbeitet die Eingaben und delegiert die Logik an das Model oder die View. Der Benutzer interagiert nur über den Controller mit dem System. Wenn das Verhalten des Controllers von dem aktuellen Status des Models abhängig ist, registriert sich der Controller auch mittels «change-propagation» Mechanismus beim Modell. Somit kann der Controller auf Änderungen eingehen. Der Controller wird von der View instanziiert. In dieser Variante hat jede View ihren eigenen Controller.
PAC-Pattern
Das Presentation-Abstraction-Control (kurz PAC) Pattern definiert eine Struktur für Interaktive Softwaresysteme in Form einer Hierarchie von kooperierenden Agenten. Jeder Agent ist für einen spezifischen Aspekt der Applikationsfunktionalität zuständig und besitzt folgende Komponenten: Presentation, Abstraction und Control.
Beispiel: Ein Programm für politische Abstimmungen, welches eine Tabelle als Dateneineingabe und unterschiedliche Darstellungsformen für die Daten wie Charts und Tabellen besitzt.
Problem
Interaktive Systeme können oft als Gruppe kooperierender Agenten angesehen werden. Agenten, die für die Interaktion mit dem Menschen spezialisiert sind, werden für die Eingabe und das Darstellen der Daten verwendet. Andere Agenten unterhalten das Datenmodell des Systems und offerieren Funktionalitäten, um die Daten zu verändern.
Daneben kann es Agenten geben, die für andere Aufgaben wie z.B. die Fehlerbehandlung zuständig sind. Jeder Agent ist für eine spezielle Aufgabe spezialisiert. Sämtliche Agenten zusammen stellen die Systemfunktionalität zur Verfügung. Dies erlaubt eine vertikale sowie auch horizontale Aufteilung des Systems.
Forces
• Agents besitzen einen eigenen Status, es braucht Mechanismen um Daten, Nachrichten
und Events zwischen den Agents auszutauschen.
• Agents stellen ein eigenes User Interface zur Verfügung.
• Änderungen an Agenten oder Erweiterungen des Systems sollte das System als
Ganzes nicht beeinflussen
Lösung
Die interaktive Applikationen als Baum ähnliche Hierarchie aus PAC Agenten strukturieren. Die Hierarchie wird aufgeteilt in Top, Intermediate sowie Bottom-Level-Agenten. Jeder Agent ist für einen Teil der Applikationsfunktionalität zuständig und beinhaltet die Komponenten: Presentation, Abstraction und Control. Die Präsentationskomponente ist für das sichtbare Verhalten des Agenten zuständig. Die Abstraktionskomponente verwaltet das Datenmodell und stellt Funktionalität für das Manipulieren der Daten zur Verfügung. Die Controlkomponente verbindet die Präsentation
und die Abstraktionskomponente und erlaubt die Kommunikation mit anderen Agenten.
PAC-Struktur
Top Level Agent Dieser stellt die Kernfunktionalität des Systems zur Verfügung. Die meisten anderen Agenten sind von diesem abhängig. Dieser Agent besitzt den Teil des User Interfaces, der den einzelnen Subtasks nicht zugeteilt werden kann (z.B. Menüleisten, Dialogboxen mit Applikationsinformationen, etc.). Die Kontrollkomponente des Top Level Agenten hat die folgenden Zuständigkeiten:
• Erlaubt tiefer liegenden Agenten das Zugreifen und Manipulieren des globalen Datenmodells.
• Koordiniert die Hierarchie der PAC Agenten. Verwaltet die Informationen über die Verbindungen zwischen den Agenten.
• Unterhält Informationen über die Interaktion mit dem Benutzer (z.B. das Prüfen, ob eine Operation durchgeführt werden darf, Undo, Redo, etc.).
• Fehlerbehandlung
Bottom Level Agents Repräsentierten abgeschlossene, semantische Konzepte, mit welchen der Benutzer interagieren kann (z.B. Tabellen und Charts). Die Präsentation stellt eine spezifische View und Zugriff auf alle Funktionen, die der User triggern kann, zur Verfügung. Die Abstraktionskomponente ist für den Unterhalt der spezifischen Daten des entsprechenden Konzeptes zuständig. Für das Koppeln der Präsentations- und Abstraktionskomponente ist die Kontrollkomponente zuständig. Somit gibt es keine direkten Abhängigkeiten. Daneben ist sie für die Kommunikation
mit anderen Agenten zuständig.
Intermediate Level Agents Repräsentieren Kombinationen oder Abhängigkeiten zwischen Bottom Level Agents (z.B. das Manipulieren von Daten, welche von mehreren Views benutzt werden). Diese Agenten sind für die Komposition oder Koordination zuständig. Sie können zusammenhängende Agenten gruppieren, um einen neuen Abstraktionslevel zu generieren. Daneben können sie auch für die Koordination von gemeinsamen Daten zuständig sein (Mediator?).
MVC und PAC
Unterschied zu MVC
Das Model-View-Controller-Muster (ebenfalls ein Architekturmuster für interaktive Softwaresysteme) reicht für diese Anwendungen nicht aus und so geht PAC über dieses hinaus. Es teilt ein System in zwei Richtungen auf, einmal in die drei Einheiten grafische Benutzungsschnittstelle (Presentation), Vermittlung und Kommunikation (Control) und das Datenmodell (engl. Abstraction) – dies ist ähnlich dem MVC – und darüber hinaus noch hierarchisch in verschiedene Teile, die, wie eingangs gefordert, jeweils einen Teil der Aufgaben des Systems anbieten. Diese Teile nennt man im PAC-Muster „Agenten“ und sie stellen die erste Stufe der Strukturierung während des Architekturentwurfes dar. Das heißt, man beginnt den Entwurf mit der Aufteilung der gesamten Anforderungen auf einzelne Agenten und baut die hierarchische Struktur darauf auf. Für jeden Agenten wird dann im zweiten Schritt des Entwurfes eine Aufteilung in die besagten Komponenten, Darstellung, Abstraktion und Steuerung, vorgenommen.
Microkernel-Pattern
Das Microkernel Pattern ist für Systeme, die sich an verändernde Systemanforderungen anpassen müssen, nützlich. Dabei wird ein minimaler funktionaler Kern von der erweiterten Funktionalität und kundenspezifischen Elementen separiert. Der Microkernel dient zudem als Schnittstelle für Erweiterungen und zur Koordination der Kollaboration ebendieser Erweiterungen.
Kontext
Die Entwicklung von Anwendungen, die gleiche (oder zumindest ähnliche) Programmierschnittstellen nutzen, welche auf der gleichen Kern-Funktionalität aufbauen.
Problem
Bekannte Beispiele für die Problem-Domain sind Applikationsplattformen (OS, DBMS, usw.). Solche Systeme haben eine lange Lebensdauer (10+ Jahre) und müssen neue Technologien (Hardware/Software) integrieren können.
Forces
• Die Applikationsplattform muss immer die neuste Hardware- und Software-Generation unterstützen.
• Die Applikationsplattform muss portabel, erweiterbar und einfach in neue Systeme integrierbar sein.
• Der Kern der Applikationsplattform soll eine separate Komponente mit minimaler Speicherbelegung sein und seine Services sollen so wenig Rechenleistung wie möglich in Anspruch nehmen.
Lösung
Das Microkernel Pattern schafft Abhilfe für die oben erwähnten Probleme. Dabei werden die fundamentalen Services einer Applikationsplattform in eine Microkernel Komponente gepackt. Der Microkernel bietet anderen Komponenten die in separaten Prozessen laufen, die Möglichkeit miteinander zu kommunizieren. Er verwaltet ausserdem systemweite Ressourcen, und er bietet Interfaces an, die anderen Komponenten Zugriff auf seine Funktionen bieten.
Microkernel-Structure
Client Ein Client ist eine Applikation, die sich mit einem External Server assoziiert.
Adapter Der Adapter entkoppelt den Client vom Externen Server. Versteckt z.B. die Kommunikationsmechanismus des Microkernels vom Client. Der Adapter wird im Client-Prozess ausgeführt und bietet eine definierte Schnittstelle an. Der Adapter kann auch mehrere externe Server unterstützen und dadurch die Emulation einer Anwendung auf verschiedenen Systemen vornehmen. Ein Beispiel hierfür ist die C-Api, welche z.B. für das File-Handling identisch ist für sämtliche Systeme. Die konkreten Implementierung rufen dann intern die Interrupt-Services auf.
External Server Jeder externe Server läuft in seinem eigenen Prozess. Der externe Server stellt eine Schnittstelle bzw. eine spezielle Sicht für den Client bereit. Er nimmt die Client-Anforderungen an, führt den Dienst aus und antwortet dem Client. Der externe Server verwendet hierfür die Infrastruktur des Microkernels. Der externe Service stellt die Programmierschnittstelle für die Clients zur Verfügung. Ein Beispiel hierfür ist die Interrupt-Service-Routine, welche von den Clients für die Ausführung von Betriebssytem-Funktionalitäten genutzt werden kann.
Microkernel Der Microkernel stellt die Basisfunktionalitäten des System bereit. Hierbei geht es um die Adressierung von Ressourcen (z.B. Files) sowie die Kommunikation zwischen den einzelnen Komponenten. Der Microkernel stellt die Infrastruktur zur Verfügung, damit die Internen sowie Externen Server miteinander kommunizieren können.
Internal Server Stellen erweiterte Funktionen bereit, welche nicht im Microkernel implementiert werden. Diese Dienste werden vom Microkernel erst bei Bedarf geladen. Ein Beispiel hierfür sind Gerätetreiber.
Broker-Pattern
Try to imagine that 10 people have messages they need to deliver. Another 10 people are expecting messages from the previous group. In an open environment, each person in the first group would have to deliver their message to the recipient manually, so each person has to visit at least one member of the second group. This is inefficient and chaotic.
In broker, there is a control class (in this case the postman) who receives all the messages from group one. The broker then organizes the messages based off destination and does any operations needed, before visiting each recipient once to deliver all messages for them. This is far more efficient.
Problem
Es ist erforderlich, dass zwischen den verteilten Komponenten eine Art Interprozess-Kommunikation besteht. Falls die Komponenten diese Kommunikation selbst regeln, resultiert das in unnötigen Abhängigkeiten. Es werden Services für das Hinzufügen, Entfernen, Austauschen, Aktivieren und das Auffinden von Komponenten benötigt. Die Programmierschnittstelle sollte sich von der Programmieren von nicht verteilten Anwendungssystemen möglichst nicht unterscheiden.
Forces
• Es soll Komponenten möglich sein, auf die Services anderer Komponenten mittels remote service invocations zuzugreifen.
• Es soll möglich sein, Komponenten zur Laufzeit hinzuzufügen, zu entfernen oder auszutauschen.
• Die Architektur soll system- und implementationsspezifische Details vor den Nutzern von Komponenten und Services verbergen.
Lösung
Es wird eine Broker Komponente eingeführt. Diese ist für die Auffindung von Diensten zuständig. Server registrieren ihre Serviceinterfaces beim Broker, wodurch diese für Clients verfügbar sind. Die Clients können den Broker für die Auflösung eines spezifischen Serviceinterfaces anfragen. Die Broker Komponente regelt dabei die Lokalisierung der Server, die Weiterleitung von Requests und die Übertragung von Resultaten oder auch Exceptions zu den Clients. Durch den Broker wird der Client und der Server räumlich entkoppelt. Kann der Broker Anfragen zwischenspeichern, dann erfolgt auch eine
zeitliche Entkoppelung.
Broker-Structure
Server Der Server stellt eine Dienstleistung über ein Schnittstelleninterface zur Verfügung. Der Server implementiert das Schnittstelleninterface und registriert sich selbst beim Broker.
Broker Der Broker stellt eine zentrale Registry für das Auffinden von Server-Diensten dar. Die Server können sich beim Broker (de-) registrieren. Clients können mittels der Registry die gewünschten Schnittstellen abfragen. Der Broker stellt zusätzlich einen Kommunikationsmittelpunkt zwischen Client und Server dar. Der Broker definiert ein Protokoll sowie Nachrichtenformat, welches von sämtlichen Clients und Server eingehalten werden muss. Dadurch ist sichergestellt, dass die Implementierung auch mit heterogenen Systemen funktioniert.
Client Ein Client ist eine Anwendung, welche eine Serverschnittstelle nutzen möchte. Der zugehörige Dienst kann der Client über den Broker abrufen. Der Client kennt die Lokalität des Servers nicht, da die Kommunikation über den Broker erfolgt.
Client-Side-Proxy Der Client-Proxy wrappt die Server Schnittstellen-API und gestaltet die Client-Aufrufe für den Client transparent. Der Proxy leitet die lokalen Anfragen an den Broker weiter und nimmt das notwendige (Un-) Marhsalling vor.
Server-Side-Proxy Der Server-Proxy stellt den Eingangspunkt in die Server-Logik dar. Sie entkoppelt die Server-Implementierung von der Interprozess-Kommunikation. Der Proxy ist somit zuständig für das (Un-) Marshallling und Dispatchen der Anfragen auf die korrekte Server-Komponente.
Bridge Die Bridge ist optional. Diese wird für die Kommunikation zwischen den einzelnen Broker benötigt, falls diese dezentral betrieben werden.
