Die Java 2 Platform Enterprise Edition (J2EE) schafft eine einheitliche Umgebung für unternehmensweite und Web-basierende Informationssysteme (siehe Grafik). Solche Anwendungen müssen höchstverfügbar, sicher, zuverlässig und skalierbar sein. Die Anforderungen werden idealerweise durch den Einsatz von mehrschichtigen Architekturen erreicht. Die J2EE soll diese Ziele bei gleichzeitiger Reduktion der Entwicklungs- und Anpassungskosten umsetzen. Eine mehrschichtige Architektur (n-tier), wie sie von J2EE für verteilte Applikationen propagiert wird, kombiniert die Vorteile der zentralen und dezentralen Welt: Die durch EJB realisierte Geschäftslogik wird auf die mittlere Schicht, den Applikations-Server, verlagert. Hier ist sie zentral administrierbar. Sie ist in wiederverwendbaren Server-Komponenten, den Enterprise Beans, gekapselt, deren Lebensraum der EJB-Container des Applikations-Servers ist. Der Anwendungsentwickler konzentriert sich auf die fachliche Logik und nutzt die Dienste, zum Beispiel Transaktionssicherheit, indem er seine Anforderungen an die Laufzeitumgebung spezifiziert oder sie über wohl definierte Schnittstellen aufruft (siehe Grafik "Ziele von EJB"). Der Code für die Anpassung an die reale Systemlandschaft, die "Glue logic", wird nur noch generiert. Dies beschleunigt die Entwicklung, reduziert die Fehlerquellen und vereinfacht den Austausch von Systemkomponenten. Die Backend-Systeme in der hintersten Schicht, zum Beispiel relationale Datenbank-Server, werden über Adapter angesprochen, die unter J2EE als "Connector" bezeichnet werden.

Ein zentrales Ziel ist die Unabhängigkeit von der gesamten Infrastruktur. Dadurch befreit das EJB-Modell den Entwickler von grundsätzlichen Aufgaben bei der Programmierung mehrschichtiger Applikationen: Transaktions- und Zustandsverwaltung, Persistenz, Sicherheit, Nebenläufigkeit oder Ressourcenverwaltung. Idealerweise sind diese speziellen Eigenschaften der Enterprise Beans wie Sicherheit und Transaktions-Management von der Implementierung getrennt.

Dies erlaubt die Änderung dieser Eigenschaften in Abhängigkeit vom spezifischen Kontext. Enterprise Beans können, solange sie sich an die EJB-Spezifikation halten, in jedem EJB-konformen Container eingesetzt werden. Der Container ist die Ablaufumgebung für Enterprise Beans innerhalb des eingesetzten Applikations-Servers.

Interessant für den Einsatz der EJB-Technologie sind die festgelegten Rollen. Die EJB-Spezifikation legt zur Aufgabenteilung mehrere Rollen im Lebenszyklus der Komponenten fest, darunter für die Entwicklung einzelner und das Zusammenstellen verschiedener Enterprise Beans sowie deren Inbetriebnahme (Deployment) und Administration. Der Bean Provider zum Beispiel erstellt ein Enterprise Bean und liefert somit die Anwendungslogik. Ihre Eigenschaften spezifiziert er deklarativ im Deployment-Deskriptor, den er, zusammen mit den übrigen Dateien, als Java-Archiv ausliefert. Weiterhin legt die Spezifikation die Verträge zwischen den verschiedenen Parteien genau fest, die das ungestörte Zusammenarbeiten von Enterprise Beans aus verschiedenen Quellen garantieren (Design by Contract).

In der EJB-Technologie sind unterschiedliche Typen von Enterprise Beans für die Abbildung der Geschäftslogik festgelegt. So fasst die Bezeichnung "Session Beans" die Server-seitigen EJB-Komponenten zusammen, deren Aufgabe in der Realisierung der Geschäftsvorfälle liegt. Sie präsentieren sich den Clients über eine Schnittstelle. Über die Schnittstellen der Session Beans wird die komplette Funktionalität der Applikation angeboten, ohne konkrete Details über Persistenz, Transaktionsmanagement, Nebenläufigkeit und Sicherheit zu verraten. Auf diese Weise lassen sich auch Workflows oder komplexere Geschäftsvorfälle definieren, indem die einzelnen Komponenten miteinander verbunden werden.

