Enterprise JavaBeans; Enterprise JavaBeans;

1 Einfuhrung

Die Programmiersprache Java hat ihre Po-pularitat ursprunglich mit der Program-mierung von Clientprogrammen, uberwie-gend mit Applets innerhalb von Webseiten,erlangt. Mittlerweile hat Java auch auf derServerseite mit Technologien wie JavaServlets und Enterprise JavaBeans (EJB)Einzug gehalten.

Fur die Entwicklung von modernen Web-basierten Informationssystemen mit hohenAnforderungen an Skalierbarkeit undWartbarkeit bietet sich eine mehrstufigeSystemarchitektur an, welche die Aufgabenvon Benutzerfuhrung, Anwendungskernund Datenbank auf verschiedene Systeme(und ggf. auch verschiedene Rechner) ver-teilt. Die Spezifikation der Enterprise Java-Beans [SunM02] der Firma Sun Microsys-tems definiert einen Application Serverund sieht eine derartige Architektur vor.

Dieser Beitrag beschreibt zunachst die An-forderungen an ein betriebliches Informa-tionssystem, untersucht die Moglichkeiten,die von EJB geboten werden und erklart,wie diese eingesetzt werden konnen, umwartbare und effiziente Systeme zu erhal-ten. Es wird gezeigt, dass EJB durchaus ei-nen Mehrwert beisteuern kann, aber den-noch kritisch zu beurteilen ist.

1.1 Betriebliche, Web-basierteInformationssysteme

Große betriebliche Informationssystemesind einerseits gekennzeichnet durch hohe

Datenmengen, hohe Clientlasten und hoheAnforderungen an Zuverlassigkeit und Si-cherheit, und andererseits durch eine zumTeil sehr komplexe fachliche Logik. Zudemweisen sie typischerweise eine hohe Le-bensdauer auf. Sie werden meist in Formvon mehrstufigen Client/Server-Systemenrealisiert. Dabei werden die Aspekte Da-tenhaltung, Geschaftslogik und Prasenta-tion sowohl konzeptuell als auch technischvoneinander getrennt. Die Ausfuhrung derGeschaftslogik und die Datenhaltung wer-den auf jeweils fur diesen Zweck speziali-sierten Servern durchgefuhrt (Applika-tionsserver bzw. Datenserver), wahrendder Client fur die Prasentation der Datenund die Benutzerinteraktion zustandig ist(„thin client“, Bild 1).

Der Vorteil einer solchen Architektur liegtzum einen in der besseren Skalierbarkeit;man kann sowohl den logischen Daten-bankserver als auch die Aufgabe des logi-schen Anwendungsservers auf mehrerephysische Server verteilen. Zum anderenist auch die Verwaltung eines solchen Soft-waresystems einfacher, da große Teile desGesamtsystems auf wenigen zentralisiertenRechnern liegen und nur relativ schlankeProgramme auf die zahlreichen Clientrech-ner verteilt werden mussen. Die Clientswerden heute oft in Form von Webanwen-dungen auf Browser-Basis z. T. mit Stan-dard-Webtechnologien [Weit02] oder auchmit Java Applets realisiert.

Um den technischen Herausforderungenan derartige Systeme zu begegnen, sindvielfaltige Technologien und Werkzeugeunterschiedlicher Hersteller zu einem per-formanten und zuverlassigen Gesamtsys-

WIRTSCHAFTSINFORMATIK 44 (2002) 3, S. 217–224

Die Autoren

Roland SchatzleTilman SeifertJorg Kleine-Gung

Dr. Roland Schatzle,adviion GmbH,Ritterstr. 7,D-76133 Karlsruhe,E-Mail: [email protected];Dipl.-Wi.-Ing. Tilman Seifert,TU Munchen,Institut fur Informatik, H5,Arcisstr. 21,D-80290 Munchen,E-Mail: [email protected];Dipl.-Math. oec. Jorg Kleine-Gung,Deutsche Bank AG,PCAM GT/CTO Germany/Platform Server/AES/DTS,Alfred-Herrhausen-Allee 16–24,D-65760 Eschborn,E-Mail: [email protected]

Enterprise JavaBeansKritische Betrachtungen zu einermodernen Software-Architektur

WI – Schwerpunktaufsatz

tem zusammen zu fugen. Typischerweisemussen zusammenwirken: Datenbanksys-teme, verschiedene Middlewareprodukte(Transaktionsmonitore, Messagingsysteme,Object Request Broker u. a.), Sicherheits-software (z. B. zur Verschlusselung) unddiverse Kommunikationsprotokolle. Daru-ber hinaus sind vielfach bestehende (Alt-)Anwendungen mit einzubinden. Fur dasZusammenwirken all dieser Teile kommenoft proprietare Schnittstellen zum Einsatz.Die Konsequenzen sind hoher Entwick-lungsaufwand und eine hohe Abhangigkeitvon Produkten und Herstellern.

Da betriebliche Informationssysteme einehohe Lebensdauer aufweisen, spielen daru-ber hinaus auch Wartbarkeit und Erweiter-barkeit eine bedeutende Rolle, wodurchdie Anforderungen an die Entwicklungweiter steigen. Die wesentliche Herausfor-derung besteht somit darin, komplexefachliche Anforderungen mit Hilfe einerVielzahl von notwendigen Technologienund Produkten in ein qualitativ hochste-hendes Softwareprodukt zu uberfuhren.Dies ist nur uber eine gute Basisarchitekturzu erreichen.

Die EJB-Spezifikation (Enterprise Java-Beans) der Firma Sun Microsystems defi-niert einen Application Server, der verschie-dene Dienste fur die genannten Anforde-rungen integriert und stellt eine Architekturvor, die genau diese Ziele erreichen mochte.Die EJB-Spezifikation wurde 1998 erst-malig im Rahmen der sog. Enterprise Edi-

tion (J2EE) der Java-Plattform spezifiziert.Die Enterprise Edition umfasst neben denEnterprise JavaBeans auch die Technolo-gien Java Server Pages und Servlets, die imvorliegenden Artikel aber nicht weiter be-trachtet werden. EJB sind ubrigens nicht zuverwechseln mit JavaBeans; dabei handeltes sich ebenfalls um eine Komponente-narchitektur fur Java, die aber fur eherleichtgewichtige, clientseitige Komponen-ten konzipiert wurde und ansonsten mitEJB nicht weiter verwandt ist.

