Sie sind hier: Home>Programmiersprachen>Java

 

 

JavaBeans

Schon seit geraumer Zeit verfolgt die Gemeinde der Software-Entwicklung verstärkt den Gedanken wiederverwendbarer Komponenten. Eine Komponente - im allgemeinen Sinn, nicht im Sinne des AWT - ist ein wiederverwendbares Software-Teil, das leicht zur Erstellung von Anwendungen verwendet werden kann, und zwar mit weitaus größerer Entwicklungseffizienz. Dieser Gedanke der Wiederverwendung sorgfältig zusammengestellter Software wurde zu einem gewissen Maße dem Verfahren des Montagebandes entliehen, das während der industriellen Revolution in den Vereinigten Staaten, lange vor der Ära moderner Computer, so populär wurde. Auf Software angewandt bedeutet das, einmalig zu Beginn kleine, wiederverwendbare Komponenten zu bauen und sie dann in höchstmöglichem Maße wiederzuverwenden und damit den gesamten Entwicklungsprozeß zu rationalisieren.

Eine Software-Komponente ist ein Stück Software, das in eine diskrete, leicht wiederverwendbare Struktur gekapselt ist.

Obwohl Komponenten-Software ihre Vorteile bietet, muß sich die vollständig wiederverwendbare Software erst noch richtig etablieren. Dies aus einer Vielzahl von Gründen, nicht zuletzt der Tatsache, daß die Software-Industrie im Vergleich zu den Industrien, die sich während der industriellen Revolution etabliert haben, noch sehr jung ist. Es leuchtet ein, daß es einige Zeit dauert, die schwachen Punkte im gesamten Software-Produktionsprozeß auszumerzen. (Wenn Sie meine Einstellung teilen, nehmen Sie die rapiden, in der Welt der Software stattfindenden Veränderungen bereitwillig an und genießen die Tatsache, daß Sie ein Teil von so etwas ähnlichem wie einer Revolution sind - eine Informationsrevolution. Aber ich schweife ab!)

Das vielleicht größte Problem, dem sich Komponenten-Software stellen mußte, ist der große Bereich ungleichartiger Mikroprozessoren und heute eingesetzter Betriebssysteme. Es gab eine Reihe angemessener Versuche in der Komponenten-Software, die aber immer auf ein spezifisches Betriebssystem limitiert waren. Die VBX- und OCX- Komponentenarchitekturen von Microsoft verzeichneten große Erfolge in der Welt des PC, konnten aber wenig zum Schließen der Lücke zwischen anderen Betriebssystemtypen beitragen. Wirft man das Arbeitsvolumen in die Waagschale, das dazu benötigt wird, um eine inhärente, plattformabhängige Komponententechnologie auf einer Vielzahl von Betriebssystemen zum Laufen zu bringen, macht die ausschließliche Fokussierung auf den PC-Markt von Microsoft Sinn.

Tatsächlich zielt die auf ihrer OCX-Technologie basierte ActiveX-Technologie von Microsoft darauf ab, eine universelle Komponententechnologie bereitzustellen, die Kompatibilität für einen breiten Bereich von Plattformen bietet. Betrachtet man allerdings die Abhängigkeit des ActiveX von dem 32-Bit-Windows-Code, bleibt abzuwarten, wie Microsoft das Problem der Plattformabhängigkeit lösen wird. Vielleicht wartet man nur darauf, daß alle zu Windows 95/NT wechseln?

Bevor es zur der explosionsartigen Entwicklung im Internet-Bereich kam, stellte die Plattformabhängigkeit nicht so ein großes Problem dar. PC-Entwickler machten sich nicht unbedingt allzu viele Gedanken darüber, daß ihre Produkte nicht auf einem Solaris-System laufen konnten. Okay, einige PC-Entwickler gingen auf Nummer sicher und sorgten für Anschluß Ihrer Anwendungen an die Macintosh-Plattform, allerdings oftmals unter beträchtlichem Entwicklungsaufwand. Das gesamte Szenario änderte sich durch den vom Internet erzeugten Schmelztiegel der Betriebssysteme. Daraus resultierte ein erneutes Interesse, Software zu entwickeln, die von jedermann, unabhängig vom benutzten Betriebssystem, benutzt werden kann. Java trug in großem Maße dazu bei, echt plattformunabhängige Software-Entwicklung Wirklichkeit werden zu lassen. Allerdings hatte Java bis vor kurzem keine Antwort auf das Problem der Komponenten-Software - dazu kommen wir gleich.

