Enterprise JavaBeans 2 - inf.fu-berlin.de JavaBean… · Enterprise JavaBeans™ 2.0 Seminar KBSE Juli 2002 Seite 6/24 3.2 Der Zugriff auf eine EJB™ Jede EJB™ muss ein Home Interface

Enterprise JavaBeans™ 2.0 Seminar KBSE

Juli 2002 Seite 1/24

Enterprise JavaBeans™ 2.0

Sebastian Lempert, Hauke Traulsen

Institut für Informatik Freie Universität Berlin

{lempert, traulsen}@inf.fu-berlin.de Zusammenfassung Diese Ausarbeitung hat die Enterprise JavaBeans™ Spezifikation in der Version 2.0 [DEM01] zum Thema. Im Rahmen des Seminars „Komponentenbasierte Software-entwicklung“ [LOE02] wird das Konzept der Enterprise JavaBeans™ vorgestellt. Zu-nächst werden Grundlagen behandelt, die für das Verständnis von EJB™ unerläss-lich sind. Um den Rahmen für den Einsatz von EJB™ zu schaffen, wird eine Einfüh-rung in die in diesem Zusammenhang wichtigen Bestandteile von J2EE™ abgehan-delt, bevor zunächst auf den Stand der Entwicklung von EJB™ nach Spezifikation 1.1 [MAT99] eingegangen wird, um darauf folgend die Neuerungen in der Spezifika-tion 2.0 besser herausstellen zu können. Die Neuerungen sind u.a. Erweiterungen im Bereich CMP/CMR sowie die Einführung eines neuen Bean-Typs (Message Driven Beans) und der Local Interfaces.

1 Grundlagen

1.1 Multitier-Architektur

Im Bereich der Verteilten Systeme trifft man häufig auf Interaktionsbeziehungen zwi-schen Objekten. Ein Spezialfall hierfür ist das Client-Server-Modell, welches Mitte der Achtziger entstand. Dieses orientiert sich an der häufig auftretenden Situation aus dem täglichen Leben, in der Kunden (Clients) einem Anbieter eines Dienstes (Server) einen Auftrag erteilen. Dieser Sachverhalt lässt sich auf einen Methodenaufruf zwi-schen zwei Objekten abbilden. Anfang der Neunziger wurde das Basismodell, das aus zwei Schichten besteht, zu einer sogenannten Multitierarchitektur bzw. n-tier-Architektur erweitert, indem in der Mitte eine Komponente hinzugefügt wurde. Das gesamte Modell umfasst dann fol-gende Komponenten: Den Client (front-end) für die Darstellungslogik, die mittlere Komponente für gemeinsamen Zugriff und Kontrolle, sowie den Server (back-end) für die eigentliche Dienstleistung. Bedingt durch die Entstehung des Client-Server-Modells im Bereich der Verteilten Systeme befinden sich Client und Server im allgemeinen auf unterschiedlichen Rechnerknoten. Die Interaktion zwischen ihnen muss also über Rechnergrenzen hinweg erfolgen. Ein weit verbreitetes Verfahren für diesen Fall ist der sogenannte entfernte Prozeduraufruf oder RPC (Remote Procedure Call).

mailto:@inf.fu-berlin.de



Wenn sich Client und Server nicht auf dem gleichen Rechner befinden, müssen be-stimmte Anforderungen seitens des Systems erfüllt sein, damit die Interaktion ermög-licht wird. Für genaure Informationen zum Thema Verteilte Systeme siehe [LOE01].

1.2 Transaktionen

Eine Transaktion ist das bedeutsamste Konzept, wenn es darum geht, mit Unter-nehmensanwendungen umzugehen. Für einen Nutzer ist eine Transaktion ein ein-zelnes Ereignis, dass entweder eine Veränderung mit sich bringt oder nicht. Für Sys-tementwickler ist eine Transaktion eine Art zu programmieren, die es ihnen ermög-licht, Module zu schreiben, die an verteilten Berechnungen teilnehmen können. Um dieses Konzept zu veranschaulichen, nehme man einmal an, dass Geld von ei-nem Konto A auf ein zweites Konto B überwiesen werden soll. In diesem Fall wird die Transaktion als erfolgreich angesehen, wenn das Geld nicht mehr auf Konto A son-dern auf Konto B gutgeschrieben ist. Andernfalls darf sich nichts verändern, wenn aus irgendwelchen Gründen die Transaktion nicht durchgeführt werden kann. Es darf nicht plötzlich das Geld auf beiden Konten auftauchen, da das die Banken sicher nicht gutheißen, und das Geld darf nicht plötzlich auf keinem Konten auftauchen, da das der Überweisende sicher nicht gutheißt. Obwohl diese Anforderungen einfach zu verstehen sind, sind sie nicht automatisch leicht in verteilten Systemen zu realisieren, denn Server können Fehler machen, sogar abstürzen und Nachrichten können verlo-ren gehen. Eine Transaktion ist demnach ein Weg, eine Menge von Operationen zu einer atoma-ren Ausführungseinheit zu bündeln. Diese atomare "Alles oder Nichts"-Eigenschaft ist nicht neu, sondern tritt vielfach im alltäglichen Leben auf. Eine Menge von Parteien beteiligt sich an einer möglichen Transaktion. Wenn jede dieser Parteien zur Vollendung dieser Transaktion notwen-dig ist, muss jede Partei ihre Zustimmung zum Ablauf der Transaktion geben. Wenn auch nur eine jene Zustimmung nicht gibt, kann die Transaktion nicht durchgeführt werden und alles, was bisher als Teil der Transaktion durchgeführt wurde, muss rückgängig gemacht werden, was man im Allgemeinem mit dem Begriff Rollback be-zeichnet.

1.2.1 Eigenschaften von Transaktionen

Die Eigenschaften des Transaktionskonzepts werden oft unter der Abkürzung ACID zusammengefasst. Das sogenannte ACID-Paradigma steht dabei für vier Eigenschaften: § Atomicity (Atomarität): Diese Eigenschaft verlangt, dass eine Transaktion als

kleinste, nicht mehr weiter zerlegbare Einheit behandelt wird, d.h. entweder wer-den alle Änderungen der Transaktion in der Datenbasis festgeschrieben oder gar keine. Man nennt dies auch das "Alles oder Nichts" - Prinzip. Beispiel: Ein Objekt soll umbenannt werden. Bei einer erfolgreichen Transaktion (commit) wird der neue Name erzeugt und der alte Name gelöscht. War die Transaktion nicht erfolg-reich (rollback), dann ändert sich nichts.



§ Consistency (Konsistenz): Eine Transaktion hinterlässt nach Beendigung einen konsistenten Datenbasiszustand. Andernfalls wird sie komplett (siehe Atomarität) zurückgesetzt. Zwischenzustände, die während der Transaktionsbearbeitung ent-stehen, dürfen inkonsistent sein, aber der resultierende Endzustand muss die im Schema definierten Konsistenzbedingungen (z.B. referentielle Integrität) erfüllen. Beispiel: Beim Hinzufügen eines Elements in eine doppelt verkettete Liste müs-sen vier Zeiger (zweimal Vorgänger und zweimal Nachfolger) aktualisiert werden.

§ Isolation (Serialisierbarkeit): Diese Eigenschaft verlangt, dass nebenläufig (paral-lel, gleichzeitig) ausgeführte Transaktionen sich nicht gegenseitig beeinflussen: Nebenläufige Transaktionen müssen serialisierbar sein. Jede Transaktion muss – logisch gesehen – so ausgeführt werden, als wäre sie die einzige Transaktion, die während der gesamten Ausführungszeit auf der Datenbasis aktiv ist. Mit anderen Worten, alle anderen parallel ausgeführten Transaktionen bzw. deren Effekte dür-fen nicht sichtbar sein. Beispiel: Eine Transaktion, welche die o.g. doppelt verket-tete Liste traversiert, sieht keine nur teilweise vorgenommenen Änderungen einer anderen noch nicht abgeschlossenen Transaktion.