1.2 Ziele und Grundideender EJB-Architektur

Die EJB-Architektur verspricht eine Ver-einfachung der Entwicklung von mehrstu-figen (n-tier) Client/Server-Anwendungendurch folgende Ziele:

& Wiederverwendbare, fachliche Kom-ponenten (sog. Business Objects) konnenunabhangig von technischen Aspektenentwickelt werden.

& Standardisierte Schnittstellen machendie Anwendungen unabhangig von be-stimmten Herstellern und Produkten.

& Durch die Trennung von fachlichen undtechnischen Aspekten sowie durch dieVerwendung standardisierter Schnitt-stellen ist bei den Entwicklern wenigerSpezialwissen notwendig, und unter-schiedliche Fachleute konnen sich gemaßder ihnen zugeteilten Rollen auf ihre ei-gentlichen Entwicklungsaufgaben kon-zentrieren.

Im Detail bedeutet dies, dass Applikations-software aus wiederverwendbaren Ge-schaftsobjekten – den Enterprise JavaBeans– besteht, die direkt aus der Anwendungs-domane entstammen und somit ausschließ-lich Fachkonzepte reprasentieren. Beispielefur solche Geschaftsobjekte sind Kunden,Rechnungen, Produkte u. a. m. Anforde-rungen nach Transaktionssicherheit, Persis-tenz und Sicherheit (im Sinne von „secur-ity“) werden durch eine darunter liegendeInfrastruktur, bestehend aus Produktenverschiedenster Hersteller, auf die uberstandardisierte Schnittstellen zugegriffenwird, erfullt. Außerdem werden diese An-forderungen nicht zusammen mit der Ge-schaftslogik im Programmcode, sonderngetrennt davon deklarativ formuliert, so-dass z. B. die Sicherheitsanforderungen ei-nes solchen Geschaftsobjekts je nach Ein-satz geandert werden konnen, ohne dassam Programmcode Veranderungen not-wendig sind und ohne dass der Quellcodeuberhaupt verfugbar sein muss. Man erhaltsomit eine klare Trennung zwischen fachli-chen und technischen Komponenten, wiesie auch in [SiDe00] gefordert wird.

Die Business Objects ihrerseits stellen ihreSchnittstelle, also ihre Attribute und Me-thoden, ebenfalls auf eine standardisierteArt und Weise nach außen zur Verfugung.Dadurch kann die Kommunikation zwi-schen Client und Applikation unabhangigvon den darunter liegenden Protokollendurchgefuhrt werden. Außerdem bekommtder Entwickler eines Geschaftsobjekts ei-nen Rahmen vorgegeben, den er mit derGeschaftlogik fullen kann, ohne sich umtechnische Details kummern zu mussen.

Inzwischen sind einige großere Projekteauf Basis von EJB umgesetzt worden undbefinden sich im produktiven Einsatz, so-dass hier nun Erfahrungswerte vorliegenund Konzepte und Produkte in Bezug aufdie Erreichung der o. g. Ziele einer kriti-schen Prufung unterzogen werden konnen.Dies wird im zweiten Kapitel geschehen.Zunachst werden die grundlegenden Kon-zepte der EJBs im Detail eingefuhrt.

1.3 Enterprise JavaBeans:Grundkonzepte

1.3.1 Die Ablaufumgebung

Enterprise JavaBeans sind nicht alleine ab-lauffahig; sie benotigen eine Laufzeit-umgebung, die Betriebssystemressourcen


Server

Client 1 Client nClient 2

Datenhaltung

Präsentationslogik

Applikationsserver

Anwendungslogik

Bild 1 Mehrstufige Client/Server-Architektur (hier: dreistufig)

218 Roland Schatzle, Tilman Seifert, Jorg Kleine-Gung

wie Prozesse oder Threads bereitstellt undsich um die Persistenz der Beans, dieTransaktionsverwaltung und Sicherheits-anforderungen kummert. Die Laufzeit-umgebung ist fur das ordnungsgemaße Er-zeugen und Initialisieren von Beanszustandig und stellt die Infrastruktur furdie Kommunikation mit dem Client zurVerfugung, sodass ein neu gestarteterClient „seine“ Beans findet und mit diesenkommunizieren kann.

Entsprechend der EJB-Spezifikation[SunM01] wird die Laufzeitumgebung inForm eines Containers zur Verfugung ge-stellt, der wiederum in einem J2EE-Serverablauft. Ein Container verwaltet ein odermehrere Beans. Es existieren J2EE-Serververschiedener Hersteller, z. B. der BEAWebLogic Server von BEA, der WebSphereApplication Server von IBM, der BorlandApplication Server von Borland, der Net-Dynamics Application Server von Sunoder auch der Jboss Server, der frei verfug-bar ist, um nur einige wenige zu nennen[SunM02]. Ein Application Server kann diegenannten Dienste selbst bereitstellen oderdabei auf weitere Produkte zuruckgreifen(z. B. auf Datenbanken zur Bereitstellungvon Persistenzmechanismen).

1.3.2 Zwei Artenvon Enterprise JavaBeans

Wie schon erwahnt reprasentiert ein Enter-prise JavaBean ein Geschaftsobjekt aus derAnwendungsdomane der zur erstellendenAnwendung. Dabei wird im Wesentlichenzwischen zwei Arten von EJBs unterschie-den: Den Entity Beans und den SessionBeans.

Entity Beans

Entity Beans reprasentieren Geschafts-objekte wie Kunden oder Produkte, die ei-ne langere Lebensdauer haben und somitpersistent gespeichert werden mussen. Mankann sich ein Entity Bean im einfachstenFall als Datensatz oder Objekt in einer Da-tenbank vorstellen. Jedes Entity Bean hateinen Primarschlussel, also eine Attribut-kombination, die ein solches Objekt ein-deutig identifiziert.

Ein besonderes Problem beim Entwurf ei-ner EJB-Anwendung ist die effiziente Spei-cherung der Daten in einer Datenbank. DieEJB-Spezifikation bietet dafur zwei unter-schiedliche Mechanismen. Bei der sog.bean-managed persistence (BMP) muss der

EJB-Entwickler die Methoden zum Ladenund Speichern des Beans selbst implemen-tieren. In diesem Fall kennt das Bean dieAbbildung der Daten in das (typischerweiserelationale) Schema. Im zweiten Fall kannder Container die Speicherung komplettubernehmen (container-managed persis-tence, CMP); dann wird die objektrela-tionale Abbildung im sog. Deployment-Deskriptor deklarativ bekannt gegeben.

