Java Servlet Technology 2.3 D Enterprise Java Beans … · 1 J2EE Java 2 Enterprise Edition...

2002-2006, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2006s-AvID-D-EJB.fm, 2006-05-11 12.16] http://www-vs.informatik.uni-ulm.de/teach/ss06/avid/

D Enterprise Java Beans

D.1 2002-2006, Franz J. Hauck, Verteilte Systeme, Univ. Ulm, [2006s-AvID-D-EJB.fm, 2006-05-11 12.16] http://www-vs.informatik.uni-ulm.de/teach/ss06/avid/

1 J2EE

■ Java 2 Enterprise Edition

◆ Erweiterungen zum Standard Java (J2SE, Java 2 Standard Edition)

◆ EJB 2.0 (Enterprise Java Beans)

◆ JDBC 2.0 (Java Database Connectivity)

◆ Java Servlet Technology 2.3

◆ JSP 1.2 (Java Server Pages)

◆ JMS 1.0 (Java Message Service)

◆ JNDI 1.2 (Java Naming and Directory Interface)

◆ JTA 1.0 (Java Transaction API)

◆ JavaMail API 1.2

◆ JAXP 1.1 (Java API for XML Processing)

◆ JCA (Java Connector Architecture)

◆ JAAS 1.0 (Java Authentication and Authorization Service)

D.2


2 Motivation

■ Webbasierte Dienste

◆ Zugriff auf Dienstleistungen mittels Web-Browser

◆ klassisches Client-Server-Prinzip

◆ Beispiele:

• von Kalender und Web-Cam bis zum Online-Shop

▲ Problem

◆ statische Web-Seiten wie im klassischen Web-Server nicht ausreichend

◆ Zustandspeicherung für Benutzerinteraktion notwendig

✱ Folgerung

◆ dynamische Generierung von Antwortseiten aufgrund von Benutzereingaben

◆ Zugang zu Datenspeichern

Browser

Web-Server

HTTP


3 Dynamische Web-Inhalte

3.1 CGI-Skripten

■ Common Gateway Interface

◆ Standard zum dynamischen Erzeugen von Web-Inhalten

■ Vorgehensweise

◆ Registrierung eines CGI-Skripts unter bestimmten URIs

◆ bei Anfrage nach URI wird Skript gestartet

• statt statische Web-Seite ausgeliefert

◆ Skript gibt geforderten Web-Inhalt zurück

• Inhalt kann dynamisch erzeugt bzw. manipuliert werden

Browser

Web-Server CGISkript

CGI

HTTP

D.4


3.1 CGI-Skripten (2)

■ Schnittstelle

◆ CGI-Skript ist ein neuer Prozess im Betriebssystem

• ineffiziente Bearbeitung von Anfragen

◆ Eingabe über Umgebungsvariablen und Eingabestrom

• Umgebungsvariablen: Anfrage URI, Header-Informationen etc.

• Eingabestrom: im Body übermittelte Daten, z.B. bei HTTP POST Methode

◆ Ausgabe über Ausgabestrom

• Ausgabe eines Teils der HTTP-Header, z.B. Content-Type

• Ausgabe des HTTP-Body für den HTTP-Response

■ Fähigkeiten

◆ beliebige Inhaltserzeugung

◆ Zustandsspeicherung über Dateisystem oder Datenbank im Hintergrund


3.2 Servlets

■ “The Java Way of CGI”

◆ Implementierung der CGI-Funktionalität in Java

◆ Servlet kann HTTP-Anfragen bearbeiten und Antwort generieren

• standardisierte Schnittstelle für Servlet-Objekte

◆ Servlet-Container

• Behälter für mehrere Servlets

• ruft richtiges Servlet entsprechend Konfiguration auf

■ Typische Software-Konfiguration

◆ Container als eigenständiger Prozess

◆ Web-Server leitet Anfragen weiter

◆ zur Effizienzsteigerung Kombination von Web-Server und Container möglich

Browser

Web-Server

HTTPHTTP

ServletServletServletContainer

D.6


3.2 Servlets (2)

■ Servlet-Objekte

◆ implementieren bestimmte Schnittstelle

• insbesondere Methode:

void doGet( HTTPServletRequest req,HTTPServletResponse resp );

◆ HTTPServletRequest enthält alle nötigen Eingabeinformationen

◆ HTTPServletResponse kann dynamisch erstellten Web-Inhalt aufnehmen

• Java-Ausgabestrom zum Aufnehmen des Body-Bereichs der HTTP-Response

• Einsatz von üblichen „print“-Anweisungen zum Erzeugen der Ausgabe

■ Konfiguration des Containers

◆ „Deployment“ (wörtlich Einsatz, Stationierung)

◆ Bereitstellung der Dienste

• Konfiguration der Servlet-Klassen für verschiedene URIs


3.3 Java-Server-Pages

■ Nachteil von Servlets

◆ Programmieraufwand für fast vollständig statische Web-Inhalte

• z.B. lediglich Page-Counter hinzuzufügen

• z.B. lediglich wenige benutzerspezifischen Teile anzupassen

■ Konzept der Java-Server-Pages (JSP)

◆ Entwicklung eines XHTML- oder XML-Dokuments

• wird als Ergebnis einer Anfrage zurückgegeben

◆ dynamische Anteile durch spezielle Auszeichnungen

• XML-Elemente in speziellem Namensraum

• über XML hinausgehende Auszeichnungen

• spezielle Instruktionen– zum Zugriff auf Java-Variablen– zum Aufruf von Java-Objekten, – für Bedingungen und Schleifen

D.8


3.3 Java-Server-Pages (2)

✱ JSP-Seite ist umgestülptes Servlet (und umgekehrt)

■ Interne Implementierung

◆ Erzeugung eines Servlets aus XML-Dokument im JSP-Container

• in der Regel erst bei Anfrage

<html><body><p>...</p>

Servlet Code

</body></html>

XML-DokumentServlet-Klasse

...doGet(...) { ...

out.print “<html>\n<body>”;out.print “<p>...</p>”;

Servlet Code

out.print “</body>\n</html>”;...

}


3.3 Java-Server-Pages (3)

■ Programmierung im JSP-Dokument

◆ vorgegebene Anweisungen und XML-Elemente

◆ weitere Anweisungen integrierbar durch Tag-Libraries

■ Tag-Library

◆ Java-Klassenbibliothek mit speziellen Schnittstellen

◆ Deployment im Container und im JSP-Dokument

◆ neuer XML-Namensraum für Anweisungen einer Tag-Lib

◆ Anwendungsbereiche

• Datenbankanbindung

• Stringmanipulationen

• Zugang zu Verzeichnisdiensten

• etc.

D.10


3.4 Bestandsaufnahme

▲ Nachteile von CGI, Servlets und JSP

◆ Zugang zu Zustandsinformationen mühsam

◆ Koordinierung nebenläufiger Anfragen problematisch

• Stichwort: Transaktionen

◆ unter Umständen Vermischung von Darstellung und Anwendungslogik

◆ Sicherheitsanforderungen müssen immer wieder integriert werden


4 Motivation für EJB

■ Große verteilte Anwendungen im „Geschäftsleben“

◆ viele Clients

• wollen Dienste nutzen

◆ einige Server

• stellen Dienste bereit

◆ einige Datenbanken

• halten die Geschäftsdaten

■ Problem

◆ Aufbau des Systems

◆ Zergliederung in Einzelteile

◆ Kommunikation der Teile

✱ Middleware

ServerServer

ClientClientClientClient ClientClient

Server

Daten-bank

Server

D.12


4 Motivation für EJB (2)

✱ Komponenten-Idee

◆ Zerlegung der Geschäftslogik („Business-Logik“) in Komponenten

• z.B. Komponente zur Preisberechnung

