Enterprise JavaBeans

Transkript

1 Enterprise JavaBeans Übersicht Marc Monecke Praktische Informatik Fachbereich Elektrotechnik und Informatik Universität Siegen, D Siegen 1. Juli 2003 Zusammenfassung Enterprise JavaBeans (EJB) sind ein quasi-standard für serverseitige, in Java implementierte Komponenten. EJB-Server und EJB-Container stellen eine Infrastruktur für diese Komponenten bereit und bieten Basisdienste an, die vom Anwendungsentwickler beim Bau von Geschäftsanwendungen direkt genutzt werden können. In diesem Skript wird die EJB-Technologie vorgestellt und es werden die verschiedenen Bean-Typen mit ihren Merkmalen erläutert. Inhaltsverzeichnis 1 Einleitung und Überblick Komponenten in Geschäftsanwendungen Übersicht Java Enterprise-Architektur Dienste und Schnittstellen Dienste des EJB-Containers Technische Details von Enterprise JavaBeans Bean-Typen Bestandteile einer Bean EJB-Architektur Beispiel: HelloWorld EJB-Server/Container OpenEJB Entity Beans Lebenszyklus Persistenz

2 4.3 Container-Managed Persistence Beispiel: CMP Entitiy Bean Bean-Klasse Deployment Descriptor Suchanfragen mit EJB-QL (ab EJB 2.0) Beispiele für EJB-QL-Anfragen Bean-Managed Persistence Session Beans Lebenszyklus von Session Beans Zustandslose Session Beans Zustandsbehaftete Session Beans Container-Dienste Rollenbasierte Zugriffskontrollen Transaktionen Transaktionsattribute EJB in der Praxis Rollen bei Entwicklung und Einsatz Sichten auf die EJB-Technologie Anwendungsentwicklung Komponenten-Paradigma Unternehmen Zusammenfassung 25 2

3 1 Einleitung und Überblick Enterprise JavaBeans 1997 von Sun Microsystems vorgeschlagen schnell von zahlreichen Herstellern akzeptiert quasi-standardisiertes serverseitiges Komponentenmodell, wird von vielen Komponenten-Transaktionsmonitoren (CTM) unterstützt Investitionssicherheit Basis für Framework- und Komponenten-Industrie nutzt weitere Java-Technologien (JDBC, JNDI, JavaMail) zum Teil proprietäre Erweiterungen unabhängig von der Implementierung systemnaher Dienste, kann daher auf vorhandene CTM aufsetzen dies hat mit zur starken Verbreitung von EJB beigetragen, weil vorhandene Produkte, in die ein großer Entwicklungsaufwand investiert wurde, weiterhin genutzt werden können. EJB haben nur wenig mit JavaBeans zu tun (vgl. Vorlesung in STII dazu): JavaBeans zielen eher auf GUI-Komponenten, die mit GUI builder-werkzeugen zu einer Anwendung zusammengesetzt werden. EJB sind hingegen Komponenten von Geschäftsanwendungen, die keine graphische Repräsentation haben müssen. Sie werden bei der Installation zu einer Anwendung zusammengesetzt und an die jeweilige Situation angepaßt (customizing). Dazu werden Werkzeuge des EJB-Applikationsservers verwendet. aktuell ist die EJB-Version 2.0; hier wird hauptsächlich EJB 1.1 behandelt. Auf einige Unterschiede und Neuerungen wird später kurz eingegangen. 1.1 Komponenten in Geschäftsanwendungen Ziel: Das Ziel der komponentenbasierte Software-Entwicklung ist es, den Anwendungsentwickler von technischen Details bei der Realisierung seiner Anwendung abzuschirmen. Er soll sich allein auf die Realisierung der Geschäftslogik konzentrieren. Andererseits ermöglichen es Komponenten, Anwendungen modular aus Bausteinen zusammenzusetzen. Dadurch können Kosten gesenkt und es kann die Wartbarkeit, Erweiterbarkeit und die Qualität der resultierenden Anwendung erhöht werden. Merkmale von Komponenten: Die interne Realisierung wird versteckt. Komponenten stehen mit der Außenwelt nur über die angebotenen Dienste in Verbindung. Die angebotene Menge von Diensten wird in der Schnittstelle der Komponente zusammengefaßt. Bezug auf die Anwendungswelt: Bei Geschäftsanwendungen entstammen die Komponenten der Anwendungswelt etwa Kunde, Lieferung, Lagerverwaltung oder Abrechnung. Bei der Konstruktion einer Anwendung können also die Konzepte und Begriffe verwendet werden, in denen der spätere Benutzer denkt. Der Entwickler dieser Komponenten kann sich voll auf die Geschäfts- oder Fachlogik konzentrieren und muß sich nicht um technisch Details kümmern dies übernimmt der Entwickler der Basistechnologien (zu den unterschiedlichen Rollen vgl. Abschnitt 7.1). 3

4 2 Übersicht 2.1 Java Enterprise-Architektur J2EE Server Klient Servlet JSP Browser Servlet Container Datenbank Applikation Enterprise Bean Enterprise Bean EJB Container Kommunikation/ Datenaustausch Abbildung 1: Übersicht über die J2EE-Architektur EJB sind Teil der Java Enterprise-Architektur (J2EE). Abbildung 1 zeigt die Zusammenhänge: Die Benutzungsschnittstelle einer Anwendung wird auf einem Klienten-Rechner ausgeführt. Sie kann durch eine Applikation implementiert oder innerhalb eines Browsers dargestellt werden. Der Klient greift über eine Netzwerkverbindung auf den J2EE-Server zu. Auf diesem Server läuft die eigentliche Anwendung. Sie kann mit Servlets oder JSP realisiert werden. Beide brauchen eine eigene Laufzeitumgebung innerhalb des Servers, den Servlet-Container. Bei Verwendung eines Browsers befindet sich die Anwendungslogik zum größten Teil auf dem Server. Im Browser können lediglich Javascript-Programme oder Applets ausgeführt werden. Bei Verwendung einer Applikation ist diese Trennung nicht so klar hier können Anwendungsfunktionen auch auf dem Klienten ausgeführt werden. EJB werden in einem EJB-Container ausgeführt. EJB enthalten nur die Geschäftslogik, also keine Benutzungsschnittstelle. Diese wird von einer Anwendung implementiert oder mit Servlets und JSP im Browser dargestellt. Der J2EE-Server hat Verbindungen zu einer oder mehreren Datenbanken. Servlets, JSP und EJB können diese Verbindungen nutzen, um auf die Daten zuzugreifen. Sie müssen sich dabei aber nicht um die Ressourcenverwaltung kümmern, diese übernimmt der Server. 2.2 Dienste und Schnittstellen Abbildung 2 zeigt die Architektur einer EJB-Anwendung. Die Enterprise-Beans werden in einem EJB-Container verwaltet. Er stellt die Laufzeit-Umgebung für die Bean zur 4

