1 Geschichtliche Entwicklung des JavaBean-Modells

1.1 Geschichte der Komponententechnik

Um zu verstehen, was Java-Komponenten bzw. JavaBeans sind und welche Technologie dahinter steckt, ist ein kurzer Ausflug in die Geschichte der Komponentenentwicklung notwendig.
Nach dem Aufkommen der objektorientierten Programmierung, fragte sich so mancher Experte, ob darin die endgültige Lösung für die Softwareentwicklung der 90er Jahre liegen könnte. Kaum hat sich dieses Paradigma auf breiter Front etabliert, erscheint ein neuer Stern am Himmel: die "Componentware". Kleine Module (Komponenten) sollen zu komplexen Programmen "zusammengeklickt" werden und lästige "Handarbeit" vermindern helfen. Damit solche Komponenten genutzt werden können, muß ein einheitlicher Unterbau, eine taugliche Komponentenarchitektur, vorhanden sein. Die Entwicklung von Komponententechnologie(n) begann mit dem Aufkommen grafischer Benutzeroberflächen und das JavaBeans-Modell definiert sich sogar daraus:

"A JavaBean is a reusable software component that can be manipulated visually in a builder tool."

Diese Aussage, hier als Zitat aus der JavaBeans-Spezifikation [1] [1], ist allgemeingültig für alle Komponentenmodelle.
Bekannte Technologien sind OpenDoc (propagiert und entwickelt von Apple und IBM), CORBA (von einem Konsortium einiger hundert Firmen) und DCOM/ActiveX (Microsoft). Die verschiedenen Technologien sind insofern nicht vergleichbar da teilweise verschiedene Probleme gelöst werden, welche bei einer zweiten Technologie nicht auftreten oder die sich noch in der Entwicklung befindet. Marktrelevanz der o. a. Technologien haben nur noch die Microsoft-Vorschläge und CORBA. Die Entwicklung von OpenDoc wurde 1997 eingestellt, nicht zuletzt ein Tribut an die neue Technologie der JavaBeans, welche nun von IBM und Apple (mit)propagiert wird! CORBA wird es trotz seiner allgemeinen Unterstützung und Verbreitung weiterhin schwer gegen ActiveX haben, was an der absoluten Marktdominanz der Microsoft Betriebssysteme liegt, welche alle ActiveX implementieren und anbieten. Eine kurze Geschichte der wichtigen Microsoft-Komponententechnologie ist der Tabelle 1.1 zu entnehmen.

Nr:	Protokoll/Technik:	Erläuterung:
1	Datenaustausch mit Cut`n`Copy	Beispielsweise über die Windows-Zwischenablage.
2	DDE-Protokoll	Dynamic Data Exchange: Fokus der Technologie liegt auf Daten - erstmals programmierbarer und automatisierter Datenaustausch zwischen Anwendungen
3	OLE	Object Linking and Embedding: Erster Objektorientierter Ansatz - kann innerhalb einer Anwendung die Funktionalität einer anderen Anwendung zur Verfügung stellen. Noch kein Komponentemodell!
4a	COM	Component Object Model: programmierprachenunabhängiges Objektmodell für Windows
4b	VBX	Visual Basic Extension: 16-Bit Basic Komponenten
5a	DCOM	Distributed COM: erstes MS Objektmodell für verteilte Umgebungen
5b	OCX	OLE Control Extension: Basiert auf COM und VBX, 32-Bit
6	ActiveX	Verkleinerung der 'großen' OCX-Objekte auf 'kleine' (netztaugliche) Objekte

Tabelle 1.1: Entwicklung der Windows-Komponetentechnologie

Die meisten Technologien starteten mit proprietären Lösungen, bei denen einfach alle verwendeten UI-Elemente des Wirtssystems in eigene Elemente eingesetzt wurden. Bekannte Beispiele sind hier Fensterrahmen, Fensterlaufleisten oder auch komplexere Objekte wie ein komplettes Dialogfenster (Ja/Nein/Abbrechen). Erster Vertreter dieser "neuen" Compiler war Visual Basic. Sowieso stellte sich VB als Schrittmacher der Komponentenprogrammierung bei Microsofts Windows-Oberfläche heraus. Die ersten Komponenten waren VBX-Komponenten (Visual Basic EXtension). Anfangs noch stark an die Bedürfnisse von Basic angepaßt, waren diese für die meisten höheren Programmiersprachen nur sehr schwer ansprechbar. VBX wurde ein großer Erfolg, nachdem Microsoft eine einheitliche Schnittstelle mit einer festgelegten Struktur für Komponenten vorschrieb. Dies ermöglichte "3rd-party-development" - die Herstellung und Programmierung von Komponenten durch Drittanbieter - mit der Garantie, daß die vom Programmierer gekauften Komponenten mit dem Compiler und dem Betriebssystem vollkommen kooperieren. (Den gleichen Ansatz verfolgt auch Sun mit dem JavaBeans-Modell.) Aufgrund des Erfolgs wurde ein Nachfolgemodell entwickelt, daß auch die o. e. Mängel (z. B. waren alle Komponenten noch 16-Bit) beseitigen sollte: OCX-Komponenten (OLE Control EXtension), welche z. B. 32-Bit-Technologie einführten. Beide Varianten konnten bereits über die definierten OLE/COM-Schnittstellen auf einem System miteinander Module tauschen und/oder kommunizieren. Trotz DCOM (Distributed COM) konnte von "echter" Verteilung - sprich: von Verteilung und Kommunikation von Modulen über Rechner- und Betriebssystemgrenzen hinweg - keine Rede sein.