◆ Wiederverwendung von Komponenten

• Komponentenmarkt mit Komponentenanbietern

• Zusammenschalten von neuen und eingekauften Komponentenzu einer neuen Anwendung

◆ Bereitstellung einer Umgebung für Komponenten

• Umgebung unterstützt Sicherheit

• Umgebung unterstützt Anwendungskonsistenz durch Transaktionen

■ Application Server

◆ Umgebung für Komponenten

• Menge von Komponenten bilden eine Anwendung


4 Motivation (3)

■ Komponentenmodell

◆ Spezifikation zur Konstruktion und Interaktion von Komponenten

◆ Spezifikation der Umgebung und deren Schnittstellen

◆ Komponenten-Idee benötigt standardisierte Plattform

■ EJB-Komponentenmodell als ein Standard

◆ Programmiersprache Java

• Programmiersicherheit (keine Zeiger, Byte-Code-Verifier)

• dynamisches Klassenladen

• Reflection-API (Introspektion von unbekannten Objekten)

• Unabhängigkeit von Hardware- und Systemplattform (Portabilität)

◆ Komponente: Enterprise Java Bean

D.14


4 Motivation (4)

■ Enterprise Java Bean ist nicht gleich Java Bean

◆ Java Bean ist lokales Objekt mit bestimmten Eigenschaften

• lokale Komponente

• set*, get* Methoden

• mit Reflection-API dynamisch komponierbar

◆ EJB ist Komponente im Verteilten System

• spezielle Schnittstellen zur Interaktion

• Einbindung in Transaktions- und Sicherheitsdienste

■ Andere Komponentenmodelle

◆ Microsofts .NET Managed Objects

◆ CORBA Component Model (CCM)

◆ einige weitere Forschungssysteme


5 Architektur

■ Typisch: Architektur aus mehreren Schichten (Multitiered Architecture)

◆ Client-Tier

• Anwendungsteil des Client

• Webbrowser

• dedizierte Anwendung

◆ Middle-Tier

• Geschäftslogik

• Service-Bereitstellung

◆ EIS-Tier (Enterprise Information System)

• Datenbank

• Archiv der Geschäftsvorgänge

Client

Server

D.16


5 Architektur (2)

■ Client-Tier

◆ Webbrowser als Client-Anwendung

• Zugriff auf dynamische Webseiten(z.B. GMX, Webshop, Hotelreservierung)

• Webseiten mit Applets(Applet-Programm tritt als Client zur Anwendung auf, z.B. Homebanking)

◆ dedizierte Client-Anwendung

• kommuniziert mit dem Rest der Anwendung

◆ Web-Services-Schnittstelle

◆ Benutzeroberfläche zur Anwendung

◆ lokale Berechnung/Verarbeitung


5 Architektur (3)

■ Middle-Tier

◆ Web-Tier

• Web-Container für Java Server Pages oder Servlets

• (CGI-Skript)

• unnötig bei dedizierter Client-Anwendung

◆ Business-Tier

• enthält eigentliche Geschäftslogik

• Einsatz von Geschäfts-Komponenten

• Komponenten-Container

◆ Verarbeitung von Geschäftsprozessen und Geschäftsdaten

D.18


5 Architektur (4)

■ EIS-Tier

◆ Datenbanksysteme

• relationale Datenbanken

• objektorientierte Datenbanken

◆ Altanwendungen zum Zugriff auf Geschäftsdaten

◆ Datenverwaltung von Geschäftsdaten

• Konsistenz der Daten


5.1 EJB-Architektur

■ Globales Bild einer EJB-Anwendung

andere

Client

Servlets

EJB-Container

JSP

Client Client

HTTPSOAP

Client Tier

IIOP

Firewall

Middle Tier

EIS Tier

JDBC Connector

JMS SQL propr. Protokoll IIOP, SOAP

Systeme

EJ Beans

J2EE-Server

D.20


5.1 EJB-Architektur (2)

■ Beispielanwendungen

◆ Bankanwendung

• Client am Webbrowser

• Application-Server erlaubt Ansicht des Kontoauszug, Beauftragung für Überweisung, Dauerauftrag etc.

• Datenbanken im Hintergrund halten Buchungen und Kontostände sowie Benutzerdaten

◆ Webshop

• Client am Webbrowser

• mehrere Application-Server für Kreditkartenzahlung, Produktkatalog, Kundenprofilverwaltung

■ Abwicklung von Geschäftsprozessen

◆ Zerlegung für mehrere hierarchisch aufgerufene Beans


5.2 Rollen von EJB

■ Bean-Entwickler

◆ Komponentenverkäufer im Komponentenmarkt

◆ Entwicklungsabteilung

◆ ... liefern Enterprise-Java-Bean

• d.h. Java Klassen gemäß EJB-Spezifikation für Komponenten

■ Anwendungsentwickler

◆ Entscheidung über Koponenteneinsatz (Zukauf, Eigenentwicklung)

◆ Verbindungscode zwischen Komponenten

◆ Entwicklung der Benutzerschnittstelle (JSP, Servlet, Applet)

D.22


5.2 Rollen von EJB (2)

■ Anwendungsinstallateur (Deployer)

◆ Aufstellen der Hardware für Application-Server

• Stichworte: Redundanz und Fehlertoleranz

◆ Verteilung der Beans auf Application-Server

◆ Sicherung der Kommunikation durch Firewalls

◆ Integration in Infrastruktur

• Stichwort: Verknüpfung von Zugrifssrechten mit aktuellen Benutzern

◆ Performance-Tuning

■ Systemadministratoren

◆ Betrieb der Anwendung

• Managementfunktion

◆ Überwachung der Anwendung

• Monitoring, Fehlerbehebung



■ Application-Server-Anbieter

◆ Bereitstellen des Bean-Containers

• Behausung für Enterprise Java Beans

• Unterstützung für Sicherheit, Transaktionen etc.

◆ Beispiele

• WebLogic (BEA) Bluestone (HP)

• iPlanet iPortal (IONA)

• Websphere (IBM) Borland Application Server

• Oracle 9i JBoss (Open Source)

• JRun (Macromedia) Powertier (Persistence)

• Gemstone/J (Brokat)

D.24



■ Werkzeuganbieter

◆ Werkzeuge für die Code-Entwicklung

• IDE, Integrated Development Environment

• z.B. Visual Age (IBM)

◆ Werkzeuge zur Modellierung und Code-Erzeugung

• UML, Unified Modelling Language

• z.B. Rational Rose, Together/J


5.3 Unterschied zu klassischer Middleware

■ Klassische Middleware ist explizit

◆ Middleware: CORBA, Java RMI

◆ Beispiel: Überweisungsvorgang von Konto zu Konto

account1.transfer( Amount s, Account other );

◆ notwendiger Code im Kontoobjekt

• Aufruf eines Sicherheitsservice, ob Aufrufer berechtigt

• Aufruf eines Transaktionsservice zum Start einer Transaktion

• Aufruf eines Datenbankservers zum Laden von Kontoinformationen

• lokale Kontostandsberichtigung

• Aufruf des zweiten Kontos zur Kontostandsberichtigung

• Aufruf des Datenbankservers zum Speichern der Kontoinformationen

• Aufruf des Transaktionsservice zum Beenden der Transaktion

D.26


5.3 Unterschied zu klassischer Middleware (2)

▲ Problem

◆ komplexe Programmierung

◆ schwierige Wartung

◆ Interaktion verschiedener Produkte unter Umständen problematisch

• z.B. Datenbankserver und Transaktionsdienst

✱ Vorteil

◆ hohe Flexibilität



■ Implizite Middleware wie bei EJB

◆ Beispiel: Überweisungsvorgang von Konto zu Konto

account1.transfer( Amount s, Account other );