Die CMP der Version 1.1 zur Abbildungder Entity Beans in die Datenbank erlaubtnur sehr einfache Datenstrukturen; so ist esz. B. nicht moglich, abhangige Objekte ab-zubilden (klassisches Beispiel: ein Auftragmit beliebig vielen Auftragspositionen).Beziehungen zwischen Beans mussen vonHand ausprogrammiert oder uber proprie-tare Funktionalitat des Containers gelostwerden. Bei BMP hingegen steht dem Vor-teil der Flexibilitat die Tatsache gegenuber,dass die Abbildung von Hand ausprogram-miert werden muss – und das ist naturlichentsprechend aufwandig. Zudem durfendie vorgegebenen Mechanismen nicht naiveingesetzt werden, da der Bean-Program-mierer nicht in der Hand hat, wie oft dasBean gelesen und geschrieben wird.

Es ist also keine allgemeingultige Aussagemoglich, ob CMP oder BMP das effizien-tere Vorgehen ist. BMP kann die Art desDatenbankzugriffs besser kontrollieren,wahrend CMP dem Container die Mog-lichkeit gibt, mit Hilfe von Cachingverfah-ren die Zahl der Datenbankzugriffe zu re-duzieren.

Der Container stellt fur Entity BeansTransaktionsmechanismen zur Verfugung,sodass im Fehlerfalle keine Datenverlusteoder Inkonsistenzen auftreten. Außerdemist er zustandig fur das Pooling von Daten-

bankverbindungen, die �berprufung vonSicherheitsrichtlinien u. a.

Session Beans

Session Beans reprasentieren Anwen-dungsfalle wie das Ausleihen eines Buches,die Durchfuhrung einer �berweisung oderdas Buchen einer Reise. Ihre Lebensdauerbeschrankt sich auf die Dauer der Durch-fuhrung des zugehorigen Anwendungs-falls, d. h. ein Session Bean wird nach sei-ner Beendigung nicht gespeichert. SessionBeans sind genau einem Client zugeordnet.Session Beans werden unterschieden instateful Session Beans, welche zwischenzwei Methodenaufrufen erhalten bleiben,genau dem aufrufenden Client zugeordnetbleiben und insbesondere einen Zustandbehalten konnen, und stateless SessionBeans, die nur fur einen Methodenaufrufeinem Client zugeordnet sind. Sie konnenalso zwischen zwei Aufrufen keinen Zu-stand behalten. Fur die Entscheidung, obSession Beans zustandslos oder zustands-behaftet eingesetzt werden, sind �berle-gungen auf zwei Ebenen wichtig: Einer-seits die �bersichtlichkeit und Klarheit desClients und des Beans, und andererseits dieFahigkeiten des eingesetzten EJB-Contain-ers hinsichtlich Lastverteilung und Fail-over-Sicherheit. Fail-over-Sicherheit be-deutet, dass bei Ausfall eines ApplicationServers ein anderer dessen Aufgabe uber-nimmt. Dies geschieht im Idealfall fur denBenutzer vollig transparent.

Bei interaktiven Anwendungen ziehen sichAnwendungsfalle in der Regel uber mehre-re Aufrufe an den Server hin; hier bietensich stateful Session Beans an, da der Zu-stand behalten werden kann und die Auf-rufe an sich einfacher sein konnen. Aller-dings kann das bei hohen Clientlasten dazu


Kernpunkte fur das Management

Große Web-basierte Informationssysteme stellen hohe Anforderungen an Skalierbarkeit,Wartbarkeit, Zuverlassigkeit und Sicherheit. Um die Entwicklung solcher Systeme zu erleich-tern, werden entsprechende Software-Architekturen benotigt. Eine solche Architektur wirdvon Sun Microsystems in Form der Enterprise JavaBeans-Spezifikation zur Verfugung ge-stellt. Ausgehend von konkreten Projekterfahrungen wird diese Architektur einer kritischenBetrachtung unterzogen. Es werden dabei Mangel aufgezeigt, die die Kosten einer Anwen-dung uber ihren Lebenszyklus hinweg betrachtet in erheblichem Maße beeinflussen konnen.

Stichworte: Web-basierte Informationssysteme, Komponenten-basierte Architektur,Enterprise JavaBeans, Application Server

Enterprise JavaBeans 219

fuhren, dass sehr viele Session Beans in-stanziiert werden mussen, obwohl nur einegeringe Zahl von Clients tatsachlich Anfra-gen an den Server schickt. Dann mussendie zur Zeit nicht aktiven Beans ausgelagertwerden. Der Verwaltungsaufwand fur denContainer steigt also.

Fur viele Projekte wird aber zum entschei-denen Argument, ausschließlich statelessSession Beans einzusetzen, dass Fail-over-Sicherheit mit den gangigen Produkten zurZeit nur mit stateless Session Beans ge-wahrleistet werden kann, und dass auchLastverteilung nur bedingt mit stateful Ses-sion Beans moglich ist.

1.3.3 Die Bestandteile von EJBs

Wahrend „normale“ JavaBeans durch eineeinzige Java-Klasse implementiert werdenkonnen, bestehen Enterprise JavaBeans ausmehreren Teilen (Bild 2). Dies ist zum einendasHome Interface, welches alle Methodenzum Suchen, Erzeugen und Loschen desbetreffenden EJB auflistet. Daraus wird mitHilfe des Application Server die zugehorigeImplementierung (die EJB-Home-Klasse)generiert. Zum anderen ist dies das EJB-Re-mote-Interface (das Interface heißt tatsach-lich EJBObject, ist aber eher unter demNa-men EJB-Remote-Interface bekannt;s. Bild 2), das alle Businessmethoden desBeans auflistet. Auch hier wird die zugeho-rige EJB-Klasse automatisch generiert.

Der Client tritt nie mit einem EJB direkt inKontakt, sondern immer nur uber eine zu-satzliche Indirektionsstufe, namlich das zu-gehorige Home-Objekt bzw. das EJB-Ob-jekt. Dadurch wird der Container in dieLage versetzt, Methodenaufrufe von Seitendes Clients mit Zusatzfunktionalitat be-zuglich Persistenz, Transaktionsverwaltungetc. zu versehen.

