Bei Lösungen für geschäftskritische Anwendungen gelten seit gut zwei Jahrzehnten die Wiederverwendbarkeit von (Programm-) Code, die Bereitstellung austauschbarer Softwarebausteine und die Applikationsentwicklung durch die Zusammenstellung mehrerer Teile als wichtigste Strategie für die wirtschaftliche Produktion von Software. Als Mittel zur Umsetzung dieser Prinzipien wird die objektorientierte Programmierung (OO) mancherorts noch diskutiert. In einigen Unternehmen setzt man sie aber auch schon vermehrt für kritische Anwendungen ein. In komplexen, plattformübergreifenden Business-Anwendungen scheitert das Ganze indes häufig. Der Hauptgrund dafür ist, daß die erhöhte Produktivität bei Verwendung von OO-Methoden durch die Mehraufwände - entstanden durch fehlende Frameworks - mehr als kompensiert wurde.
Die Idee, Software wie Industriegüter zu produzieren, ist eng mit Komponentenmodellen verknüpft. Softwarekomponenten spielen darin die gleiche Rolle wie etwa Komponenten im Automobilbau: Dort werden Fahrzeuge heute aus zugelieferten Komponenten zusammengesetzt. Damit das gleiche auch mit Software funktioniert, müssen Schnittstellen - also APIs und Protokolle - standardisiert werden. Diese Standards sind dann von allen strikt einzuhalten, daß heißt, Komponentenmodelle und Frameworks für Programmierer sind nicht unabhängig voneinander.
Auf der Suche nach dem richtigen Komponentenmodell werden derzeit drei Ansätze diskutiert: COM (Component Object Model) von Microsoft, CCM (Corba Component Model) und EJB (Enterprise Java- beans). Ging es dabei bisher vor allem um die Entwicklung für die Client-Seite, steht mittlerweile zunehmend der Server im Mittelpunkt des Interesses. Dies zeigt sich auch in der Java-Welt: Zu Javabeans, geschaffen und geeignet für Client-Komponenten - in gewisser Weise das Java-Pendant zu COM -, gesellt sich der EJB-Ansatz als die Server-seitige Ergänzung. Sie soll dem Entwickler die schnelle und sichere Implementierung kritischer Applikationen ermöglichen, und zwar dadurch, daß jenem sehr viel "Low-level"-Komplexität verborgen bleibt.
EJB sind dabei auf die Entwicklung und Verteilung von Java-Applikationslogik ausgerichtet, die auf einer Multi-Tier-Architektur basiert. Das Modell folgt dem inzwischen bewährten Client-Server-Modell: die Präsentation streng entkoppelt von der Applikationslogik, diese wiederum streng entkoppelt vom Daten-Management. Die EJB-Spezifikation ist für die mittlere Ebene, die "Middle-Tier", relevant und muß somit die Schnittstellen und Protokolle sowohl zur Präsentationsschicht (Client) als auch zur Daten-Management-Schicht enthalten (siehe Grafik oben). EJB sind zugänglich für Clients, die auf unterschiedlichen Standards beruhen: HTML, Java, Corba und Active X. Die Daten-Management-Schicht wird von der JDBC-Technologie (Java Database Connectivity) abgedeckt. Dies - kombiniert mit der Plattformunabhängigkeit der Applikationskomponenten ("Write once, run everywhere") erzeugt eine hochgradige Flexibilität für Anwendungsentwickler und Nutzer.
Sun Microsystems hat ein Set standardisierter Programmier-Schnittstellen (Standard-APIs) veröffentlicht, das seit Juli 1998 in der Version 1.0 vorliegt. Die- ses API definiert exakt die wichtigen Schnittstellen zu Transak- tions-, Naming- und Persistenz-Services, die für Server-seitige Komponenten von Anwendungen absolut notwendig sind, weil zum Beispiel eine E-Commerce-Anwendung nicht ohne die Gewährleistung von Transaktionen, Sicherheit und Skalierbarkeit denkbar ist.
Die Idee hinter der Spezifikation der Enterprise-Java-APIs ist dabei genial einfach, die Realisierung sicher nicht. Jede heute in einem größeren Unternehmen vorhandene Applikationsplattform besitzt ihre eigenen Naming-, Messaging-, Transaktions- und Datenzugriffsdienste. Die Enterprise-Java-API-Spezifikation legt darüber eine neutrale Schicht, die den Entwickler von den spezifischen (unter Umständen sogar proprietären) APIs entkoppelt. Applikationen erreichen damit eine neue Qualität hinsichtlich ihrer Portabilität. Nicht nur der Quellcode wird portabel, sondern auch das Laufzeitobjekt, da alle benötigten Infrastrukturdienste von einem EJB-Java-API-konformen Server angeboten werden.
Laufzeitumgebung aus Container und Server
Aufgrund der Trennung der EJB in Schichten, weiß eine produzierte Komponente zunächst noch nicht, auf welcher Plattform sie konkret laufen wird. Diese Information wird erst dann relevant, wenn die Komponente installiert wird. Die erforderliche Laufzeitumgebung besteht in der ersten Schicht aus dem EJB-Container, der die Ausführung der Applikationskomponente übernimmt. Der Container weist einen Prozeß oder Thread zu, steuert alle Ressourcen für die Komponente und kümmert sich um die Interaktion mit der Außenwelt. Der Container stellt (aus Sicht der Komponente) auch Dienste wie Lifecycle-Management, implizite Transaktionskontrolle, Persistenz-Management sowie transparente Datenverteilungs- und Sicherheitsdienste (Distribution und Security Services) bereit. Der EJB-Server bildet die nächste Schicht und stellt dabei mindestens einen EJB-Container für die Beans zur Verfügung.
Bei konsequent objektorientiert aufgebauten Anwendungen, deren Aufgabenstellung mit klassischen, transaktionsorientierten (Online Transaction Processing, OLTP) Applikationen vergleichbar ist, ergeben sich ganz neue Problemstellungen. Das Pendant zum Objekt ist in der OLTP-Anwendung ein Service oder eine Funktion, die ohne Gedächtnis - "stateless" - ist. Zustandsänderungen werden durch Update in einem Datenbanksystem realisiert. Das OO-Modellen zugrundeliegende Konzept arbeitet mit Objekten, die über ein Gedächtnis verfügen - sie sind "stateful". Ein solches Objekt enthält die Daten, auf denen die Methoden operieren.
Eine Instanz im EJB-Server muß sich also um die Persistenz von Objekten kümmern, und zwar so effizient, daß das Antwortzeitverhalten von klassischen OLTP-Anwendungen erreicht wird. Das EJB-Komponentenmodell bietet hierfür zwei Arten von Beans: Session Beans und Entity Beans. Session Beans entsprechen in ihren Eigenschaften am ehesten den Services/Funktionen in einer OLTP-Anwendung. Sie sind typischerweise stateless und kurzlebig. Entity Beans entsprechen eher dem Datenbankmodell. Sie sind stateful, transaktionsorientiert und können langlebig sein.
Ein Session Bean bildet die erste Kontaktstelle eines Client in einer Anwendung, während der Zugriff auf das Daten-Management über ein Entity Bean erfolgt. Entity Beans sind in der EJB-1.0-Spezifikation als optional gekennzeichnet. Für große Anwendungen sind sie aber sehr wichtig, weil nur so die Dauerhaftigkeit und Integrität der Anwendungsdaten vernünftig gewährleistet werden kann. Bei Redaktionsschluß stand nur der Weblogic Server von Bea Systems Entity Beans in einer für die Produktion geeigneten Implementierung zur Verfügung.
Die Abgrenzung von Transaktionen ist grundsätzlich offen, sie kann über öffentliche und proprietäre Schnittstellen erfolgen. Um die optimale Wiederverwendbarkeit von Code sicherzustellen, ist ein öffentliches API vorzuziehen.
Dafür bietet sich die entsprechende Java-Schnittstelle (Java-Transaction-API) aus der EJB-Spezifikation an. Sie kann Transaktionen starten, Beans in Transaktionen einbinden, Transaktionen beenden oder zurückrollen. Die Art des Transaktions-Managements bestimmen die verfügbaren Java-Transaktionsdienste (Java Transaction Services, JTS). JTS entspricht im übrigen dem Java-Binding der von der Object Management Group (OMG) definierten Object Transaction Services (OTS) aus der Corba-Spezifikation. Sollen beispielsweise in einer Anwendung zwei oder mehr Resource-Manager (Datenbanken) koordiniert werden (Two Phase Commit), muß ein Transaktionsmonitor wie BEA Tuxedo hinter dem JTS stehen. Wichtig ist, daß der Anwendungsentwickler beim Einsatz des EJB-Modells keinerlei Transaktionscode schreiben muß. Vielmehr beschreibt er - per Deklaration - das gewünschte Verhalten des Beans zur Laufzeit. Den Rest erledigen der EJB-Container und der EJB-Server (siehe Kasten).
Ein sehr wichtiges Thema ist das Installieren und Betreiben von EJBs. Hier zeigt sich am deutlichsten, daß sich die EJB-Schöpfer Gedanken über eine praxisgerechte Lösung gemacht haben. EJBs werden in Form sogenannter JAR-Dateien (ein Wortspiel: Java-Archiv und jar = Topf) geliefert. Neben der Bean-Komponente umfassen diese ein Objekt namens Deployment Descriptor (DD) und zwei weitere Schnittstellen: Home und Remote Interface. Der DD enhält alle für Installation und Betrieb einer EJB notwendigen Einstellungen in Form von Deklarationen. Somit kontrolliert der Deployment Descriptor das Verhalten des Beans zur Laufzeit. Einige Deklarationen beziehen sich auf herstellerunabhängige Dienste wie Sicherheit, Transaktionen, Environment Properties, andere beschreiben spezifische Dienste wie Persistence Mapping.
Das Corba-Komponentenmodell war bis vor kurzem noch nicht exakt definiert. Um dieses möglichst interoperabel mit Enterprise-Java-Standards zu gestalten, möchte eine Initiative von zehn Firmen, darunter BEA Systems, IBM und Oracle, beide Standards zusammenführen. Mit der vorgeschlagenen endgültigen Revision der Component-Model-Spezifikation lassen sich Applikationen entwickeln, die aus Corba-Komponenten - in Corba-Komponenten-Servern - und EJBs - in EJB-Servern - bestehen. Diese Komponenten können synchron und asynchron über Object Request Broker kommunizieren. Besagte Spezifikation geht sogar darüber hinaus: Corba-Server sollen einesteils für EJBs gleichberechtigt mit Corba-Komponenten als Host fungieren, und Standard-EJB-Server sollen andererseits Corba-Komponenten beheimaten können.
Unter dem Strich verhält sich also eine Corba-Komponente wie ein Enterprise Javabean. Corba- und Enterprise-Javabeans-Technologien könnten so tatsächlich verschmelzen. Praxisgerechte Komponentenmodelle existieren schon heute und belegen, daß das EJB-Konzept sich bewährt. Es gibt deshalb nicht das Corba- oder das Java-Thema, vielmehr findet die Integration auf der Client- und der Server-Seite statt..
Transaktionen
Mögliche Deklarationen zum Beschreiben der transaktionalen Eigenschaften vonEJBs
TX_BEAN_MANAGEDDas Bean kümmert sich selbst um Demarkation von Transaktionen über das JTA.
TX_NOT_SUPPORTEDDas Bean kann nicht im Kontext einer Transaktion laufen. Falls es einen Aufruf zum Zeitpunkt einer aktiven Transaktion erhält, wird die Transaktion solang suspendiert.
TX_SUPPORTSDas Bean kann in einem Transaktionskontext laufen.
TX_REQUIREDDas Bean muß in einer Transaktion laufen. Hat der Client gerade eine Transaktion offen, wird es in den Transaktionskontext einbezogen, andernfalls wird eine neue gestartet.
TX_REQUIRES_NEWDas Bean muß in einer Transaktion laufen. Der Container startet aber eine neue Transaktion für den Methodenaufruf.
TX_MANDATORYDas Bean muß in einer Transaktion laufen. Hat der Client zum Zeitpunkt des Methodenaufrufs keine Transaktion offen, generiert der Container die Ausnahmesituation "Transaction Required", auf die der Server reagiert.
Angeklickt
Suns Server-Komponentenmodell EJB ist auf die Entwicklung und Verteilung von Java-Applikationslogik ausgerichtet, die auf einer Multi-Tier-Architektur basiert. Die EJB-Spezifikationen geben Schnittstellen und Protokolle vor und führen eine strenge Entkopplung der Präsentations- von der Applikationslogik ein, wobei letztere wiederum streng vom Daten-Management getrennt ist. Entwickler sollen sich künftig ganz auf die Erstellung von Applikationslogik konzentrieren können, die später über "Container" gesteuert und ausgeführt wird, und von der aufwendigen Programmierung von Schnittstellen befreit sein. Zugleich ist der Standardisierungsprozeß für EJB noch im Fluß. So scheint sich eine Verschmelzung mit der Corba-Architektur langsam anzubahnen.
*Dr. Friedrich Schanda ist Leiter Sales Support in Zentraleuropa bei BEA Systems.