Als ob das Problem der Plattformabhängigkeit noch nicht genug ist, leiden einige verfügbare Komponententechnologien darunter, in einer spezifischen Programmiersprache oder für eine spezielle Umgebung entwickelt werden zu müssen. So wie die Plattformabhängigkeit Komponenten zur Laufzeit verkrüppelt, führt Limitierung der Komponentenentwicklung auf eine spezifische Programmiersprache oder Entwicklungsumgebung gleichermaßen zur Verkrüpplung der Komponenten im Entwicklungsbereich. Software-Entwickler würden lieber selbst entscheiden, welche Sprache für eine bestimmte Aufgabe und welche Entwicklungsumgebung die am besten geeignete ist, als gezwungen zu sein, eine den Einschränkungen einer Komponententechnologie unterliegende zu verwenden. Demnach muß sich jede realistische, auf lange Sicht ausgerichtete Komponententechnologie dem Problem der Plattform- und Sprachabhängigkeit stellen. Und das bringt mich zu unserem Thema: JavaBeans. Die JavaBeans- Technologie von JavaSoft ist eine Komponententechnologie, die direkte Antworten auf beide Probleme bietet. Die JavaBeans-Technologie verspricht das Paradigma der Zusammenfügung von Komponenten-Software auf eine neue Ebene zu heben. Im Augenblick befindet sich die JavaBeans-Spezifikation in der Entwicklung und die vorläufige Freigabe soll im Anschluß daran erfolgen.

JavaBeans wird als architektur- und plattformunabhängiges API zur Erstellung und Verwendung dynamischer Java-Software-Komponenten realisiert. JavaBeans setzt an dem Punkt an, wo andere Komponententechnologien aufgehört haben, und verwendet die portable Java-Plattform als Basis zur Bereitstellung einer kompletten Lösung für Komponenten-Software, die in der Welt des Online ohne weiteres anwendbar ist.

 

Das Ziel von JavaBeans

Nach dem schnellen Erfolg des Laufzeitsystems und der Programmiersprache von Java,, war JavaSoft die Bedeutung der Entwicklung einer kompletten Lösung für die Komponententechnologie klar. Man antwortete mit der JavaBeans-Technologie, deren Designziele in folgender Spezifikationsliste zusammengefaßt werden können:

  • Kompakt, leicht zu erstellen und zu benutzen
  • Völlig portabel
  • Basiert auf der inhärenten Stärke von Java
  • Robuster, verteilter Rechenmechanismus
  • Unterstützung für flexible Entwicklungszeit der Komponenteneditoren

Die erste Anforderung von JavaBeans - so kompakt zu sein - beruht auf der Tatsache, daß die JavaBeans-Komponenten häufig in verteilten Umgebungen verwendet werden, in denen komplette Komponenten eventuell über eine Internet-Verbindung mit geringer Bandbreite übertragen werden. Genauer gesagt müssen Komponenten so kompakt wie möglich sein, um eine angemessene Übertragungszeit zu ermöglichen. Der zweite Teil dieses Designziels bezieht sich auf die Leichtigkeit, mit der diese Komponenten erstellt und verwendet werden. Leicht verwendbare Komponenten kann man sich relativ leicht vorstellen, aber die Erzeugung einer Komponentenarchitektur, die das Erstellen von Komponenten leicht gestaltet, ist eine völlig andere Sache. Versuche auf der Ebene der Komponenten-Software werden dem Entwickler oftmals durch komplexes Programmieren von APIs erschwert. JavaBeans-Komponenten müssen also nicht nur leicht zu verwenden, sondern auch leicht zu entwickeln sein. Dies stellt für Sie und mich eine wesentliche Anforderung dar, da sie weniger Kopfschmerzen bereitet und uns mehr Zeit gibt, die Komponenten mit blumigen Eigenschaften auszuschmücken.

