Java Reference
In-Depth Information
Bei prog1, prog2 und prog3 muss es sich um ausführbare Programme handeln, die über die
PATH-Umgebungsvariable im Dateisystem gefunden werden.
Die Unix-Shell erzeugt für jedes auszuführende Programm einen eigenen Prozess und für
jedes Pipe-Symbol | eine Unix-Pipe. Eine Pipe ist ein Kommunikationskanal, in den Daten
geschrieben und aus dem diese Daten wieder gelesen werden können. Der lesende und
schreibende Zugriff hat unter Umstä nden synchronisierende Wirkung: So wird ein Leser
blockiert, wenn er aus einer leeren Pipe lesen möchte, ein Schreiber, wenn er in eine volle
Pipe schreiben möchte. Die erzeugten Prozesse und Pipes werden nun so verschaltet, dass
die Standardausgabe eines Prozesses auf die Pipe, die dem nachfolgenden Pipe-Symbol ent-
spricht, „umgebogen“ wird. Das heißt, immer wenn in der Anwendung, die von diesem
Prozess ausgeführt wird, etwas auf die Standardausgabe geschrieben wird (in einem Java-
Programm ist das System.out), dann erscheint die Ausgabe nicht auf dem Bildschirm, son-
dern wird in die Pipe geschrieben. Analog wird die Standardeingabe eins Prozesses (in Java
System.in) auf die Pipe umgebogen, die dem vorausgehenden Pipe-Symbol entspricht. Das,
was also das Programm normalerweise von der Tastatur einlesen würde, kommt jetzt aus
der Pipe.
Wie üblich können jedem ausführbaren Programm auch Kommandozeilenargumente mit-
gegeben werden:
$ prog1 arg11 arg12 | prog2 arg21 | prog3 arg31 arg32 arg33
Damit kann die Kopplung auch für Java-Programme vorgenommen werden:
$ java a.b.Main1 | java c.d.Main2 args | java e.f.g.Main3 otherargs
Und ebenso können Java-Programme mit Programmen, die in anderen Sprachen geschrie-
ben wurden, gekoppelt werden:
$ java a.b.Main1 | prog2 | java e.f.g.Main3 arg1 arg2
In meinen Augen könnte man hier in der Tat von einem kleinen Komponentensystem spre-
chen, welches hier durch die Unix-Shell in der Rolle des Frameworks realisiert wird. Zwar
ist das Komponentenmodell auch schwach ausgeprägt (eine Komponente ist eine Anwen-
dung, die die Standardein- und/oder -ausgabe benutzt). Auch gibt es keinen Lebenszyklus
und keine expliziten Angaben, was importiert und exportiert wird. Was es aber gibt (und
das halte ich hier für entscheidend), ist ein Kopplungsmechanismus, der außerhalb der
Komponenten allein durch das Framework realisiert wird. Dieser Mechanismus ermöglicht
eine sehr einfache Kopplung der Komponenten, die leicht verä nderbar ist, wenn auch nicht
im laufenden Betrieb. Ich würde also sagen, dass es sich beim Pipe-Mechanismus gerade
noch um ein Komponentensystem handelt. Wenn Sie zu einer anderen Bewertung kommen,
dann ist das sicher auch gut vertretbar.
Weitere Komponentensysteme im Nicht-Java-Umfeld sind COM, DCOM und die .NET-Kom-
ponenten aus der Windows-Welt, das CORBA Component Model (CCM) aus der CORBA-
Welt, Web Services und die Loadable Kernel Modules des Linux-Betriebssystems. Wegen
des Fokus auf Java in diesem Buch gehen wir auf diese Systeme nicht weiter ein.