5 Klient Bean spezifische Schnittstelle EJB Server (J2EE Server) EJB Container Enterprise Bean DVS... DVS Hersteller spezifische Schnittstelle EJB konforme Schnittstelle Abbildung 2: EJB-Architektur Verfügung. Der EJB-Container ist wiederum in einen EJB-Server eingebettet. Allgemein kann hier von einem J2EE-Server gesprochen werden, weil der Server meist weitere Aufgaben innerhalb der J2EE-Architektur übernimmt. Viele Produkte enthalten sowohl Container als auch Server, so daß beide teilweise schwer zu trennen sind. Manche Container können aber separat in Verbindung mit einem anderen Server genutzt werden. Oft werden auch mehrere Instanzen eines EJB-Containers in einem Server verwendet. Der Klient greift von außen auf die Schnittstelle der Bean zu. Für ihn sind die Kapseln, in denen die Bean verborgen ist, transparent. Die Bean greift über eine Schnittstelle auf die Dienste des EJB-Containers zu. Welche Dienste das sind und wie genau die Schnittstelle aussieht, ist in der EJB-Spezifikation vorgeschrieben. Der EJB-Container stützt sich auf die Dienste des EJB-Servers ab. Die Schnittstelle zwischen EJB-Container und EJB-Server ist dabei Hersteller-spezifisch und nicht in der Spezifikation definiert. EJB-Server unterstützen oft auch andere Komponentenmodelle, können also auch andere als EJB-Container enthalten. Zu den Funktionen, die ein solcher Server anbietet, gehören: Thread- und Prozeßmanagement zur Verwaltung mehrerer paralleler Container Clustering und Lastverteilung zur Verteilung der Arbeitslast auf mehrere Server Ausfallsicherheit durch redundanten Betrieb auf mehreren Server-Knoten und Umlenken von Anfragen an einen ausgefallenen Server auf einen funktionierenden Namens- und Verzeichnisdienste zum Finden von Komponenten und anderen Ressourcen Verwaltung von Ressourcen (Pooling) wie Netzwerk-Sockets und Datenbank-Verbindungen EJB-Server und EJB-Container schließen einen Vertrag, in dem der Server dem Container eine Menge von Diensten garantiert (Server-Container-Vertrag). 5

6 2.2.1 Dienste des EJB-Containers Der EJB-Container stellt die Laufzeitumgebung zur Verfügung, in der Beans ausgeführt werden, und dient als Mittler zwischen den Beans und dem EJB-Server. Die Dienste, die der Container den enthaltenen Beans anbieten muß, sind in der EJB-Spezifikation festgelegt. Im EJB 2.0-Standard gehören dazu folgende [1]: Kontrolle des Lebenszyklus und der Zustände von Beans: Der Container erzeugt Beans und steuert ihre Zustände. Nicht benötigte Beans werden gelöscht oder auf Halde verwaltet (pooling), so daß sie beim nächsten Zugriff eines Klienten schnell wieder zur Verfügung stehen besonders wichtig etwa bei Beans, die mit Datenbank- Verbindungen arbeiten (Abschnitt 4.1). Andererseits können nicht benötigte Beans aus dem Hauptspeicher ausgelagert werden (Passivierung), um den benötigten Speicherplatz zu verringern. Beans werden dazu serialisiert und persistent gespeichert. Verteilung, Namens- und Verzeichnisdienste: Bei einer Geschäftsanwendung können Beans auf unterschiedliche Rechner verteilt sein. Der EJB-Container sorgt dafür, daß der Operationsaufruf eines Klienten an die passende Bean weitergeleitet wird, ohne daß sich der Klient um die Verteilung kümmern muß. Hier ist entscheidend, daß ein Klient eine benötigte Bean überhaupt finden kann. Ein Namensdienst ermöglicht es, den Objekten Namen zuzuweisen (binding), über die ein Klient auf das Objekt zugreifen kann (lookup). Verzeichnisdienste sind noch leistungsfähiger als Namensdienste. Sie erlauben die hierarchische Strukturierung von Namensräumen und die Zuordnung weiterer Informationen zu den Ressourcen. In EJB wird JNDI (Java Naming and Directory Interface) verwendet, das wiederum mit anderen Verzeichnisdiensten wie LDAP zusammenarbeiten kann. Persistenz: Der EJB-Container stellt Datenbank-Verbindungen zur Verfügung, über die Beans auf Datenbanken zugreifen und ihren Zustand persistent machen können. Außerdem stehen Mechanismen zur Verfügung, mit denen der Bean-Zustand automatisch gespeichert werden kann, ohne daß dies in der Implementierung der Bean berücksichtigt werden muß (container-managed persistence, CMP). In diesem Fall übernimmt der Container auch die Abbildung auf unterschiedliche Datenverwaltungssysteme (DVS), etwa objektorientierte Datenbanken, das Dateisystem oder andere Anwendungssysteme, die die Daten verwalten. Die Bean bleibt also unabhängig von Hersteller und Typ des verwendeten DVS. Transaktionen: Transaktionen sind bei der Entwicklung verteilter, mehrbenutzerfähiger Anwendungen unverzichtbar, um auf Fehler geeignet reagieren und den parallelen Zugriff mehrerer Benutzer handhaben zu können. Der Container stellt Transaktionsmechanismen zur Verfügung, auf die der Bean-Entwickler direkt zugreifen kann. Alternativ können Transaktionen auch deklarativ ausgewählt werden: Bei der Installation der Bean im Container wird der gewünschte Transaktionstyp angegeben. Für die Einhaltung der Transaktionskriterien sorgt dann der EJB-Container. Transaktionen müssen also nicht in der Implementierung der Geschäftsoperationen berücksichtigt werden die gleiche Bean kann in unterschiedlichen Installationen mit verschiedenen Transaktionstypen arbeiten. Nachrichtenübermittlung: Der Container unterstützt den asynchronen Nachrichtenaustausch zwischen beliebigen Parteien. Dadurch können Prozesse entkoppelt und 6