◆ notwendiger Code in Bean

• lokale Kontostandsberichtigung

• Aufruf einer zweiten Bean zur Kontostandsberichtigung des anderen Kontos

◆ Interaktion mit Services erfolgt implizit

• Container fängt Interaktionen ab

◆ Beschreibung der Interaktion in der Deployment-Phase

• Deployment-Deskriptor (XML)

D.28



✱ Vorteil

◆ einfach zu entwickelnden Beans

◆ leichte Wartung da übersichtlicher Code

◆ gesichertes Zusammenspiel der Komponenten

▲ Nachteil

◆ weniger flexibel

◆ im Fehlerfall weniger durchschaubar

• abhängig vom Reifegrad der Produkte



■ EJB bietete implizite Unterstützung für

◆ verteilte Transaktionen

• Abbruch oder Bestätigung der Ergebnisse einer Transaktion

• Koordinierung nebenläufiger Aktionen

◆ Sicherheitsdienst

• Zugriffskontrolle

◆ Ressourcen- und Life-Cycle-Kontrolle

• Container verwaltet teilweise Bean-Lebenszyklus

◆ Persistenz

• automatisches Sichern persistenter Daten z.B. in Datenbanken

◆ Monitoring

• Container kann Last und Aufrufhäufigkeiten erfassen

D.30



■ Implizite EJB Unterstütztung (fortges.)

◆ entfernte Aufrufe

◆ Ortstransparenz

• wie klassische Middleware


6 EJB-Grundlagen

■ Verschiedene Bean-Typen

◆ Session-Bean

• Modellierung von Geschäftsprozessen

• agieren wie Verben (repräsentieren mögliche Aktionen)

• z.B. „überweisen“, „autorisieren“

• interagieren typischerweise mit Entity-Beans und Session-Beans

◆ Entity-Bean

• Modellierung von Geschäftsdaten

• agieren wie Substantive (repräsentieren Daten aus der Datenbank)

• z.B. „Konto“, „Kreditkarte“, „Produkt“

◆ Message-Driven-Bean

• ähnlich Session-Bean

• ansprechbar über Nachrichten

D.32


6.1 Bean-Klassen

■ Beans werden durch Java-Klassen repräsentiert

◆ müssen bestimmte Java-Interface implementieren

■ Alle Beans

◆ implementieren Marker-Interface: javax.ejb.EnterpriseBean

◆ markiert Bean gleichzeitig als serializable

■ Einzelne Bean-Typen

◆ implementieren jeweils Typ-Interfaces: javax.ejb.SessionBean, javax.ejb.EntityBean, java.ejb.MessageDrivenBean


6.2 Interaktion mit Beans

■ Keine direkte Interaktion

◆ Bean-Instanzen sind nicht direkt ansprechbar

• implizite Middleware-Aktionen erfordern ein unbedingtes Abfangen von Aufrufen

■ Repräsentant für eine Bean-Instanz ist das EJBObject

◆ implementiert ein (entferntes) Bean-Interface

• Bean-Interface muss von javax.ejb.EJBObject erben

• dieses implementiert java.rmi.Remote

• deklariert alle Methoden der Geschäftslogik

◆ Implementierung des EJBObject herstellerspezifisch

◆ Clienten rufen Bean über ein EJBObject auf

• entfernte Aufrufe über RMI bzw. RMI-IIOP möglich

D.34


6.2 Interaktion mit Beans (2)

■ EJBObject fängt Aufrufe an der Bean ab

◆ führt implizite Middleware-Interkationen durch

• Sicherheitsüberprüfung, Transaktionsverwaltung, Datenbankanfragen ...

◆ Interaktion mit EJBObject über RMI bzw. RMI-IIOP

• Interaktion im lokalen Fall teuer (Marshalling und Demarshalling, lokaler Nachrichtentransport etc.)

EJBObjectClientRMI-

Bean-Instanz

Referenz EJB-Container



■ Lokaler Repräsentant für eine Bean-Instanz ist das EJBLocalObject

◆ implementiert ein lokales Bean-Interface

• Bean-Interface muss von javax.ejb.EJBLocalObject erben

• deklariert alle Methoden der Geschäftslogik

◆ Implementierung des EJBLocalObject herstellerspezifisch

◆ Clienten rufen Bean über ein EJBLocalObject auf

• kein entfernter Aufruf möglich

■ EJBLocalObject fängt Aufrufe an der Bean ab

◆ auch hier: implizite Interaktion mit der Middleware

EJBLocalObjectClientlokale Java-

Bean-Instanz

Referenz EJB-Container

D.36



■ Zusammenhänge

◆ Methoden der Bean-Klasse

◆ Methoden des EJBObject (entferntes Bean-Interface)

◆ Methoden des EJBLocalObject (lokales Bean-Interface)

◆ Methoden der Bean müssen mit gleicher Signatur im Bean-Interface des EJBObject auftreten (jedoch hier mit Exception java.rmi.RemoteException)

◆ Methoden der Bean müssen mit gleicher Signatur im lokalen Bean-Interface des EJBLocalObject auftreten (jedoch hier u.U. ohne Exception java.rmi.RemoteException)

◆ Methoden der Bean benötigen keine java.rmi.RemoteException

• Methoden der Bean können EJB-System-Exceptions werfen

• diese werden nicht an den Client weitergegeben



■ Zusammenhänge (fortges.)

◆ kein syntaktischer Zusammenhang zwischen den zwei Interfaces und der Bean-Klasse

◆ Zusammenhang kann vom Bean-Entwickler durch eigenes Interface eingezogen werden

• Bean-Klasse erbt von eigenem Business-Logic-Interface

• EJBObject- und EJBLocalObject-Interface erbt von eigenem Business-Logic-Interface

D.38


6.3 Erzeugung von Beans

■ Eigentlich Erzeugung von EJBObjects bzw. EJBLocalObjects

◆ Erzeugung der Bean-Instanz erfolgt implizit durch die Middleware bzw. den EJB-Container

■ Erzeugung über Factory-Pattern

◆ Schnittstelle zur Factory heißt Home-Object

■ Repräsentant für ein Home-Object

◆ implementiert ein entferntes oder lokales Home-Interface

• Home-Interface muss von javax.ejb.EJBHome bzw. java.ejb.EJBLocalHome erben

• ersteres implementiert java.rmi.Remote, letzteres nicht

• deklariert Methoden zur Bean-Erzeugung, z.B. create()

◆ Implementierung des Home-Object herstellerspezifisch

◆ Finden des Home-Object durch Namensdienst (typisch über JNDI)


6.3 Erzeugung von Beans (2)

■ Beispiel: entferntes Home-Object

◆ Erzeugung des EJBObject durch Aufruf der create()-Methode am EJBHome (z.B. über RMI-IIOP)

◆ Rückgabe der Referenz auf das EJBObject

EJBObjectClient

RMI-

Bean-Instanz

Referenz

EJB-Container

EJBHome

<<erzeugt>>

D.40


6.4 Verwaltung des Lebenszyklus

■ Clienten interagieren nur mit EJBObject- bzw. EJBLocalObject- und EJBHome- bzw. EJBLocalHome-Objekten

◆ d.h. nur mit herstellerspezifischen Objekten des EJB-Containers

■ Lebenszyklus der EJBObjects bzw. EJBLocalObjects

◆ explizite Methode remove()

◆ muss vom Client aufgerufen werden, falls Referenz nicht mehr benötigt wird

◆ zerstört Bean

■ Lebenszyklus der Bean-Instanz

◆ völlig unabhängig vom Lebenszyklus der EJBObjects

• Bean kann erst bei Aufruf erzeugt werden

• Bean kann „gepoolt“ werden (Wiederverwendung „gebrauchter“ Beans)