§ Durability (Dauerhaftigkeit / Persistenz): Die Wirkung einer erfolgreich abge-schlossenen Transaktion bleibt dauerhaft in der Datenbank erhalten. Die Transak-tionsverwaltung muss sicherstellen, dass dies auch nach einem Systemfehler (Hardware oder Systemsoftware) gewährleistet ist. Die einzige Möglichkeit, die Wirkungen einer einmal erfolgreich abgeschlossenen Transaktion ganz oder teil-weise aufzuheben, besteht darin, eine andere sogenannte kompensierende Transaktion auszuführen.

Anmerkung: Es gibt unterschiedlich starke bzw. schwache Konsistenzforderungen, die je nach Art der Anwendung ausreichend sein können, oder nicht. Allgemein wer-den die Konsistenzbedingungen durch eine Invariante beschrieben. Nach jeder Transaktion muss die Datenbasis in einem konsistenten Zustand hinterlassen wer-den, was bedeutet, dass die Invariante aufrechterhalten werden muss. Da Transaktionen vor allem im Zusammenhang mit Datenbanken auftreten sei an dieser Stelle für weitergehende Informationen hinsichtlich von Datenbanken auf [HIN02] verwiesen.

2 Java 2 Platform Enterprise Edition (J2EE™) Die Java 2 Platform Enterprise Edition (J2EE™) spezifiziert Schnittstellen für die dauerhafte Speicherung von Daten und deren Parallelverarbeitung. Des weiteren ist die J2EE™ für die Transaktionen und die Ausführung der Programme verantwortlich, um Geschäftsprozesse zu unterstützen. Insgesamt hat die Firma Sun mit der Java 2 Platform Enterprise Edition eine Refe-renzimplementierung der zugehörigen Spezifikation [SHA01] geschaffen, die gleich-zeitig eine Test- und Entwicklungsumgebung für Enterprise JavaBeans™ darstellt. Im Zusammenhang mit EJB™ kommt der J2EE™ die Rolle eines Servers bzw. Contai-ners zu.



2.1 J2EE™-Schnittstellen

Die J2EE™ umfasst mehrere Bestandteile. Dazu gehören: § Enterprise JavaBeans™ (EJB™): Implementierung von Geschäftslogik § Servlets und JavaServer Pages™ (JSP™): Verbindung von Web und Geschäfts-

logik; JSP™ [PEL01] stellen eine Erweiterung von Servlets dar. § Java Database Connectivity (JDBC™): Anbindung von relationalen Datenbanken § Connector API: Anbindung von ERP-Systemen § JavaMail™: Integration von E-Mail-Funktionalität § Java Transaction Service (JTS), Java Transaction API (JTA): Steuerung verteilter

Transaktionen § Java Messaging Service (JMS): asynchrone Kommunikation zwischen Anwen-

dungen

3 Enterprise JavaBeans™ (EJB™) Der Begriff Enterprise JavaBeans™ (EJB™) ist der Name einer Spezifikation, die es ermöglicht, serverseitig skalierbare, transaktionsorientierte Anwendungen auf Unter-nehmensebene zu schreiben, die außerdem sicher mit der gleichzeitigen Benutzung durch viele Klienten umgehen können. An dieser Stelle soll ein kurzer Überblick über die verschiedenen Versionen der Spe-zifikation gegeben werden, deren Kenntnis jeder EJB™-Entwickler besitzen sollte: § Enterprise JavaBeans™ [MAT98] § Enterprise JavaBeans™ Specification, v1.1 [MAT99] § Enterprise JavaBeans™ Specification, Version 2.0 [DEM01] § Enterprise JavaBeans™ Specification, Version 2.1 (Public Draft) [DEM02]

J2EE™-Architektur

Application Client Container Application

Client

J2SE™

JMS

JAA

S

JAX

P

JDB

C™

Web Container

JSP™ Servlet

J2SE™

Application Client Container

J2SE™

Applet

JMS

JAA

S

JTA

JAX

P

Con

nect

or Java

Mail™ JAF

EJB™ Container

J2SE™

JMS

JAA

S

JTA

JAX

P

Con

nect

or Java

Mail™ JAF

EJB™

HTTP SSL

HTTP SSL

Database

Die einzelnen Bestandteile der J2EE™ ergänzen sich und ermöglichen eine umfassende Unterstützung von Geschäftsprozessen. Ein Applikati-ons-Server implementiert die standardisierten Schnittstellen als Ablaufumgebung für Java Anwendungen

JDB

C™

JDB

C™



3.1 Architektur

Durch EJB™ wird eine konsistente Komponentenarchitektur beschrieben, welche die Entwicklung von n-tier Middleware ermöglicht. Die folgende Übersicht über die EJB™-Architektur ist aus [SES99] entnommen: Eine EJB™-Architektur besteht also aus den folgenden Bestandteilen: § einem EJB™-Server § EJB™-Containern, die auf diesem Server laufen § sog. "Home objects" , sog. "Remote EJB Objects" und Enterprise JavaBeans™

die in den Containern laufen § mindestens einem EJB™-Client § weiteren Hilfssystemen wie JNDI, JTS, Sicherheitsdiensten usw.

EJB™ Client

EJB™ Server

EJB™ Container

Enterprise Java Bean

Databases

Home Object

Enterprise Services and API

Nam

ing

Ser

vice

(J

ND

I)

Tran

sact

ion

Ser

vice

(J

TG)

Sec

urity

Mes

sagi

ng

EJB Object

Home Interface

Remote Interface

Locate, Create and Remove, instance of EJB

Invoke Business methods of EJB



3.2 Der Zugriff auf eine EJB™

Jede EJB™ muss ein Home Interface und Remote Interface aufweisen. Über diese Schnittstellen erfolgt der Zugriff auf die Bean. Die zu den beiden Schnittstellen kor-respondierenden Objekte Home Object bzw. EJB Object werden auf der Grundlage der Schnittstellen von dem EJB-Container automatisch generiert und sind nicht vom Entwickler zu implementieren. Die folgende Grafik [EBE01] illustriert den Zugriff auf eine EJB™: Damit ein Client auf eine EJB™ zugreifen kann, muss er sich zuerst über den Na-mensdienst an das Home Interface wenden, welches Zugriff auf das Home Object besitzt. Dieses erzeugt wiederum das EJB Object und sendet eine Referenz auf das zugehörige Remote Interface zurück an den Client. Über das Remote Interface ist der Client nun in der Lage, das EJB Object und somit auch die EJB™ anzusprechen. Für detailliertere Informationen über den grundsätzlichen Aufbau einer EJB™ und deren Verwendung siehe [PAW02].

3.3 Java Naming and Directory Interface (JNDI)

Bei dem Java Naming and Directory Interface (JNDI) handelt es sich um eine client-seitige Programmierschnittstelle (API), welche Namens- und Verzeichnisdienste zur Verfügung stellt. JNDI wurde nicht als Alternative zu bereits etablierten Namens- und Verzeichnisdiensten entwickelt, sondern als Schnittstelle zu eben diesen. Zu diesen existierenden Lösungen zählen: DNS, NDS, LDAP, CORBA und RMI. Durch JNDI werden die Details der o.g. unterschiedlichen Implementierungen von Namens- und Verzeichnisdiensten verborgen. Dadurch können diese Implementie-rungen nebeneinander koexistieren bzw. über einen JNDI-Client miteinander koope-rieren. Der Benutzer ist somit in der Lage, die unterschiedlichen Dienste transparent nutzen.

EJB-Container

Client

Rem

ote In

terface

EJB

EJB

Object

Hom

e In

terface

Home Object

2. Erzeuge EJB Object

5. Zugriff auf EJB

4. Zugriff auf EJB Object

1. Frage nach Referenz

3. Sende Referenz



3.4 Java Transaction Service (JTS)