7 auch Schnittstellen zu Fremdsystemen geschaffen werden. Ab EJB 2.0 muß der Container die Nachrichtenübermittlung über den Java Message Service (JMS) unterstützen. Sicherheit: Bei der Installation einer Bean im Container kann die Sicherheitspolitik für diese Bean (deklarativ) festgelegt werden. Für die Umsetzung der gewählten Sicherheitspolitik ist dann der Container zuständig. Dadurch läßt sich eine Bean in verschiedenen Umgebungen mit unterschiedlichen Sicherheitsanforderungen einsetzen, ohne daß die Bean geändert werden muß: Die Sicherheitsstrategie ist für die Bean transparent. Bei der Installation einer Bean wird festgelegt, welche Benutzerrollen welche Operationen der Bean aufrufen dürfen. Bei der Ausführung der Geschäftsanwendung prüft der Container jeweils, ob der aktuelle Benutzer die gewünschte Operation ausführen darf. Einem Benutzer können mehrere Rollen zugeordnet werden. Außerdem unterstützt der Container die Authentifizierung des Benutzers und die sichere Kommunikation. Die Tatsache, daß der EJB-Container eine Schnittstelle anbietet, die die Beans nutzen, wird auch als Container-Bean-Vertrag bezeichnet. 3 Technische Details von Enterprise JavaBeans 3.1 Bean-Typen Folgende Typen von Enterprise Beans werden unterschieden: 1. Entity Beans modellieren Geschäftskonzepte (Substantive). Sie enthalten den Zustand oder die Eigenschaften dieser Konzepte (in Form von Attributen) und ihre Operationen. Die Attribute können persistent in einem Datenverwaltungssystem (meist einer relationalen Datenbank) gespeichert werden. Bei der persistenten Speicherung werden zwei Alternativen unterschieden (Abschnitt 4.2): Persistenz wird vom Container verwaltet (container-managed persistence, CMP) Persistenz wird von der Bean selbst verwaltet (bean-managed persistence, BMP) 2. Session Beansimplementieren Aufgaben, Abläufe oder Geschäftsprozesse. Sie enthalten selbst keine persistenten Daten, können aber direkt auf gespeicherte Daten zugreifen und mit anderen Beans interagieren. Es werden zwei Arten von Session Beans unterschieden: Zustandslose Session Beans (stateless session beans) haben keinen internen Zustand; dieser muß vom Klienten verwaltet werden. Zustandsbehaftete Session Beans (stateful session beans) besitzen einen internen Zustand, können also den Zustand einer Sitzung über mehrere Dienstaufrufe hinweg speichern. 3. Message-Driven Beanssind ab EJB 2.0 verfügbar. Ein Klient kommuniziert mit einer Message-Driven Bean nur asynchron über den Austausch von Nachrichten, kann also ihre Operationen nicht direkt aufrufen. Zum Nachrichtenaustausch wird der Java Message Service (JMS) genutzt. 7

8 3.2 Bestandteile einer Bean Um eine Enterprise Bean zu implementieren, müssen zwei Interfaces und eine oder zwei Klassen definiert werden: Bean-Klasse: Die Bean-Klasse implementiert die Geschäftsoperationen der Bean. Der Klient kann aber nicht direkt auf diese Operationen zugreifen, sondern nur über die beiden folgenden Schnittstellen. Die Zuordnung zwischen der aufgerufenen Operationen aus der Schnittstelle und der auszuführenden Operation der Bean-Klasse übernimmt der EJB-Container. Eine Entity Bean implementiert javax.ejb.entitybean, eine Session Bean implementiert javax.ejb.sessionbean, die beide von javax.ejb.enterprisebean abgeleitet sind. Letztere enthält die Operationen, um mit dem EJB-Container zu interagieren. Remote Interface: Das Remote Interface enthält die Geschäftsoperationen einer Bean, die dem Klienten zur Verfügung gestellt werden. Der EJB-Container bildet Aufrufe von Operationen aus dieser Schnittstelle auf die Aufrufe von Operationen der Bean-Klasse ab. Die Schnittstelle wird von javax.ejb.ejbobject abgeleitet. Home Interface: Das Home Interface enthält Operationen, mit denen Beans erzeugt, gelöscht und gefunden werden können mit denen also der Lebenszyklus einer Bean gesteuert werden kann. Es wird von javax.ejbhome abgeleitet. Primärschlüsselklasse: Die Primärschlüsselklasse liefert einen Schlüsselwert für eine Entity Bean, wird also bei Session Beans nicht gebraucht. Der Schlüsselwert wird genutzt, um die persistenten Daten der Bean in einer Datenbank zu finden. Als Primärschlüsselklasse können auch einfache Java-Klassen (Integer, String) verwendet werden; dann muß keine eigene implementiert werden. Neben diesen Bestandteilen einer Bean ist eine Beschreibung wichtig, die das Verhalten der Bean zur Laufzeit und die Zusammensetzung einer Anwendung aus Beans festlegt. Diese Beschreibung heißt Deployment Descriptor und wird ab EJB 1.1 in einer XML-Datei notiert. Der Deployment Descriptor enthält: Name, Beschreibung der Beans Liste der Bestandteile (volle Namen von Klassen und Schnittstellen) Hinweise zum Speichern der Bean diese werden vom EJB-Container benötigt, wenn er für die Persistenz von Beans sorgen muß (container-managed persistence, vgl. Abschnitt 4.2) Rollendefinitionen und Zugriffsrechte an Operationen In EJB 2.0 kommen zwei weitere Schnittstellen hinzu: Über lokale Schnittstellen können Beans innerhalb der Laufzeitumgebung des EJB-Containers direkt kommunizieren, ohne dabei den Umweg über RMI gehen zu müssen. Diese Schnittstellen werden als local interfaces bezeichnet, während die Schnittstellen für den entfernten Zugriff remote interfaces heißen. Daraus resultieren vier mögliche Schnittstellentypen, wobei das remote home interface dem home interface aus EJB 1.1 entspricht und das remote component interface dem remote interface. Einfache Beispiele für die Bean-Bestandteile und den Deployment Descriptor werden in Abschnitt 3.4 gegeben. 8

9 3.3 EJB-Architektur Abbildung 3 verdeutlicht die Architektur einer EJB-Anwendung. Die kursiv dargestellten Bestandteile werden automatisch von den Hilfswerkzeugen des EJB-Containers erzeugt; die anderen liefert der Bean-Entwickler. Klient lokaler EJB Stub Home Interface EJB Server EJB Container Remote Interface EJB Objekt Stub Home Interface Remote Interface Home Objekt EJB Objekt Bean Instanz Abbildung 3: EJB-Architektur Bean-Entwickler erstellt Home Interface Schnittstelle für den Lebenszyklus Remote Interface Schnittstelle mit den Geschäftsoperationen Bean-Klasse Implementierung der Geschäftslogik und eventuell von Lebenszyklus- Operationen eventuell Primärschlüsselklasse werden in jar-datei verpackt und ausgeliefert jar-datei wird in EJB-Container installiert (deployment) Container erzeugt auf Basis von Schnittstellen/Klassen und deployment descriptor EJB-Objekt: Kapselt Bean-Instanz, sorgt für Basisdienste wie Transaktionen, Sicherheit, systemnahe Operationen EJB-Home-Objekt: implementiert Operationen des Home Interface Klient greift zu auf Home Interface Erzeugen der Bean (oder Zuordnen einer vorhandenen Instanz, vgl. Abschnitt 4.1) Remote Interface Aufrufen der Geschäftsoperationen Operationsaufrufe werden von den stubs im Klienten in Operationsaufrufe an den Objekten auf dem Server umgewandelt dazu werden entfernte Operationsaufrufe (remote method invocation, RMI) verwendet. Der Klient greift also nie direkt auf die Instanz der Bean-Klasse zu (dies wäre ja auch nicht möglich, weil Klient und Server auf unterschiedlichen Rechnern laufen können). 9

