JavaBeans sind ein Komponentenmodell basierend auf der Programmiersprache Java. Ihr Ziel ist es, die Zusammenstellung von Komponenten für ein komplettes Programm mit minimalem Aufwand über grafische Oberflächen zu ermöglichen. Auch einzelne Beans lassen sich als Applets z.B. auf Webseiten einbauen. In Builder Tools können JavaBeans per Mausklick zusammengefügt werden. Prinzipiell ist jede Bean eine Java-Klasse, die auf Konfiguration und Anpassbarkeit modifiziert wurde. JavaBeans legen für die nachträgliche Anpassbarkeit ihre Eigenschaften, Methoden und Ereignisse in einem Builder offen und sind somit introspektiv.
In ihnen sind indizierte (Eigenschaften können mehrere Werte annehmen), gebundene (teilen anderen Beans Änderungen mit) und Eigenschaften mit Nebenbedingungen (andere Beans können vor einer Änderung ein Veto einlegen) implementiert.
Verbunden werden sie lose durch Ereignisse mittels get( ) und set( ) Methoden, eine JavaBean kann so ihre Dienste anderen Javabeans anbieten und wiederum andere Dienste beanspruchen, indem sie sich als Empfänger bzw. Abhörer bei der entsprechenden Bean anmeldet. Diese lose Kopplung macht JavaBeans sehr flexibel einsetzbar.¹²³
JavaBeans benötigen dabei immer einen Container, also eine Laufzeitumgebung, in dem sie eingebettet werden können.¹²⁴
Für die Entwicklung von JavaBeans hat Sun Spezifikationen herausgegeben, um die Einhaltung des Standards sicher zu stellen.

Bewertung der JavaBeans125

Vorteile

Nachteile

Architektur- und Plattformunabhängigkeit ''Write Once Run Anywhere'' Nicht typgebunden Strukturierte Anwendungsentwicklung Einfache Erstellung, da Java Starke Unterstützung von Seiten der Industrie (Apple, Borland, IBM, JustSystem, Microsoft, Netscape, Rogue Wave, SunSoft and Symantec etc.) Großes Anwendungsspektrum (komplexe traditionelle Anwendungen bis hin zur Integration einzelner Beans) Einfache und vor allem schnelle Erweiterung bestehender Programme Portierbarkeit Schnelle Anpassbarkeit Nutzung der vielen Java-Sicherheitsmaßnahmen Spätes Binden als Teil der Java Sprache verwirklicht Graphische Verbindung von Komponenten bereits im Sprachumfang de facto normiert.

Langsame Ausführung, da sie auf der Java Virtual Machine erst interpretiert werden müssen Schwieriger Zugriff auf Datensystem und Hardware durch Sicherheitsschranken Keine Brücke von ActiveX in Richtung JavaBeans Keine Ausnutzung der Java Interfaces Keine strenge Trennung von Interface und Implementation

3.2.5.3 CORBA von OMG

CORBA gehört zu den verteilten objektorientierten Anwendungen und unterstützt als Middleware genau wie COM+ oder wie die EnterpriseJavaBeans Geschäftsabläufe in verteilten und heterogenen Systemen. Middleware-Plattformen müssen also Mehrbenutzerfähigkeiten besitzen, auf die Anzahl der Nutzer, Daten und Geschäftsprozesse skalierbar sein und eine hohe Verfügbarkeit besitzen.
CORBA ist dabei lediglich ein Standard und eine Spezifikation für die Infrastruktur solcher Plattformen und Komponentenmodelle, die ausschließlich über Schnittstellen kommunizieren.
Die Basis dafür ist die Referenzarchitektur Object Management Architecture, kurz OMA:

Abbildung 11: OMA Architektur von CORBA¹²⁶

Komponenten dieser Architektur sind die Client- und Serverobjekte und der Object Request Broker, kurz ORB. Dieser leitet die Anfrage zwischen den Client- und Serverschnittstellen im verteilten System weiter, um nicht auf komplizierte Netzwerkprotokolle zurückgreifen zu müssen. Das ganze geschieht mit Hilfe von Stubs auf der Clientseite und Skeletons auf der Serverseite. Sie simulieren die angebotenen Objektdienste wie Namensgebung, Kopieren und Löschen von Objekten (Lifecycle-Dienste), Hilfsdienste, Drucken, Sicherheitsdienste, als wären sie lokal vorhanden. Die Kommunikation erfolgt ausschließlich darüber. Auf die Objekte selbst kann nie direkt zugegriffen werden. Schnittstellen, Klassen und Objekte werden dabei mit Hilfe der Definitionssprache IDL beschrieben. Die Schnittstellenbeschreibung selbst liefert das Dynamic Invocation Interface (DII) und ersetzt unbekannte Schnittstellen.
Der erläuterte Aufbau ist äquivalent zu den EnterpriseJavaBeans.¹²⁷
Zusammenfassung der Vor- und Nachteile des Middleware-Standards:

Bewertung von CORBA128

Vorteile

Nachteile

Offener Standard mit uneingeschränkter Erweiterbarkeit Programmiersprachen und Plattformunabhängigkeit Verbesserte Internetanwendungen Beliebige Einbindung von CORBAObjekten Für mobile Geräte gibt es eine schlankere CORBA-Form Ausfallsichere Middleware mit einfacher Kommunikation Skalierbarkeit Spezifikation zur Entwicklung verteilter Anwendungen / Komponenten Starke Unterstützung seitens der Industrie Portables System Komplementäres Arbeiten mit EJB Strenge Trennung von Interface und Implementierung Dynamische Bindung

Rechenintensive Architektur Vererbung kann möglich sein: Der CORBA Standard gibt keine Hinweise wie Stubs und Skeletons zu funktionieren haben. Deshalb kann durchaus Vererbung intern verwendet werden mit allen Nachteilen. Keine Möglichkeit des Multiple Interface Handling: Damit gibt es auch keine Möglichkeit des geregelten Updates einzelner Komponenten von CORBA Systemen.

Tabelle 22: Bewertung von CORBA

• 123: Vgl. [Balz 2001] S 856 ff
• 124: Vgl. [Java 2005]
• 125: Vgl. [Balz 2001] S. 896 und [Java 2005] und [Weis 1999] S. 19 ff und [Lemp 2002] S. 9 ff und [Punz 1999]
• 126: Vgl. [Balz 2001] S. 925 und 927
• 127: Vgl. [Balz 2001] S. 924 ff und [Wiki 2005] CORBA
• 128: Vgl. [Weis 1999] S. 19 ff und [Balz 2001] S. 924 ff und [Punz 1999]

 

---

Top| Home| << Zurück | Nächste >> " TARGET="_blank"> >> Home Page <<