Dem Java Transaction Service (JTS) kommt die Rolle des Transaktionskoordinators bzw. Transaktionsmanagers (transaction manager) zu, welcher alle Bestandteile ei-ner EJB™-Architektur überwachen muss. Diejenigen Komponenten, die eine transak-tionsgeschützte Ressource implementieren, wie z.B. relationale Datenbanken, wer-den Ressourcenmanager (resource managers) genannt. Wenn eine Anwendung eine Transaktion beginnt, dann wird zuerst ein Transaktions-objekt erzeugt, welches die Transaktion repräsentiert. Anschließend beauftragt die Anwendung die Ressourcenmanager mit der Ausführung der Transaktion. Während die Transaktion durchgeführt wird, behält der Transaktionsmanager sämtliche Res-sourcenmanager im Auge. Die erste Verbindung der Anwendung mit einem Ressour-cenmanager identifiziert dabei die Transaktion. Ab diesem Zeitpunkt werden sämtli-che Anweisungen zu der Transaktion gezählt. Dies geschieht solange, bis die Transaktion durch den Aufruf der Methode xa_commit() beendet wird. Wenn die Transaktion nicht erfolgreich beendet werden konnte, dann wird automatisch die Methode xa_rollback() aufgerufen, welche sämtli-che durch die Transaktion bewirkten Änderungen rückgängig macht. Wenn die An-wendung abstürzt, dann wird eine begonnene Transaktion durch den JTS abgebro-chen. Andernfalls wird der JTS durch die Anwendung beauftragt, die Transaktion zu beenden. Einmal beauftragt, versucht der JTS von allen an der Transaktion beteilig-ten Ressourcenmanagern eine erfolgreiche Nachricht zu bekommen, die die gelun-gene Abarbeitung der Transaktion bedeutet. Dabei kommt das Zweiphasen-Commit-Protokoll (two-phase commit / 2PC) zum Einsatz.

Java Application

JNDI API

Naming Manager

JNDI Server

LDA

P

DN

S

ND

S

NIS

CO

RB

A

(CO

S)

RM

I



Beispiel: Wenn die Anwendung sich an eine relationale Datenbank wendet, dann wird das Transaktionsobjekt an die über die JDBC™-Schnittstelle hergestellte Ver-bindung zur Datenbank gebunden und die Transaktion kann beginnen.

3.5 Warum EJB™ benutzen

EJB™ bietet ein Konzept an, dass es ermöglicht, sich auf die Entwicklung von Ge-schäftslogik (business logic) zu konzentrieren, sich dabei aber nicht mit den nerven-aufreibenden Eigenschaften und Eigenheiten der Entwicklung von Enterprise-Anwendungen befassen zu müssen. Dies kann dem Entwickler über die Nutzung von EJB™-Komponenten abgenommen werden. Diese Idee des codefreien Pro-grammierens kann man auch in Anwendungen wie z.B. Microsoft Visual Basic finden, wo ein Fenster mit Eigenschaften existiert, was die Programmierung der Objekte oh-ne das Schreiben von Code in gewissen Grenzen erlaubt. In einer typischen 3-tier-Architektur befindet sich die Geschäftslogik per Konvention in der mittleren Schicht. Mit EJB™ kann man die Geschäftslogik wohin auch immer verschieben und auch zusätzliche Schichten bei Bedarf einfügen: Die EJB™, die die Geschäftslogik enthalten, sind plattformunabhängig und können beispielsweise auf eine besser skalierbare Plattform verschoben werden. Wenn sich die Notwendigkeit ergibt, EJB™ von einer Plattform auf eine andere zu transferieren, dann kann dies ohne eine Änderung des für die Geschäftslogik zu-ständigen Codes geschehen. Das wichtigste Merkmal der EJB™-Spezifikation ist die Unterstützung bereits fertig-gestellter Komponenten, wodurch die mit "plug and work" bezeichnete Vorgehens-weise ermöglicht wird. Diese sieht vor, bereits existierende EJB™ in das eigene Pro-jekt zu integrieren, ohne diese selbst entwickelt oder getestet zu haben. Der Entwick-ler muss also nicht einmal über den internen Aufbau der hinzugekommenen EJB™ bescheid wissen. Die primären Vorteile von EJB™ sind:

Präsentation (first tier)

Geschäftslogik (middle tier)

Daten (third tier)

GUI Server Datenbank



§ Unabhängigkeit von der zugrundeliegenden Middleware: EJB™ isolieren den Ent-wickler von der zugrundeliegenden Middleware, da die einzige Umgebung, die der EJB™-Entwickler sieht, die Java-Umgebung ist. Des weiteren kann der Her-steller der Middleware (z.B. eines EJB™-Servers bzw. EJB™-Containers) Ver-besserungen vornehmen, ohne bestehende Enterprise-Anwendungen zu beein-flussen.

§ Plattformunabhängigkeit oder Write Once Run Anywhere (WORA): Da EJB™ auf der Java-Technologie aufbauen, profitieren Entwickler und Anwender von dem Umstand, dass EJB™-Komponenten plattformunabhängig sind. Solange sich ein EJB™-Server genau an die EJB™-Spezifikation hält, sollte jede EJB™-Komponente eines Drittherstellers in diesem Server lauffähig sein.

§ Strukturierte Anwendungsentwicklung: Die EJB™-Spezifikation bringt spezifische Rollen für die an der Entwicklung von Enterprise-Anwendungen beteiligten Per-sonengruppen mit sich. Die Einteilung der EJB™-Architektur in eine Geschäftslo-gik-, Präsentations-, und Datenebene bringt auch gleichzeitig eine Einteilung der Software mit sich. Somit kann sich ein Entwickler auf seinen Bereich konzentrie-ren ohne dabei die Bereiche eines anderen Entwicklers zu beeinflussen.

§ Transaktionsmanagement: Der Hersteller eines EJB™-Containers ist dazu ver-pflichtet eine Transaktionsüberwachung zu integrieren. Somit braucht sich der Entwickler von Geschäftslogik nicht mehr darum kümmern, ob eine Transaktion gestartet oder beendet wurde.

§ Verteiltes Transaktionsmanagement: Eine verteilte Transaktion bietet die Mög-lichkeit, eine Transaktion zu beginnen, innerhalb derer Methoden unterschiedli-cher EJB™ aufgerufen werden, welche auf unterschiedlichen Servern bzw. in un-terschiedlichen Virtuellen Maschinen laufen. Diese wiederum können auf unter-schiedlichen Rechnern sowie auf unterschiedlichen Plattformen laufen. Methoden einer EJB™, die Methoden anderer EJB™ aufrufen, werden in dem selben Transaktionskontext ausgeführt.

§ Portierbarkeit und Skalierbarkeit: EJB™, die sich an die EJB™-Spezifikation hal-ten, können auf jedem EJB™-Server installiert und ausgeführt werden.

§ Nahtlose Integration von CORBA: EJB™-Spezifikation und die CORBA-Spezifikation sind zueinander komplementäre Spezifikationen, die auf natürliche Weise zusammenwirken. Zum Beispiel kann CORBA/IIOP als robuster Transport Mechanismus innerhalb von EJB™ zum Einsatz kommen. Ebenfalls ist es mög-lich, dass reine CORBA Clients auf EJB™ als EJB™-Client zugreifen.

3.6 Die Komponentenidee

Verteilte Unternehmensanwendungen zu schreiben, war schon immer eine signifikante Herausforderung, aber dieses Mal hat sich etwas mit den Vorteilen von komponentenbasierter Programmierung im Generellen verbessert. Zum Beispiel ist der Modul-Charakter erhöht worden, wodurch man in der Lage ist, sehr umfangreiche Anwendungen durch einfaches Zusammenstecken vieler Komponenten mit eigen-ständiger Funktionalität zu generieren. Darüber hinaus sorgt der Modul-Charakter für eine erhöhte Wiederverwendbarkeit, da zusammengebaute Komponenten wiederum eine einzige große Komponente ergeben, welche wiederverwendet werden kann. Trotz der o.g. Modularität bestehen einige Herausforderungen, die während der Ent-wicklung eine wichtige Rolle spielen. Wenn früher in einem großen Softwaresystem