JavaBeans-Komponenten basieren größtenteils auf der bereits in der traditionellen Applet-Programmierung von Java verwendeten Klassenstruktur, was wiederum für diejenigen von uns, die viel Zeit und Energie darauf aufwenden, Java zu erlernen, einen enormen Vorteil bietet. JavaSoft hat versprochen, daß die rund um das AWT-Paket entworfenen Java-Applets sich leicht in neue JavaBeans-Komponenten verwandeln lassen. Auch dies leistet den positiven Nebeneffekt der ausgesprochenen Kompaktheit von JavaBeans-Komponenten, da Java-Applets hinsichtlich der Größe bereits sehr leistungsfähig sind.

Das zweite Hauptziel von JavaBeans ist vollständige Portabilität; darüber haben wir zu Beginn dieser Lektion gesprochen. Als Folge davon brauchen sich Entwickler keine Gedanken um die Einbeziehung plattformspezifischer Bibliotheken bei Ihren Java-Applets zu machen. Das Ergebnis sind wiederverwendbare Komponenten, die die Computerwelt glücklich und friedlich unter einem Dach vereinigen. (Okay, vielleicht ist das etwas zu viel verlangt - ich begnüge mich schon mit der Entwicklung einer Komponente, die ohne Anbringen von Modifizierungen auf einem Java-unterstützten System läuft.)

Die bestehende Java-Architektur bietet bereits eine große Anzahl von Vorteilen, die leicht auf Komponenten anwendbar ist. Eine der wesentlicheren Eigenschaften von Java ist ihr eingebauter Klassenerkennungsmechanismus, der dynamische Interaktionen zwischen Objekten ermöglicht. Daraus entsteht ein System, in dem sich Objekte unabhängig von ihrem Ursprung oder ihrer Entwicklungsgeschichte ineinander einbauen lassen. Dieser Mechanismus zur Klassenauffindung stellt nicht nur eine nette Eigenschaft von Java dar, sondern ist in jeder Komponentenarchitektur eine notwendige Voraussetzung und für JavaBeans ein Glücksfall, daß diese Funktionalität von Java bereits kostenlos geboten wird. Andere Komponentenarchitekturen mußten vertrackte Registriermechanismen implementieren, um zu dem gleichen Ergebnis zu kommen.

Darüber hinaus erhält JavaBeans aus der bestehenden Java-Funktionalität noch die Persistenz, d.h. die Fähigkeit eines Objektes, seinen internen Status zu speichern und wieder zu laden. Diese Persistenz erfolgt in JavaBeans automatisch einfach durch die Verwendung des in Java bereits vorhandenen Serialisations-Mechanismus. Falls erforderlich, können Entwickler alternativ speziell angepaßte Persistenz-Lösungen erstellen.

Persistenz ist die Fähigkeit eines Objektes, seinen internen Status zu speichern und wieder zu laden. Serialisation ist das Verfahren, Informationen über ein Standardprotokoll zu speichern oder zu laden.

Obwohl kein Schlüsselelement der JavaBeans-Architektur, stellt die Unterstützung für verteiltes Rechnen bei JavaBeans dennoch ein Hauptthema dar. Da verteiltes Rechnen, als ein Ergebnis der komplexen Natur der verteilten Systeme, relativ komplexe Lösungen erforderlich macht, hebt JavaBeans die Verwendung von externen verteilten, auf Bedarf basierten Methoden an. Anders ausgedrückt ermöglichen JavaBeans Entwicklern die Verwendung verteilter Rechenmechanismen, wann immer erforderlich, überladen sich aber auch nicht mit entsprechender Unterstützung für verteiltes Rechnen. Man könnte jetzt die JavaBeans-Architekten für faul halten, Tatsache ist aber, daß genau in diesem Designansatz der Schlüssel für die Kompaktheit der JavaBeans-Komponenten liegt, da verteilte Rechenlösungen unvermeidlich zu höherer Systemverwaltungszeit führen.

