Java Reference
In-Depth Information
7.4.2 Gegenbeispiele aus dem Java-Umfeld
Wenn man sich ausführbare Jar-Dateien ansieht, dann sehen diese in ihrer Struktur den
Beispielkomponenten des Prototyp-Frameworks sehr ähnlich. Neben den Class-Dateien ent-
halten sie eine Manifest-Datei, in der durch eine „Main-Class:“-Zeile die Einstiegsklasse
defi niert wird, in der sich die statische Main-Methode befi ndet. Das Betriebssystem und die
JVMs (Java Virtual Machines) könnte man als das zugrundeliegende Framework betrachten,
das gewisse Dienste bereitstellt. Sogar eine Art Lebenszyklus ist vorhanden, denn so wie die
Main-Methode der Einstiegsklasse zu Beginn aufgerufen wird, ist es auch möglich einzu-
stellen, dass Methoden kurz vor dem Ende des Prozesses aktiv werden. Insofern gibt es
Hinweise auf das Vorhandensein eines Komponentensystems. Was aber komplett fehlt, ist
ein Kopplungsmechanismus. Auch werden bereitgestellte Komponenten nicht durch das
Framework gestartet. Aus diesen Gründen würde ich ausführbare Jar-Dateien nicht als Kom-
ponenten einschätzen. Wenn man den Pipe-Mechanismus von Unix jedoch mit einbezieht,
komme ich zu einer anderen Wertung (s. Abschnitt 7.4.3).
Ein weiteres Beispiel, das betrachtet werden soll, sind verteilte RMI-Anwendungen. RMI
steht für Remote Method Invocation. Mit RMI wird eine Registratur namens RMI Registry
bereitgestellt, die sehr ähnlich funktioniert wie die Registratur in unserem Prototyp-Sys-
tem. Es können Objekte an- und abgemeldet sowie abgerufen werden. Das Besondere daran
ist, dass ein angemeldetes Objekt, das sich in einem Java-Prozess befi ndet, von einem ande-
ren Java-Prozess aus genutzt werden kann. Die Prozesse können sich sogar auf unterschied-
lichen Rechnern befi nden, was das R in RMI erklärt. Man könnte nun versucht sein, die
einzelnen Java-Programme, die über RMI kooperieren, als Komponenten zu sehen. In der
Tat besitzt ein solches System eine gewisse Modularität, denn es können einfach einzelne
Komponenten hinzugefügt, entfernt und neu gestartet werden, ohne dass andere betroff en
sind, und dies sogar im laufenden Betrieb. Der Kopplungsmechanismus für diese Kompo-
nenten ist RMI. Dieser ist zwar eher schwach, wie in Abschnitt 7.4.1 für das Prototyp-Sys-
tem erwähnt wurde, da er keine Kopplung ohne Zutun der Komponenten erlaubt. Das Kom-
ponentenmodell ist eher unscharf (jede Anwendung, die RMI nutzt). Auch wird nicht
erzwungen, dass die Komponenten über RMI kommunizieren müssen. Bereitgestellte Kom-
ponenten werden nicht durch das Framework gestartet (man könnte mit dem Hinweis auf
die RMI-Aktivierung gegen diese Aussage argumentieren). Ein Lebenszyklus ist schwach
vorhanden (wie oben für ausführbare Jar-Dateien diskutiert). Explizite Angaben des Im- und
Exports gibt es nicht (sind im Programmcode versteckt). Ich würde auch in diesem Fall eher
nicht von einem Komponentensystem sprechen, denn der Erfüllungsgrad der Eigenscha en
E1 bis E4 ist zwar nicht null, aber in meinen Augen nicht stark und deutlich genug. Man
könnte aber auch die gegenteilige Auff assung vertreten.
743 Beispiele aus dem Nicht-Java-Umfeld
Die Verkettung über Pipes aus dem Unix-Betriebssystem wird ab und zu ebenfalls als Kom-
ponentensystem angeführt. Betrachten wir als Beispiel die folgende Zeile, die einem Unix-
Kommandointerpretierer (Unix Shell) angegeben werden kann ($ soll dabei der von der
Shell ausgegebene Prompt sein):
$ prog1 | prog2 | prog3