Session Beans liegen in zwei Ausprägungen vor. Zustandsbehaftete (stateful) Beans werden eingesetzt, wenn auf einen Client bezogene Informationen für den Verlauf einer Sitzung festgehalten werden müssen. Ein typisches Einsatzgebiet ist ein Einkaufswagen in einem Online-Shop. Der EJB-Container sorgt sich hierbei um die gesamte Zustandsverwaltung. Das Ende einer Sitzung wird in der Regel explizit vom Client angefordert, kann aber auch durch einen Timeout ausgelöst werden oder schlicht durch einen Server-Absturz verursacht sein. Zustandslose (stateless) Session Beans besitzen kein Gedächtnis. Sie dienen primär als Fassade für Geschäftsvorfälle beziehungsweise allgemein als Server-seitige Funktionsbibliotheken.

Viele der Daten müssen über eine Session hinaus persistent gemacht werden. Diese Daten werden in Form von Entity Beans modelliert. Sie sind persistente Server-Objekte, die im einfachsten Fall einer Zeile in einer Datenbank-Tabelle entsprechen. Ihre Persistenz können die Beans selbst verwalten (Bean-managed) oder dem EJB-Container überlassen (container-managed), wobei die Abwicklung transparent geschieht. Im letzteren Fall charakterisiert der Entwickler die persistenten Attribute und Felder im Deployment-Deskriptor. Die konkrete Abbildung etwa auf eine Datenbank wird erst beim Einrichten der Komponenten im EJB-Container festgelegt.

Offensichtliche Probleme und versteckte TückenSo viel zunächst zur Theorie. Doch wie sieht es nun in der Praxis aus? Immerhin ist EJB eine noch sehr junge Technologie, und man muss davon ausgehen, dass viele Schwächen erst mit wachsender Erfahrung auf diesem Gebiet eine befriedigende Lösung finden werden. Diese Annahme ist nicht unbegründet. Es hat sich gezeigt, dass der EJB-Entwickler nicht blauäugig den Versprechungen der EJB-Spezifikation vertrauen kann und an vielen Stellen Workarounds einsetzen muss, die sich aufgrund konzeptueller und Performance mindernder Schwächen der EJB-Technologie ergeben. Im Folgenden beleuchten wir einige der wesentlichen Schwächen und skizzieren bewährte Lösungsansätze.

In der Praxis gelten vor allem das Konzept der Entity Beans und das damit verbundene Thema Persistenz als problematisch. Zunächst stellt sich für den Entwickler die Frage, ob er die Entity Beans mit automatischer, Container-managed Persistence (CMP) oder besser mit Bean-managed Persistence (BMP) versehen soll. Eine Umfrage unter EJB-Entwicklern hat ergeben, dass CMP nur in etwa zehn Prozent der Entity Beans zum Einsatz kommt. Hierbei wird CMP vor allem dann genutzt, wenn eine bestehende Tabelle einer relationalen Datenbank durch die Entity Beans repräsentiert wird, sich die Modellierung also nach dem Datenbankschema richtet. CMP scheidet spätestens dann aus, wenn man eine genaue Kontrolle über die Datenzugriffe benötigt, etwa für das Laden von Daten erst auf Bedarf (Lazy Loading) oder wenn die Abbildung auf die Datenbank zu komplex ist. Denn die Konfiguration der CMP findet über die Administrationswerkzeuge des eingesetzten EJB-Containers statt. Hier bestimmt die Leistungsfähigkeit dieses herstellerspezifischen Werkzeugs über die Möglichkeiten bei der Abbildung auf die Datenbank.

Einen Mittelweg zwischen der relativ unflexiblen CMP und dem expliziten Ausprogrammieren im Rahmen der BMP erlauben objektrelationale Mapping-Werkzeuge. Mit ihrer Laufzeitumgebung bieten sie die Transparenz von CMP, gestatten allerdings weiter gehende Abbildungsmöglichkeiten, etwa die Persistenz von beliebigen Relationen zwischen Objekten, und befreien den Entwickler von der Konfigurationsabhängigkeit eines spezifischen EJB-Containers. Viele dieser Mapping-Produkte, etwa "Toplink" und "Cocobase", bieten mittlerweile sogar direkte Unterstützung für EJB. Der Nachteil dieser erkauften Flexibilität ist allerdings, dass nachträgliche Änderungen am Datenmodell in der Regel eine Umorganisation der Abbildung nach sich zieht und der Anwender Gefahr läuft, bestehende Datensätze umständlich anpassen zu müssen.

Entity Beans weisen zudem diverse konzeptuelle Schwächen auf. So macht es die EJB-Spezifikation durch gewisse Festlegungen unmöglich, eine konsistente befriedigende Vererbungsbeziehung zwischen Entity Beans zu etablieren. Weiterhin ist der Umgang mit potenziell großen Mengen an Entity Beans, wie sie etwa bei Suchergebnissen auftreten, alles andere als effizient. Die vielfältigen Probleme werfen die Frage auf, ob der Einsatz von Entity Beans überhaupt zu empfehlen ist. Dies hängt von der spezifischen Anwendung und vor allem von deren Komplexität ab. Wir empfehlen beim jetzigen Stand der EJB-Spezifikation, die Entity Beans mindestens mit Vorsicht zu genießen.