Entwickler von JavaBeans-Komponenten haben die Möglichkeit, die für ihre Bedürfnisse am besten geeignete Methode auszuwählen. Mit seiner Technologie der Remote Method Invocation (RMI, Methoden-Fernaufruf) bietet JavaSoft eine verteilte Rechenlösung, die aber den JavaBeans-Entwicklern keinesfalls die Hände bindet. Unter anderem beinhalten andere Lösungsmöglichkeiten CORBA (Common Object Request Broker Architecture) und von Microsoft DCOM (Distributed Component Object Model). Der Punkt ist, daß verteiltes Rechnen säuberlich von JavaBeans abgetrennt wurde, um die Struktur straff zu halten und gleichzeitig Entwicklern, die die entsprechende Unterstützung benötigen, einen breiten Bereich an Optionen zu bieten. Das letzte Designziel von JavaBeans behandelt Probleme der Entwurfszeit und die Art und Weise, wie Entwickler Anwendungen unter Verwendung von JavaBeans-Komponenten erstellen. Die Architektur von JavaBeans umfaßt Unterstützung für die Spezifizierung von Eigenschaften der Entwurfszeit und Bearbeitungsmechanismen zur weiteren Erleichterung visueller Bearbeitung von JavaBeans-Komponenten. Das hat zur Folge, daß Entwickler visuelle Werkzeuge zum nahtlosen Zusammenfügen und Modifizieren von JavaBeans-Komponenten einsetzen können, ganz ähnlich der Weise, in der bestehende visuelle PC-Werkzeuge mit Komponenten wie VBX- oder OCX-Steuerungen arbeiten. Komponentenentwickler spezifizieren so die Art und Weise, in der die Komponenten in einer Entwicklungsumgebung zu verwenden und zu manipulieren sind. Allein diese Eigenschaft wird offiziell die Verwendung von professionellen visuellen Editoren einleiten und der Produktivität von Anwendungsentwicklern in bedeutender Weise Auftrieb verleihen.

 

Wie JavaBeans in Beziehung zu Java steht

Für viele Entwickler, die nicht ganz mit dem Gedanken von Software-Komponenten vertraut sind, wird die Beziehung zwischen JavaBeans und Java etwas verwirrend sein. Wurde für Java nicht als eine objektorientierte Technologie mit der Fähigkeit, wiederverwendbare Objekte zu bedienen, die Werbetrommel gerührt? Ja und Nein. Ja, Java bietet eine Möglichkeit der Erstellung wiederverwendbarer Objekte, allerdings gibt es einige Regeln oder Standards, die für die Art und Weise, wie Objekte miteinander interagieren, maßgeblich sind. Durch Spezifizieren umfangreicher Gruppen von Mechanismen für die Interaktion zwischen Objekten, zusammen mit allgemeinen, von den meisten Objekten zu unterstützende Aktionen wie Persistenz- und Ereignisbehandlung, baut JavaBeans auf dem bestehenden Design von Java auf.

Das aktuelle Java-Komponentenmodell ist, obgleich es nicht schlecht ist, relativ limitiert, wenn es darum geht, echte Wiederverwendung und Interoperabilität zu liefern. Auf der Objektebene gibt es definitiv keinen einfachen Mechanismus zur Erstellung wiederverwendbarer Java-Objekte, die mit anderen Objekten dynamisch in konsequenter Weise in Wechselwirkung treten können. Was Sie dem am nächsten kommend in Java durchführen können, ist, Applets zu erstellen und zu versuchen, diese auf einer Webseite miteinander kommunizieren zu lassen, was nicht gerade eine leichte Aufgabe ist. JavaBeans stellt den Rahmen, in dem diese Kommunikation stattfinden kann, mit Leichtigkeit zur Verfügung. Noch wichtiger ist die Tatsache, daß JavaBeans- Komponenten leicht über eine Standardgruppe von gut definierten Eigenschaften getriggert werden können. JavaBeans vereinigt die Leistungsstärke eines voll ausgereiften Java-Applet mit der Kompaktheit und Wiederverwendbarkeit von Java-AWT- Komponenten, wie beispielsweise Schaltflächen.