Dies war der technische Stand (bei Microsoft) etwa Mitte 1996. Im gleichen Jahr sollte eine "neue" Programmiersprache - Java - die Entwicklerszene revolutionieren. Die Sprache fiel auf durch kleine, effektive Programme eingebettet in Internet WWW-Seiten. Offenbar war es möglich geworden mit vergleichsweise winzigen Programmen in einem weltweiten, mehr oder weniger chaotisch verwalteten Netzwerk, mit Millionen von Benutzern, ein stabile und sichere Methode zur Verfügung zu stellen, Programme vom Server- auf einen Clientrechner zu übertragen und dort auszuführen. Java erlebte einen gewaltigen Boom. Alle großen Softwarefirmen lizensierten Java, tausende von Freaks entwarfen immer neue Applets für ihre Internetseiten: Vom Börsenticker bis zum Kreuzworträtsel. Java öffnete offenbar ein neues Gebiet im Bereich des "distributed computing". Möglich wurde dieser Erfolg durch ein neues durchdachtes System, das alle Anforderungen an eine moderne Programmiersprache erfüllte. Tatsächlich vereinigt Java "nur" altbekannte Konzepte anderer Programmiersprachen. Java bringt die Industrie dem Ziel eines verteilten, plattformunabhängigen Betriebssystems oder Programms ein gutes Stück näher. Durch die Einhaltung von bekannten internationalen (!!!) Standards, der kompletten Offenlegung aller Quelltexte, Schnittstellen usw. und nicht zuletzt der kostenlosen Verfügbarkeit ist Java ein voller Erfolg. Der "Erfinder" von Java - die Firma Sun Microsystems - hat als Netzwerkspezialist mit Erfahrungen in diesem Bereich dem Microsoft-Imperium einen empfindlichen Schlag versetzt - ohne selbst größere PC-Software anzubieten! Zu diesem Zeitpunkt hatte Microsoft der neuen Technik nichts entgegenzusetzen. Das OCX/DCOM-Modell scheiterte schlicht an der größe der Komponenten, die bis in den Megabytebereich vordringen können. Eine (weltweite) Übertragung solcher Files über das vergleichsweise langsame Internet ist inakzeptabel. Microsoft veröffentlichte gezwungenermaßen ein neues Objektmodell mit dem Namen ActiveX. Durch die volle Abwärtskompatibilität dieses Modells standen den Entwicklern sofort tausende "alter" Komponenten zur Verfügung. Natürlich blieb es bei der langen Entwicklung nicht aus, daß eine Menge von Rückwärtskompatibilitäten, "work-arounds" usw. in dieser Technologie haften geblieben sind, die die Programmierung von ActiveX-Controls spannend machen können. Desweiteren glaubte man bei Microsoft wohl, daß sich die Erfahrungen mit lokalen Systemen ohne weiters auf die Internet-Programmierung übertragen lassen. Schutzrechte sind ActiveX unbekannt und warum sollte es mich stören, daß ein beliebiger Programmierer oder Komponentennutzer alles mit der lokalen Festplatte machen kann? Auch das Senden von "i`m-still-alive"-Messages von ActiveX-Objekten (auch eine "alte Erbschaft"), welches nach wie vor notwendig ist um die Objektqueue aktuell zu halten, unterstreicht nicht gerade die Netztauglichkeit von ActiveX; im Internet gehen nach wie vor TCP/IP-Pakete verloren.

1.2 Einordnung des JavaBean-Modells

