22.1 Grundlagen der Komponententechnik

In der Einleitung wollen wir uns klarmachen, dass wiederverwendbare Softwarebausteine das Leben eines Designers versüßen können. Wir werden unterschiedliche Komponentenmodelle kennen lernen und Beans als reine Java-Lösung mit alternativen Ansätzen vergleichen.

22.1.1 Brauchen wir überhaupt Komponenten?

In großen Projekten ist es nicht eine Klasse, die die gesamte Arbeit verrichtet, sondern eine Menge von Klassen, die zusammenarbeiten. Diese werden in einem Paket gebündelt. Jedes Paket übernimmt einen Arbeitsbereich, genauso wie wir es von den Standardpaketen im Java-SDK kennen. Das Net-Paket etwa übernimmt Aufgaben für den Netzwerkverkehr und das Security-Paket die Verschlüsselung von Daten. Bei eigenen Paketen würden wir aus unseren Klassen eine Jar-Datei erstellen und unser Produkt zum Kauf anbieten. Auf diese Weise haben wir für uns und für Kunden ein Stückchen wiederverwertbare Software entwickelt, so dass ein spezieller Baustein eine Aufgabe löst. Dieses Paket können wir allerdings noch nicht Komponente nennen, obwohl Pakete schon erste Anzeichen in diese Richtung geben. Eine wichtige Eigenschaft fehlt: JavaBeans sind Softwarekomponenten, die über wohl definierte Schnittstellen miteinander kommunizieren können. Diese JavaBeans-Schnittstellen zeichnen sich durch eine besondere Signatur aus. Betrachten wir Komponenten als bloße Bibliotheken, so ist nicht viel gewonnen - Softwarebaukästen gab es schon zu Assembler-Zeiten.

Eine einfache Form von wiederverwertbaren Komponenten haben wir mit Applets schon kennen gelernt. Doch hier ist der Einsatz auf Web-Seiten begrenzt. Bei Beans kommt noch ein Interaktions-Modell hinzu. Die Schnittstelle und der Kleber der Komponenten ist das JavaBeans-Modell. Die Komponenten, also JavaBeans, halten sich an bestimmte Namenskonventionen und lassen sich deshalb über Reflection durch ein visuelles Dienstprogramm bedienen. Diese Bausteine werden für die Zukunft des Softwareentwurfs wegweisend sein. Hier fällt auch ein ganz neuer Begriff: Componentware. Mit Hilfe der Komponenten soll es möglich sein, komplexe Systeme aus diesen Bausteinen zusammenzusetzen, genauso wie einzelne Puzzleteile ein Bild ergeben. Die Java-Komponenten sollen miteinander über Ereignisse interagieren können.

22.1.2 Visuelle und nichtvisuelle Komponenten

Sun definiert Komponenten derart, dass sie sich visuell durch so genannte Application-Builder manipulieren lassen. Die Bean kann auf dem Bildschirm dargestellt und angepasst werden. Vielen von uns dürfte dies von GUI-Buildern bekannt vorkommen. Und hier gibt es auch eine Verwandtschaft, denn in Java sind die AWT-Komponenten ebenfalls nichts anderes als Beans. Nehmen wir etwa eine Schaltfläche: Sie besitzt ein Aussehen (View) und einen internen Zustand (Modell). Die Schaltfläche lässt sich auf einem Arbeitsblatt positionieren, und über einen speziellen Dialog des Builders kann der Text oder die Schriftfarbe angepasst werden.

Eine Komponente muss aber nicht zwingend grafisch sein. Genauso gut kann es eine Datenstruktur oder eine FTP-Klasse sein. Eine häufig eingesetzte Komponente ist etwa ein Timer, der in festen Abständen ein Ereignis meldet. Von IBM werden eine Reihe von Beans angeboten, die Elemente einer Programmiersprache aufweisen, etwa Schleifen und Kontrollstrukturen. Die Beans-Komponenten können auch wiederum andere Beans aufnehmen und als Container arbeiten. Dadurch wird eine Hierarchie von Komponenten geschaffen.

22.1.3 Andere Komponententechnologien oder: Was uns Microsoft brachte