Spielt Performance eine Rolle, oder wird auf ein bestehendes Datenbank-Schemata aufgesetzt? Wenn nicht die gesamte Leistungsbandbreite von Entity Beans benötigt wird, sollte man besser auf eigene, spezifische Datenzugriffsobjekte (DAOs = Data Access Objects) ausweichen.

Sie sind ebenfalls zwischen Session Beans und der Datenbank- beziehungsweise der Backend-Schicht geschaltet, werden allerdings unkompliziert über lokale Methodenaufrufe angesprochen. Der Zugriff auf die Daten kann etwa mittels JDBC, in Zukunft auch mittels JDO (siehe unten) oder über die Connector-Abstraktion abgewickelt werden.

DAOs eröffnen diverse architektonische Freiheiten: So lässt sich ein solches Objekt etwa einem zustandsbehafteten Session Bean zuordnen, wodurch das Bean seine private Datenversion während eines Geschäftsvorfalls hält. Hierbei sollte das DAO so ausgelegt sein, dass nur die jeweils relevanten Informationen aus der Datenbank geladen werden ("Lazy Loading"). Alternativ können DAOs auch, im Sinne der Entity Beans, auf den gemeinsamen Zugriff durch mehrere Session Beans ausgerichtet sein. Sollten Entity Beans in der Anwendung zum Einsatz kommen, so empfehlen wir, Bean-managed Persistence (BMP) zu verwenden und gleichzeitig eine zusätzliche Abstraktion zum Backend hin mittels Datenzugriffsobjekten einzuführen.

Zum Abschluss der Diskussion über Entity Beans sei auch erwähnt, dass Sun in Zusammenarbeit mit zahlreichen Firmen eine Persistenz-Spezifikation entwickelt - JDO (Java Data Objects). Sie liegt konzeptuell etwa zwischen Entity Beans-Persistenz (CMP) und der ODMG-Spezifikation (Object Data Management Group). Im Gegensatz zum ODMG-Ansatz bietet JDO eine transparente Persistenz. Die Spezifikation ist allerdings noch nicht fertig ausgearbeitet, und die Implementierungen liegen noch im Betateststadium vor. Es zeichnet sich jedoch ab, dass JDO eine Alternative zu CMP oder - wie man in diversen EJB-Entwicklerforen liest - das bessere Persistenz-Konzept gegenüber CMP sein könnte.

Man muss sich allerdings im Klaren darüber sein, dass die Persistenz in anderen Komponentenmodellen auch unvollkommen ist. Microsoft geht in seinem proprietären COM+ dem Problem schlicht aus dem Weg und bietet lediglich eine zu den (stateful) Session Beans äquivalente Funktionalität an. Und der Persistenz-Dienst des Industriestandards CORBA erwies sich in beiden Ausarbeitungen als wenig praxistauglich. Sun bemüht sich dagegen um eine befriedigende Lösung. Entity Beans waren im Lauf der Überarbeitungen der EJB-Spezifikation stets wesentlichen Änderungen unterworfen.

Bei aller Kritik stellt EJB dennoch die zur Zeit beste und meist versprechende Server-seitige Komponententechnologie dar. Sie wird sich mit zunehmender Erfahrung auf diesem Gebiet sicherlich noch weiter entwickeln. So arbeitet Sun mit Volldampf daran, EJB von seinen Kinderkrankheiten zu befreien, ohne dabei die Rückwärtskompatibilität und somit den Schutz bestehender Investitionen aus den Augen zu verlieren. Die kommende EJB-Spezifikation 2.0 weist bereits den richtigen Weg, wenn auch noch manche Probleme bestehen bleiben (siehe Kasten "Wunschliste" auf Seite 71). Zudem steht und fällt die Akzeptanz von EJB mit den derzeit erhältlichen Applikations-Servern, Entwicklungswerkzeugen und einsatzfertigen EJB-Komponenten.

Mittlerweile gibt es hier eine beachtliche und vielfältige Auswahl an Produkten mit hoher Qualität, die den gesamten Preisbereich von Open Source bis Highend abdecken (siehe nebenstehenden Kasten). Noch spärlich sind dagegen Lösungen, die alle Arbeitsabläufe der EJB-Komponenten-Entwicklung begleiten, vom Modellieren, Generieren und Ausprogrammieren der Beans bis hin zum Deployment und Debuggen. Die neuesten Produktgenerationen, wie zum Beispiel "Webgain", "TogetherJ Control Center" und "JBuilder 4 Enterprise", schließen aber auch diese Lücke.