Der sog. Deployment-Deskriptor enthalteine deklarative Beschreibung (in Form ei-nes XML-Dokuments) des Verhaltens desEJB zur Laufzeit u. a. bezuglich Trans-aktionen und Sicherheit. Fur Transaktio-nen sind dies Angaben uber das Verhaltender Anwendung bei konkurrierendem Zu-griff. Listen fur die Zugriffskontrolle (ac-cess control lists) enthalten Informationendaruber, wer welche Operationen des Be-ans ausfuhren darf. Weiterhin enthalt derDeployment-Deskriptor die Beschreibungdes objektrelationalen Mappings, also derAbbildung der Objektstruktur auf das rela-tionale Datenmodell der verwendeten En-tity Beans.

1.3.4 Die Rollen bei der Anwendungs-entwicklung mit EJBs

Die Enterprise-Java-Beans-Architektur er-moglicht – zumindest von der Idee her –eine gezielte Verteilung der Rollen, die beider Entwicklung von mehrstufigen Client/Server-Anwendungen vorkommen, auf se-parate Personengruppen. Dadurch kannder Entwicklungsprozess weiter verein-

facht werden, da in jeder Gruppe nur be-stimmte, spezialisierte Fahigkeiten notwen-dig sind. Im Einzelnen treten folgendeRollen auf:

EJB-Entwickler

Der EJB-Entwickler erstellt Geschafts-objekte, indem er die zu einem EJB geho-renden Interfaces und Klassen erstellt unddiese zusammen mit einem Deployment-Deskriptor als Komponente zur Verfugungstellt. Der EJB-Entwickler benotigt Kennt-nisse uber Enterprise JavaBeans und dieAnwendungsdomane, fur die er Kom-ponenten entwickelt.

EJB-Installierer (EJB Deployer)

Der Installierer installiert fertige Beans ineinem EJB-Server und modifiziert ihre At-tribute (im Deployment-Deskriptor) ent-sprechend der technischen Umgebung, inder das Bean ausgefuhrt werden soll, undentsprechend der Anforderungen bezug-lich Sicherheit und Transaktionsverhaltenetc., die er vom EJB-Entwickler bekommt.Er ist insbesondere dafur zustandig, dassdas EJB uber einen JNDI-kompatiblenNamensdienst (JNDI ¼ Java Naming andDirectory Interface) im System gefundenwerden kann.

Der Installierer kennt sich mit dem tech-nischen Umfeld, also dem EJB-Server undder dahinterliegenden Infrastruktur, aus; erbenotigt wenig oder keine Kenntnisse be-zuglich Java, EJB oder der Anwendungs-domane.

Anwendungsentwickler (EJB Assembler)

Der Anwendungsentwickler implementiertClientanwendungen unter Verwendungvorhandener Beans. Er kann sich dabei aufdie Reprasentation der Daten und die Be-nutzerinteraktion konzentrieren, da er diegrundlegende Geschaftslogik uber Enter-prise JavaBeans zur Verfugung gestellt be-kommt.

EJB-Server-Anbieterund EJB-Container-Anbieter

Der EJB-Server-Anbieter offeriert eineUmgebung, in der EJB-Container ablaufenkonnen, wahrend der EJB-Container-An-bieter Container-Software herstellt, die dieAusfuhrung von Beans mit den geforder-ten Diensten ermoglicht. Da die Schnitt-stelle zwischen Container und Server im-mer noch nicht klar spezifiziert ist und dabeide Systeme eng verzahnt sind, werden


EJB

<<interface>>EJBHome

<<interface>>EJBObject

EJBHome EJBObject

EJB Container

EJB Server

Client

<<calls>> <<calls>>

Deployment-Descriptor

Bild 2 Die Bestandteile eines Enterprise JavaBeans und seine Ablaufumgebung(als UML-Diagramm)


nur Systeme (Application Server) angebo-ten, die beide Aufgaben, also Server undContainer, in einem System vereinen.

1.3.5 Basistechnologien

Die Enterprise JavaBeans-Architektur be-steht nicht aus vollig neuen Elementen,sondern basiert auf einer Reihe schon lan-ger verfugbarer Spezifikationen und Tech-nologien.

Transaktionsdienste werden z. B. uber dasJava Transaction Service API (JTS) zur Ver-fugung gestellt. Der Zugriff auf relationaleDatenbanken kann uber JDBC (Java Data-base Connectivity) erfolgen, und im Be-reich Sicherheit wird auf die java.security-Bibliothek aufgesetzt.

Eine Clientanwendung findet „ihre“ Beansim Netz uber einen JNDI-basierten Di-rectory-Service. Die Kommunikation zwi-schen Client und Bean erfolgt uber denJava-spezifischen Remote-Method-Invoca-tion-Mechanismus (RMI), der dem Metho-denaufruf uber Rechnergrenzen hinwegdient.

2 Kritische Betrachtungder EJB-Architektur

Im Folgenden werden nun die von derEJB-Architektur angestrebten Ziele, nam-lich

& die Trennung zwischen fachlichen undtechnischen Aspekten,

& Herstellerunabhangigkeit durch standar-disierte APIs und

& daraus folgend eine Reduktion der An-forderungen an die einzelnen Software-entwickler

einer genaueren Betrachtung unterzogen.Es wird untersucht, ob bzw. inwieweit die-se Ziele erreicht werden.

2.1 Trennung von fachlichenund technischen Aspekten

2.1.1 Klassifikationvon Softwarebausteinen

Die Forderung nach einer separation ofconcerns [Dijk76] wird schon seit Jahr-zehnten an gute Softwarearchitekturengestellt. In der Qualitats-Software-Archi-

tektur (Quasar) [SiDe00] wird diese Forde-rung konkretisiert und fur moderne be-triebliche Anwendungssysteme fassbar undhandhabbar gemacht. Entsprechend dieserArchitektur lasst sich jeder Baustein einerAnwendung in eine der folgenden vier Ka-tegorien einordnen:

& 0-Software: Unabhangig von Anwen-dungswelt und Technik

& A-Software: Bestimmt durch die An-wendungswelt, aber unabhangig von derTechnik

& T-Software: Unabhangig von der An-wendungswelt, aber bestimmt durch dieTechnik

& AT-Software: Sowohl durch Anwen-dungswelt als auch durch Technik be-stimmt