ein Fehler auftrat, dann wurde die ganze Einheit einfach neu entwickelt. Heutzutage ergibt sich die Herausforderung, die fehlerhafte Komponente zu finden und den Feh-ler zu isolieren, damit er sich nicht auf die anderen verbundenen Komponenten aus-wirken kann. Dieser Sachverhalt ist komplizierter als er schon im Zusammenhang mit Verteilten Systemen auftritt, auch wenn sich die Komponenten verteilt im Netzwerk befinden können. Dazu kommt noch die Komplexität, welche aus der Kombination heterogener Umgebungen entsteht, innerhalb derer sich EJB™ befinden. An dieser Stelle sei nochmals auf die unterschiedlichen Betriebssysteme und Plattformen hin-gewiesen, die durch EJB™ unterstützt werden.

3.7 JavaBeans™ vs. Enterprise JavaBeans™

JavaBeans™ Enterprise JavaBeans™

JavaBeans™ können zur Laufzeit sicht-bar oder unsichtbar sein. Im Falle der Sichtbarkeit können die Repräsentanten Button, Listen, etc. sein.

Eine EJB™ ist eine nichtvisuelles nichtlo-kales Objekt.

JavaBeans™ sollen lokal einem bestimm-ten Prozess angehören und sind dazu bestimmt clientseitig zu laufen. Man kann zwar auch serverseitige JavaBeans™ entwickeln, aber dann ist es viel einfacher stattdessen EJB™ zu benutzen.

EJB™ sind per Fernaufruf ausführbare Komponenten oder Geschäftsobjekte, die nur auf einem Server eingesetzt werden können.

JavaBeans™ ist eine Komponententech-nologie um generische Java Komponen-ten zu generieren, die zu Applets und Anwendungen zusammengefügt werden können.

Obwohl EJB™ eine Komponententechno-logie ist, baut diese weder auf JB auf noch erweitert sie die Original JavaBean Spezifikation.

JavaBeans™ besitzen ein externes Inter-face Properties, welches dafür zuständig ist, einer Entwicklungsumgebung die be-reitgestellte Funktionalität zu mitzuteilen.

EJB™ besitzen einen deployment desc-riptor, welcher die bereitgestellte Funktio-nalität beschreibt. Somit weiß eine Entwicklungsumgebung, wie sie mit einem EJB™ umzugehen hat.

JavaBeans™ können Infoklassen, Pro-perty-Editoren oder Customizer haben.

EJB™ haben all diese Konzepte nicht. Sie bieten keine zusätzlichen Informatio-nen an außer denen, die im deployment descriptor beschrieben sind.

JavaBeans™ sind ungetypt. Es gibt zwei Arten von EJB™: Session Beans und Entity Beans.

Es ist keine Transaktionsunterstützung vorgesehen.

EJB™ selbst können Transaktionen ver-wenden. Jeder EJB™-Server bringt Transaktionsmanagement mit sich.

Für JavaBeans™ sind sogenannte com-ponent bridges vorhanden: Beispielswei-

EJB™ können nicht als ActiveX-Control verwendet werden, da ActiveX-Controls



se kann ein JavaBean auch als ActiveX-Control eingesetzt werden.

auf dem Desktop und EJB™ in einem Server laufen.

4 EJB™ 2.0 Spezifikation In diesem Kapitel werden die Möglichkeiten, die sich mit der Nutzung von EJB™ er-öffnen, genauer betrachtet. Ein Schwerpunkt sind dabei die Veränderungen und Neuerungen, die die EJB™ Spezifikation 2.0 [DEM01] mit sich bringt. Zuerst erfolgt eine kurze Einführung von EJB™ 2.0 sowie die Darstellung der Neu-rungen dieser Spezifikation in einem Überblick. Danach erfolgt dann die detaillierte Betrachtung der relevanten Bereiche. Für einen noch tiefgehenderen Einblick in EJB™ 2.0, der vor allem den wichtigen Faktor Performance besonders berücksichtigt, sei auf [GRU02] verwiesen.

4.1 Überblick

Am 22. August 2001 wurde die EJB™ 2.0 Spezifikation im Status "Final Release" veröffentlicht [DEM01]. Dieses Release löste damit den "Proposed Final Draft 1" vom 23. Oktober 2000 und den "Proposed Final Draft 2" vom 19. April 2001 ab. Die Spezi-fikation ist um zwei Drittel größer als die Vorgängerversion 1.1 [MAT99] und umfasst genau 572 Seiten. Die Gebiete, auf denen schwerpunktmäßig Änderungen oder Neuerungen gegen-über früheren Spezifikationen aufgetreten sind, werden im folgenden in einem Über-blick vorgestellt:

4.1.1 Java Message Service (JMS)

Die JMS Spezifikation zur asynchronen Kommunikation wird in der EJB™ 2.0 Spezi-fikation [DEM01] benutzt, um das Konzept der Message Driven Beans zu ermögli-chen.

4.1.2 Message Driven Beans (MDB)

Nach Session und Entity Bean wird die Message Driven Bean als ein zusätzlicher dritter Beantyp eingeführt. Er ermöglicht asynchrone Methodenaufrufen durch Nach-richtenübermittlung via Java Message Service (JMS).

4.1.3 Local Interfaces

Um Serialisierung bei Methodenaufrufen zwischen in derselben JVM befindlichen Beans zu vermeiden, ist das Local Interface eingeführt worden.

4.1.3.1 Select Methoden

Derartige Methoden sind nur für den Gebrauch innerhalb einer Bean gedacht und dürfen nicht über die Interfaces für Clients sichtbar sein. Sie besitzen jedoch die glei-che Funktionalität wie Find Methoden.



4.1.3.2 Home Methoden

Bisher gab es nur die Methoden zur Steuerung der Beans allgemein im Home Inter-face. Dort können nun auch frei gewählt andere Methoden definiert werden. Diese beziehen sich jedoch prinzipiell auf statische Eigenschaften einer Bean und nicht auf die Manipulation einer einzelnen Instanz.

4.1.4 Container Managed Persistence (CMP)

Im Bereich CMP ist ein großer Teil der Änderungen von Spezifikation 1.1 [MAT99] auf Spezifikation 2.0 [DEM01] zu finden. Die wichtigsten Punkte sind § Container - Managed Relations § Cascade - Delete § Dependent Value Classes

4.1.5 Enterprise JavaBeans™ Query Language (EJB™ QL)

Mit dieser Anfragesprache ist es seit der Spezifikation 2.0 [DEM01] möglich, von der Persistenzschicht unabhängig Daten aufzufinden. Nur per CMP gespeicherte Beans können mit ihr gefunden bzw. abgefragt werden.

4.1.6 Inter-ApplicationServer-Kommunikation

In EJB™ 2.0 [DEM01] ist spezifiziert, wie Komponenten, die sich in Applicationser-vern verschiedener Hersteller befinden, mittels IIOP miteinander kommunizieren können.

4.1.7 Run-As Security

Über ein Rollenschema wird es dem Applicationserver ermöglicht, Berechtigungen zur Ausführung von Methoden zu überprüfen. Das Run-As Security Konzept erweitert das bereits bestehende Berechtigungskonzept für Enterprise JavaBeans™.

5 Änderungen im Detail In diesem Kapitel werden, die im vorrangegangenen Kapitel kurz angesprochenen Themenbereiche detailliert besprochen, um dem Leser ein genaues Bild der EJB™ Spezifikation 2.0 [DEM01] zu vermitteln.

5.1 Java Message Service (JMS)