• Aufgabenwechsel für Bean-Instanzen während der Laufzeit (dynamische Zuordnung an verschiedene EJBObjects)


6.4 Verwaltung des Lebenszyklus (2)

■ Zuordnung EJBObjects zu Bean-Instanzen nicht unbedingt 1:1

◆ Erzeugung über Home-Interface benutzt u.U. Bean-Instanz wieder

• z.B. Entity-Bean für bestimmtes Konto

◆ mehrere EJBObjects pro Bean-Instanz möglich

• z.B. soviele wie Clients eine Referenz zu einer Entity-Bean erzeugt haben

◆ gepoolte Instanzen implementieren alle referenzierten Beans sprich EJBObjects

D.42


6.5 Bean-Interaktion mit dem Container

■ Interaktion mit Container bisher nur implizit

■ Explizite Interaktion über Context-Objekt

◆ Methode setXYZContext mit XYZ gleich Session, Entity oder MessageDriven

◆ Container übergibt bei Bean-Instanzerzeugung Context-Objekt

◆ indirekte und standardisierte Interaktion mit dem Container

• Methoden zum Ermitteln der Home-Objects (lokal u. entfernt)

• Methoden zum Transaktionsdienst (z.B. ermittle Transaktionsinformationen)

• Methoden zum Sicherheitsdienst (z.B. hole Aufruferinformationen)


6.6 Beispiel

■ Session-Bean für Hello-World

◆ Java-Klasse für Bean

• z.B. example.HelloBean

• implementiert javax.ejb.SessionBean

• implementiert einige vorgegebene Methoden— ejbCreate(): Aufruf bei Erzeugung der Instanz— ejbRemove(): bei Zerstörung der Instanz— ejbPassivate(): bei Passivierung der Instanz— ejbActivate(): bei Aktivierung der Instanz— setSessionContext(): bekommt Session-Context-Object vom

Container

• fügt sayHello-Methode hinzu

D.44


6.6 Beispiel (2)

◆ lokales und entferntes Bean-Interface für das EJBObject

• z.B. example.Hello und example.HelloLocal

• implementiert javax.ejb.EJBObject bzw. EJBLocalObject

• fügt sayHello-Methode hinzu

◆ lokales und entferntes Home-Interface für Home-Object

• z.B. example.HelloHome und example.HelloLocalHome

• implementiert java.ejb.EJBHome bzw. EJBLocalHome

• fügt create-Methode hinzu

◆ Kompilation der Java-Sourcen


6.6 Beispiel (3)

■ Hinzufügen eines Deployment-Descriptors

◆ XML-File

◆ Beispiel

<ejb-jar><enterprise-beans><sessions><ejb-name>Hello</ejb-name><home>example.HelloHome</home><remote>example.Hello</remote><local-home>example.HelloLocalHome</local-home><local>example.HelloLocal</local><ejb-class>example.HelloBean</ejb-class><session-type>Stateless</session-type><transaction-type>Container</transaction-type></sessions></enterprise-beans>

</ejb-jar>

D.46


6.6 Beispiel (4)

■ Descriptorinhalt

◆ Spitzname (Nickname) für die Bean

• wird für den Eintrag des Home-Objects im Namensdienst verwendet

◆ Benennung der Interfaces und der Bean-Klasse

◆ Angaben zur impliziten Middleware-Interaktion

• hier: zustandslose Session-Bean(wird für Lebenszyklusverwaltung verwendet)

• hier: Container-basierte Transaktionsverwaltung(Container kümmert sich um Transaktion pro Aufruf)

■ Class-Files plus Descriptor

◆ Zusammenpacken zu einem jar-File

◆ „verkaufbare“ EJB-Komponente


6.7 Deployment

■ Installation einer Komponente stark herstellerabhängig

■ Vorfeld

◆ Integration des jar-Files in den Application-Server / EJB-Container

◆ Überprüfung der Konsistenz durch Werkzeuge

• Passen Interfaces zur Bean-Klasse?

• Sind die notwendigen Methoden implementiert?

◆ Werkzeuge erzeugen EJBObject, EJBLocalObject, EJBHome- und EJBLocalHome-Objekte

◆ Werkzeuge erzeugen RMI-IIOP-Stubs und -Skeletons für EJBObject und EJBHome-Objekt

■ Eigentliches Deployment

◆ veranlasst EJB-Container, die Bean zu installieren

D.48


6.8 Interaktion mit der Bean

■ Clients müssen folgende Schritte durchführen

◆ Namensdienst über JNDI anfragen (z.B. nach „Hello“)

◆ das zurückgegebene Objekt muss mittels Narrow in einen Stellvertreter vom Typ example.HelloHome gewandelt werden

• Narrow ist eine Typanpassungsfunktion aus der CORBA-Welt(hier: von RMI-IIOP)

◆ Aufruf von create() gibt Objektreferenz auf Stellvertreter für ein EJBObject der Hello-Bean zurück

◆ Aufruf von sayHello() am EJBObject


7 Session-Beans

■ Eigenschaften einer Session-Bean

◆ Lebenszeit verknüpft mit einer Session

• z.B. aktiv solange ein Einkaufsprozedere läuft

• z.B. aktiv solange Kunde auf seine Bankdaten zugreift

• Session-Bean realisiert „Verben“ der Anwendungsspezifikation

• transiente Lebenszeit(überlebt keinesfalls Rechnerausfall, Container-Ausfall)

◆ zwei Varianten bzgl. Zustandsspeicherung während einer Session

• zustandslos

• zustandsbehaftet

D.50


7.1 Zustandslose Session-Bean

■ Eigenschaften

◆ zustandslose Session-Bean speichert keinen Zustand

• Aktion/Session besteht aus nur einem einzigen Methodenaufruf

• z.B. Hello-Bean

• z.B. Kreditkartenautorisierung

◆ Zustand nur während der Methodenbehandlung

◆ falls doch Zustand erforderlich:

• Zustandsübergabe per Parameterübergabe und -rückgabe oder

• Zustandsspeicherung externz.B. über Datenbank, Datei oder Entity-Bean


7.1 Zustandslose Session-Bean (2)

■ Behandlung im Container

◆ beliebige Beaninstanz kann für alle EJBObjects des gleichen Bean-Typs benutzt werden

• Wiederverwendung vorhandener Bean-Instanzen möglich(Vergangenheit der Instanz irrelevant)

◆ Pooling von Bean-Instanzen

• pro Bean nur ein aktiver Methodenaufruf (single-threaded)

• Erzeugung einer Menge von Arbeitsinstanzen für nebenläufige Aufrufbearbeitung

D.52



■ Lebenszeit einer zustandslosen Session-Bean (typisch)

◆ Session-Bean im Pool: keine konkrete Instanz zugeordnet

• Zuordnung erfolgt erst beim Aufruf

nicht existent

im Pool

ErzeugungZerstörung

Methodenaufruf(Geschäftslogik)

1. Class.newInstance2. setSessionContext

3. ejbCreate1. ejbRemove

nach Roman et al.



■ Interaktion des Containers mit der Bean

◆ Aufruf von ejbCreate() nach Erzeugung

• zur Initialisierung (z.B. Reservierung von Ressourcen)

• immer ohne Parameter

• taucht im Home-Interface als create() auf

◆ Aufruf von ejbRemove() vor Zerstörung

• zum Freigeben von Ressourcen

D.54


7.2 Zustandsbehaftete Session-Bean

■ Eigenschaften

◆ Session-Bean speichert Zustand

• bis Aufrufer EJBObject freigibt (durch Aufruf von remove())

◆ Aktion/Session besteht aus mehreren Methodenaufrufen

• z.B. Kaufvorgang in einem Webshop

■ Behandlung im Container

◆ Nutzung einer Bean-Instanz pro Client (pro erzeugtem EJBObject)

