Java Reference
In-Depth Information
■
7.4 Beispiele und Gegenbeispiele für
Komponentensysteme
741 Beispiele aus dem Java-Umfeld
Der dritte Teil dieses Buchs enthält eine ganze Reihe von Beispielen, die mehr oder weniger
als Komponentensysteme gelten können. Dazu gehören z. B. Eclipse, Applets, Servlets,
Enterprise Java Beans und Spring. Auf diese Beispiele soll hier nicht weiter eingegangen
werden, da sie im Folgenden ausführlicher besprochen werden.
Als ein Beispiel für ein Java-Komponentensystem betrachten wir nochmals unser prototypi-
sches System aus dem vorhergehenden Kapitel und prüfen, inwiefern dieses System die
Eigenscha en E1 bis E4 tatsächlich besitzt:
!
Zu E1: Es sollte gerade für das Prototypsystem deutlich geworden sein, was eine Kompo-
nente ist und wie das Komponentenmodell dafür aussieht. Dazu gehört das Verpacken der
benötigten Dateien in eine Jar- oder Zip-Datei mit der vorgegebenen Verzeichnisstruktur,
die Manifest-Datei mit ihren möglichen Einträgen („Main: . . .“ und „Uses: . . .“) sowie die
mit @Start und @Stop annotierten Methoden, die die Einstiegsklasse haben kann, aber
nicht haben muss.
!
Zu E2: Das Modularitätsprinzip ist sehr gut erfüllt, da Komponenten im laufenden Betrieb
hinzugefügt, entfernt und erneuert werden können. Eine Schwachstelle des prototypi-
schen Frameworks stellt der Kopplungsmechanismus für Komponenten dar. Hier stellt
das Framework zwar eine Registratur bereit. Für die Nutzung der Registratur sind aller-
dings die Komponenten selbst verantwortlich. Das heißt also, dass ein „Verdrahten“ der
Komponenten komplett durch das Framework und von außerhalb der Komponenten nicht
möglich ist.
!
Zu E3: Durch die Start- und Stop-Methoden wird ein einfacher Lebenszyklus für die
„Hauptobjekte“ durch das Framework realisiert. Das Framework stellt auch einen ein-
fachen Dienst in Form einer Registratur für ihre Komponenten bereit.
!
Zu E4: Eine Komponente kann und muss nicht explizit spezifi zieren, was sie bereitstellt.
Grundsätzlich können die öff entlichen Klassen und Schnittstellen von anderen Kompo-
nenten genutzt werden. Welche Objekte durch die Registratur zur Verfügung gestellt wer-
den, ist im Code verborgen und wird nicht deklarativ angegeben (z. B. in einer Konfi gura-
tionsdatei oder durch eine Annotation). Wenn es also auch keine expliziten Angaben für
den Export gibt, so muss eine Komponente für den Import allerdings eine entsprechende
„Uses:“-Zeile in seiner Manifest-Datei haben. Das Importieren muss also explizit defi niert
werden.
Die Diskussion zeigt, dass unser Prototyp-Framework nicht alle Eigenscha en E1 bis E4 voll
und ganz erfüllt. Die Mehrzahl der Eigenscha en wird aber erfüllt, so dass das Framework
aus dem vorigen Kapitel durchaus als Beispiel eines Komponentensystems gelten kann, was
nicht überraschend ist, denn andernfalls wäre es im vorigen Kapitel des Buches nicht vor-
gestellt worden, zumindest nicht in dieser Form.