Die aktuellste JMS Spezifikation ist die "Final Release 1.1" vom 12. März 2002. Die erste Spezifikation wurde jedoch bereits im August 1998 veröffentlicht. Die JMS API ist von Sun und einigen Partnerunternehmen entwickelt worden, um es Anwendun-gen zu ermöglichen, Nachrichten zu erstellen, zu senden, zu empfangen und zu le-sen. Die JMS Kommunikation hat folgende Eigenschaften: § asynchron § reliable



Asynchron bedeutet, dass der JMS - Server Nachrichten an den betreffenden Client ausliefert, sowie sie eintreffen. Der Client muss die Nachrichten nicht anfordern. Reliable bedeutet, dass JMS in der Lage ist, eine Nachricht sicher einmal und zwar genau einmal auszuliefern. Es besteht jedoch die Möglichkeit, auch geringere Anfor-derungen an die Übertragung zu stellen, wenn weniger benötigt wird (etwa Duplikate oder Nachrichtenverluste). Es geht bei JMS nicht um die Kommunikation zwischen Nutzern, sondern vielmehr die Kommunikation zwischen Prozessen, also zwischen Anwendungen und/oder Komponenten. Asynchrone Interprozesskommunikation wird als Konzept auch unter dem Namen Message - Oriented Middleware geführt. Der Producer ist im Zusammenhang von JMS der Hersteller und Absender einer Nachricht, der Consumer der Empfänger der Nachricht. Bei der Übermittlung kann man aus zwei verschiedenen Methoden wählen: § P2P § Publish/Subscribe P2P steht für Point To Point. Anders als man erwarten könnte, handelt es sich um keine über mehrere Nachrichten feststehende Verbindung zwischen einem Sender und genau einem Empfänger. Vielmehr handelt es sich bei P2P um die Verwendung sogenannter Queues. Eine Queue nimmt Nachrichten auf, die der einzige Sender schickt und speichert sie, und zwar solange bis ein möglicher Empfänger die Nach-richt erhalten hat. Es kann also mehrere potentielle Empfänger geben. Der Name P2P rührt nun daher, dass nur einer von ihnen für das Empfangen der Nachricht ausgewählt wird. Die anderen erhalten die Nachricht nicht. Der Empfänger schickt ein Acknowledgement. Bevor nicht dieses Acknowledgement nach möglicherweise mehreren Zustellversuchen eingetroffen ist, wird die Nachricht nicht aus der Queue gelöscht. Publish / Subscribe (auch kurz: pub/sub) ist dagegen ein Konzept, bei dem jeder po-tentielle Empfänger die Nachricht erhält. Hierbei spricht man aber nicht von einer Queue, sondern von einem Topic. An einem Topic kann sich ein neuer Consumer jederzeit anmelden, was mit Subscribe gemeint ist. Jeder Consumer, der sich bei einem Topic eingetragen hat, erhält jede Nachricht, die der Sender schickt; der Sen-der veröffentlicht quasi seine Nachricht (publish). Das hat zur Folge, dass auch kein Consumer zu einem Zeitpunkt eingetragen sein kann. pub/sub sollte also eingesetzt werden, wenn eine Nachricht keinen Abnehmer haben braucht. Sowohl Queues als auch Topics liegen auf einem JMS – Server und sind für Sender und Empfänger über den Namensdienst auffindbar. Auf diesem Server werden Nach-richten auch, falls dies aufgrund von Auslieferungsschwierigkeiten notwendig sein sollte, in einem persistenten Speicher solange gehalten, bis der Empfänger eben je-ne Nachricht erhalten hat. Der Producer schickt seine Nachricht zum JMS - Server. Zeitlich entkoppelt davon sorgt der Server für die Auslieferung der Nachricht an den Consumer. Sun spricht von diesem JMS - Server als JMS - Provider und sowohl Producer als auch Consumer fallen in die Kategorie Client.



Bei der übermittelten Nachricht handelt es sich um eine serialisierte Klasse vom Typ javax.jms.Message. Auf Consumerseite lässt sich ein sog. Selector definieren. Dabei handelt es sich um einen Filter, der bestimmte Nachrichten durchleitet und andere ignoriert. Ein Consu-mer kann einen String übergeben bekommen, der eine Anfrage aus Teilen der SQL-92 - Syntax beinhaltet, die sich auf Teile von Nachrichtenköpfen und anderen Eigen-schaften einer Nachricht bezieht. Diese Anfrage definiert den Selector, der nur im Falle einer positiven Auswertung der Anfrage, die Nachricht bearbeiten lässt. Der zur Realisierung des Konzeptes der Message Driven Beans erforderliche JMS – Server wird häufig in den EJB™ - Applicationserver integriert und somit meistens vom Server Provider mit angeboten.

5.2 Message Driven Beans (MDB)

Eine Message Driven Bean ist eine zustandslose Komponente, die von Java Messa-ges (javax.jms.Message) gesteuert wird. Wie schon die vorher spezifizierten Session - und Entity - Beans sind auch MDB serverseitig und transaktionssicher. Eine MDB wird vom EJB™ Container, in dem sie sich befindet, immer dann aufgeru-fen, wenn dieser eine Nachricht aus einer JMS Queue oder einem JMS Topic erhal-ten hat. Damit erfüllt eine MDB die Aufgabe eines Message Listeners. Vor der Einführung der MDB musste ein anderes Konzept genutzt werden, um asyn-chrone Methodenaufrufe in Enterprise Beans zu realisieren. Asynchrone Methodenaufrufe bis Spezifikation 1.1

Dabei wurde ein externes Java Programm eingesetzt (extern im Sinne von 'außer-halb des Applicationservers'), dass als Listener agierte und im Falle des Erhaltens einer JMS - Nachricht eine Methode einer Session Bean aufrief, die per Look - Up zuvor gefunden wurde. Die Nachricht wurde also außerhalb des EJB™ - Servers empfangen und war somit kein Teil einer Transaktion in eben diesem Server (Stich-wort Transaktionssicherheit). MDB löst dieses Problem.

Client

JMS-Server

Ext. Java Programm

Session Bean Pool

Applicationserver



Asynchrone Methodenaufrufe in Spezifikation 2.0

Es ist für in einem Applicationserver befindliche MDB von zweitrangiger Bedeutung, wer Absender einer Nachricht ist. Das kann ein Java Client, eine Enterprise Bean, eine JSP™ Komponente oder aber auch eine Anwendung, die selbst nicht auf J2EE™ aufbaut, sein. Der allgemeine Client sendet die Nachricht zum EJB™ Server, ohne sich der einzelnen vorhandenen MDB im Container bewusst zu sein. Der Grund für die mangelnde Sicht auf einzelne MDB ist das Fehlen von Home und Re-mote Interfaces bei diesem Beantyp.

5.2.1 Struktur einer MDB

Für eine MDB existieren weder Home- noch Remote - Interface. Es gibt nur die Beanklasse. Eine MDB ist vom Typ her eine zustandslose Session Bean. Das bedeutet, dass man es mit relativ kurzlebigen Instanzen der MDB zu tun hat, die sich keinen Client mer-ken können. Ein Client agiert mit einer MDB auf dieselbe Weise, in der er mit einer JMS Anwendung agieren würde. Durch die Einführung der MDB wird der EJB™ - Container der Version 2.0 zu einem Listener für asynchrone Aufrufe und ruft direkt (ohne Interfaces) die MDB auf, die sich dann wie eine zustandslose Session Bean verhält. Alle Instanzen eines MDB - Typs sind gleich, da sie nicht direkt für den Client sicht-bar sind und keine Zustände annehmen. Daraus resultiert die Möglichkeit für den Container, Pools aus MDB - Instanzen zu bilden, um Skalierbarkeit zu erzeugen. Eine MDB Klasse wird grundsätzlich public definiert und kann weder abstract noch final sein. Analog zu den anderen Beantypen implementieren auch MDB ein Marker – Interface. Es trägt den Namen MessageDrivenBean. In einer MDB gibt es eine Methode von zentraler Bedeutung. Eine MDB muss näm-lich die Schnittstelle javax.jms.MessageListener implementieren. Dies führt zur Implementierung der Methode onMessage(Message m). In ihr befindet sich die Logik, die das Eintreffen der vom Container als Parameter übergebenen Nachricht verarbeiten soll. Eine Message Driven Bean muss einen Konstruktor ohne Parameter enthalten und eine abgesehen von den typischen create- und remove-