JavaBeans-Komponenten sind jedoch nicht auf visuelle Objekte wie Schaltflächen beschränkt. Sie können genauso einfach nicht visuelle JavaBeans-Komponenten entwikkeln, die zusammen mit anderen Komponenten einige Hintergrundfunktionen ausüben. Auf diese Weise vereinigt JavaBeans die Leistungsstärke visueller Java-Applets mit nicht visuellen Java-Anwendungen unter dem festen Dach eines Komponentengerüsts.

Eine nicht visuelle Komponente ist jede Komponente, deren Ausgabe nicht sichtbar ist. Wenn man sich eine Komponente im Hinblick auf AWT- Objekte wie Schaltflächen und Menüs betrachtet, mag das ein wenig fremd erscheinen. Vergessen Sie dabei aber nicht, daß eine Komponente einfach ein dicht gepacktes Programm ist und nicht unbedingt visuell sein muß. Ein gutes Beispiel für eine nicht visuelle Komponente ist eine Timer-Komponente, die in bestimmten Abständen Ereignisse sendet. Timer-Komponenten sind in anderen Entwicklungsumgebungen von Komponenten wie Microsoft Visual Basic sehr populär.

Sie können eine Vielzahl von JavaBeans-Komponenten gemeinsam benutzen, ohne daß Sie unter Verwendung visueller Werkzeuge einen Code schreiben müssen. Diese Möglichkeit der gleichzeitigen Benutzung einer Vielzahl von Komponenten, deren Ursprung dabei unwichtig ist, stellt eine Verbesserung des aktuellen Java-Modells dar. Sicherlich können Sie andere, in Java bereits integrierte Objekte benutzen, müssen aber über ausführliches Wissen, die Schnittstelle des Objektes betreffend, verfügen. Darüber hinaus müssen Sie das Objekt programmatisch in Ihren Code integrieren. JavaBeans-Komponenten legen ihre eigenen Schnittstellen visuell dar und stellen somit ein Mittel zur Bearbeitung ihrer Eigenschaften ohne Programmierung bereit. Des weiteren können Sie mit der Verwendung eines visuellen Editors eine JavaBeans-Komponente einfach in eine Anwendung einfügen, ohne daß Sie eine einzige Zeile Code schreiben müssen. Hier sehen wir eine vollständig neue Ebene der Flexibilität und Wiederverwendung, die mit Java allein bisher nicht möglich war.

 

Das JavaBeans-API

Okay, genug gesagt über JavaBeans und darüber, was es kann und warum es »cool« ist. Konzentrieren wir uns jetzt auf einige Einzelheiten, um festzustellen, wie das alles möglich ist. Behalten Sie dabei im Auge, daß JavaBeans letztendlich eine Programmierschnittstelle ist, was bedeutet, daß all seine Eigenschaften als Erweiterungen der Standard-Klassenbibliothek von Java realisiert werden. Somit wird die gesamte, von JavaBeans zur Verfügung gestellte Funktionalität tatsächlich in dem JavaBeans-API realisiert. Das JavaBeans-API selbst ist eine Reihe von kleineren APIs, die spezifischen Funktionen oder Services gewidmet sind. Die nachfolgende Liste zeigt wesentliche Komponentenservices in dem JavaBeans-API, die zur Erleichterung all der Eigenschaften, die Sie heute gelernt haben, notwendig sind:

  • Vereinigung der grafischen Benutzeroberfläche
  • Persistenz
  • Ereignisbehandlung
  • Introspektion
  • Application Builder Support

Durch entsprechendes Verständnis dieser Services und wie sie arbeiten, bekommen Sie einen größeren Einblick in die Technologie von JavaBeans. Jeder dieser Services wird in Form von kleineren, in dem größeren API enthaltenen APIs realisiert. In den nächsten Abschnitten widmen wir uns jedem dieser APIs und erklären, warum sie notwendige Elemente der JavaBeans-Architektur darstellen.

