5. JavaBeans - Komponentenbasierte Softwareentwicklung

5.1 Motivation zur komponentenbasierten Softwareentwicklung

• Reduzierung der Komplexität bei der Softwareentwicklung (große Projekte können in Teilprobleme aufgeteilt werden)
• Schnellere Entwicklung (Termineinhaltung; schnell am Markt sein; "Time to Market"-Problem)
• Wiederverwendung von vorhandenem Code (auf bereits vorhandenes Know-How zurückgreifen; Verringerung der Fehlerträchtigkeit)
• Unabhängigkeit von Hardware und Betriebssystem
• Erweiterung bereits bestehender Softwaresysteme durch neue Komponenten

5.2 Einführung in die lokale Komponentenarchitektur

5.2.1 Das Objektmodell

• Trennung von Schnittstellendefinition und Klassenimplementierung: Dadurch wird der Zustand von Objekten gekapselt und läßt sich nur über Elementfunktionen ändern. Für den Entwickler wird hierdurch eine höhere Transparenz erzeugt.
• Versionierungsmechanismus (Anpassbarkeit von Objekten): Neuere Versionen von Objekten müssen alte ablösen können, d.h. sie müssen aber auch die alte Funktionen nach wie vor bereitstellen.
• Wiederverwendbarkeit bestehender Klassen: Dies soll durch Vererbung oder durch einen Mechanismus zur Einbettung oder Erweiterung vorhandener Klassen erfolgen.
• Binäre Klassenbibliotheken müssen sich dynamisch (zur Laufzeit des Programms) einbinden lassen.

5.2.2 Aufbau einer lokalen komponentenbasierten Anwendung

Die Containeranwendung besteht aus einem Anwendungsgerüst und aus mehreren binären Softwarekomponenten, denen spezielle Aufgabe zukommen. Bei diesen Komponenten handelt es sich um Softwarebausteine, die als solche in mehrere Anwendungen eingebunden werden können. Eine Komponente könnte ein z.B. Listenfeld sein, das in einer Anwendung eingesetzt wird. Aber auch eine komplexe Tabellenkalkulation kann einen Baustein einer noch komplexeren Anwendung darstellen. Zur Regelung der Kommunikation zwischen den einzelnen Komponenten wird eine Componentware-Infrastruktur benötigt. Hier verwendet man meist ORB-basierte Ansätze (ORB = Objekt Request Broker). Ein ORB ist ein Softwarebus, der die Kommunikation zwischen Objekten regelt.
 
Man darf diese Aufteilung jedoch nicht als starre Funktionszuordnung betrachten, die eine Komponente erhält, sondere eher als wechselnde Rolle, die ein Softwarebaustein einnehmen kann. So ist es durchaus möglich bzw. beabsichtigt, daß eine Komponente im einen Fall als Container eingesetzt wird und in einem anderen Fall nur als Komponente.

5.2.3 Anforderungen an das Komponentenmodell

• Das Komponentenmodell muß festlegen, wie auf eine Komponente und ihre Funktionalität zugegriffen werden kann. Dies erfolgt über spezielle Ein- und Ausgangsschnittstellen. Die Eingangsschnittstelle stellt Methoden bereit, mit denen der Zustand eines Objekts (seine Attribute) verändert werden kann und mit denen das Objekt zur Ausführung spezieller Funktionen veranlaßt wird. Über die Augangsschnittstelle kommuniziert das Objekt mit anderen Komponenten und gibt Werte zurück.
• Damit der Zustand einer Komponente persistent gemacht werden kann, wird ein Mechanismus zur Speicherung benötigt.
• Um sich an das Bildschirmlayout einer Anwendung anpassen zu können, ist ein Mechanismus erforderlich mit Hilfe dessen sich Komponenten innerhalb eines Containers an dessen Layout automatisch anpassen können.
• Komponenten benötigen "Stellschrauben" in Form von Attributen, mit denen der Softwareentwickler Anpassungen vornehmen kann.
• Das Komponentenmodell muß von Softwareentwicklungsumgebungen unterstützt werden. Dadurch soll es möglich werden die Attribute und Methoden innerhalb einer Programmierumgebung abrufbar zu machen bzw. diese zu visualisieren (z.B. mit Hilfe eines Class-Viewers).
• Durch dynamisches Binden sollen Komponenten zur Laufzeit in den Adreßraum eines Containers eingebunden werden können. Dies hat vor allem sehr positive Auswirkungen auf die Performanz einer Anwendung.

5.2.4 Verteilte Komponentenarchitektur