◆ Problem: große Ressourcenverschwendung durch Vielzahl von Session-Bean-Instanzen, die selten genutzt werden

◆ Lösung: Passivierung und Aktivierung

• Passivierung sichert Zustand der Bean-Instanz

• Aktivierung stellt Zustand der Bean-Instanz wieder her


7.2 Zustandsbehaftete Session-Bean (2)

■ Behandlung im Container (fortges.)

◆ Passivierung- und Aktivierungsmechanismen

• Java-Serialisierung oder

• proprietäres Verfahren (z.B. Serialisierung und Reflection-API)

• alle nicht-transienten Variablen werden gesichert

• besondere Sicherung für Referenzen auf EJBObjects, Home-Interfaces, Session-Kontextobjekte und JNDI-Namenskontexte

D.56



■ Behandlung im Container (fortges.)

◆ Pooling der Bean-Instanzen

• Pool der Instanzen bilden aktive Bean-Instanzen

• Zugriff auf passive Beans (Activation on Demand)– Passivierung einer aktiven Bean-Instanz (z.B. nach LRU-Algorithmus)– Aktivierung der gleichen/einer neuen Instanz mit neuem Bean-Zustand– Weiterleitung des Aufrufs vom EJBObjekt an dieser Instanz

• vergleiche Virtueller Speicher!

◆ keine Passivierung der Teilnehmer einer Transaktion


7.2 Zustandsbehaftete Session Bean (4)

■ Lebenszeit einer zustandsbehafteten Session-Bean

◆ Session-Bean im Pool: Zuordnung zu konkreter Instanz erfolgt bei ejbCreate() bzw. ejbActivate()

◆ Zerstörung von Bean-Instanzen nach einstellbarem Timeout

• Parameter des herstellerabhängigen Deployments

nicht existent

im Pool

ErzeugungZerstörung



3. ejbCreate()

1. ejbRemove

passiv

Passivierung

1. ejbPassivate

Aktivierung

1. ejbActivate

Timeout

nach Roman et al.

D.58



■ Interaktion des Containers mit der Bean

◆ Aufruf von ejbCreate() nach Erzeugung

• zur Initialisierung (z.B. Reservierung von Ressourcen)

• mehrere Varianten mit unterschiedlichen Parametern möglich

• taucht im Home-Interface als Varianten von create() auf

◆ Aufruf von ejbRemove() vor Zerstörung

• zum Freigeben von Ressourcen

◆ Aufruf von ejbPassivate() vor Passivierung

• zur Freigabe von Ressourcen

• zum Aufräumen des Zustands

◆ Aufruf von ejbActivate() nach Aktivierung

• zum Belegen von Ressourcen

• zum Initialisieren des reaktivierten Zustands


7.3 Container-Interaktion

■ Zusätzliche Methoden im SessionContext-Objekt

◆ getEJBObject() erzeugt ein EJBObject für die aktuelle Bean

◆ getEJBLocalObject() erzeugt ein EJBLocalObject für die aktuelle Bean

◆ Weitergabe einer „this“-Referenz an andere Beans

• wg. Pooling und Passivierung eigentliche this-Referenz nicht verwendbar

D.60


8 Entity-Beans

■ Eigenschaften einer Entity-Bean

◆ Lebenszeit unabhängig von der Session, dem Container und dem Lauf des Rechensystems

• Entity-Bean ist persistent

◆ Entity-Bean realisiert „Substantitve“ der Anwendungsspezifikation

• datenorientiert

• z.B. Konto, Kreditkarte, Produkt

• Entity-Bean ist Repräsentant für Dateneinheit

• keine persistente Speicherung in der Bean(stattdessen typischerweise Datenbank)

• Entity-Bean wird eindeutig einer Dateneinheit in einer Datenbank zugeordnet (Relation, Objekt, ...)


8.1 Primary-Key

■ Repräsentation der eindeutigen Zuordnung zu Datensatz in der Datenbank

◆ Primary-Key-Klasse

◆ erzeugt serialisierbare Objekte

◆ enthält beliebige Attribute

◆ die selbe Zuordnung wird durch gleiches Primary-Key-Objekt repräsentiert

• Beispiel: Primary-Key-Objekt enthält eindeutige Kontonummer

◆ containerinterne Verwendung

• Identifizierung von Beans, die auf dieselben Daten verweisen

D.62


8.2 Container und Entity-Bean

■ Pooling von Entity-Beans

◆ mehrere Beans pro Datum

• gleicher Primary-Key

• repräsentieren dieselben Daten

• Beans sind single-threaded: höherer Durchsatz durch mehrere Instanzen

• Koordinierung der Konsistenz durch Container bzw. Transaktionen

◆ Wechsel der Bean-Zugehörigkeit

• Passivierung und Aktivierung ermöglicht Pooling von Bean-Instanzen

• dynamische Zuordnung der Daten zu Bean-Instanzen

■ Zwei Entity-Bean-Typen

◆ Bean-Managed Persistence (BMP)

◆ Container-Managed Persistence (CMP)


8.3 Interaktion mit Container

■ Zusätzliche Methoden der Entity-Bean für Datenhaltung

◆ ejbLoad() lädt Daten aus der Datenbank in die Bean

◆ ejbStore() speichert Daten zurück in die Datenbank

◆ implizite Aufrufe

• Anwendungsentwickler muss sich nicht um korrekte Aufrufe kümmern.

◆ ansonsten Methoden wie bei Session-Bean

• ejbCreate(), ejbRemove(), ejbPassivate(), ejbActivate()

• aber setEntityContext() und unsetEntityContext()

D.64


8.3 Interaktion mit dem Container (2)

■ Zusätzliche Methoden der Entity-Bean für Datenhaltung (fortges.)

◆ ejbCreate() Methode zur Erzeugung neuer Datenbankeinträge

• mehrere Varianten möglich

• kann auch ganz fehlen: durch EJB-System keine neuen Einträge möglich

• ergänzt durch ejbPostCreate() mit gleichen Parametern(kann jetzt auch EJBObjects von sich weitergeben)

◆ ejbRemove() zum Löschen des Datums aus der Datenbank

■ Zusätzliche Methoden der Bean für das Home-Interface

◆ Methoden, die sich nicht auf konkretes Datum beziehen(z.B. Statistiken, Prüfungen)

◆ Methoden ejbHomeXYZ() tauchen als Methode XYZ() im Home-Interface auf



■ Methoden der Bean zum Finden von Entity-Beans

◆ eine oder mehrere Finder-Methoden zur Ermittlung von Entity-Beans aus der Datenbank

◆ Methoden ejbFindXYZ()

• mindestens ejbFindByPrimaryKey( ... )

• Rückgabewert: entweder Primary-Key-Objekt oder Collection von Primary-Key-Objekten

◆ Methoden tauchen als findXYZ() im Home-Interface bzw. LocalHome-Interface auf

• geben EJBObject bzw. EJBLocalObject oder Collection von EJBObjects bzw. EJBLocalObjects zurück

◆ Finder-Methoden müssen javax.ejb.FinderException werfen können

D.66



■ Methoden im Entity-Kontextobjekt

◆ wie bei Session-Kontext: getEJBObject(), getEJBLocalObject()

◆ zusätzlich: getPrimaryKey()

• Ermittlung des aktuellen Primary-Key-Objekts

• Primary-Key-Objekt muss von ejbCreate() zurückgegeben werden


8.4 Bean-Managed Persistence

■ Entity-Bean-Implementierung sorgt für Persistenz der Daten

◆ Zugriff auf Datenbank über JDBC-Verbindung

• Container legt javax.sql.DataSource-Objekt im JNDI-Namensraum ab (über Deployment-Deskriptor konfigurierbar)