Client

JMS-Server MDB

Pool

Applicationserver



Methoden eine MDB - spezifische Methode setMessageDrivenContext (MessageDri-venContext mdc), die vom EJB™ Container nach dem Erschaffen der Instanz aufgerufen wird. Das Fehlen des Home - und Remote – Interfaces führt bei einer MDB zu dem Prob-lem, dass man einer MDB – Instanz nicht bei Erschaffung den bereits erwähnten Se-lector übergeben kann. Aus diesem Grund hat man den Deployment Descriptor er-weitert. Er bietet nun die Möglichkeit, einen derartigen Selector für jede Message Driven Bean zu definieren. Zu diesem Zweck existiert ein Element <message-selector>, innerhalb dessen man mit einer in der JMS - Spezifikation vereinbarten und bereits erwähnten Syntax einen Filter spezifizieren kann.

5.3 Local Interfaces

Die Enterprise JavaBeans™ Spezifikation in der Version 1.0 [MAT98] bzw. in der Version 1.1 [MAT99] bringt ausschließlich Remote Interfaces mit sich: Schnittstellen deren Methoden durch Fernaufrufe über RMI (Remote Method Invocation) angespro-chen werden. Auf Beans wird somit immer zugegriffen, als seien sie auf einem ent-fernten System gelegen. Dies hat zur Folge, dass Methodenaufrufe stets über zwischengeschaltete Stubs bzw. Skeletons laufen und dabei sämtliche Parameter serialisiert und anschließend wieder deserialisiert werden müssen. Unter diesem nicht unerheblichen Verwal-tungsaufwand leidet die Performance von EJB™ ganz erheblich. Gerade bei Beans, die nebeneinander bzw. innerhalb der gleichen JVM (Java Virtual Machine) ablaufen ist diese Vorgehensweise um so ärgerlicher, da der Performance-verlust vermeidbar erscheint: Mit der Einführung von Local Interfaces in der Enterpri-se JavaBeans™ Spezifikation 2.0 [DEM01] wird genau diese Problemstellung adres-siert. Durch sie ist es möglich, dass Beans, die in der selben JVM laufen, Aufrufpa-rameter per Referenz übergeben. Ein solcher lokaler Methodenaufruf ist theoretisch bis zu 10000mal schneller als ein entfernter Methodenaufruf. Eine ausführliche Ab-handlung, warum dieser theoretische Geschwindigkeitsgewinn nicht immer umge-setzt werden kann, findet sich in [SCH02]. Zusammen mit den Local Interfaces wurde eine neue Terminologie eingeführt, die an dieser Stelle kurz angesprochen werden soll. Es lassen sich nun vier verschiedene Interfaces unterscheiden, von denen bereits zwei bekannt sind, die nun allerdings unter anderen Namen auftreten:



Art Aufgabe

Local Interfaces Remote Interfaces

Home Interfaces

Lebenszyklus der EJB™: Methoden zum Erzeu-gen, Suchen und Lö-schen von Beans. Neu: Home Methods.

Local Home Inter-face

Remote Home In-terface (ehemals Home Interface)

Component Interfaces

Zugriff auf die Geschäfts-logik und die Attribute von EJB™.

Local Component Interface

Remote Compo-nent Interface (ehemals Remote Interface)

Es ist zu beachten, dass die Implementierung einer Bean mit Local Interfaces (also Local Home und Local Component Interface) eine gleichzeitige Implementierung der Remote Interfaces (also Remote Home und Remote Component Interface) nicht aus-schließt. Daraus ergibt sich, dass eine Bean alle vier der o.g. Interfaces besitzen kann. Ein daraus resultierender Nebeneffekt ist die Aufgabe der Ortsunabhängigkeit (location transparency), da der Programmierer nun gezwungen ist zu entscheiden, ob der Zugriff innerhalb der gleichen JVM oder auf ein entferntes System stattfindet. In diesem Zusammenhang wird zwischen einem feingranularem und grobgranularem Zugriff bzw. zwischen einer feinen und groben Sicht auf eine Bean unterschieden: Wenn mehrere Beans einander häufig aufrufen, beispielsweise weil sie im Lebens-zyklus voneinander abhängen oder in einem engen fachlichen Zusammenhang ste-hen, dann handelt es sich um einen feingranularen Zugriff. Dem Entwickler werden durch die Local Interfaces und die Remote Interfaces Werkzeuge an die Hand gege-ben, mit dem er die feine bzw. grobe Sichtweise steuern kann.

5.3.1 Home Methods

Home Methods sind Methoden, die zusätzlich zu den bekannten create(), remove() und find() Methoden in einem Home Interface definiert werden können. Es handelt sich dabei um ein mit der Enterprise JavaBeans™ Spezifikation 2.0 [DEM01] einge-führtes Konzept für Entity Beans: Die aus der normalen Java-Programmierung bekannten Klassenmethoden können nun auch in Entity Beans verwendet werden. Home Methods bezeichnen also Klassenmethoden von Entity Beans. Der Aufruf ei-ner solchen Methode bezieht sich nicht nur auf eine einzelne Instanz (Instanzmetho-de), sondern auf eine Menge von Instanzen. In einem Home Interface können somit Klassen- und Instanzmethoden auftauchen, während es sich bei den Methoden eines Component Interfaces stets um Instanzme-thoden handelt. Eine wichtige Eigenschaft von Klassenmethoden ist, dass sie zu einem anderen Zu-stand im Lebenszyklus einer Entity Bean ausgeführt werden als Instanzmethoden. Eine genau Übersicht liefert die folgende Tabelle:



Zustand Bedeutung aufrufbare Methoden

does not exist Initialer Zustand: Es exis-tiert noch keine Instanz.

keine

pooled

Alle Instanzen in diesem Zustand sind gleich, d.h. die Attribute der Entity Bean wurden noch nicht belegt.

EJB™select() und Home Methods (Klassenmeth-oden)

ready Konkrete Instanz, deren Attribute eine bestimmte Ausprägung vorweisen.

Methoden aus dem Component Interface (Instanzmethoden)

5.4 Container Managed Persistence (CMP)

CMP steht für Container Managed Persistence. Dieses Konzept transferiert die Ver-antwortlichkeit für die Persistenz von Entity Beans vom Bean Entwickler zum Ent-wickler des Containers. Das Gegenteil von CMP heißt BMP, was analog Bean Managed Persistence bedeu-tet. Bei BMP schreibt der Bean Entwickler selbst den Code, der die Persistenz der entsprechenden Bean gewährleistet. War in der Version 1.1 der Bereich CMP noch stellenweise ungenau, so ist die Spezi-fikation 2.0 bedeutend genauer und die Portierung von Sourcecode von Beans, die CMP benutzen, deutlich leichter geworden. Neben der genaueren Fassung bereits bestehender Konzepte sind neue Möglichkei-ten im Bereich CMP hinzugekommen. Eine der Neuerungen ist die Modellierung von Abhängigkeiten (Beziehungen) von Enterprise Beans untereinander, das sogenannte Cascade – Delete. Das bereits aus dem Bereich der Datenbanken bekannte Löschen abhängiger Datensätze ist nun auch auf der Ebene der Enterprise Beans spezifizierbar.

5.4.1 CMP vs. BMP

Seit der Enterprise JavaBeans™ Spezifikation 1.1 [MAT99] bzw. insbesondere seit der Version 2.0 [DEM01] sind zwei Konzepte zur dauerhaften Speicherung (Per-sistenz) von Attributen einer Entity Bean vorgesehen: Bean Managed Persistence (BMP) und Container Managed Persistence (CMP). Im folgenden sollen beide Kon-zepte gegenübergestellt und hinsichtlich der folgenden sechs Punkte verglichen wer-den: § Flexibilität: Wie viele Freiheiten hat der Bean-Entwickler? Können bestimmte Wer-