Anwendungsbestimmter Code (A-Soft-ware) kennt Begriffe wie „Kunde“, „Auf-trag“ oder „Rechnung“. Technikbestimm-ter Code (T-Software) kennt (mindestens)ein technisches API wie z. B. JDBC oderOCI (Oracle Call Interface). Zusatzlich zuden genannten vier Kategorien gibt es nochdie Kategorie „R“ (R-Software), die sichmit der externen Reprasentation von Ob-jekten befasst.

0-Software ist ideal wiederverwendbar, fursich alleine aber ohne Nutzen. Klassenbib-liotheken, die sich mit Strings und Behal-tern befassen (z. B. in Java die Klassen imPaket java.util) sind Beispiele fur 0-Soft-ware.

A-Software kann immer dann wiederver-wendet werden, wenn vorhandene Anwen-dungslogik ganz oder teilweise benotigtwird.

T-Software kann immer dann wiederver-wendet werden, wenn ein neues Systemdieselbe technische Komponente einsetzt(JDBC, ODBC, CICS).

AT-Software befasst sich mit Technik undAnwendung zugleich. Sie ist schwer zuwarten, widersetzt sich �nderungen, kannkaum wiederverwendet werden und ist da-her zu vermeiden; es sei denn, es handeltsich um R-Software.

R-Software ist eine milde Art von AT-Soft-ware. Sie befasst sich mit der Transforma-tion zwischen fachlichen Objekten und ex-ternen Reprasentationen (Zeilen einerDatenbank-Tabelle, ein Bildschirmformat,XML). R-Software kann z. B. mit Hilfevon Skripts generiert werden.

2.1.2 Entity-Beans und Persistenz

Auf Grund der Tatsache, dass ein EntityBean selbst nichts uber die Persistenz weiß,erhalt man anscheinend eine saubereA/T-Trennung in Bean (eine fachlicheKomponente, also A-Software) und De-skriptor (T). Im Entity Bean wird die fach-liche Logik implementiert, und die tech-nischen Abhangigkeiten, in diesem Fall dieAbbildung in die Datenbank (das OR-Mapping; OR steht fur objektrelational),wird deskriptiv gelost.

Was auf den ersten Blick so einfach aus-sieht, birgt bei naherer Betrachtung eineReihe von Problemen:

Die Spezifikation legt nur fest, wie persis-tente Attribute im Deployment-Deskrip-tor benannt werden. Die genaue Abbil-dung in die Datenbank wird nichtspezifiziert. Das ist zunachst unter demGesichtspunkt der Portabilitat ein Nach-teil: Werden Entity Beans auf einen ande-ren Container portiert, muss der OR-Map-ping-Deskriptor neu geschrieben werden.Dabei sind unter Umstanden nicht nur ent-sprechend den unterschiedlichen Herstel-lerspezifikationen anderslautende XML-Tags erforderlich, sondern teilweise sind dieOR-Mapping-Mechanismen unterschied-lich machtig.

Die Standardmechanismen der gangigenContainer sind relativ trivial: Sie bilden je-des Bean auf eine Tabelle, jedes Attribut aufeine Spalte und jede Entitat auf eine Zeileab. Komplexere Objektgeflechte, die kom-plexere Abbildungen erfordern, gehen uberdie Spezifikation hinaus und sind nichtmehr portabel. Einige der gangigen Contai-ner konnen abhangige Objekte von solchnicht-trivialen Datentypen hochstens alsBLOB (binary large object) abspeichern.Hier taucht dann das Problem auf, dass Da-tenbanken wie z. B. Oracle nur eine BLOB-Spalte pro Tabelle unterstutzen; außerdemkann uber diese Spalten nicht gesucht wer-den, und die Definition der abgespeichertenKlassenstruktur darf sich nie wieder an-dern. Erst aufwandige Werkzeuge wie z. B.Toplink [TopL01] leisten hier mehr.

Daraus folgt in vielen Fallen, dass auch dasBean anders entworfen werden muss, umdie Moglichkeiten des Containers ausnut-zen und somit Objektgeflechte uberhaupterst persistent machen zu konnen. Unter-schiedlich machtige OR-Mapping-Mecha-nismen haben also direkten Einfluss auf



den Entwurf von Entity Beans! KomplexeObjektgeflechte konnen oft nur durch be-an-managed persistence, also manuelleProgrammierung, persistent gemacht wer-den. Dies hat dann weiterhin zur Kon-sequenz, dass außerdem der Sperrmecha-nismus bei konkurrierenden Zugriffensowie Caching-Strategien vom Entwicklerberucksichtigt werden mussen. Somit han-delt es sich bei diesen Entity Beans nichtum A-Software, sondern um den zu ver-meidenden Fall von AT-Software.

2.1.3 Performanz

Enterprise Beans werden auch dann zurAT-Software, wenn Performanzuberlegun-gen die Schnittstelle der Beans diktieren.Dies geschieht beispielsweise in folgendemFall:

Jeder Aufruf einer fachlichen Methode ist,zumindest bis zur Version 1.1, ein Remote-Aufruf uber den RMI-Mechanismus (RMI¼ remote method invocation). Das bedeu-tet, dass alle Parameter serialisiert werdenund der Aufruf uber das Netzwerk geleitetwird, selbst wenn das gerufene Objekt sichauf dem selben Rechner in der selben Vir-tuellen Maschine befindet. Das stellt einenenormen Performanzengpass fur jedenAufruf einer Methode des Remote-Inter-face dar. Vergleichsmessungen haben erge-ben: Remote-Aufrufe sind ca. tausendmallangsamer als lokale Methodenaufrufe.

Aus diesem Grund schlagt Sun selbst einbestimmtes Design Pattern, namlich dasValue-Object-Pattern vor [AlCM01], umdie Schnittstelle des Entity Beans moglichstschmal zu halten und moglichst wenigeAufrufe uber die Remote-Schnittstelle zutatigen. Nach diesem Entwurfsmuster ent-halt das Entity Bean im Remote-Interfacenur noch zwei Methoden: getData( ), wel-che ein sog. Transfer-Objekt zuruckliefert,auf dem der Client, in der Regel ein SessionBean, die fachlichen Operation ausfuhrt,und mittels der zweiten Methode setData(My-TransferObject obj) die Daten im En-tity Bean wieder setzen kann.

Der Einsatz des Value-Object-Mustersfuhrt also dazu, dass das Entity Bean nachtechnischen Gesichtspunkten entworfenwird, und dass es nur noch als Schnittstellezur Datenbank existiert. Sun verabschiedetsich mit diesem Vorschlag von dem Kon-zept, Entity Beans seien intelligente An-wendungsobjekte mit transparenter Persis-tenz.