Wirklich neu ist diese Idee der Komponenten nicht, und in der Windows-Welt finden JavaBeans ihren größten Konkurrenten: das ActiveX-Komponentenmodell. JavaBeans (die wir im Folgenden einfach Beans nennen wollen) sind die plattformunabhängige Antwort auf die Windows-Welt. Weitere bekannte Technologien zum Austausch von Komponenten sind OpenDoc (seit 1997 tot) und auch CORBA, obwohl CORBA eher einen anderen Weg verfolgt.

Mit ActiveX ist bereits eine lange Entwicklung verbunden. Die erste Station ist OLE (Object Linking and Embedding), mit dem eine Anwendung ihre Funktionen einer anderen Anwendung zur Verfügung stellen konnte. Das erste Komponentenmodell von MS ist COM (Component Object Model), das programmiersprachenunabhängige Schnittstellen definiert. COM ist aber eingeschränkt auf die lokale Maschine, so dass aus COM das Distributed COM (DCOM) wurde. Für Microsoft ist Visual Basic eine der wichtigsten Programmiersprachen für Quick'n'Dirty. So wundert es nicht, dass auch dort Komponenten entwickelt und verteilt werden. Hier gibt es ein spezielles Format, die Visual Basic Extension (VBX), für die 16-Bit-Welt und die OCX (OLE Control Extension), die auf COM und VBX basieren. OCXe leben in der 32-Bit-Welt. Als letzter Schritt folgte ActiveX. Eine Änderung der OCX-Komponenten ist nötig geworden, da OCX- und DCOM-Objekte zu groß sind, um sie ähnlich schnell wie Java-Applets über das Netzwerk zu übertragen. Andernfalls hätten Surfer über eine Modem- oder ISDN-Verbindung auf eine megabytegroße Datei etwas länger warten müssen. Da ActiveX jedoch nur eine Erweiterung seines Vorgängers mit Zertifikaten ist, bestehen immer noch Sicherheitsprobleme, die mit Java nicht auftreten. Wer möchte schon ein Quicken-Programm ferngesteuert sehen, das heimlich ein paar Mark abbucht?

Gut, dass es Java gibt!

Dass ActiveX keine Lösung ist, lässt sich aus zwei Gründen ableiten. Es ist auf die Windows-Welt fixiert und zu unsicher. Jedes ActiveX-Control kann die Festplatte formatieren oder sensible Daten in ein Diskussionsforum senden (das ist besonders ärgerlich). Mit Java kann das nicht passieren, und Beans sind in Java keine Fremdkörper, sondern eine Ergänzung. So laufen die Beans unter plattformunabhängigen Programmiersprachen und nutzen das eingebaute Sicherheitsmodell. Möchte ein Applet eine Datei öffnen, moniert das Sicherheitsmodell dies bereits. Java bietet auch im Gegensatz zu C++ und anderen Sprachen den großen Vorteil, dass zur Laufzeit Komponenten untersucht (Reflection) und benutzt werden können. So wird eine unbekannte Bean einfach auf eine Bearbeitungsfläche gezogen und gleich angewendet.

Auf der anderen Seite darf nicht verschwiegen werden, dass die Windows-Plattform einen Markt darstellt, der gewaltig viele Komponenten erzeugt. Da ActiveX-Komponenten in Visual C++ erzeugt, in Visual Basic getestet und in Delphi eingebaut werden können, heißt die Lösung unter Windows eindeutig ActiveX. Dann wäre es bei den großen Einsatzmöglichkeiten von ActiveX-Komponenten schade, wenn es keine JavaBeans gäbe, die wir nicht auch als ActiveX-Control nutzen könnten. Hier heißt die Lösung nicht J++, sondern sie liegt darin, so wie bei ODBC-Treibern, eine Brücke zu implementieren, die zwischen plattformunabhängigen Beans und Windows-Controls vermittelt. Die ActiveX-Bridge ermöglicht es, die OLE-Komponenten von Windows mit JavaBeans-Komponenten zu kombinieren. So kann Geld für teure Eigenentwicklungen gespart werden, und unsere Java-Komponenten können wir in Word, im Explorer oder in Visual Basic einsetzen. So ergibt sich Wiederverwendbarkeit auf hohem Niveau.