Hier stelle ich die nächsten Entwicklungsziele für dWb+ vor. Diesmal steht eine größere Architekturänderung zur weiteren Modularisierung an.

Hierbei geht es um eine größere Architekturänderung, die es erlauben soll, Modulaspekte geziehlt zur Modellierung des Contexts zu nutzen: Anders als zur Zeit wird der Modul-Container lediglich die Module aufnehmen und entsprechend instantiieren. Sie werden nicht mehr zum BeanContext hinzugefügt. Statt dessen wird der Context beim Hinzufügen und Entfernen Signale an einen neu zu schaffenden Manager senden, der dann andere Context-Implementationen über diese Tatasachen informiert. Der erste dieser neu zu schaffenden Contexts wird eine Umsetzung des BeanContext sein, so dasss anschließend wieder dieselbe Funktionalität erreicht sein wird, wie aktuell in der alten Architektur. Der zweite Context soll dann Module, die einen entsprechenden Aspekt aufweisen, über eine REST-Schnittstelle steuerbar machen. Diese geplante Architekturänderung führte zu tiefergehenden Gedanken zur konkreten Umsetzung, die sich in folgenden Aspekten widerspiegeln: Sollten die verfügbaren Services zur Laufzeit umkonfiguriert werden können? Beispiele dafür wären unter anderem die Möglichkeit, spezielle Services hinzufügen oder entfernen zu können. Alternativ dazu (und sicher einfacher umzusetzen) wäre es, die Menge der Context-Implementierungen fest an den Container zu binden. Dann müsste man spezielle Group-Workspaces oder auch Layer definieren, die über die an sie gebundenen Context-Implementierungen spezielle Mehrwerte anbieten. Daher kam auch die Idee, die Einbindung von Modulen feiner zu steuern, als über bloßes Hinzufügen und Entfernen: Setzt man mit den Context-Implementierungen bei den Layern auf, kann das Hinzufügen eines Moduls zum Container noch gar nichts Besonderes bewirken - erst wenn man es innerhalb des Containers in einen Layer verschiebt, der spzielle Context-Implementationen anbietet, würde ein entsprechender Mehrwert aktiviert. Dazu müsste sich man von dem Konzept des Layers als reine Gliederungshilfe, wie es jetzt besteht weg hin zu einer komplexeren Sichtweise bewegen. Die flexibelste aber auch komplexeste Variante wäre eine Kombination aus beiden: Die Layer verwalten eine Sammlung von Context-Implementationen, deren Umfang und Inhalt jederzeit geändert werden kann.

Ein weiterer Aspekt führte zunächst ein wenig mäandernd zu folgenden zwei Fragestellungen: Welche Context-Implementierung ist am schnellsten und problemlosesten auszuprobieren. Dadurch kam ich auf die Idee, eine solche anzubieten, die beliebige Module hernimmt und sie als MBeans über JMX exponieren kann. Dadurch kam mir die Idee, wie man JavaBeans als MBeans exponieren könnte, ohne das MBean-Interface zu implementieren (JavaBeans, über die man keine Quelltexthoheit hat beispielsweise). Und die zweite Frage, die sich mir stellte und über die ich bisher noch nie gelesen hatte: Wenn JavaBeans als MBeans exponiert werden können - wird dann die BeanInfo honoriert? Zwei Gedanken, denen ich noch vor der Umsetzung des eigentlich hier beschriebenen Ziels nachjagen wollte...

Artikel, die hierher verlinken

Kommentar hinzufügen (via ) Kommentare ansehen (via )

Kommentar hinzufügen (via ) Kommentare ansehen (via )