Die die grafische Benutzeroberfläche vereinigenden APIs bieten einer Komponente ein Werkzeug zur Vereinigung ihrer Elemente der grafischen Benutzeroberfläche mit dem Container-Dokument, das normalerweise nur die die Komponente beinhaltende Webseite ist. Die meisten Container-Dokumente haben Menüs und Werkzeugleisten, die zur Anzeige der speziellen, von dieser Komponenten bereitgestellten Eigenschaften dienen. Die die grafische Benutzeroberfläche vereinigenden APIs ermöglichen der Komponente, dem Menü und der Werkzeugleiste des Container-Dokuments Eigenschaften hinzuzufügen. Diese APIs definieren auch den Mechanismus, der Raumverhandlungen zwischen den Komponenten und ihren Containern ermöglicht. Anders gesagt, die die grafische Benutzeroberfläche vereinigenden APIs sind auch für die Definition der Layout-Eigenschaften von Komponenten zuständig.

Ein Container-Dokument ist ein JavaBeans-Komponenten enthaltendes Dokument (normalerweise HTML), das als Eltern für alle in ihm enthaltenen Komponenten dient. Neben anderen Dingen sind Container-Dokumente normalerweise für die Verwaltung des Hauptmenüs und der Werkzeugleiste zuständig.

Die Persistenz-APIs spezifizieren den Mechanismus, mit dem Komponenten innerhalb des Kontexts eines Container-Dokumentes gespeichert und geladen werden können. Komponenten erben per Voreinstellung den automatischen, von Java bereitgestellten Serialisations-Mechanismus. Entwickler haben ebenfalls die Freiheit, auf den speziellen Erfordernissen ihrer Komponenten basierende, besser ausgearbeitete Persistenz- Lösungen zu entwerfen.

Die APIs zur Ereignisbehandlung spezifizieren eine ereignisgesteuerte Architektur, die die Wechselwirkung der Komponenten miteinander definiert. Das Java-AWT beinhaltet bereits ein leistungsstarkes Ereignisbehandlungsmodell, das als Grundlage für die Komponenten-APIs zur Ereignisbehandlung dient. Diese APIs sind wesentlich, wenn es darum geht, den Komponenten die Freiheit zu gewähren, in konsequenter Weise miteinander zu interagieren.

Die Introspektions-APIs definieren Techniken, die Komponenten dazu veranlassen, ihre interne Struktur zur Entwurfszeit direkt zur Verfügung zu stellen. Diese APIs enthalten die notwendige Funktionalität, es Entwicklungstools zu ermöglichen, eine Komponente nach ihrem internen Status abzufragen, einschließlich der Schnittstellen, Methoden und Member-Variablen, aus denen die Komponente besteht. Die APIs sind, basierend auf der Ebene, auf der sie benutzt werden, in zwei getrennte Abschnitte unterteilt. Die Introspektions-APIs der unteren Ebene ermöglichen beispielsweise Entwicklungswerkzeugen direkten Zugriff auf die Komponenteneigenschaften, also eine Funktion, die Sie nicht unbedingt in den Händen von Komponentenbenutzern sehen wollen. APIs der höheren Ebene verwenden APIs der unteren Ebene zur Bestimmung der Teile einer Komponente, die zur Änderung durch den Benutzer exportiert werden . Das heißt, obwohl Entwicklungswerkzeuge zweifellos Gebrauch von beiden Arten von APIs machen, werden sie die APIs der höheren Ebene nur dann verwenden, wenn sie dem Benutzer Komponenteninformationen bereitstellen.

Application Builder Support APIs stellen die bei Entwurfszeit für Bearbeitung und Manipulation der Komponenten erforderliche Systemverwaltungszeit bereit. Diese APIs werden größtenteils von visuellen Entwicklungswerkzeugen eingesetzt, um die Möglichkeit eines visuellen Layouts und Bearbeitung von Komponenten während der Erstellung einer Anwendung zu bieten. Der Teil einer Komponente, der die visuellen Bearbeitungsmöglichkeiten bereitstellt, wurde speziell so entworfen, daß er physisch von der Komponente selbst getrennt ist und somit dazu beiträgt, autonome Laufzeitkomponenten so kompakt wie möglich zu gestalten. In einer reinen Laufzeitumgebung werden Komponenten nur mit der erforderlichen Laufzeitkomponente übertragen. Entwickler, die sich der Vorteile von Entwurfszeitkomponenten bedienen wollen, können leicht den Entwurfszeitteil der Komponente erlangen.

 

Sie sind hier: Home>Programmiersprachen>Java