*Dr. Martin Backschat und Dr. Boris Reichel von der MGM EDV-Beratung GmbH in München beschäftigen sich mit dem Design und der Umsetzung von verteilten komponentenorientierten Anwendungen im EJB- und J2EE-Umfeld. Martin Backschat ist weiterhin verantwortlich für die Betreuung der Enterprise JavaBeans Special Interest Group (www.ejbsig.de/ejbsig).

ANGEKLICKTEnterprise Javabeans (EJB) ist eine vielversprechende Server-seitige Komponententechnologie und Teil der Java 2 Platform Enterprise Edition (J2EE). Sie erfreut sich wachsender Akzeptanz in Großunternehmen. In der Praxis dürfen EJB-Entwickler jedoch nicht blauäugig den Versprechungen der EJB-Spezifikation vertrauen. Vielmehr ist er an vielen Stellen auf Workarounds aufgrund konzeptueller und Performance mindernder Schwächen des aktuellen Stands der EJB-Technologie angewiesen. Mit den laufenden Standardisierungen und dem angekündigten Release 2.0 werden aber viele der aktuellen Probleme behoben werden.

EJB 2.0Mit der kommenden EJB-Version 2.0 wird eine Vielzahl an Änderungen in die Spezifikation Einzug halten, die den Umgang mit der EJB-Technologie erheblich vereinfachen sollen, darunter

- ein neuer Bean-Typ zur Verarbeitung von asynchronen Nachrichten (message-driven Bean)

- weiter gehende Container-managed Persistence. Insbesondere ist der Umgang mit Beziehungen (Relationen) befriedigend gelöst

- einheitlicher Query-Syntax für das Auffinden von Entity Beans.

WUNSCHLISTEIn der neuen, noch in diesem Jahr erscheinenden EJB-Spezifikation 2.0 hat sich Sun vieler der angesprochenen Schwächen angenommen. Eine grundsätzliche Problematik bleibt jedoch bestehen: Die Spezifikation widmet sich lediglich den konzeptionellen Aspekten, den Schnittstellen sowie den Verträgen zwischen den EJB-Rollen. Performance-bezogene Aspekte werden nicht geregelt. Dies führt dazu, dass in der Realität viele EJB-Container spezifische Erweiterungen für die Performance-Steigerung anbieten. Greift der Entwickler darauf zurück und setzt sie im Bean-Code ein, bindet er sich an den Hersteller. Die wichtigsten Punkte sind im Folgenden zusammengefasst:

- Der Zugriff auf ein Entity Bean erfolgt durch entfernte Methodenaufrufe. Dieses Vorgehen ist zeitlich sehr aufwändig, denn einerseits müssen die Parameter und Ergebnisse serialisiert werden, andererseits werden stets alle Transportschichten durchlaufen. Dies zwingt den Entwickler dazu, seine Implementierung darauf auszurichten. So ist es etwa bewährte Praxis, nicht jedes Attribut eines Entity Beans einzeln abzufragen, sondern alle für einen Geschäftsvorfall nötigen Informationen auf einmal in Form eines entsprechenden Datenobjekts abzuholen. In vielen Fällen werden aber die Entity Beans nur von Session Beans im selben EJB-Container angesprochen. Sun sollte deshalb konsequenterweise auch eine Variante von Entity Beans vorsehen, die nur innerhalb des Containers sichtbar und ansprechbar ist. Diese lokalen Entity Beans ließen sich idealerweise mit einer schlanken Call-by-Reference-Aufrufsemantik versehen.

- Ein weiteres kritisches Thema ist die Optimierung der Datenzustandsverwaltung bei der CMP. Zur Zeit lässt sich nicht spezifizieren, ob eine Methode als persistent deklarierte Attribute verändert hat. Ohne dieses Wissen bleibt dem EJB-Container nichts anderes übrig, als nach jeder Transaktion den Zustand in der Datenbank zu sichern. Hier wäre ein Signalisierungsmechanismus sinnvoll ("dirty detection"). Damit ließen sich dann auch Read-Only- und Read-Mostly-Beans effizient realisieren. Der EJB-Container "Weblogic" der Firma Bea Systems löst dieses Dilemma unter anderem durch optionale Abfrage einer proprietären Bean-Methode "isModified".