Ab der EJB-Spezifikation 2.0 ist dieserEngpass durch die Einfuhrung von localinterfaces abgeschafft, was naturlich bei be-stehenden Beans, die entsprechend der Ver-sion 1.1 entwickelt wurden, Probleme ganzanderer Art schafft. Diese sind – kaum einJahr alt – bereits Altsysteme!

Die geschilderte Problematik mit dem Re-mote-Interface eines Enterprise Beans istnur einer von mehreren Punkten, wo Per-formanzuberlegungen den Entwurf derBeans beeinflussen. In [Such01] wird deut-lich, dass z. B. bei der Verwendung voncontainer-managed persistence beim Frei-geben von Datenbanksperren und bei An-fragen uber JNDI ebenfalls das Problemauftritt, dass Performanzuberlegungen denEntwurf von Enterprise Beans beeinflus-sen.

2.1.4 Sperrverhalten

Um beim konkurrierenden Zugriff mehre-rer Clients Konsistenz zu gewahrleisten,mussen die in den Entity Beans enthaltenenDaten durch einen Sperrmechanismus ge-schutzt werden. Dieser kann entwedernach dem optimistischen oder dem pessi-mistischen Prinzip realisiert werden.

In der pessimistischen Variante werden alleZugriffe auf ein Entity Bean serialisiert, so-dass der erste Client Zugriff auf das EntityBean bekommt und bis zum Ende derTransaktion behalt; alle weiteren Clients,die auf das selbe Entity Bean zugreifenwollen, bleiben gesperrt. Diese Strategiewird von den meisten Applikationsservernverfolgt. Bei der optimistischen Strategiewerden fur eine Datenbank-Identitat beikonkurrierendem Zugriff mehrere Entity-Bean-Instanzen erzeugt, und am Transak-tionsende wird gepruft, ob die Daten beimZuruckschreiben in die Datenbank einenoptimistischen Sperrkonflikt auslosen.Diese Strategie beherrscht zur Zeit nur derBorland Application Server. Eine dritteVariante ist es, das Sperren von Entity Be-ans auf das Sperrverhalten der darunter lie-genden Datenbank zu verlagern. Damitkommen die Fahigkeiten der Datenbankund nicht mehr ausschließlich die des Con-tainers zum Tragen. Diese Moglichkeit bie-tet z. B. der BEA WebLogic Server in derVersion 6.1.

Die Durchfuhrung des Sperrmechanismusist technischer Natur und soll fur den An-wendungsprogrammierer nicht sichtbarsein. Die Entscheidung jedoch, welche

Strategie verfolgt werden soll, ist fur denAnwendungsprogrammierer wichtig, dennsie bestimmt, wie sich die Anwendung un-ter hoher Clientlast verhalten wird.

Die EJB-Spezifikation schweigt sich jedochuber diesen Punkt aus und zwingt die Her-steller dazu, sich entweder auf eine Strate-gie festzulegen oder uber proprietare Wegeeine Wahlmoglichkeit einzufuhren. So wirdsich dieselbe Anwendung, auf zwei unter-schiedlichen Servern installiert, unter-schiedlich verhalten.

Fur die meisten Anwendungen ist die Ver-wendung eines optimistischen Sperrverfah-rens ohnehin zwingend notwendig, umausreichende Skalierbarkeit bei langlaufen-den Transaktionen zu erreichen. In diesenFallen kann man nicht mehr auf den EJB-Mechanismen aufsetzen, sondern muss dasSperrverfahren manuell ausprogrammieren[AkLa01].

Man ist also auch hier von der Trennungzwischen fachlichen und technischenAspekten noch weit entfernt.

2.2 Unabhangigkeitvon Produkten durchstandardisierte Schnittstellen

Schon im letzten Abschnitt wurde deutlich,dass das versprochene Ziel der Hersteller-unabhangigkeit nicht erreicht wird. Meistist dies verursacht durch Lucken in derSpezifikation, wie z. B. beim objektrelatio-nalen Mapping, das nur die einfachstenFalle abdeckt, oder wie beim Sperrverhal-ten des Application Server, welches vonder Spezifikation einfach nicht festgelegtist.

Den Herstellern der Application Serverbleibt hier gar nichts anderes ubrig, als die-se Lucken in der Spezifikation mit proprie-taren Losungen zu fullen. Daruber hinausversucht jeder dieser Hersteller zur Verbes-serung seiner Marktchancen weitere Funk-tionen anzubieten, die fur den Entwicklerin vielen Fallen sicher hilfreich sind, aberdas Ziel der Herstellerunabhangigkeit inweite Ferne rucken lassen.

Dazu kommt, dass in großen Unterneh-men Systeme auf mehreren Plattformenund Betriebssystemen betrieben werden.Dort ist es unwahrscheinlich, dass auf je-der Plattform der gleiche Application Ser-



ver eines einzigen Herstellers benutztwird. Auch ist es gewohnlich so, dass Mes-sagingsysteme in den Unternehmen schonsehr viel langer in Einsatz sind als EJB Ap-plication Server, sodass man Softwaresys-teme unterschiedlicher Generation mit-einander koppeln muss. In einem solchenSzenario machen sich Unvertraglichkeitenzwischen Teilkomponenten und ein Man-gel an Standards besonders schmerzlichbemerkbar.

Informationssysteme auf Basis der EJB-Technologie sind somit nach wie vor tech-nisch sehr komplex und schwer handhab-bar. Verstarkt wird diese Problematikdurch den raschen Versionswechsel derEJB-Spezifikation: Die Versionen 1.0, 1.1und 2.0 erschienen innerhalb von nur dreiJahren, und EJBs entsprechend der Version2.0 sind inkompatibel zu alteren Versionen.Dies bedeutet fur die Hersteller der Appli-cation Server, dass neue Produkte in ra-scher Folge auf den Markt gebracht wer-den mussen. Dabei haben wir dieErfahrung gemacht, dass oftmals derenQualitat zugunsten neuer Funktionalitatvernachlassigt wird. Die ohnehin schonsehr aufwandige Fehlersuche in einer EJB-Anwendung wird dadurch weiter er-schwert, da man nie sicher sein kann, obdie verwendete Basissoftware – bis hin zurJava Virtual Machine – fehlerfrei und stabilfunktioniert.

