13.4. Infrastruktur-Konzepte
Im folgenden werden die Konzepte des metaframeworks erläutert, welche die Infrastruktur für eine Anwendung darstellen.
13.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 13-4 ist das UML Modell der Plug-In Definition dargestellt.
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.
13.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 13-5 zeigt die UML Definition der Service Registry sowie die im metaframework enthaltene Standard-Implementierung.
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.
13.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 13-6 ist das UML Klassendiagramm der drei Registries dargestellt.
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.
13.4.4. Resolver
In Abschnitt Section 13.3 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 13-7 zeigt die Definition des Resolvers in UML.
Neben der Schnittstelle ist auch eine Implementierung für Webanwendungen vorhanden, welche die aufgerufene URL auf die Kontext-Struktur abbildet.
13.4.5. Locator
Basierend auf den Informationen des HandlerInfo Objektes ermittelt der Loctor den RequestHandler welcher den aktuellen Request bearbeiten kann. Abbildung Figure 13-8 zeigt das UML Klassenmodell des Locators und einer Standardimplementierung.
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.