- Weitere Kritikpunkte daraus ergeben sich in den Bereichen des "Lazy Loading" beziehungsweise "Hollow Instances", um Daten erst zu laden, wenn diese wirklich benötigt werden. Hier vermisst man Standardisierungen im Bereich der Zugriffsgranularität auf abhängige Objekte oder Enterprise Beans, welche die Anzahl der zu ladenden Ebenen oder einen noch feineren Zugriffspfad definiert. Dieses Problem wird immerhin teilweise von der kommenden JDO-Spezifikation (siehe oben) gelöst werden.

- Massive Performance-Probleme entstehen auch durch das Fehlen einer standardisierten Caching-Strategie sowohl bei Container- als auch bei Bean-managed Persistence. So ist für einen BMP-Entwickler kein Caching-Mechanismus vorgesehen, gleichzeitig für eine performante Verarbeitung aber zwingend nötig. Keine Aussagen finden sich zudem zur Skalierung dieses Caches zwischen mehreren Server-Instanzen in einem Cluster-Betrieb.

- Die Anwendung des MGM-Lasttest-Frameworks auf verschiedene EJB-Container führte zum Ergebnis, dass Durchsatz und Stabilität der Container stark vom getesteten Anwendungsfall abhängen. Diese Erfahrung legt nahe, dass Sun seine bereits vorhandene Referenz-Implementierung des EJB-Containers und sein Konformitätstest-Framework um einen Standardsatz von ausgewählten, repräsentativen Anwendungsfällen erweitern sollte. Einen ersten Schritt in diese Richtung hat Sun mit dem "ECPerf"-Benchmark angekündigt.

- Techniken für die Identifizierung und Spezifikation von Komponenten in frühen Phasen des Software-Lebenszyklus (Analyse und Design) stecken noch in den Kinderschuhen. Erste Ansätze, die von MGM unter anderem für ein Bankenkonsortium entwickelt wurden, zeigen, dass aus konzeptueller Sicht eine Komponente nicht ein Enterprise Beans ist. Vielmehr können Klassen einer identifizierten Komponente, falls sie bestimmten Auswahlkriterien entsprechen, Enterprise Beans zugeordnet und alle Bestandteile einer Komponente in einer EJB-Deployment-Einheit zusammengefasst werden.

EJB-Applikations-ServerAnbieter von EJB- und CORBA-Applikations-Servern sind in der Regel etablierte Middleware- oder Datenbank-Hersteller, die durch Eigenentwicklung oder Zukauf von Technologien und Firmen in diesen lukrativen Markt drängen. Einige Beispiele:.

- Sun Microsystems vereint gleich drei Server im neuen Produkt "iPlanet Application Server". Neben dem eigenen NetDynamics kamen durch die Allianz mit Netscape und durch den Aufkauf von Forté zwei weitere hinzu, die in diesem Jahr integriert wurden.

- BEA ist als Hersteller des Transaktionssystems "Tuxedo" bekannt. Durch Aufkauf der Firma WebLogic mit deren Produkt "Tengah", einem Pionier auf dem Gebiet der EJB-Server, bekam BEA Zugriff auf einen Java-Applikations-Server und entwickelt ihn konsequent in Richtung der Java 2 Enterprise Edition weiter.

- Oracle ist Marktführer bei den relationalen Datenbanken und bietet mit seiner Architektur des "Oracle Application Server" mit Applikationserweiterungen (Cartridges) eine Lösung an, die ebenfalls in Richtung J2EE strebt.

- IBM vereint sein Know-how aus dem Transaktionsumfeld ("CICS", "Encina") und dem Datenbankbereich ("DB2", "UDB") mit dem CORBA-Produkt "ComponentBroker" im "WebSphere Application Server". Dieser dient als Container für EJBs und als ORB, sowie als Laufzeitumgebung für Servlets und JSP, eine volle Unterstützung von J2EE ist jedoch nicht vorgesehen.

- Fujitsu-Siemens sind die einzigen, die mit dem Produkt "BeanTA" ihren EJB-Container vollständig integriert auf ihren bewährten Transaktionsmonitor "openUTM" anbieten und interessante Erweiterungen für die transaktionssichere Anbindung von Legacy-Applikationen entwickelt haben.

- Newcomer gibt es viele in diesem heiß umkämpften Markt. Einer der erfolgreichsten ist die Firma Silverstream.

Der Trend ist klar erkennbar. Fast alle Produkte streben auf eine Unterstützung der J2EE-Plattform hin oder haben die noch junge Spezifikation schon erfüllt. Besonders weit fortgeschritten sind BEA WebLogic und der SilverStream Application Server.

Abb: Die Java 2 Enterprise Edition bietet eine immer ausgereiftere Plattform für die Entwicklung mehrschichtiger Anwendungen. Quelle: MGM