te auf bestimmte Art und Weise abgelegt werden? Lässt sich festlegen, in welche Tabellen Daten geschrieben bzw. aus welchen Tabellen Daten gelesen werden?



§ Aufwand: Welchen Implementierungsaufwand muss der Entwickler zur Umset-zung der Persistenz investieren?

§ Wartbarkeit: Wie gut kann bestehender Programmtext an neue Anforderungen (z.B. an ein zusätzliches Attribut) angepasst werden?

§ Fehleranfälligkeit: Wie wahrscheinlich es ist, dass der Entwickler bei der Umset-zung der Persistenz Fehler in der Implementierung macht?

§ Portierbarkeit: Wie leicht lässt sich eine bestehende Enterprise-Anwendung an eine veränderte Umgebung, z.B. an einen anderer Server oder an eine andere Datenbank, anpassen?

§ Performance: Kann immer die effizienteste Anfrage (z.B. an eine Datenbank) rea-lisiert werden?

5.4.2 Bean Managed Persistence (BMP)

Bei diesem seit der Enterprise JavaBeans™ Spezifikation 1.0 [MAT98] existierendem Konzept ist vorgesehen, dass die notwendige Funktionalität zum dauerhaften Spei-chern einer Entity Bean vom Entwickler der Bean implementiert wird. Der Standard sieht dabei die Implementierung sogenannter Callback-Methoden ejbLoad(), ejbStore(), ejbCreate(), usw. vor. Dabei ist man abhängig von der Anfra-gesprache der unter dem Applikationsserver liegenden Persistenzschicht. Hierbei kommt zumeist die Structured Query Language (SQL) zum Einsatz, welche von rela-tionalen Datenbanken zur Anfrage und zur Manipulation der Datenbasis verwendet wird:

Methode SQL-Befehl

ejbCreate() INSERT

ejbStore() UPDATE

ejbLoad() SELECT

ejbRemove() DELETE

ejbFindBy<XXX>() spezielles SELECT

Der Vorteil bei dieser Vorgehensweise liegt in der maximalen Freiheit des Entwick-lers bei der Gestaltung der Speicherungsfunktionalität. Die Entscheidung, welches Bean-Attribut in welche Spalte einer Datenbanktabelle geschrieben wird, obliegt dem Entwickler. Auch die gegenüber CMP erzielbare Performance ist als Vorteil zu ver-zeichnen, da dem Entwickler in der Ausgestaltung der Abfragen sämtliche Möglich-keiten zur Verfügung stehen. Eine relativ gute Portierbarkeit ist gegeben, wenn der Typ der Persistenzschicht nicht geändert wird. Im Falle von relationalen Datenbanken bedeutet dies, dass die Chan-cen auf eine einfache Portierbarkeit nur dann bestehen, wenn keine datenbankspezi-fischen Features genutzt werden. Eine weitere Voraussetzung ist die Unterstützung des selben SQL-Standards durch die unterschiedlichen Datenbanksysteme.



Nachteilig bei diesem Konzept ist die ungleich höhere Wahrscheinlichkeit einer feh-lerhaften Implementierung gegenüber CMP, da der Entwickler hier alles selbst imp-lementieren und testen muss. Des weiteren ist der hohe Aufwand bei der Entwick-lung zu nennen. Beispielsweise führt das alleinige Hinzufügen eines einzelnen Attri-butes zu einer Änderung sämtlicher Callback-Methoden, welche anschließend einem erneuten Test unterzogen werden müssen.

5.4.3 Container Managed Persistence (CMP)

Das Konzept der Container Managed Persistence (CMP) besteht seit der Version 1.1 der Enterprise JavaBeans™ Spezifikation [MAT98]. Allerdings räumt erst die Version 2.0 [DEM01] mit den Limitationen der vorangegangenen Version auf und bringt eine umfangreiche Erweiterung der Architektur CMP mit sich. Das Ziel ist, dass der Entwickler das Datenbankschema nicht kennen muss, sondern dass durch CMP ein Mapping zwischen dem abstrakten und dem physischen Sche-ma vollzogen wird. Die Steuerung der Persistenz soll durch den Server erfolgen. Vom Bean-Entwickler müssen lediglich die Objekteigenschaften angegeben werden, die gesichert werden sollen. Um Entity Beans persistent zu machen, sieht dieses Konzept die Deklaration sämtli-cher Attribute im Deployment Descriptor vor. Des weiteren muss das objektrelationa-le Mapping, also die Abbildung zwischen den Attributen und den Datenbankstruktu-ren, im Deployment Descriptor angegeben werden. Der Server ist somit in der Lage, selbständig die benötigte Datenbanktabelle zu er-zeugen bzw. Eintragungen innerhalb dieser vorzunehmen. Auch bei Änderungen von Attributen einer Entity Bean werden die Daten vom Server automatisch in der Tabelle gespeichert. Bei einer Suchanfrage kommt ebenfalls der Server zum Einsatz. Damit diese "Automatik" funktioniert, muss jeder Server ein Generatorwerkzeug mitbringen, welches in der Lage ist, aus dem Deployment Descriptor Code zu erzeugen, der die o.g. Funktionalität bietet. Der Bean-Entwickler muss also keine einzige Zeile Programmtext verfassen, die mit dem Datenbankzugriff zusammenhängt. Dies ist ein klarer Vorteil und reduziert den Entwicklungsaufwand beträchtlich. Außerdem ergibt sich aus der Abhängigkeit von CMP Entity Beans von einem Generator ein weiterer Vorteil: Man ist unabhängig von der darunter liegenden Persistenzschicht, was einer sehr hohen Portierbarkeit ent-spricht. Eine verbesserte Wartbarkeit ist dadurch gegeben, dass Änderungen am Namens-schema bzw. an den Attributen einer Bean konsistent durch den Generator berück-sichtigt werden. Auch die Fehleranfälligkeit ist vergleichsweise gering, woraus folgt, dass der generierte Code nicht so intensiv getestet werden muss, wie selbst ge-schriebener Quelltext. Dies bringt jedoch den Nachteil mit sich, dass die Datenbankzugriffe nicht immer so effizient sein können, wie bei selbst geschriebenem Code. Trotzdem bringen viele Server Optimierungen mit sich, welche an die Nutzung von CMP gebunden sind. Im folgenden soll auf drei wichtige Konzepte, die im Zusammenhang mit CMP Entity Beans auftreten, näher eingegangen werden:



§ Container Managed Relations (CMR) § Cascaded Delete § EJB™-QL

5.4.4 Container Managed Relations (CMR)

Die Verwaltung der Relationen zwischen verschiedenen Enterprise JavaBeans™ kann seit der Version 2.0 der Spezifikation [DEM01] dem Container überlassen wer-den. Eine Voraussetzung dafür ist jedoch, dass es sich bei den zu verwaltenden Beans um CMP Entity Beans handelt. Des weiteren müssen die Relationen im Deployment Descriptor angegeben werden. In der entsprechenden Bean müssen abstrakte get() und set() Methoden definiert werden, welche den Attributen der Relationen entsprechen. Die tatsächliche Imple-mentierung dieser Methoden erfolgt durch den Containerhersteller, welcher wieder-um einen Generator zur Verfügung stellen muss. Sämtliche aus dem Datenbankentwurf bekannten Kardinalitäten werden unterstützt: 1-zu-1, 1-zu-m und m-zu-n Beziehungen können im Deployment Descriptor angege-ben werden. Dabei ist es möglich, die Relationen entweder nur in eine Richtung (uni-direktional) bzw. in beide Richtungen (bidirektional) zu traversieren. Die dabei ver-wendete Semantik ist in eindeutiger Weise in der Spezifikation 2.0 [DEM01] be-schrieben. Eine weitere Aufgabe, die in diesem Zusammenhang dem Container zu-kommt, ist die Gewährleistung der referentiellen Integrität in der Datenbasis.

