10.4. Infrastruktur-Konzepte

Im folgenden werden die Konzepte des metaframeworks erläutert, welche die Infrastruktur für eine Anwendung darstellen.

10.4.1. Plug-Ins

Das metaframework selbst ist relativ einfach aufgebaut und stellt lediglich eine Ablaufumgebung bereit. Durch Plug-Ins kann eine Webanwendung basierend auf dem metaframework mit Leben gefüllt werden. In Abbildung Figure 10.4, “UML Modell des Plug-In Konzepts” ist das UML Modell der Plug-In Definition dargestellt.

Figure 10.4. UML Modell des Plug-In Konzepts

UML Modell des Plug-In Konzepts

Das metaframework unterscheidet dabei zwei Arten von Plug-Ins:

PlugIn

Mit Plug-Ins kann eine Webanwendung modular aufgebaut werden. Jedes Plug-In stellt dazu einen zugreifbaren Kontext sowie die Request-Handler bereit um URL Anfragen zu beantworten.

CorePlugIn

Aktuell kann es nur ein Core Plug-In geben. Es stellt alle notwendigen Standard-Implementierungen der metaframework Schnittstellen bereit. Daher verfügt es über eine zusätzliche Methode welche die Initialisierung eventuell genutzter Frameworks oder Bibliotheken sicher stellt.

Weiterhin stellt das Core Plug-In die Service Registry bereit über die zentral auf Infrastruktur-Objekte zugegriffen werden kann.

Weiterhin gibt es eine Standardimplementierung PlugInBase die als Basis für eigene Plug-Ins genutzt werden kann und die zu implementierenden Methoden auf eine ( getId()) reduziert.

10.4.2. Service Registry

Die Service Registry verwaltet zentral alle Infrastruktur-Objekte, d.h. alle Instanzen der Implementierugnen der metaframework Schnittstellen. Dies umfasst die PlugInRegistry, ExtensionRegistry, InterceptorRegistry, Resolver, Locator, Rendering sowie die von den Plug-Ins definierten RequestHandler und Interceptoren.

Die Abbildung Figure 10.5, “UML Modell der Service Registry” zeigt die UML Definition der Service Registry sowie die im metaframework enthaltene Standard-Implementierung.

Figure 10.5. UML Modell der Service Registry

UML Modell der Service Registry

Um die gegenseitigen Referenzen der Objekte untereinander elegant zu lösen bietet sich als Implementierung ein Dependency Injection Container an. Siehe dazu metaframework Plug-Ins.

10.4.3. Plug-In Registry, Interceptor Registry, Extension Registry

Diese drei Registries werden genutzt um Plug-Ins, Interceptor-Definitionen sowie Contributions auf Extensions zu verwalten. Die PlugInRegistry und die InterceptorRegistry werden nur von der Klasse Metaframework genutzt, während die ExtensionRegistry vom Anwendungscode genutzt wird. In Abbildung Figure 10.6, “UML Modell der Plug-In, Interceptor und Extension Registry” ist das UML Klassendiagramm der drei Registries dargestellt.

Figure 10.6. UML Modell der Plug-In, Interceptor und Extension Registry

UML Modell der Plug-In, Interceptor und Extension Registry

Bei der Plug-In Registry werden alle Plug-Ins verwaltet sowie die Abhängigkeiten zwischen ihnen geprüft. Bei fehlenden Plug-Ins wird die Abarbeitung durch das Framework gestoppt.

Die Interceptor-Registry verwaltet die Interceptoren mit den zugehörigen URL-Pattern für welches sie ausgeführt werden.

Die Extension-Registry verwaltet die Contributions von Plug-Ins zu Extensions. Das Extension-Contrubution Konzept wird hier näher erläutert.

10.4.4. Resolver

In Abschnitt Section 10.3, “Gliederung einer Anwendung” wurde das Kontext-Konzept vorgestellt um eine Anwendung zu gliedern. Kontexte können dabei mit einem Identifikator auf einen RequestHandler verweisen. Die Aufgabe des Resolvers ist es einen Aufruf der Anwendung auf die Kontext-Struktur abzubilden und Kontext-Informationen über den aktuellen Request zu ermitteln. Diese Informationen werden in einem HandlerInfo Objekt zusammengefasst und zurückgeliefert. Abbildung Figure 10.7, “UML Modell des Resolvers” zeigt die Definition des Resolvers in UML.

Figure 10.7. UML Modell des Resolvers

UML Modell des Resolvers

Neben der Schnittstelle ist auch eine Implementierung für Webanwendungen vorhanden, welche die aufgerufene URL auf die Kontext-Struktur abbildet.

10.4.5. Locator

Basierend auf den Informationen des HandlerInfo Objektes ermittelt der Loctor den RequestHandler welcher den aktuellen Request bearbeiten kann. Abbildung Figure 10.8, “UML Modell des Locators” zeigt das UML Klassenmodell des Locators und einer Standardimplementierung.

Figure 10.8. UML Modell des Locators

UML Modell des Locators

Die Standardimplementierung nutzt die Service Registry um eine Referenz auf den RequestHandler zu erlangen. Neben der Service Registry ist auch eine Instanziierung per Reflection denkbar, wie sie bei vielen MVC-Frameworks eingesetzt wird.