◆ automatisches Pooling von Datenbankverbindungen

• Anforderung und Freigabe der Verbindung vor und nach allen CRUD-Operationen (Create, Read, Update, Delete)

• Anforderung: Methode getConnection() an DataSource-Objekt

• Freigabe: Methode close() am Verbindungsobjekt

◆ Verändern und Lesen der Datenbank über SQL-Anweisungen mit JDBC-Methoden

• Erzeugung von PreparedStatement-Objekten über Methode prepareStatement() am Verbindungsobjekt

• Ausführung des übergebenen SQL-Statements durch Methodenaufrufe

D.68


8.4 Bean-Managed-Persistence (2)

■ Implementierung von Datenbankzugriffen in

◆ ejbCreate-Methoden

◆ ejbRemove-Methode

◆ ejbFind*-Methoden

◆ evtl. ejbHome*-Methoden, falls Zugriffe erforderlich sind

◆ ejbLoad- und ejbStore-Methode

◆ Beispiel: Konto-Bean

• ejbCreate( AccountID id, String ownerName )

• ejbFindByPrimaryKey(), ejbFindByOwnerName()

• ejbHomeGetTotalBalance()


8.4 Bean-Managed Persistence (3)

■ Lebenszyklus einer BMP-Entity-Bean

◆ im Pool: keine Zuordnung zu EJBObject

nicht existent

im Pool

Erzeugung Zerstörung


1. Class.newInstance2. setEntityContext

1. unsetEntityContext

aktiv

Passivierung

1. ejbStore

Aktivierung

1. ejbActivate

ejbFind*ejbHome*

ejbLoadejbStore

2. ejbLoad 2. ejbPassivate

Zerstörung

1. ejbRemove

Erzeugung

1. ejbCreate2. ejbPostCreate

nach Roman et al.

D.70



■ Deployment-Deskriptor

◆ Beispiel

◆ rekursive Aufrufe

• Bean kann über andere Beans sich selbst aufrufen (reentrant = True)

<ejb-jar><enterprise-beans><entity><ejb-name>Account</ejb-name><home>example.AccountHome</home><remote>example.Account</remote><local-home>example.AccountLocalHome</local-home><local>example.AccountLocal</local><ejb-class>example.AccountBean</ejb-class><persistence-type>Bean</persistence-type><prim-key-class>example.AccountPK</prim-key-class><reentrant>False</reentrant>

...



■ Deployment-Descriptor (fortges.)

◆ Angabe zum Finden der JDBC-Ressourcen

◆ Angaben zu Transaktionen

<resource-ref><res-ref-name>jdbc/ejbPool</res-ref-name><res-type>javax.sql.DataSource</res-type><res-auth>Container</res-auth>

</resource-ref></entity></enterprise-beans>

<assembly-descriptor><container-transactions>...</container-transactions></assembly-descriptor>

</ejb-jar>

D.72


8.5 Container-Managed Persistence

■ Neuheit seit EJB 2.0

◆ Container kümmert sich um Datenbankanbindung

• CMP = Container-Managed Persistence

◆ starke Vereinfachung der Bean-Entwicklung

■ Implementierung der Datenbankanbindung

◆ Bereitstellung einer abstrakten Entity-Bean-Klasse durch Entwickler

◆ Container stellt generierte, herstellerspezifische Subklasse bereit

• Subklassen-Instanz ist eigentliche Bean-Instanz

Bean-Klasse

Subklasse


8.5 Container-Managed Persistence (2)

■ Abstrakte Bean-Klasse des Bean-Entwicklers

◆ Weglassen aller Datenbankzugriffe

◆ Weglassen aller persistenten Datenfelder

◆ Deklarierung von abstrakten set*/get*-Methoden für alle Datenfelder

◆ Verwendung dieser Methoden zum Datenzugriff in Businesslogik

◆ Weglassen aller Implementierungen von ejbFind*-Methoden

• bleiben aber im Home-Interface erhalten

◆ Deklarierung von abstrakten ejbSelect*-Methoden

• nur bean-intern verwendbar