5.4.5 Cascaded Delete

Der sogenannte Cascaded Delete ist ein Begriff, der im Zusammenhang mit Daten-banken auftritt. Dabei geht es um das automatische Entfernen von Datensätzen, die von einem übergeordneten Datensatz abhängig sind, sobald der übergeordnete Da-tensatz gelöscht wird. Ein Beispiel dafür ist eine Rechnung, welche aus mehreren Positionen besteht. Wenn die Rechnung gelöscht wird, dann sollten auch die zugehörigen Rechnungs-positionen gelöscht werden, damit die Datenbasis in einem konsistenten Zustand verbleibt. Diese Aufgabe kann dem Programmierer nun bei den Cascaded Deletes abgenommen werden und wird vom Containerhersteller übernommen. Allerdings lassen sich Cascaded Deletes nur auf 1-zu-1 bzw. 1-zu-n Beziehungen definieren bzw. anwenden, da das Element, von dem der Löschvorgang gestartet wird, eine Kardinalität von 1 aufweisen muss. Auch hier werden die für Cascaded Deletes notwendigen Informationen im Deployment Descriptor hinterlegt.



5.4.6 Übersicht

CMP BMP

Flexibilität Eingeschränkt, da von Ge-neratorwerkzeugen abhän-gig.

Sehr flexibel.

Aufwand

Sehr geringer Aufwand: Fast alle Aufgaben werden vom Containerhersteller bzw. dessen Generator-werkzeugen übernommen.

Hoch, da alles vom Ent-wickler implementiert wer-den muss.

Wartbarkeit / Feh-leranfälligkeit

Gute Wartbarkeit, da wenig zeitaufwendig; Tests für automatisch generierten Code sind einfach zu ges-talten.

Schlechte Wartbarkeit, da selbst geschriebener Code potentiell fehleranfällig ist.

Portierbarkeit Sehr gut, da die Unabhän-gigkeit von der Persistenz-schicht gegeben ist.

Relativ gut, solange die Art der Persistenzschicht die gleiche bleibt.

Performance Nur durch Erweiterungen der Containerhersteller nutzbar, wodurch sich eine Abhängigkeit ergibt.

Optimal.

5.5 EJB™-QL

Die Abkürzung EJB™-QL steht für Enterprise JavaBeans™ Query Language. Dabei gibt es nicht nur in der Namensgebung Ähnlichkeiten zu der Structured Query Lan-guage (SQL). Bei EJB™-QL handelt es sich um eine Untermenge von SQL 92. Aller-dings ist die EJB™-QL eine reine Abfragesprache, was bedeutet, dass mit EJB™-QL keinerlei Datenmanipulationen vorgenommen werden können. Die Enterprise JavaBeans™ Spezifikation in der Version 2.0 [DEM01] beschreibt die EJB™-QL als "query specification language", welche auf dem in dem Deployment Descriptor angegebenen abstrakten Schema der Bean arbeitet. Das heißt, dass die EJB™-QL ausschließlich im Zusammenhang mit dem Deployment Descriptor ver-wendet wird, sie wird nicht innerhalb der Beans implementiert. Auf der Bean-Seite müssen lediglich die Signaturen von sogenannten find<XXX>() bzw. select<XXX>() Methoden definiert werden, die Implementierung erfolgt automa-tisch durch einen weiteren Generator, welcher abermals vom Containerhersteller zur Verfügung gestellt werden muss. Damit dies funktioniert, müssen die o.g. Signaturen komplett im Deployment Descriptor wiederholt werden.



6 Ausblick Für die nächste Version 2.1 der Enterprise JavaBeans™ Spezifikation [DEM02] wur-de am 17. Juni 2002 ein Public Draft veröffentlicht. D.h. es handelt sich noch nicht um die endgültige Version, jedoch lässt sich daraus ableiten, in welche Richtung die weitere Entwicklung von EJB™ gehen wird. Zu den neuen Punkten zählen: § Verbesserte Unterstützung von Webservices § Einführung eines container-managed timer service § Erweiterung der EJB-QL durch „ORDER BY“ und Aggregationsoperatoren. § Neue Nachrichtentypen für Message Driven Beans

7 Literatur und Links [EBE01] A. Eberhart, S. Fischer (2001)

Java-Bausteine für E-Commerce-Anwendungen Hanser

[SES99] G. Seshadri (1999)

Enterprise Java Computing – Applications and Architecture Cambridge University Press

[GRU02] V. Gruhn, M. Schneider (2002)

EJB 2.0 Anwendungen Addison-Wesley

[MAT98] V. Matene, M. Hapner (1998)

Enterprise JavaBeans™ http://www.java.sun.com/products/ejb/docs.html

[MAT99] V. Matene, M. Hapner (1999)

Enterprise JavaBeans™ Specification, v1.1 http://www.java.sun.com/products/ejb/docs.html

[DEM01] L. DeMichiel, L. Yalçinalp, S. Krishnan (2001)

Enterprise JavaBeans™ Specification, Version 2.0 http://www.java.sun.com/products/ejb/docs.html

[DEM02] L. DeMichiel (2002) Enterprise JavaBeans™ Specification, Version 2.1 (Public Draft) http://www.java.sun.com/products/ejb/docs.html [SHA01] B. Shannon (2001)

Java 2 Platform Enterprise Edition Specification, v1.3 http://java.sun.com/j2ee/download.html

[PAW02] M. Pawlan, D. Green, K. Haase, S. Bodoff,

E. Jendrock, B. Stearns (2002) The J2EE™ Tutorial http://java.sun.com/j2ee/download.html

http://www.java.sun.com/products/ejb/docs.html




http://java.sun.com/j2ee/download.html

http://java.sun.com/j2ee/download.html



[PEL01] E. Pelegri-Llopart (2001) JavaServer Pages™ Specification Version 1.2 http://java.sun.com/products/jsp/download.html

[SCH02] H.A. Schmid (2002)

An Evaluation of the Use of Enterprise JavaBeans 2.0 Local Interfaces University of Applied Sciences, Konstanz

[LOE01] K.P. Löhr, T. Fink (2001) Vorlesung: Verteilte Systeme Freie Universität Berlin, Institut für Informatik http://www.inf.fu-berlin.de/lehre/WS01/VS/index.html bzw. http://www.inf.fu-berlin.de/lehre/WS01/VS/lect.html [LOE02] K.P. Löhr, K. Otto (2002) Seminar: Komponentenbasierte Softwareentwicklung Freie Universität Berlin, Institut für Informatik http://www.inf.fu-berlin.de/lehre/SS02/KBSE/index.html bzw.

http://www.inf.fu-berlin.de/lehre/SS02/KBSE/theme.html [HIN02] A. Hinze, Z. Kanaeva (2002) Vorlesung: Einführung in Datenbanksysteme Freie Universität Berlin, Institut für Informatik http://www.inf.fu-berlin.de/lehre/SS02/DBS/index.html bzw. http://www.inf.fu-berlin.de/lehre/SS02/DBS/skripte.html

http://java.sun.com/products/jsp/download.html

http://www.inf.fu-berlin.de/lehre/WS01/VS/index.html

http://www.inf.fu-berlin.de/lehre/WS01/VS/lect.html

http://www.inf.fu-berlin.de/lehre/SS02/KBSE/index.html

http://www.inf.fu-berlin.de/lehre/SS02/KBSE/theme.html

http://www.inf.fu-berlin.de/lehre/SS02/DBS/index.html

http://www.inf.fu-berlin.de/lehre/SS02/DBS/skripte.html

Documents

Enterprise JavaBeans 2 - inf.fu-berlin.de JavaBean… · Enterprise JavaBeans™ 2.0 Seminar KBSE Juli 2002 Seite 6/24 3.2 Der Zugriff auf eine EJB™ Jede EJB™ muss ein Home Interface