2.3 Reduktion der Anforderungenan die Anwendungs-entwickler

Wie in den vorangegangen Abschnitten ge-zeigt wurde, ist die angestrebte Trennungzwischen fachlichen und technischenAspekten nur sehr unzureichend erfullt.Und auch die Herstellerunabhangigkeit istweniger Realitat, sondern eher „a nobleand somewhat lofty objective“ [CaAl01].

Dies bedeutet fur die Entwickler von EJB-Anwendungen, dass sie sich nicht wie vor-gesehen auf die fachlichen Aspekte kon-zentrieren konnen, sondern daruber hinaustechnische EJB-Experten sein mussen, dieuber alle Untiefen der EJB-Architektur Be-scheid wissen. Erschwerend kommt hinzu,dass fur jede EJB-Version (bislang die Ver-sionen 1.0, 1.1 und 2.0) unterschiedlichesKnow-how notwendig ist.

Um wirklich leistungsfahige Anwendun-gen erstellen zu konnen, ist außerdem pro-

fundes Wissen uber den eingesetzten Ap-plication Server mit seinen proprietarenErweiterungen und Fehlern erforderlich.

Die Vision, dass man zur Erstellung einerAnwendung einerseits hauptsachlich Java-Programmierer mit Fachkenntnissen unddazu einige technische Experten mit EJB-Know-how benotigt, wird leider nichterreicht. In realen Projekten sucht mandeshalb oft nach Mitarbeitern, die bei-spielsweise gleichzeitig Kenntnis der An-wendungswelt haben, Java-Entwicklersind, objekt-orientierte Analyse und De-sign beherrschen, Erfahrung mit demWebLogic Application Server Version 6.1in Verbindung mit der Oracle-Datenbankhaben und EJBs entsprechend der Spezifi-kation Version 2.0 entwickeln konnen –eine offensichtlich unbefriedigende Situa-tion.

2.4 EJB Version 2.0

Im August 2001 wurde die Version 2.0 derEJB-Spezifikation verabschiedet, in die be-zuglich der Behebung der o. g. Mangel ho-he Erwartungen gesetzt wurde. Neben denin Abschnitt 2.1.3 erwahnten local inter-faces gibt es u. a. folgende Neuerungen, dieaber kaum zur Verbesserung der Situationbeitragen:

Message Driven Beans

Diese neue Art von Enterprise Beans ent-halt, ahnlich wie die Session Beans, Ge-schaftslogik. Im Gegensatz zu den SessionBeans wird diese Logik aber nicht direktuber einen Client angesprochen, sondernuber asynchrone Nachrichten mittels einesMessagingsystems.

Container-Managed Relationships

Beziehungen zwischen Entity Beans sindnun ein eigenstandiges konzeptuellesKonstrukt und konnen bei Verwendungder container-managed persistence eben-falls „container-managed“ gespeichert wer-den – inklusive des objektrelationalenMappings. Dies ist ein wichtiger Schritt,um komplexe Objektgeflechte „container-managed“ speichern zu konnen; aber daseigentliche Ziel wird noch nicht erreicht.

Eine Abfragesprache (EJB-QL)

Die meisten Container der Spezifikation1.1 haben ihre eigenen, proprietaren Abfra-gesprachen mitgebracht, mit deren Hilfe

Abfragen an die Datenbank abgesetzt wer-den konnen. Diese Abfragesprachen warenalle an SQL angelehnt; nach dem Musterdieser Abfragesprachen ist die EJB-QLneu in die Spezifikation aufgenommen. Siebringt also nicht mehr Funktionalitat, son-dern nur mehr Portabilitat zwischen ver-schiedenen Containern.

Geanderte „Container-managendpersistence“

Der Zugriff auf die persistenten Attributelauft nun uber (abstrakte) Zugriffsmetho-den und nicht mehr direkt uber die Attri-bute. Der Zugriffsmechanismus wurde al-so um eine Indirektionsstufe erweitert.Dies war u. a. notwendig, um container-managed relationships realisieren zu kon-nen.

Insgesamt verbessern die Neuerungen derVersion 2.0 die oben beschriebene Mangel-situation nicht. Die z. T. hochgestecktenErwartungen besonders im Hinblick aufdie Verwendung von abhangigen Objektenund ihrer Persistenz wurden enttauscht.Weitere �nderungen sind deshalb zu er-warten (oder zu erhoffen), wodurch sichdas Versionskarussell mit den damit ver-bundenen Problemen weiter dreht.

3 Fazit

Wie eingangs beschrieben, stellen Web-ba-sierte betriebliche Informationssystemehohe Anforderungen sowohl in tech-nischer als auch in fachlicher Hinsicht. Siemussen verteilt arbeiten, mit hohen Da-ten- und Clientlasten zurechtkommenund sich in eine gegebene Infrastruktureingliedern. Gleichzeitig mussen individu-elle fachliche Losungen implementiertwerden, die zum Teil komplexe Algorith-men verlangen. Weiterhin weisen sie typi-scherweise eine hohe Lebensdauer auf; esist mehr die Regel als die Ausnahme, dasssich sowohl fachliche als auch technischeAnforderungen andern. Die erforderlichenAufwande zur Anpassung oder Erweite-rung konnen erhebliche Ausmaße anneh-men. Der Schlussel, die Wartungskostenim Rahmen zu halten, liegt deshalb nichtnur darin, eine moglichst machtige Basis-technologie einzusetzen, sondern außer-dem noch die individuelle fachliche Logikvon dieser Basistechnologie unabhangigzu halten.



Fur die Losung der technischen Anforde-rungen existiert eine Reihe von Diensten,die bei der Entwicklung eingesetzt werdenkonnen: Transaktionskontrolle, Ressour-cenmanagement, Datenbankzugriff usw.Moderne Application Server, wie sie auchvon der EJB-Spezifikation beschriebenwerden, integrieren solche Dienste undbieten Programmierschnittstellen fur siean. Durch die Integration der verschiede-nen Dienste wird der Anwendungspro-grammierer unterstutzt, da er nicht mehrmit unterschiedlichen Werkzeugen arbeitenmuss. An dieser Stelle bringen Produktewie EJB-Container einen erheblichenMehrwert.