• erlauben die Selektion bestimmter Daten aus der Datenbank (nicht

• z.B. notwendig für Implementierung von ejbHomeGetTotalBalance() des Konto-Beispiels (z.B. ejbSelectTotalBalance())

D.74



■ Abstrakte Bean-Klasse des Bean-Entwicklers (fortges.)

◆ Implementierung der ejbHome*-Methoden

• keine direkten Datenbankzugriffe

• stattdessen Nutzung der ejbSelect*-Methoden

◆ Implementierung von ejbCreate-Methoden

• aufgerufen durch entsprechende Methode aus der Subklasse

• nicht unbedingt notwendig, wenn keine Datenerzeugung benötigt

• kein Datenbankzugriff

• stattdessen setzen der Daten durch set*-Methoden

• Container fügt anschließend Daten in die Datenbank ein

• ähnliches Vorgehen für ejbPostCreate-Methoden

◆ Implementierung von ejbActivate und ejbPassivate

• gleiche Funktion wie bei BMP-Beans



■ Abstrakte Bean-Klasse des Bean-Entwicklers (fortges.)

◆ Implementierung von ejbLoad und ejbStore

• keine Datenbankzugriffe

• Container hat vor ejbLoad-Aufruf Daten geladen

• Container speichert nach ejbStore-Aufruf Daten ab

◆ Implementierung von ejbRemove

• keine Dantenbankzugriffe

• Container löscht Daten nach dem Aufruf

D.76



■ Vom Container generierte Subklasse

◆ implementiert set*/get*-Methoden für alle persistenten Entity-Daten

• Namen kommen aus dem Deployment-Deskriptor

• Typen kommen aus der Bean-Klasse (abstrakte Methodendeklarationen)

◆ fängt ejb*-Methoden ab, um Datenbankzugriffe durchzuführen

• ruft meist ejb*-Methoden der Bean-Klasse des Entwicklers auf

◆ implementiert ejbFind*-Methoden

• Abfrageinformation kommt aus dem Deployment-Deskriptor

◆ implementiert ejbSelect*-Methoden

• Abfrageinformation kommt aus dem Deployment-Deskriptor



■ Deployment-Deskriptor

◆ Beispiel

◆ zu allen Feldern muss es get*/set*-Methoden geben

<ejb-jar><enterprise-beans><entity>...<persistence-type>Container</persistence-type>...<cmp-version>2.x</cmp-version><abstract-shema-name>AccountBean</abstract-shema-name><cmp-field><field-name>accountID</field-name>

</cmp-field>...<prim-key-field>accountID</prim-key-field>...

D.78



■ Deployment-Deskriptor (fortges.)

◆ Deskriptor enthält die persistenten Felder der Entity-Bean

■ Container-abhängiges Deployment

◆ Abbildung der Felder auf Datenbankdaten

• z.B. Abbildung auf Spalten einer Tabelle in relationaler Datenbank

• Abbildung herstellerabhängig zu konfigurieren

■ Beschreibung der ejbFind*- und ejbSelect*-Methoden

◆ EJB-QL (Query-Language, Abfragesprache)

◆ abstrakte Datenbankzugriffsprache

• unabhängig von konkreter Datenbankanbindung

• leicht in SQL-Anfragen überführbar



■ Beispiel für EJB-QL-Beschreibung im Deployment-Descriptor

◆ Angabe der Abfragen für jede ejbFind*- und ejbSelect*-Methode

<ejb-jar><enterprise-beans><entity>...<query><query-method><method-name>findByName</method-name><method-params><method-param>java.lang.String</method-param></method-params></query-method><ejb-ql><![CDATA[SELECT OBJECT(a) FROM AccountBean AS a

WHERE name = ?1]]></ejb-ql>

</query>...

D.80



■ Lebenszyklus einer CMP-Entity-Bean

◆ im Pool: keine Zuordnung zu EJBObject

nicht existent

im Pool

Erzeugung Zerstörung



1. unsetEntityContext

aktiv

Passivierung

1. ejbStore

Aktivierung

1. ejbActivate

ejbFind*ejbHome*

ejbLoadejbStore

2. ejbLoad 2. ejbPassivate

Zerstörung

1. ejbRemove

Erzeugung

1. ejbCreate2. ejbPostCreate

ejbSelect*

ejbSelect*nach Roman et al.


9 Message-Driven Bean

■ Schnittstelle zu nachrichtenbasierten Systemen

◆ MOM (Message-oriented Middleware)

◆ JMS (Java Message Service)

• Schnittstelle zu allen möglichen Nachrichtensystemen

■ Message-Driven Bean

◆ Enterprise-Java-Bean, die Nachrichten entgegen nehmen kann

◆ kein Home-Interface

◆ eine Methode: onMessage()

◆ zustandslose Weiterverarbeitung der Nachricht

• bedingte, verarbeitete Weiterleitung der Nachricht an andere Beans (typisch Session-Beans)

D.82


10 Bean-Referenzen

■ Referenzen zwischen Beans

◆ Herstellung wie von Client-Seite

• Namensauflösung über JNDI

• create() am Home-Interface ausführen

• RMI-IIOP-Referenz oder lokale Referenz auf EJBObject oder EJBLocalObject zurückbekommen

◆ Deklaration im Deployment-Descriptor möglich

• Angabe eines Namens im JNDI-Namensraum– kann vom Container über symbolische Links auf echten Namen

umgebogen werden

• Angabe von Bean-Klasse und -typ


10 Bean-Referenzen (2)

■ Langlebige Referenzen auf Beans

◆ z.B. Abbruch der RMI-IIOP Verbindung

◆ Umwandlung von EJBObject-Referenzen in EJB-Object-Handles

• Aufruf von getHandle()

◆ Handle kann serialisiert werden

• z.B. Referenz auf bestimmte Entity-Bean

◆ Umwandlung einer Handle in EJBObject

• Aufruf von getEJBObject() an dem Handle-Objekt

• anschließendes Narrow notwendig

■ Langlebige Referenzen auf Home-Objects

◆ selbe Prozedur nur für Home-Handles

▲ Handles sind nicht portabel von Container zu Container

D.84


11 Sicherheit

■ Authentisierung

◆ Feststellung der Identität

■ Autorisierung

◆ Feststellung der Erlaubnis für eine Aktion

• benötigt typischerweise Authentisierung

■ Nutzung von JAAS (Java Authentication and Authorization API)

◆ komplexes Rahmenwerk zur Übermittlung von Authentisierungskontexten bei Aufrufen

• transparenter Sicherheitskontext im Rahmen von IIOP-Kommunikation

• EJB-Container kann Aufrufe einem Subjekt (Principal) zuordnen


11.1 Authentisierung

■ Subject-Objekte von JAAS

◆ enthalten Informationen über authentisisierten Principal

◆ bekommt man als Ergebnis der Authentisierung

■ Aktionsobjekte

◆ leiten von PriviledgedAction ab

◆ implementieren eine run()-Methode

• z.B. Aufruf von sayhello() an einer neuen Hello-Bean

■ Ausführung einer privilegierten Aktion

◆ Aufruf einer statische Methode:Subject.doAs( Subject s, PriviledgedAction a )

◆ Rückgabewert als java.lang.Object

D.86


11.1 Authentisierung (2)

■ Schematischer Ablauf

◆ Subject-Objekt wird nach Authentisierung erzeugt

JAAS API

Login Module J2EEContainer

Priveledged-Action

SubjectClient

run()

doAs()

Login Context

konfigurierbar



■ Verschiedene Verfahren zur Erzeugung von Subject-Objekten

◆ Angabe von X.509-Zertifikaten

• zertifizierte Public-Keys

◆ Angabe von Benutzernamen und Passwort

• Verifikation des richtigen Passworts

• z.B. über das Web

◆ Ermittlung von Benutzer-IDs aus dem Betriebssystem

◆ JAAS-interne Login-Module verifizieren Benutzerinformationen und erzeugen Subject-Objekt

• z.B. Abfrage von Passwörtern

• proprietäres Protokoll zu dem Container

• Erzeugung und Rückgabe von Subject-Objekten

D.88



■ Übertragung der Aufruferinformation

◆ Integration des Subject-Objekts in den Aufrufkontext

◆ Aufrufkontext:

• zusätzlich zu Methodenaufruf und Parameter übertragene Informationen

• z.B. RMI-IIOP, Integration in den IIOP-Kontext

• Subject-Objekt wird im Container wiedererkannt und authentisiertem Benutzer zugeordnet


11.2 Autorisierung

■ Zwei Arten

◆ programmatische Autorisierung

• Bean-Managed Authorization

◆ deklarative Autorisierung

• Container-Managed Authorization

■ Sicherheitsrollen

◆ Aufrufe erfordern vom Principal das Innehaben einer Rolle

• Unabhängigkeit von konkreten Personen bzw. Principals

◆ externe Zuordnung von Personen zu Rollen

• Zuordnung im container-spezifischem Deployment

D.90


11.3 Programmatische Autorisierung

■ Ermittlung der Principal-Informationen

◆ Aufruf am EJBContext-Objekt von getCallerPrincipal()

■ Ermittlung der Rollenzugehörigkeit

◆ Aufruf am EJBContext-Objekt von isCallerInRole( String role )

◆ dynamische Zugriffsentscheidung

■ Definition der erforderlichen Rolle im Deployment-Descriptor

...<session>...<security-role-ref><description>...</description><role-name>administrators</role-name><role-link>admins</role-link></security-role-ref>...


11.3 Programmatische Autorisierung (2)

■ Abbildung der Rolle innerhalb der Bean an reale Anwendungsrolle

◆ z.B. Abbildung der Rolle administrators auf die Rolle admins

◆ Definition der realen Rolle im Deployment-Descriptor

• im Abschnitt zur Komposition der Anwendung

...<assembly-description>...<security-role><description>...</description><role-name>admins</role-name></security-role></assembly-description>...

D.92


11.4 Deklarative Autorisierung

■ Deklaration der Aufruferlaubnis im Deployment-Descriptor

◆ zusätzlich Deklaration der Rollen wie bei programmatischer Autorisierung

<assembly-description>...<method-permission><role-name>admins</role-name><method><ejb-name>Account</ejb-name><method-name>*</method-name></method><method><ejb-name>Hello</ebj-name><method-name>sayHello</method-name><method-params>void</method-params>

</method></method-permission>...</assembly-description>...


12 Transaktionen

■ Motivation

◆ Konsistenz von Daten

• bei Fehlern aller Art

• bei nebenläufigem und parallelem Zugriff

■ Transaktionen

◆ fassen mehrere Teilaktionen zu einer atomaren Operation zusammen

• entweder alles ausgeführt oder nichts (Atomicity)

◆ Fehler führen zu einem Rückfahren der bisherigen Effekte (Roll-Back)

D.94


12 Transaktionen (2)

■ Eigenschaften typischer Transaktionsverfahren (ACID)

◆ Atomicity: alle Transaktionen (mit allen Teilaktionen) erscheinen atomar

• Möglichkeit zum Roll-Back im Fehlerfall

◆ Consistency: jede Transaktion hinterlässt das System in konsistentem Zustand (inkonsistente Zustände führen zu Roll-Back)

◆ Isolation: eine Transaktion „sieht“ keine unvollständig ausgeführte andere Transaktion im System

◆ Durability: Persistenz der Aktionen einer Transaktion über die Lebenszeit von Teilsystemen hinaus (z.B. Crash des Datenbankservers)


12 Transaktionen (3)

■ Start der Transaktion

◆ typischerweise begin()-Aufruf an einem Transaktionsmanager

■ Beenden der Transaktion

◆ typischerweise commit()-Aufruf an einem Transaktionsmanager

■ Abbruch der Transaktion

◆ typischerweise abort()-Aufruf an einem Transaktionsmanager

D.96


12.1 EJB-Transaktionsunterstützung

■ Drei Varianten der Transaktionsunterstützung

◆ Transaktionskontrolle durch Klient/Aufrufer (client-side)

• außenstehender Aufrufer startet und beendet Transaktion

• Bean-Aufrufe laufen im Rahmen dieser Transaktion

◆ Transaktionskontrolle durch Container (declarative)

• Container startet und beendet Transaktion für Bean-Aufrufe

◆ Transaktionskontrolle durch Bean (programmatic)

• Bean-Methodenimplementierungen starten und beenden Transaktion


12.2 Container-Managed Transaction

■ Angabe des Transaktionstyps und eines Transaktionsattributs im Deployment-Deskriptor zu jeder Bean

...<transaction-type>Container</transaction-type>...<container-transaction><trans-attribute>Required</trans-attribute><method><ejb-name>Account</ejb-name><method-name>*</method-name></method><method><ejb-name>Hello</ebj-name><method-name>sayHello</method-name><method-params>void</method-params>

</method></container-transaction>...

D.98


12.2 Container-Managed Transaction (2)

■ Transaktionsattribute

◆ abhängig von laufender Transaktion nimmt Beanaufruf an Transaktion teil oder nicht

◆ mögliche Werte und deren Bedeutung

Attribut laufende Transaktion

Transaktiondes Bean-

aufrufs

Required (S, E, M)

keine Tneu

Talt Talt

RequiresNew (S, E)

keine Tneu

Talt Tneu

Supports (S stateless)

keine keine

Talt Talt


12.3 Container-Managed Transaction (3)

■ Transaktionsattribute

◆ mögliche Werte und deren Bedeutung (fortges.)

◆ abhängig vom Transaktionsattribut wird neue Transaktion gestartet

Attribut laufende Transaktion

Transaktiondes Bean-

aufrufs

NotSupported (S stateless, M)

keine keine

Talt keine

Mandatory (S, E)

keine error

Talt Talt

Never (S stateless)

keine keine

Talt error

D.100


12.4 Bean-Managed Transaction

■ CORBA OTS (Object Transaction Service)

◆ Menge von Schnittstellen für einen Transaktionsmanager

■ JTS (Java Transaction Service)

◆ Abbildung von OTS auf Java

■ Rückgriff auf JTA (Java Transactions API)

◆ lediglich Schnittstelle zum Starten und Beenden von Transaktionen

◆ interne Schnittstellen bleiben verdeckt (z.B. zwischen Datenbank und Transaktionsmanger etc.)

◆ Zugang zu javax.transaction.UserTransaction-Objekt über JNDI

• Aufruf von begin(), commit() oder rollback()


12.5 Klientenseitige Transaktion

■ Start und Beenden der Transaktion im Klientenprogramm

◆ z.B. Applet, JSP etc.

◆ Zugang zu UserTransaction-Objekt über JNDI

12.6 Isolation

■ Strikte Isolation

◆ Serialisierbarkeit aller Transaktionen

◆ Transaktion liest keine von laufenden Transaktionen veränderten Daten(kein Dirty Read)

◆ gelesene Daten verändern sich nicht im Laufe der Transaktion(kein Unrepeatable Read)

◆ während der Transaktion tauchen keine neuen Datensätze auf(kein Phantom Read)

D.102


12.6 Isolation (2)

■ Zugang zu Daten wird kontrolliert

◆ Kontrolle der Nebenläufigkeit (Koordinierung) über Sperren

◆ Sicherstellung der Serialisierbarkeit

◆ z.B. zwei Transaktionen zur Überweisung vom gleichen Konto

• erste Transaktion verändert Soll-Konto

• zweite Transaktion darf nicht auf Soll-Konto zugreifen(sonst: Dirty Read)

• zweite Transaktion muss warten

• Koordination im Container beim Zugang zur entsprechendenEntity-Bean


12.6 Isolation (3)

■ Abgeschwächte Isolation

◆ schwächere Isolation steigert Nebenläufigkeit und damit Effizienz

◆ READ UNCOMMITTED erlaubt Dirty-Read, Unrepeatable-Read und Phantom-Read

◆ READ COMMITTED erlaubt Unrepeatable-Read und Phantom-Read

◆ REPEATABLE READ erlaubt Phantom-Read

◆ SERIALIZABLE entspricht strikter Isolation

◆ Isolationsform kann bei der Datenbankverbindung eingestellt werden

◆ bei Container-Managed-Transaction Bestandteil des herstellerabhängigen Deployment-Deskriptors

D.104


12.7 Transaktionsimplementierung

■ Übertragung des Transaktionskontext über (RMI-)IIOP

◆ Ressourcen-Manager und Container können feststellen, in welcher Transaktion der Aufrufer läuft

■ Zugang zu geschützten Ressourcen

◆ z.B. zur Datenbank über Entity-Beans

• Einrichtung von Sperren zur Isolation

• Aufruf von ejbLoad() und ejbStore() als Teil der Transaktion(Beginn und Commit)

■ Transaktionsmanager

◆ kennt alle Ressource-Manager (z.B. Datenbanken), die an Transaktion beteiligt

◆ bei Commit: Befragung aller Manager nach Zustimmung

◆ bei Abort: Rollback und Freigabe aller Sperren


13 Zusammenfassungzum EJB-Programmiermodell

■ Verteilung

◆ Kommunikation über RMI-IIOP/CORBA

■ Unterstützung nichtfunktionaler Eigenschaften

◆ Effizienz und Ressourcenverwaltung

• Abkopplung der Lebenszeit von Bean-Instanzen von der Lebenszeit der Bean

◆ Konsistenz und Nebenläufigkeit

• Transaktionskonzept

◆ Sicherheit

• Sicherheitskonzept

◆ Persistenz

• Anbindung an Datenbank

D.106


13 Zusammenfassungzum EJB-Programmiemodell (2)

✱ Interessantes Programmiermodell

◆ jedoch noch einige Schwächen im Modell: Portabilitäts- und Semantikprobleme (z.B. Transaktionssemantik)

◆ kommt sehr häufig für Internetdienste zum Einsatz


14 EJB-Anbindung an den Client

■ Direkte Anbindung

◆ Zugang zum Home-Interface eines Bean-Typs

• z.B. über JNDI aus Namensdienst des Containers

◆ Zugriff auf Beans über RMI-IIOP

■ Zugriff über dynamische Webseiten

◆ z.B. Bestellformular, „Einkaufswagen“

◆ Implementierung

• CGI-Skript greift direkt auf Beans zu

• JSP (Java-Server-Pages)– Taglib für EJB-Anbindung (z.B. Referenz auf Home-Interface in JNDI suchen)

• Servlets

D.108


15 Literatur

■ EJB

◆ E. Roman, S. Ambler, T. Jewell: Mastering Enterprise Java Beans. 2nd Ed., Wiley & Sons, 2002.

◆ Enterprise JavaBeans Ver. 2.1, Specification<http://java.sun.com/products/java/docs.html>

◆ Developer’s Bookshelf about Java 2 Enterprise Edition (J2EE)<http://java.sun.com/developer/Books/j2ee/>

D.109

Date post:	08-Aug-2018
Category:	Documents
Upload:	ngoque
View:	237 times
Download:	0 times

Java Servlet Technology 2.3 D Enterprise Java Beans … · 1 J2EE Java 2 Enterprise Edition...

Documents