Etwa zeitgleich zu ActiveX veröffentlichte Sun erste "Papers" zu Javas Komponentenmodell - den JavaBeans. Die Technologie basiert vollständig auf der Programmiersprache Java und ist somit plattformunabhängig. Weiterhin "erbt" jede Bohne den hohen Sicherheitsstandard Javas in Bezug auf verteilte Anwendungen und Inter-/Intranetkommunikation. Speziell die Plattformunabhängigkeit eröffnet aber zunächst eine neue Problematik. Ein Windows-Dialog hat ein anderes Aussehen als z. B. ein Motif-Dialog. Dialoge verschicken Nachrichten bzw. Antworten und Ergebnisse an z. B. ihre aufrufende Instanz - dies kann wiederum auf völlig unterschiedliche Art und Weise geschehen. Sun ist es inzwischen gelungen dieses Problem weitestgehend zu lösen, weshalb der Programmierer auch von dieser Problematik befreit ist. Der Hauptunterschied zu den in Kapitel 1.1 vorgestellten Technologien ist wohl, daß es sich bei Beans-Technologie nicht um konkreten "neuen" Kode handelt. Alle zur Programmierung von Java-Beans notwendigen Elemente, sind bereits im JDK enthalten. Das Konzept integriert sich voll und ganz in die Programmiersprache Java! Das Modell besteht vielmehr aus bindenden Vereinbarungen, die jeder Programmierer einhalten muß, um eine Bean zu programmieren und auch veröffentlichen zu können - ganz ähnlich wie es bei Visual Basic praktiziert wurde. Diese Vereinbarungen (von Sun auch "Design Patterns" genannt [2] [2], nicht zu verwechseln mit den "Design Patterns" von Gamma, Helm, Johnson, Vlissides [3] [3]). Sie sind insoweit verpflichtend, als das Sun ein Softwarepaket zum schnellen entwickeln, testen und veröffentlichen von Beans anbietet, welches genau diese Vereinbarungen benötigt und überprüft. Von Seiten der Entwickler stellt diese Vereinbarung sowieso keinen Nachteil dar, eine "Komponente", die nur auf einem Rechnersystem und/oder nur einer Konfiguration läuft, widerspricht dem Sinn einer Komponente - es ist einfach keine. Die Vereinbarung betrifft z. B. konkret Methodennamen der Java-"Bohne". In Borlands Delphi würde eine Komponenteneigenschaft beispielsweise folgerndermaßen gesetzt:

    aBean.aStringProperty = "10";

bei einer JavaBean hingegen folgendermaßen:

    aBean.setStringProperty("10");

Der Zugriff erfolgt also über Methoden und nicht direkt! Mehr hierzu im nächsten Kapitel.

Manch einer mag die Frage stellen wozu JavaBeans erfunden worden sind, Java-Applets seien doch schon Komponenten? Wie wir später genau sehen werden sind sie das nicht - prinzipiell läßt sich aber aus jedem Java-Applet und auch jeder Java-Applikation eine Java-Bean machen. Eine Java-Bean ist viel flexibler "einstellbar" als ein Applet - ohne das dem Programmierer der Quellcode oder eine exakte Beschreibung der (Schnittstellen-)Methoden der verwendeten Bean vorliegen muß. Durch die definierte Schnittstelle (bzw. die Vereinbarung) der Komponente kann eine Java-Virtual-Machine während der Laufzeit feststellen, welche Fähigkeiten eine Java-Bean hat und wie diese genutzt werden können. Bei der Programmierung (oder auch später) können so während der Programmausführung neue Komponenten (dem Programm völlig unbekannte!) mit Drag&Drop eingefügt und sofort genutzt werden! Diese neue Leistung, derzeit nur mit Java möglich, ist natürlich nicht nur auf die Spezifikation einiger Schnittstellen zurückzuführen, sondern eben auch konkret auf Eigenschaften der Programmiersprache Java und der Laufzeitumgebung; sie unterstreicht die Leistungsfähigkeit Javas und demonstriert eindrucksvoll die Fähigkeiten einer modernen Programmiersprache - Java-Beans sind bereits "eine Anwendung" von Java!

Zum Schluß dieses Abschnitts soll nicht verschwiegen werden, daß die Entwicklung der JavaBeans-Komponententechnologie noch lange nicht abgeschlossen ist. Um schon jetzt diese Technologie in bestehende Betriebssysteme integrieren zu können wurde beispielsweise von Sun ein ActiveX-Bean-Bridge programmiert. Sie ermöglicht die Benutzung von Java-Beans in ActiveX-Controls. Ähnliche proprietäre Lösungen wurden noch letztes Jahr von diversen Datenbankanbietern bereitgestellt, um "ihre" Datenbank Java-fähig zu machen. Aber gerade im Bereich der Datenbanken sind inzwischen solche Lösungen überholt. Es hat sich gezeigt, daß die diversen Technologien nicht unbedingt direkte Konkurrenz zueinander darstellen, sondern sich in vielen Bereichen gut ergänzen. So ist es z. B. sehr wohl möglich eine CORBA-Implementierung für Java mit Beans zu realisieren, wie in [4] [4] vorgeschlagen. Die großen Softwarehäuser arbeiten mit Hochdruck an Java-Beans bzw. Java-Komponentenbibliotheken in reinem Java. Berücksichtigt man, daß das bisher erreichte in nur zwei Jahren "aus dem Boden gestampft" wurde ist abzusehen, daß Java-Beans in Kürze im Komponentenmarkt einen beträchtlichen Marktanteil gewinnen dürften.