Wie wir aber in Kap. 2 festgestellt haben,hat die EJB-Architektur als solche die vonSun selbst zum Ziel gesetzte Trennungzwischen fachlicher und technischer Logiknoch nicht erreicht. Ebenso wird die ange-strebte Herstellerunabhangigkeit zwischenAnwendung und den verwendeten Pro-dukten (Application Server, Datenbanketc.) noch nicht erfullt, da die Spezifikationz. T. Lucken hat oder zu ungenau ist. Dieshat zur Folge, dass sich die in der EJB-Spe-zifikation versprochene Rollenverteilungim Entwicklungsteam nicht realisierenlasst.

Dies sind ernstzunehmende Mangel, mitdenen EJB-Projekte konfrontiert sind.Echte Konkurrenz zur EJB-Architektur istim Moment leider noch nicht vorhanden.CORBA und die zugehorige Komponen-tenarchitektur sind vielleicht am ehestenvergleichbar. Allerdings hat die schleppen-de Standardisierung viele Interessenten ab-geschreckt. Es macht sich auch bemerkbar,dass trotz ausgereifter Technologie keineentsprechendes Marketing hinter CORBAsteht. Die .NET-Technologie von Micro-soft entwickelt sich ebenfalls zu einemernstzunehmenden Konkurrenten. DieSpezifikation und die im Moment verfug-baren Produkte sind aber noch zu jung,um hier entsprechende Aussagen machenzu konnen.

Bei der Technologieauswahl ist auch abzu-wagen, ob die Vorteile der EJB-Architek-tur, wie Skalierbarkeit und Integrations-funktionalitat des Application Servers, diehohen Kosten, verursacht durch Lizenzen,Support, rare Fachkrafte und eigenenKnow-how-Erwerb, rechtfertigen. Man-ches Projekt lasst sich sicher mit wenigeraufwandigen Technologien wie z. B. Java-Servlets/Java-Server-Pages oder Zope

[Weit02] gut realisieren. Den Autoren sindproduktive Systeme bekannt, bei denen aufeinem Application Server genau ein(!) En-terprise Java Bean ablauft.

Unabhangig von der Technologie, fur dieman sich entscheidet, ist darauf zu achten,die Abhangigkeiten der fachlichen Logikvon der eingesetzten Technologie undauch dem konkret eingesetzten Produktgering zu halten, da sich die fachlichenAnforderungen immer unabhangig vonden technischen Gegebenheiten andern.Am Besten ist dies schon beim Systement-wurf durch eine geeignete Architekturmoglich, die die Trennung zwischen an-wendungsbestimmten Softwareteilen undtechnikbestimmter Software in den Mittel-punkt stellt.

Vorschlage fur solche Architekturen spe-ziell fur EJB-Anwendungen werden u. a.in [Seif02], [Such01] und [AlCM01] ge-macht. Dabei wird der Gedanke, dass EJBsfachliche Objekte darstellen, meist ganzlichaufgegeben. Ihnen bleibt nur die Aufgabe,technische Aspekte zu kapseln und dieDienste des Containers bereit zu stellen.Die fachlichen Objekte werden davon los-gelost in „normalen“ Java-Klassen imple-mentiert.

Eine derart gestaltete Architektur bringt ei-nen weiteren Vorteil mit sich: Die Arbeits-teilung im Team wird erleichtert, und eswerden jeweils weniger Experten fur denUmgang mit dem Application Server undahnlich techniklastigen Systemen einerseitsbzw. fur die Entwicklung der Anwen-dungslogik andererseits benotigt, da die ge-forderte Trennung im Code sich auch inder Teamarbeit widerspiegelt.

So kann erreicht werden, dass alle beno-tigten und vom Application Server zurVerfugung gestellten Dienste eingesetztwerden konnen und gleichzeitig die Wart-barkeit und Portierbarkeit der Softwareauch auf langere Sicht sichergestellt ist.

Literatur

[AkLa01] Akbar-Husain, Yasmin; Lane, Eoin: Op-timistic Locking pattern for EJBs. In: JavaWorld,http://www.javaworld.com, July 2001, Abruf am2002-03-05.

[AlCM01] Alur, Deepak; Crupi, John; Malks, Dan:J2EE Patterns. Prentice Hall, 2001.

[CaAl01] Caple, James; Altarace, Mike Haim: Theart of EJB deployment. In: JavaWorld,http://www.javaworld.com, August 2001, Abrufam 2002-03-05.

[Dijk76] Dijkstra, Edsger W.: A Discipline of Pro-gramming. Prentice Hall, 1976.

[Seif02] Seifert, Tilman: Persistenzmodelle in EJB-Architekturen. Diplomarbeit, Universitat Karls-ruhe (TH), Institut AIFB, 2002.

[SiDe00] Siedersleben, J.; Denert, E.: Wie baut manInformationssysteme? – �berlegungen zur Stan-dardarchitektur. In: Informatik Spektrum (2000)August.

[Such01] Sucharitakul, Akara: Seven Rules for Op-timizing Entity Beans.http://developer.java.sun.com/developer/techni-calArticles/ebeans/sevenrules/, Abruf am 2002-03-05.

[SunM01] Sun Microsystems Inc.: Enterprise Java-Beans Specification 2.0, 14.08.2001.ftp://ftp.java.sun.com/pub/ejb/947q9tbb/ejb-2_0-fr2-spec.pdf, Abruf am 2002-03-05.

[SunM02] Sun Microsystems Inc.: Java 2 Plattform,Enterprise Edition, Compatibility.http://java.sun.com/j2ee/compatibility.html, Zu-griff am 2002-03-05.

[TopL01] TopLink von der Firma WebGain, Inc.,USA.http://www.webgain.com/products/toplink, Ab-ruf am 2002-03-05.

[Weit02]Weitz, Wolfgang: Basisarchitekturen Web-basierter Informationssysteme. In: Wirtschafts-informatik 44 (2002) 3.


Abstract

Enterprise JavaBeans – critical remarks on a modern software architecture

Large web-based information systems make high demands on scalability, maintainability,reliability and security. In order to ease the development of such systems appropriate soft-ware architectures are needed. These architectures have to take into account business as-pects as well as requisite tools and products. Such an architecture is offered by Sun Micro-systems in the form of the Enterprise JavaBeans specification. Based on our experience fromdifferent projects we undertake a close examination of this architecture.

Keywords: web-based information systems, component-based architectures, EnterpriseJavaBeans, application server


Documents

Enterprise JavaBeans; Enterprise JavaBeans;