10 Dadurch können Zugriffsschutz-Mechanismen und eine ressourcensparende Verwaltung der Beans im Container realisiert werden. 3.4 Beispiel: HelloWorld Bean-Klasse mit Geschäftslogik : Abbildung 4 zeigt den Quelltext einer sehr einfachen SessionBean. Die Geschäftslogik, also die eigentliche Funktion der Bean, ist in der Operation sayhello() implementiert. Die übrigen Operationen sind in der Schnittstelle SessionBean enthalten. Außer in set- SessionContext() muß in diesem Beispiel nichts getan werden. package pi.vorlesung; import java.rmi.remoteexception; import javax.ejb.*; public class HelloBean implements SessionBean { private SessionContext sessioncontext; //-- Information ueber Zustandsaenderung public void ejbcreate() {} public void ejbremove() {} public void ejbactivate() {} public void ejbpassivate() {} //-- Context setzen public void setsessioncontext(sessioncontext sessioncontext) { this.sessioncontext = sessioncontext; } //-- Geschaeftslogik! public String sayhello() throws RemoteException { return "Hello World!!!!!"; } } Abbildung 4: Bean-Klasse einer sehr einfachen SessionBean Remote Interface: Das Remote Interface ermöglicht es den Klienten, auf die Geschäftsoperationen der Bean, hier sayhello(), zuzugreifen. Es erweitert die Schnittstelle EJBObject (Abbildung 5). Home Interface: Das Home Interface enthält die Operationen zum Erzeugen, Löschen und Auffinden der Bean. Es erweitert die Schnittstelle EJBHome und definiert im Beispiel in Abbildung 6 nur die Operation create. Die Operationen zum Löschen werden aus EJBHome geerbt; Operationen zum Auffinden gibt es bei Session Beans nicht, weil die nicht persistent verwaltet werden. 10

11 package pi.vorlesung; import java.rmi.remoteexception; import javax.ejb.*; public interface HelloObject extends EJBObject { public String sayhello() throws RemoteException; } package pi.vorlesung; import java.rmi.remoteexception; import javax.ejb.*; Abbildung 5: Remote Interface der Bean public interface HelloHome extends EJBHome { public HelloObject create() throws RemoteException, CreateException; } Abbildung 6: Home Interface der Bean Deployment Descriptor Datei ejb-jar.xml <?xml version="1.0" encoding="utf-8"?> <ejb-jar> <enterprise-beans> <session> <ejb-name>hello</ejb-name> <home>pi.vorlesung.hellohome</home> <remote>pi.vorlesung.helloobject</remote> <ejb-class>pi.vorlesung.hellobean</ejb-class>... Abbildung 7: Ausschnitt aus der ejb-jar.xml für das Beispiel Zugriff auf die Bean Sicht des Klienten: Abbildung 8 zeigt einen Quelltextausschnitt, in dem auf die Beispiel-Bean zugegriffen wird. 1. der JNDI-Context ermöglicht das Auffinden einer Bean in einer verteilten Umgebung anhand ihres Namens (lookup()) der wird im deployment descriptor festgelegt. Der Code, mit dem der JNDI-Context erzeugt wird, hängt vom verwendeten EJB-Container ab und ist hier nicht dargestellt. 11

12 InitialContext jndicontext; Object obj; HelloHome ejbhome; HelloObject ejbobject; String message;... jndicontext = new InitialContext (... ); obj = jndicontext.lookup ( "/Hello" ); ejbhome = (HelloHome) PortableRemoteObject.narrow ( obj, HelloHome.class ); ejbobject = ejbhome.create (); message = ejbobject.sayhello (); Abbildung 8: Zugriff auf die Geschäftsoperationen der HelloBean 2. geliefertes Objekt in HelloHome umwandeln (narrow()): Hier sollte keine einfache Typkonversion (ejbhome = (HelloHome) obj;) verwendet werden, sondern die Operation narrow(), um die Interoperabilität zwischen Java und anderen Sprachen zu gewährleisten. 3. über das Home Interface eine Bean-Instanz erzeugen: ejbhome.create() (genauer: ein Objekt, das das Remote Interface implementiert) 4. über dieses Objekt Geschäftsoperationen der Bean aufrufen 3.5 EJB-Server/Container OpenEJB open source-projekt EJB-Server entfernter Zugriff Server als eigenständiger Prozeß lokaler Server (IntraVM server) innerhalb einer JavaVM zum Testen einer Anwendung oder zum Einbau von OpenEJB-Containern z.b. in einen Servlet-Container enthält EJB-Container implementiert EJB-Standard in Version 1.1 als Plug-in mit verschiedenen Applikationsservern einsetzbar jeweils separater Container für stateless session beans, stateful session beans, CMP entity beans und BMP entity beans 4 Entity Beans Entitiy Beans repräsentieren Dinge oder Konzepte aus der realen (Geschäfts-) Welt, mit denen die Anwendungen umgehen muß. Geschäftskonzepte mit Zustand und Eigenschaften entstehen meist aus den Substantiven, die bei der Analyse des Problembereichs entdeckt werden, etwa Kunde, Auftrag, Wahre, Lieferung. 12

13 Die Eigenschaften werden in den Attributen der Bean-Klasse gespeichert und können über Zugriffsoperationen in der Bean-Schnittstelle (Remote Interface) bearbeitet werden. Die Attribute werden public deklariert, damit der EJB-Container direkt darauf zugreifen kann. Viele EJB-Container bieten Hilfswerkzeuge an, mit denen aus einer vorhandenen Datenbank-Tabelle eine passende Entity Bean oder umgekehrt aus einer Bean eine Tabellendefinition erzeugt werden kann. müssen persistent verwaltet werden meist in relationaler Datenbank 4.1 Lebenszyklus EJB-Container verwaltet EJB bei vielen Klienten viele Bean-Instanzen nötig häufig Instanzen erzeugen und zerstören Alternative: Instanzen-Pooling Instanzen in einem Pool verwalten, werden beim Start des Containers auf Vorrat erzeugt bei Bedarf eine Instanz dem Klienten zuordnen, danach in den Pool zurücklegen geringerer Ressourcenbedarf Abbildung 9 zeigt die möglichen Zustände einer Entity Bean bezogen auf das pooling. 1. newinstance() 2. setejbcontext() 3. Zuweisung an EJB Objekt 4. Anfragen des Klienten bearbeiten neu gepoolt bereit 5. Zurücklegen in Instanzen Pool Abbildung 9: Zustände einer Entity Bean 4.2 Persistenz Entity Beans müssen persistent verwaltet werden. Die Operationen zum Laden und Speichern von Beans sind aber meist sehr ähnlich und für den Entwickler daher eher lästig zu implementieren. Problematisch ist außerdem, daß die verwendete Datenbank nicht einfach ausgetauscht werden kann, wenn dazu Operationen der Bean geändert werden müssen. Daher ist es naheliegend, den EJB-Container einen Großteil der Arbeit erledigen zu lassen. So wird auch dafür gesorgt, daß die verwendete Datenbank leicht ausgetauscht werden kann, da der Container die Abbildung der Bean-Daten auf die konkreten Datenbank- Strukturen übernimmt. 13

14 Andererseits kann es erforderlich sein, daß eine Bean selbst Operationen implementiert, die ihren Zustand speichern und rekonstruieren etwa, wenn die Daten in einem Fremdsystem abgelegt werden müssen. Der EJB-Container unterstützen daher zwei Arten von Persistenz: 1. Container-Managed Persistence (CMP): Persistenz wird vom Container verwaltet 2. Bean-Managed Persistence (BMP): Persistenz wird von der Bean selbst verwaltet; die Operationen zum Laden und Speichern der Beans müssen also vom Entwickler implementiert werden. 4.3 Container-Managed Persistence EJB-Container sorgt für Speichern/Laden des Bean-Zustands geringerer Entwicklungsaufwand Bean unabhängig vom verwendeten DBMS EJB-Container realisiert persistente Speicherung einfachere Wiederverwendung der Bean Attribute der Bean werden auf Felder in der Datenbank abgebildet (mapping) zu speichernde Attribute im Deployment Descriptor eingetragen primitive Java-Typen oder serialisierbare Objekte als Attribute möglich Abbildung zum Teil schwierig (z.b. wenn mehrere Datenbank-Tabellen beteiligt sind) wird durch Werkzeuge unterstützt 4.4 Beispiel: CMP Entitiy Bean Bean-Klasse Abbildung 10 zeigt den Quelltext einer Entity Bean-Klasse, die container-managed persistence verwendet. implementiert set/get-operationen und weitere Geschäftsoperationen (z.b. getage()) ejbcreate() wird nach dem Aufruf von create() im Home Interface aufgerufen Felder initialisieren; id setzen ejbpostcreate() wird nach dem Erzeugen der Bean aufgerufen weitere Initialisierungen. Existieren mehrere create()-operationen im Remote Interface mit unterschiedlichen Signaturen, muß für jede eine ejbpostcreate() mit gleicher Signatur vorhanden sein. Operationen zum Laden und Speichern (ejbload(), ejbstore()) müssen bei CMP- Beans nicht implementiert werden unterschieden werden Eigenschaften: Attribute, die für den Klienten relevant sind (wie Name, Geburtsdatum) persistente Felder: Felder, die in der Datenbank gespeichert werden 14

15 Ein Attribut einer Bean-Klasse fällt also in eine oder beide Kategorien: Die id ist ein persistentes Feld, aber keine Eigenschaft; ein Attribut, das zwar von außen zugreifbar ist, aber nicht persistent verwaltet wird, ist eine Eigenschaft, aber kein persistentes Feld. der EntityContext wird hier nicht gebraucht, deshalb sind die zugehörigen Operationen nicht implementiert Deployment Descriptor Abbildung 11 zeigt einen Ausschnitt aus dem deployment descriptor, in dem die Eigenschaften der PersonBean spezifiziert werden. <persistence-type> container-managed persistence <prim-key-class> Typ des Primärschlüssels <cmp-field><field-name> Namen der persistenten Felder <primkey-field> Primärschlüsselfeld in der Datenbank 4.5 Suchanfragen mit EJB-QL (ab EJB 2.0) Entity Beans müssen Operationen zum finden von Bean-Instanzen anbieten (Home Interface) findall() liefert alle Instanzen eines Typs zurück findbyproductcode(string pcode) liefert Instanz mit angegebenem Produkt-Code zurück Implementierungsansätze: 1. SQL-Anfrage spezifisch für verwendetes DBMS, eingeschränkte Portabilität 2. Iteration durch Bean-Struktur, Abfragen von Attributwerten und Vergleich Geschwindigkeitsprobleme Anfragesprache für EJB: Enterprise JavaBeans Query Language (EJB-QL) Anfrage wird auf Hauptspeicher-Strukturen spezifiziert, nicht auf Datenbanken basiert auf SQL-92 SQL-ähnliche Syntax EJB-QL enthält aber nur eine Teilmenge von SQL; insbesondere sind nur Abfragen, keine Änderungen möglich. nur bei container-managed persistence einsetzbar Anfragen werden in deployment descriptor notiert (Abbildung 12) EJB-Container generiert daraus die Anfrage für das konkrete DBMS Beispiele für EJB-QL-Anfragen Implementierung von findall() SELECT OBJECT(p) FROM Product p 15

16 public class PersonBean implements javax.ejb.entitybean { public Integer public String public Date id; name; date_of_birth; /** Erzeugen der Bean **/ public Integer ejbcreate ( Integer id ) { setid ( id ); return null; } public void ejbpostcreate ( Integer id ) {} /** set/get fuer id **/ public Integer getid () { return id; } public void setid ( Integer id ) { this.id = id; } /** set/get fuer Eigenschaften **/ public String getname () { return name; } public void setname ( String name ) { this.name = name; } public Date getdateofbirth () { return date_of_birth; } public void setdateofbirth ( Date date_of_birth ) { this.date_of_birth = date_of_birth; } public int getage () {... } } /** Interaktion mit dem Container: nichts zu tun **/ public void setentitycontext( EntityContext ctx ) {} public void unsetentitycontext() {} public void ejbactivate() {} public void ejbpassivate() {} public void ejbload() {} public void ejbstore() {} public void ejbremove() {} Abbildung 10: Bean-Klasse einer Entity Bean 16

17 <entity> <ejb-name>personbean</ejb-name> <home>pi.vorlesung.personhome</home> <remote>pi.vorlesung.personremote</remote> <ejb-class>pi.vorlesung.personbean</ejb-class> <persistence-type>container</persistence-type> <prim-key-class>java.lang.integer</prim-key-class> <cmp-field><field-name>id</field-name></cmp-field> <cmp-field><field-name>name</field-name></cmp-field> <cmp-field><field-name>dateofbirth</field-name></cmp-field> <primkey-field>id</primkey-field>... Abbildung 11: Eintrag im deployment descriptor für die PersonBean Anfrage mit Parameter SELECT DISTINCT OBJECT(p) FROM Product p WHERE p.product_code =?1?1 wird durch den ersten Parameter der find-operation ersetzt auf Attribute wird mit Punkt-Operator (.) zugegriffen Navigation zwischen Beans SELECT DISTINCT OBJECT(r) FROM Order r, IN (r.products) AS p WHERE p.price >?1 mit Punkt-Operator (.) kann zwischen Beans navigiert werden (hier r.products): liefert die Produkte, die in einer Bestellung enthalten sind Der Punkt-Operator hat also zwei Funktionen: Vor einem Attributnamen ermöglicht er den Zugriff auf den Attributwert (p.product code); vor einem Beziehungsnamen ermöglicht er die Navigation zum Zielobjekt der Beziehung (r.products). Gegensatz zu SQL da würde ein Verbund gebildet mit IN wird eine Menge zusammengehöriger Beans definiert Navigation endet bei einfachen Feldern oder mengenwertigen Feldern deshalb kann man im obigen Beispiel nicht schreiben r.products.price. 4.6 Bean-Managed Persistence Sorgt eine Bean selbst für die persistente Speicherung ihres Zustands (bean-managed persistence), muß sie selbst die Operationen zum Lesen und Schreiben des Bean-Zustands für das gewünschte DVS bereitstellen. Wird eine relationale Datenbank verwendet, werden 17

18 <ejb-jar> <enterprise-beans> <entity> <ejb-name>productejb</ejb-name>... <query> <query-method> <method-name>findall</method-name> </query-method> <ejb-ql><![cdata[ SELECT OBJECT(p) FROM Product p ]]></ejb-ql> </query>... Abbildung 12: Notation der EJB-QL-Anfrage für die Operation findall() im deployment descriptor die Beans meist SQL-Anweisungen in den Java-Code der Operationen einbetten und über JDBC auf die Datenbank zugreifen. BMP-Beans werden durch den Eintrag <persistence-type>bean</persistence-type> im deployment descriptor gekennzeichnet. ejbcreate(), ejbpostcreate() Initialisieren der Bean-Instanz und Erzeugen der persistenten Daten, z.b. eines Tupels in der Datenbank finder-operationen zum Finden von Beans; allgemein ejbfindx(), z.b. findall(), findbyprimarykey() ejbload(): Einlesen des Bean-Zustands vom persistenten Speicher ejbstore(): Speichern des Bean-Zustands ejbremove(): Löschen der Bean-Daten im persistenten Speicher 5 Session Beans Session Beans implementieren Geschäftsprozesse und Abläufe; sie werden nicht persistent verwaltet. Es gibt zwei Arten: 1. Zustandslose Session Beans (Stateless Session Beans) Sammlung verwandter Dienste, die jeweils durch eine Operation der Bean implementiert werden. Die Dienste sind zwar verwandt, hängen aber nicht voneinander ab. werden dynamisch den verschiedenen Klienten zugeordnet ein Klient kann also eine Verbindung zu einer Session Bean haben, er kann aber nicht davon ausgehen, daß aufeinanderfolgende Dienstaufrufe von der gleichen Bean-Instanz bearbeitet werden. 18

19 Instanzen-Pooling hier besonders einfach, weil Zustand zwischen Aufrufen nicht gespeichert werden muß Bean bleibt einem Klienten nur während des Aufrufs zugeordnet (instance swapping) 2. Zustandsbehaftete Session Beans (Stateful Session Beans) enthalten Anwendungslogik, wäre bei 2-Schichten-Architektur im Klienten untergebracht verwalten Zustand der Konversation zwischen Klient und Server (conversational state) bleiben dem Klienten zugeordnet bei zustandsbehafteten und zustandslosen Beans kann eine Zeit festgelegt werden, nach der die Bean vom Klienten getrennt wird, sofern keine Kommunikation mehr stattgefunden hat. kein Pooling weil der Zustand jeweils in der Bean-Instanz gespeichert wird Wird im deployment descriptor im Eintrag <session-type> mit dem Wert Stateless oder Stateful angegeben. 5.1 Lebenszyklus von Session Beans Zustandslose Session Beans Abbildung 13 zeigt den Lebenszyklus einer zustandslosen Session Bean. Container: ejbcreate() Klient: Geschäfts operationen aufrufen existiert nicht bereit Container: ejbremove() Abbildung 13: Lebenszyklus einer zustandslosen Session Bean Zustand existiert nicht Bean nicht im Speicher vorhanden der EJB-Container sorgt dafür, daß eine ausreichende Anzahl Bean-Instanzen zur Verfügung steht ejbcreate() Aufrufe von create() im Home Interface werden nicht an die Bean weitergeleitet für das Erzeugen der Bean-Instanzen ist allein der Container zuständig; der Klient kann nur den Zugriff auf eine (beliebige) Instanz beantragen. Zustand bereit Bean-Instanz befindet sich im Speicher und kann Geschäftsoperationen ausführen in ejbremove() werden belegte Ressourcen freigegeben die Operation wird vom Container aufgerufen, wenn die Bean nicht mehr benötigt wird. 19

20 5.1.2 Zustandsbehaftete Session Beans Abbildung 14 zeigt den Lebenszyklus einer zustandsbehafteten Session Bean. Contaier: ejbcreate() Container: ejbpassivate() existiert nicht bereit passiv Container: ejbremove() Container; ejbactivate() oder timeout Klient: Geschäfts operationen aufrufen Abbildung 14: Lebenszyklus einer zustandsbehafteten Session Bean ejbcreate() wird hier als Folge des Aufrufs von create() des Home Interfaces aufgerufen EJB-Container kann Beans passivieren aus dem Speicher entfernen, um Ressourcen zu sparen Bean-Zustand wird erhalten Aufruf von ejbpassivate() Bean kann Ressourcen freigeben nach einem timeout kann die Bean vom EJB-Container entfernt werden; dabei wird nicht ejbremove() aufgerufen 6 Container-Dienste 6.1 Rollenbasierte Zugriffskontrollen Benutzer können Benutzerrollen zugeordnet werden jede Rolle hat einen Namen und eine Beschreibung Rollendefinitionen werdem im deployment descriptor eingetragen (Abbildung 15) Zugriffsrechte an Operationen definieren Zugriffsrechte legen fest, welche Rolle welche Operationen ausführen darf (Abbildung 16) Rolle Admin alle Operationen von PersonBean (*) Rolle ReadOnly nur get-operationen 6.2 Transaktionen Folgen von Operationsaufrufen müssen zu Arbeitseinheiten zusammengefaßt werden Transaktionen (Atomic, Consistent, Isolated, Durable) 20

21 <security-role> <description> Administrator-Rolle -- darf alles </description> <role-name>admin</role-name> </security-role> <security-role> <description> Nur lesender Zugriff </description> <role-name>readonly</role-name> </security-role> Abbildung 15: Definition von Benutzerrollen Arbeitseinheit: Folge von Operationen, die innerhalb einer Transaktion ausgeführt werden. Durch die Transaktion wird sichergestellt, daß die Operationsfolge entweder ganz oder gar nicht ausgeführt wird. Gültigkeitsbereich einer Transaktion: Menge der Beans, die an der Arbeitseinheit beteiligt sind Transaktionen verwenden: 1. über API (z.b. Java Transaction Service, JTS) zusätzlicher Code in Geschäftslogik, schwierig zu handhaben 2. deklarativ: Verhalten von Operationen im deployment descriptor festlegen kein zusätzlicher Implementierungsaufwand, einfach änderbar, Bean einfach wiederverwendbar (Abbildung 17) in EJB nur flache Transaktionen, keine Schachtelung möglich Transaktionsattribute legen Transaktionseigenschaften von Operationen fest in Abbildung 17 wurde für alle Operationen der Beans PersonBean und OrderBean das Transaktionsattribut Required angegeben einige Transaktionsattribute in EJB 1.1: NotSupported: Operation wird nicht innerhalb Transaktion ausgeführt; aufrufende Transaktion wird unterbrochen Supports: aufgerufene Bean wird in Gültigkeitsbereich der aufrufenden Transaktion aufgenommen Required: aufgerufene Bean wird in Gültigkeitsbereich der aufrufenden Transaktion aufgenommen; wenn Aufruf nicht innerhalb Transaktion, wird neue gestartet RequiresNew: beim Aufruf wird immer eine neue Transaktion gestartet Mandatory: Aufruf nur innerhalb einer Transaktion möglich bei einem Aufruf außerhalb einer Transaktion wird also ein Fehler ausgelöst. Transaktionsmananager überwacht Ausführung der Transaktionen: 21

22 <method-permission> <role-name>admin</role-name> <method> <ejb-name>personbean</ejb-name> <method-name>*</method-name> </method> <method> <ejb-name>orderbean</ejb-name> <method-name>*</method-name> </method> </method-permission> <method-permission> <role-name>readonly</role-name> <method> <ejb-name>personbean</ejb-name> <method-name>getname</method-name> </method> <method> <ejb-name>personbean</ejb-name> <method-name>getdateofbirth</method-name> </method> </method-permission> Abbildung 16: Definition von Zugriffsrechten Fehler alle Transaktionen im Gültigkeitsbereich zurücksetzen der Container muß in diesem Fall dafür sorgen, daß alle bisher ausgeführten Änderungen rückgängig gemacht werden. Erfolg Änderungen persistent machen 7 EJB in der Praxis 7.1 Rollen bei Entwicklung und Einsatz Bei der Entwicklung und dem Einsatz von Enterprise Beans können verschiedene Rollen unterschieden werden. Jeder Rolle sind bestimmte Aufgaben und Verantwortlichkeiten zugeordnet. Server-, Container-Hersteller: Der Server-Hersteller stellt die grundlegenden Server-Funktionen bereit, die von verschiedenen Containern genutzt werden können. Der Container-Hersteller implementiert den Bean-Container, der eine Laufzeitumgebung für Beans anbietet. Server- und Container-Hersteller können verschieden sein; wegen der oft herstellerspezifischen Schnittstelle der EJB-Server stammen Server und Container aber oft von der gleichen Firma und werden oft auch als ein Produkt angeboten. Neben den genannten kann ein weiterer Hersteller den Persistence Manager liefern eine Komponente, die für die persistente Speicherung des Bean-Zustands sorgt. Der 22

23 <container-transaction> <method> <ejb-name>personbean</ejb-name> <method-name>*</method-name> </method> <method> <ejb-name>orderbean</ejb-name> <method-name>*</method-name> </method> <trans-attribute>required</trans-attribute> </container-transaction> Abbildung 17: Deklaration von Transaktionen Persistence Manager-Hersteller ist üblicherweise ein Datenbank-Spezialist. Die Schnittstelle zwischen dem EJB-Container und dem Persistence Manager wird nicht durch die Spezifikation festgelegt. Bean-Hersteller: Die Entwickler des Bean-Herstellers implementieren die eigentliche Anwendungslogik und verpacken sie in Enterprise Beans. Sie müssen also über ausreichendes Fachwissen aus dem Anwendungsbereich verfügen. Basis für die Bean- Implementierung sind die Dienste, die vom EJB-Container bereitgestellt werden. Zu einer Bean gehört auch der deployment descriptor, der die Komponente selbst beschreibt, ihrer Konfigurationsmöglichkeiten und ihrer Interaktion mit dem Container. Application Assembler: Er setzt Anwendungen aus einzelnen Beans zusammen. Zu seinen Aufgaben können gehören: Das Zusammensetzen neuer Beans aus vorhandenen, die Entwicklung der Klientenanwendung und die Entwicklung eigener Beans, die etwa zur Koppelung vorhandener Beans genutzt werden. Die Zusammensetzung der Anwendung aus Beans wird im Deployment Descriptor dokumentiert. Bean Deployer: Er installiert Beans und bettet sie in einen gegebenen Geschäftskontext ein. Dazu gehört die Konfiguration und die Bedienung der Werkzeuge des EJB-Servers, Containers und Persistence Managers sowie die Konfiguration der eigentlichen Beans, um sie an die konkreten Anforderungen der Geschäftsanwendung anzupassen. Insbesondere muß er die Anforderungen etwa an benötigte Server-Dienste berücksichtigen, die im Deployment Descriptor dokumentiert sind. Systemadministrator: Der Administrator sorgt für den reibungslosen Betrieb der Geschäftsanwendung, überwacht also die Funktion des EJB-Containers und der benötigten Infrastruktur, etwa der Datenbank und des Netzwerks. Natürlich werden in der Praxis häufig von einer Person oder Firma mehrere Rollen übernommen. 7.2 Sichten auf die EJB-Technologie Aus unterschiedlichen Blickwinkeln betrachtet, sind unterschiedliche Aspekte für die Beurteilung der EJB-Technologie relevant. Auf drei Blickwinkel wird näher eingegangen [1]: 23

24 7.2.1 Anwendungsentwicklung 1. Rollenteilung: Durch die beschriebene Rollenteilung kann sich jeder Beteiligte auf sein eigenes Aufgabengebiet konzentrieren. Besonders die Entwicklung der eigentlichen Geschäftslogik wird erleichtert, da sich der Entwickler nicht um grundlegende Dienste wie Transaktionen, Verteilung und Persistenz kümmern muß. 2. Wiederverwendung: Bei der Aufteilung einer Anwendung in viele Komponenten werden einige Komponenten entstehen, die in verschiedenen Kontexten verwendet werden können. Durch den Komponenten-orientierten Ansatz wird also die Wiederverwendung von Software-Bausteinen gefördert. Durch die weitgehenden Möglichkeiten zur Konfiguration von Beans wird ihre Wiederverwendbarkeit weiter erhöht. 3. Wartung: Die Wartung des Systems wird erleichtert, da viele Anpassungen durch eine Änderung der Konfiguration erreicht werden können (etwa die Änderung der Sicherheitspolitik oder die Verwendung eines anderen DVS). Weitergehende Änderungen betreffen meist nur bestimmte Komponenten, können also gut lokalisiert werden. Durch die expliziten Schnittstellen zwischen den Komponenten werden unerwünschte Seiteneffekte vermieden Komponenten-Paradigma Aus Sicht der Komponenten-basierten Software-Entwicklung sind folgende Aspekte relevant: 1. Plattformunabhängigkeit: Enterprise JavaBeans sind plattformunabhängig, da die zugrundeliegende Java-Technologie plattformunabhängig ist. Enterprise Beans sind allerdings auf die Java-Plattform beschränkt. Die Interoperabilität mit anderen Komponentenplattformen etwa über CORBA ist aber möglich. 2. Ortstransparenz: Da Klienten nur über das Remote Interface auf Beans zugreifen, ist der Ort, an dem sich die Beans befinden, für den Klienten transparent. Die Verbindung zwischen Klient und Bean muß der Bean-Container herstellen. Durch Lastausgleich- Verfahren können Komponenten auch auf andere Netzknoten migriert werden, ohne daß der Klient hiervon informiert werden müßte. Entscheidend für den Zugriff auf Komponenten sind die Namensdienste des Bean-Containers. 3. Trennung von Schnittstelle und Implementierung: Die Implementierung der Komponenten (die Instanzen der Bean-Klassen) werden im Container verwaltet, während der Klient nur auf die Operationen des Remote und Home Interface zugreift. 4. Bean-Metadaten: Ein Klient kann Meta-Daten einer Bean abfragen (javax.ejb.ejb- MetaData). Dabei wird auch die Reflexivität von Java (Reflection API) ausgenutzt. Software-Entwicklungswerkzeuge, die eine Bean-basierte Entwicklung unterstützen, müssen die Eigenschaften von Beans ermitteln können, um passenden Quelltext generieren oder Entwicklungsschritte automatisieren zu können. 5. Plug & Play: Eine Bean kann prinzipiell direkt in einen Container installiert und somit in eine Anwendung integriert werden. Durch die Möglichkeit, die Eigenschaften einer Bean im Deployment Descriptor zu beeinflussen, sind keine Änderungen an der Bean-Implementierung nötig. 6. Komposition: Eine Bean kann aus anderen Beans zusammengesetzt werden (dies übernimmt der application assember aus Abschnitt 7.1). Die Zusammensetzung einer Bean aus anderen wird durch einen Abschnitt im Deployment Descriptor geregelt. 24

25 7.2.3 Unternehmen Bei den Unternehmen, die mit Enterprise Beans arbeiten, müssen Softwareproduzenten und Nutzer unterschieden werden. Für die Software-Produzenten sind folgende Aspekte wich- Software-Produzenten: tig: 1. Konzentration auf eigene Aufgaben und Kompetenzen: Durch die Trennung von Systemfunktionen und Geschäftslogik können sich Software-Hersteller auf ihr jeweiliges Aufgabengebiet konzentrieren. 2. Reduzierung der Problem-Komplexität: Das zu entwickelnde System wird zunächst in einzelne Komponenten aufgeteilt, die dann weitgehend unabhängig entwickelt (oder zugekauft) werden können. Das komplexe Gesamtproblem wird also in überschaubarere Teilprobleme zerlegt. 3. Wiederverwendung: Einmal entwickelte Beans können in verschiedenen Anwendungen oder an verschiedenen Stellen einer Anwendung wiederverwendet werden. Dies hat positive Auswirkungen auf die Kosten und die Qualität der Anwendung. Wichtig ist hier die Konfigurierbarkeit der Beans ohne Quelltext-Änderung. 4. Komponentenmarkt: Durch die breite Akzeptanz von EJB können Bean-Hersteller auf gute Vermarktungschancen und größere Stückzahlen hoffen. Software-Nutzer: Aus Sicht der Software-Nutzer haben EJB folgende Vorteile: 1. Hersteller-Unabhängigkeit: Durch die breite Unterstützung von EJB durch zahlreiche Hersteller und die standardisierten Schnittstellen sind Kunden nicht an ein Produkt und einen Lieferanten gebunden. 2. Sicherheit, Zuverlässigkeit, Qualität: Durch die Trennung von Systemfunktionen und Anwendungslogik erhöht sich die Wahrscheinlichkeit, daß der Entwickler einer bestimmten Funktion auch über ausreichende Kenntnisse auf dem jeweiligen Gebiet verfügt und die resultierende Anwendung den Erwartungen des Kunden besser entspricht. Der Standard macht Vorgaben bezüglich der Architektur und Funktionsweise einer EJB-Anwendung und stellt Mechanismen zur Verfügung, die die Entwicklung von zuverlässigen Anwendungen erleichtern. Zur Qualität der resultierenden Anwendungen kann auch der hohe Wiederverwendungsgrad einzelner Bausteine beitragen. 3. Kosten: Natürlich sinken die Kosten für eine Anwendungsentwicklung, wenn Komponenten der Anwendung bereits in anderen Anwendungen eingesetzt wurden. Wichtig sind auch effiziente Werkzeuge, die den Anwendungsentwickler bei seiner Arbeit unterstützen. Solche Werkzeuge sind nur in ausreichender Zahl und Qualität verfügbar, wenn ein stabiler Markt dafür existiert. 8 Zusammenfassung Enterprise JavaBeans: quasi-standardisiertes serverseitiges Komponentenmodell unterstützen Bau von verteilten Geschäftsanwendungen 25

26 Entity Beans Geschäftskonzepte, persistent Session Beans Abläufe und Prozesse, nicht persistent Bean besteht aus Bean-Klasse Implementierung der Bean Schnittstelle mit Geschäftsoperationen (Remote Interface) Schnittstelle mit Lebenszyklus-Operationen (Home Interface) EJB-Container stellt Basisdienste zur Verfügung Persistenz Transaktionen Zugriffskontrollen Literatur [1] S. Denninger and I. Peters. Enterprise JavaBeans [2] F. Griffel. Componentware Konzepte und Techniken eines Softwareparadigmas. dpunkt Verlag für digitale Technologie, Heidelberg, [3] V. Gruhn and M. Schneider. EJB 2.0 Anwendungen. Addison-Wesley, [4] V. Gruhn and A. Thiel. Komponentenmodelle. Addison-Wesley, (zu EJB Version 1.1). [5] R. Monson-Haefel. Enterprise JavaBeans. O Reilly, (zu EJB Version 1.1). 26