Die Verwendung  entfernter Objekte oder Komponenten macht es erforderlich, daß man Zugriff auf den Adreßraum eines entfernten Rechners hat. Zu diesem Zweck erhält eine lokale Komponente eine Referenz auf ein entferntes Objekt auf einem anderen Rechner. Da es nicht ohne weiteres möglich ist auf den Adreßraum eines anderen Rechners zuzugreifen, arbeitet man mit einer Kopie des Adreßraum an einer bestimmten Adresse. Mit Hilfe von sogenannten Factory-Objekten kann man auch Objekte auf fremden Rechnern erzeugen.

Derzeit sind solche verteilten Komponentenarchitekturen ein sehr aktuelles Thema. CORBA hat sich in diesem Bereich schon sehr behauptet, steht jedoch anderen Komponentenarchitekturen gegenüber. In Abschnitt 5.4 wird nochmals darauf eingegangen.

5.3 JavaBeans - Das Komponentenmodell für Java

http://www.javasoft.com/beans/
http://www.javasoft.com/beans/docs/spec.html

5.3.1 Das Konzept von JavaBeans

Beans arbeiten innerhalb eines Containers (z.B. Webbrowser, Bean-Box, über ActiveX-Bridge auch in ActiveX-Container), können aber auch selbst die Rolle des Containers einnehmen. Normalerweise sind Beans relativ komplexe Elemente einer grafischen Oberfläche, wie z.B. eine Kalkulationstabelle oder ein Kalender-Steuerelement. Entwickler, die Erfahrung mit OLE(OCX)- und VBX-Komponenten haben, werden erkennen, daß hier erhebliche Ähnlichkeiten zu JavaBeans bestehen.

Da die Ereignisse und Eigenschaften von JavaBeans die zwei wesentlichen Bestandteile diese Konzepts sind, sollen diese anschließend genauer dargestellt werden.

5.3.2 Eigenschaften

Einfache Eigenschaften

Einfache Eigenschaften repräsentieren einen einzigen Wert Auch werden hier nur die einfachen Datentypen von Java verwendet. Diese sind z.B. int, float, Boolean, ...

Beispiel:

public class SimpleBean extends Canvas {

// Einfache Eigenschaft
string Farbe = "Blau";

// Zugriff auf die Eigenschaft
public void setzeFarbe(string neueFarbe) {
    Farbe = neueFarbe;
}

public String gibFarbe () {
    return Farbe;
}

Indizierte Eigenschaften

Indizierte Eigenschaften ermöglichen die Verwendung von Arrays als Eigenschaft eines Beans. Somit können mehrere Werte in einer Eigenschaft zusammengefaßt werden. Der Zugriff auf die einzelnen Komponenten erfolgt über einen Index (Integer). Ein Beispiel für eine solche Menge sei z.B. eine Menge von Farben, die ein Button haben kann.

Beispiel:

public class SimpleBean extends Canvas {

// Indizierte Eigenschaft
int[] Index = {1,2,3,4,5,6,7,8,9,0};

// Zugriff auf die Eigenschaft
// 1. Das ganze Feld setzen
public void GanzesFeldSetzen(int[] x) {
    Index = x;
}

// Auf ein Element zugreifen
public void SetzeWert (int postition, int wert) {
    Index[position] = wert;
}

// Ganzes Feld zurückgeben
public int[] GanzesFeld() {
    return Index;
}

// Auf ein Element zugreifen
public int GibWert (int postition) {
    return Index[position];
}

Gebundene Eigenschaften

Gebundene Eigenschaften dienen zur Benachrichtigung über Zustandsänderungen eines Beans. Sie bieten die Möglichkeit zur Information anderer Objekte, falls sich der Wert einer Eigenschaft ändert. In diesem Fall wird ein spezielles Ereignis ausgelöst (siehe 3.3), auf das der Empfänger dann reagieren kann.

Beispiel:

public class Sender extends Canvas {

string Farbe = "Blau";
// Deklarieren und Instanziieren eines "Property Change"-Objekts
private PropertyChangeSupport Aenderung =
    new PropertyCangeSupport(this);

// Ändern der Farbe
public void setzeFarbe(string neueFarbe) {
    string alteFarbe = Farbe;
    Farbe = neueFarbe;
    // Ereignis bei Änderung auslösen
    Aenderung.firePropertyChange("string", alteFarbe, neueFarbe);
}

// ...

Zwingende Eigenschaften

Diese Eigenschaften erlauben die Validierung einer durchzuführenden Änderung durch ein anderes Objekt bzw. eine andere Komponente. Sie lassen sich auch mit gebundenen Eigenschaften kombinieren, wobei dies nur sinnvoll ist, wenn man die zwingende Eigenschaft der gebundenen voranstellt. Im Falle einer fehlgeschlagenen Validierung wird die gebundene Eigenschaft dann nicht mehr berücksichtigt.

5.3.3 Ereignisse

Ein Ereignis geht immer von einer Ereignisquelle aus und wird an einen Ereignisempfänger weitergeleitet. Dieser muß dann eine entsprechende Ereignismethode zur Verfügung stellen. Ereignisquellen haben eine Liste von Ereignisempfängern. In der Liste müssen sich die Empfänger registrieren , indem sie eine Referenz auf ihre Ereignisbehandlungsmethode übergeben. Somit wissen die Quellen, wen sie benachrichtigen sollen.

Neben diesen mehrfachen möglichen Empfängern (Multicast), ermöglicht es das Ereignismodell auch nur genau einen (bestimmten) Empfänger zuzulassen (Unicast-Ereignis). Zur Vermeidung von Deadlocks innerhalb eines Multithreading-Systems stellt JavaBeans einen Synchronisationsmechnismus bereit.

5.3.4 Enterprise JavaBeans

•  JDBC-API: Zugriff auf relationale Datenbanken.
• Remote Method Invocation (RMI): Ein RPC-Mechanismus für Java, der die Kommunikation über unterschiedliche Adreßräume hinweg erlaubt. Leider ist jedoch keine programmiersprachenneutrale Schnittstellensprache vorgesehen. Die Enterprise JavaBeans werden somit zu einer reinen Java-Lösung.
• Verwendung des Java Remote Method Protocol (JRMP) zur Kommunikation zwischen den Softwarekomponenten. In Zukunft ist die Verwendung des von der OMG spezifizierten IIOP geplant.

5.4 JavaBeans im Vergleich zu CORBA und ActiveX/DCOM

5.4.1 CORBA und ActiveX

CORBA

Folgendes Beispiel soll diese Vorgehensweise unter Verwendung der CORBA-Plattform ILU verdeutlichen:

IDL-Schnittstelle:

module Test {

interface Taschenrechner {
    // gibt das Ergebnis zurück
    double GibWert ();
};

Mit dem IDL-Compiler erzeugte Java-Schnittstelle:

public class Taschenrechner implements stubs.Test.Taschenrechner {
    // ..
    public double GibWert() {
        return aktuellerWert;
    }
    //..
}
 

Entsprechend kann auch eine C++-Schnittstelle erzeugt werden:

class Test_T_Taschenrechner : public virtual iluObject {

 public:

  Test_T_Taschenrechner();   // constructor
  virtual ~Test_T_Taschenrechner();  // destructor
//..
  virtual double GibWert (TestStatus *_status);
//..
};
 

CORBA ermöglicht eine Kommunikation über verschiedenen Adreßräume hinweg. Ein Softwarebus (ORB) regelt die Verwaltung von Objekten und Methoden der unterschiedlichen Softwarekomponenten. Der Entwickler muß sich also nicht mit technischen oder kommunikationsspezifischen Fragestellungen auseinandersetzen.
 

ActiveX/DCOM

Das zugehörige Komponetenmodell für ActiveX ist COM (Component Object Model) bzw. DCOM (Distributed Component Object Model). Beides sind ORB-basierte Komponentenmodelle. Während COM nur einen Object Request Broker für einen einzelnen Rechner zur Verfügung stellt, soll DCOM die netzwerkweite Kommunikation zwischen Softwarekomponeten ermöglichen.

Seit September 1996 ist DCOM Bestandteil von WindowsNT (Version 4.0) und seit Anfang 1997 ist es auch Bestandteil des Betriebssystems Windows 95. Dadurch hat DCOM natürlich schon weite Verbreitung gefunden. Die Implementierung von DCOM-Komponenten ist in verschiedenen Programmiersprachen möglich, auch in relativ "einfachen" und in der Praxis sehr verbreiteten Sprachen, wie Visual Basic.

Microsoft möchte mit dieser Komponentenarchitektur wieder einen eigenen Standard durchsetzen, an den sich schließlich alle anderen wieder mit ihren Konzepten anpassen müssen. So ist DCOM nicht CORBA-konform und auch JavaBeans muß sich noch gegen ActiveX behaupten. Abschließend wird nun ein Vergleich zwischen JavaBeans, CORBA und ActiveX vorgenommen.

5.4.2 Die drei Komponentenplattformen im Vergleich

Plattformunabhängigkeit

Verbreitung

Programmiersprachen

Sicherheit

Geschwindigkeit