1
J2ME Micro Edition
J2EE Enterprise Edition
J2SE Standard Edition
A Java 2 EnterpriseEdition 1 Java Plattform
Die Java Plattform ist in drei Editionen aufgeteilt:
robuste, flexible Umgebung für:
- Mobil-Telefone, PDAs
- embedded devices
VM und Standart Java
APIs für Kommunikationsprozesse.
Die J2SE definiert:
- JRE, VM, etc.
- JDK
Stellt die Basis für J2EE dar.
Standart um
Multi-Tier Enterprise Applikationen zun entwickeln.
Dienstleistungen für Komponenten und
transparente Lösungen für ihr Verhalten.
1.1 Verteilte Systeme
mehrere Prozesse kommunizieren per Nachrichtenaustausch
Gemeinsame Nutzung von Ressourcen
- Zugriff, Verzögerung, Updates zuverlässig und konsistent
Offenheit
- Erweiterbarkeit: HW, SW Standardisierung der Schnittstellen
- Interprozesskommunikation
- heterogene HW- und SW- Komp.
Skalierbarkeit
- konstante System- oder Anwendungssoftware
Fehlertoleranz
- Hardwareredundanz, Softwareredundanz
2
1.2 Technologien für Verteilte Systeme
CORBA (Common Object Request Broker Architecture):
- Plattform- und Sprachunabhängig
- nur "basic distribution"
DCOM (Distributed COM) Dienste zur Kommunikation zwischen Prozessen
- fokussiert auf Microsoft
- CORBA-DCOM Bridge
.NET (Microsoft)
- Sprach- und ( Plattform = mono ) unabhängiges Framework für Verteilte Systeme
- fokusiert Client (Services)
http://www.mono-project.com
EJB (Enterprise Java Beans)
- nur JAVA
- entwickelt für Geschäftsprozesse
- Sicherheits- und Verbindungslogik ist integriert
3
2 J2EE Applikationsframework
J2EE bezeichnet ein Applikationsframework, ausgelegt auf:
- Performance
- Skalierbarkeit
- Plattformunabhängigkeit
Die Trennung zwischen Client-Tier, Business-Tier und Data-Tier ist sehr sauber implementiert und erlaubt eine weitgehende Unabhängigkeit von den verwendeten Clients und den Systemen zur Datenhaltung im Backend.
J2EE Applikations-Server beinhaltet:
- Components
- Applets, Servlets, Enterprise Java Beans
- Containers
- Web Browsers, Servlet Engines, EJB Containers
- Resources
- SQL Datenquellen, Nachrichtensysteme, Mailsysteme
2.1 Einsatzgebiete
- Datenbankzugriff
- Dynamische Internetseiten
- Enterprise JavaBeans
- Middle-Tier Server
- Plattformenabhängige Kommunikation
- Sicherheit
- Trennung der Anwenderschwerpunkte
- Verteilte Systeme
- Web-Server-Einsatz
4
J2EE JDBC
JNDI JTA
JMS
ORACLE DB2
COS
LDAP
DNS
IBM MQSeries iBus
BEATuxedo
2.2 Architektur
Funktionelle Einheiten werden als Komponenten bezeichnet und zu einer Komponenten-Architektur zusammengefasst. Dabei dominieren die folgenden "Core Technologies":
- JNDI (Java Naming and Directory Interface) ermöglicht den Zugriff auf "naming" und "directory" Systeme wie LDAP, COS oder DNS
- JTA (Java Transaktion API) ermöglicht den Zugriff auf Transaktions-Systeme wie BEA Tuxedo, etc.
- JDBC (Java DataBase Connectivity) ermöglicht Zugriff zu relationalen Datenbanken
- JMS (Java Messaging Service) ermöglicht den Zugriff zu Message Orientated Middleware, z.B. iBus ,IBM MQSeries
2.3 Namenskonventionen
Item Syntax Beispiel
Enterprise Bean Name (DD)
<name>Bean HelloWorldBean
EJB JAR Display Name (DD)
<name>JAR HelloWorldJAR
Enterprise Bean Class <name>Bean HelloWorldBean
Home Interface <name>Home HelloWorldHome
Remote Interface <name> HelloWorld
Local Home Interface <name>LocalHome HelloWorldLocalHome
Local Remote Interface <name>Local HelloWorldLocal
Abstract Schema (DD)
<name> HelloWorld
5
2.4 Bestandteile einer J2EE-Anwendung
Eine J2EE-Anwendung ist eine J2EE-Komponente, die über einen J2EE-Server verschiedenen Clients zur Verfügung gestellt wird. Die Bestandteile einer J2EE-Anwendung werden in eine *.ear Datei (enterprise archive) gepackt und können aus den folgenden Komponenten bestehen:
- Enterprise Beans eine oder mehrere Enterprise Beans in einem *.jar Datei (java archive)
- WEB-Anwendungen HTML-Seiten, Servlets, JSP, gif- und jpg-Bilder in einer *.war Datei (web application archive)
- Client-Anwendungen Stand-Alone Java Applikation in einer *.jar Datei (java archive)
- Deployment Descriptors XML-Dokummente zur Integrationsbeschreibung (sind Bestandteil jeder EAR Komponente)
Das Enterprise Archive folgt nebenstehender Struktur, die dem Applikationsserver das Entpacken der Komponenten und das Deployen der J2EE Applikation ermöglicht:
HelloWorld.ear
HelloWorld.jar
HelloWorldClient.jar
HelloWorldWeb.war
6
WEB Browser HTML, Applets
J2EE Client Container J2EE Client
stand alone Java Client
C++ Client
WEB Server Java Servlets JSP
Applikation Server EJB
DATADATADATADATA
2.5 Multi-Tier Application
Das Verteilen einer Applikation richtet sich meistens nach dem "seperation of concern" Aspekt der OOA.
2.5.1 3 Schicht Architektur
RMI = Remote Method Invocation IIOP = Internet Inter ORB Protocol
HTTP
RMI-IIOP
IIOP
CLIENT-Tier LOGIK-Tier DATA-Tier
2.5.2 J2EE Server mit WEB- und BusinessTier
2.5.3 J2EE Server mit JavaBean Komponenten als Interface
2.5.4 J2EE Server mit WEB-, BusinessTier und EIS Tier
7
B Enterprise JavaBeans 3 EJB Definition
Development, Entwicklung,
Distribution, Verteilung
Deployment of
Umsetzung (von Modellen) Militär: Truppenbereitstellung / Installation
Java-Based Java basierten
Server-Side serverseitigen
Software Components
Software Komponenten
EJB Technologie definiert
- Interfaces
- Patterns
- Richtlinien
für komponenten-orientierte, verteilte Systeme.
EJB Komponente
- definiert Funktionalität
- Black Box
- Zugriff nur über Schnittstelle
- Wiederverwendbarkeit
EJB Ziele
- Entwicklung von Geschäftsprozessen ( keine Systemprozesse )
- Standard für Komponenten basierte Entwicklung
- Wiederverwendbarkeit
8
Applikation Server
Services
EJB CONTAINER
EJB EJB EJB
Transaction Security Distribution
Persistance Naming
Client
Client
Client
Enterprise-Bean interface javax.ejb.EnterpriseBean
Entity Bean interface javax.ejb.EntityBean
Session Bean interface javax.ejb.SessionBean
Session Bean
stateless Session Bean
statefull Entity Bean
BMP Entity Bean
CMP
Message Bean
Message Driven Bean interface javax.ejb.MessageDrivenBean
3.1 EJB Architektur
- EJBs existieren innerhalb von Containern
- Applikations-Server stellt Dienste zur Verfügung
3.2 EJB Typen
Session Bean Entity Bean Message Driven Bean
Zweck Stellt einen Prozess
für einen Client dar z.B. Geldautomat
Stellt Daten dar:
Entitäten / Objekte im persistenten Speicher (DB)
Stellt einen Nachrichten-empfänger dar.
Typen
Stateless Session Bean
Statefull SessionBean
Bean Managed Persistence
Container Managed Persistence
Message Driven Bean
Nutzung Statefull Session Bean
dedizierter Client
Stateless Session Bean keine Client Zuordnung
Gemeinsame Nutzung durch mehrere Clients möglich
keine direkte Client-zuordnung, "horcht" auf einem JMs-Kanal
Persistenz Transient
Lebenszyklus typischerweise durch Clientprozess bestimmt
Persistent Zustand bleibt im persistenten Speicher nach Container Terminierung
Transient "stirbt" bei Container Terminisierung
9
EJB Container
Home Interface
Remote Interface
EJB Implementation
Deployment Descriptor
Client
3.3 Elemente einer EJB Komponente
Die EJB besteht aus mindestens vier Komponenten:
3.3.1 Home Interface
- definiert Schnittstelle (Sichtbarkeit) was sieht der Client von dieser Komponente
Datei: ejb/HelloWorldHome.class
3.3.2 Remote Interface
- definiert Dienste (Business Methoden), die dem Client zur Verfügung stehen
Datei: ejb/HelloWorld.class
3.3.3 Bean Implementierung
- definiert und implementiert alle Methoden, die im Home- und Remote Interface deklariert sind
Datei: ejb/HelloWorldBean.class
3.3.4 Deployment Descriptor
- XML Datei zur Beschreibung der Komponente (Dateiangaben, Pfadangaben, Datenbankverbindungen und das Verhalten, z.B: Zugriffskontrolle, Transaktionsverhalten)
Datei: ejb-jar.xml
Java ARchive (*.jar)
Remote Interface
Home Interface
Bean Implementation
Deployment Descriptor ejb-jar.xml
HelloWorld.jar
ejb / HelloWorld.class
ejb / HelloWorldHome.class
ejb / HelloWorldBean.class
10
4 Hello EJB World
4.1 Voraussetzungen
- J2SDK: Software Development Kit
- J2EE: Sun™ Application Server ( <J2EE_HOME>\lib\j2ee.jar )
- Entwicklingsumgebung: Eclipse, Java Editor Tool, etc
4.2 Aufgabe
Aufbau, Installieren und Betreiben einer J2EE Applikation
4.3 Organisation
/bin generierte Class Dateien
/deployment generierte WAR Dateien generierte JAR Dateien Bibliotheks-Klassen
/src/client Source Dateien der Client Applikation
/src/ejb Source Dateien der Middle Tier Applikation (EJBs, Servlets und HelperClasses)
4.4 Umgebungsvariablen
Benutzer- oder Systemvariablen definieren/ergänzen:
4.5 Ziel
Sun™ Application Server
2. HelloWorld.jar 3. deployen
4. HelloWorldClient.class
1.
11
4.6 Hello EJB World Java Source Dateien
- das Home Interface HelloWorldHome.java - im Verzeichnis ...\ee0\src\ejb
package ejb; import java.rmi.RemoteException; import javax.ejb.CreateException; import javax.ejb.EJBHome; public interface HelloWorldHome extends EJBHome { HelloWorld create() throws RemoteException, CreateException; }
- das Remote Interface HelloWorld.java - im Verzeichnis ...\ee0\src\ejb
package ejb; import javax.ejb.EJBObject; import java.rmi.RemoteException; public interface HelloWorld extends EJBObject { public String sayHello() throws RemoteException; }
- die Enterprise BEAN Klasse HelloWorldBean.java - im Verzeichnis ...\ee0\src\ejb
package ejb; import javax.ejb.SessionBean; import javax.ejb.SessionContext; public class HelloWorldBean implements SessionBean { public String sayHello() { return "Hello World"; } public void ejbCreate() {} public void ejbRemove() {} public void ejbActivate() {} public void ejbPassivate() {} public void setSessionContext(SessionContext sc) {} }
12
- die Client Applikations-Klasse HelloWorldClient.java - im Verzeichnis ...\ee0\src\client
package client;
import java.util.Properties; import javax.naming.Context; import javax.naming.InitialContext; import javax.rmi.PortableRemoteObject; import ejb.HelloWorld; import ejb.HelloWorldHome; /* VM Arguments: * -Dorg.omg.CORBA.ORBInitalHost=$localshost * -Dorg.omg.CORBA.ORBInitalPort=$3700 */ /* System Properties: * System.setProperty("org.omg.CORBA.ORBInitalHost","localhost"); * System.setProperty("org.omg.CORBA.ORBInitalPort","3700"); */ /* Environment Properties: * Properties env = new Properties(); * env.put(Context.INITIAL_CONTEXT_FACTORY, * "com.sun.jndi.cosnaming.CNCtxFactory"); * env.put(Context.PROVIDER_URL, "iiop://localhost:3700"); */
public class HelloWorldClient {
public static void main(String[] args) {
try { Context initial = new InitialContext();
Object objref = initial.lookup("HelloWorldBean");
HelloWorldHome home = (HelloWorldHome) PortableRemoteObject.narrow( objref, HelloWorldHome.class); HelloWorld helloWorld = home.create();
System.out.println(helloWorld.sayHello());
} catch (Exception ex) { System.err.println("unexpected exception!"); ex.printStackTrace(); } } }
13
4.7 "Hello EJB World" Bean mit Tool deployen
4.7.1 Applikations-Server starten / stoppen
- � Start > Sun Microsystems > Application Server PE > Start / [Stop] Default Server
- Testen ob der Server läuft mit: http://localhost:8080
4.7.2 Deployment Applikation starten
- � Start > Sun Microsystems > Application Server PE > Deploytool
JAR Datei definieren ( Packaging the Application ):
- File > New > Application …
- Application File Name …\ee0\deployment\HelloWorld.ear
- Application Display Name HelloWorld
- File > New > Enterprise Bean …
- JAR Name HelloWorldJar
- Edit Contents …
- Bean Klasse …\ee0\bin\ejb\HelloWorldBean.class
- Home Interface …\ee0\bin\ejb\HelloWorldHome.class
- Remote Interface …\ee0\bin\ejb\HelloWorld.class
- Enterprise Bean Class ejb/HelloWorldBean
- Enterprise Bean Type Stateless Session
- [Remote] Home Interface ejb/HelloWorldHome
- [Remote] Remote Interface ejb/HelloWorld
J2EE Applikation "deployen":
- Tools > Deploy ...
- Return Client JAR …\ee0\deployment
14
4.8 "Hello EJB World" Bean deployen
Das Deployment definiert das serverseitige Bereitstellen der J2EE Komponenten. Dazu werden neben den Javakomponenten die Deployment Descriptoren ejb-jar.xml (und weitere) erstellt und gemeinsam in einer EAR Datei dem Applikationsserver übergeben. Alternativen zum Deploytool sind:
- manuelles Bereitstellen der benötigten Komponenten JAR Datei erstellen und dem Applikationsserver übergeben Deployment Descriptoren müssen vorhanden und in Jar Datei verpackt sein! copy HelloWorld.jar <J2EE_HOME> \domains\domain1\autodeploy
- ANT Script mit dem Skript Tool von Jacarta Ant™ (http://ant.apache.org ) das Packen der Applikation und das Deployen der Komponenten durchführen: z.B: asant deploy asadmin deploy --user <user-name> --password <password> --host <hostname> --port <admin-port> HelloWorld.jar
- HelloWorld.ear # Archive HelloWorld.ear META-INF\sun-j2ee-ri.project META-INF\application.xml META-INF\sun-application.xml META-INF\MANIFEST.MF ejb-jar-ic.jar\ejb\HelloWorld.class ejb-jar-ic.jar\ejb\HelloWorldHome.class ejb-jar-ic.jar\ejb\HelloWorldBean.class ejb-jar-ic.jar\META-INF\sun-j2ee-ri.project ejb-jar-ic.jar\META-INF\ejb-jar.xml ejb-jar-ic.jar\META-INF\sun-ejb-jar.xml ejb-jar-ic.jar\META-INF\MANIFEST.MF #
15
4.9 Client Applikation ausführen
mit Eclipse
Java Build Path (Eclipse) HelloWorldClient.jar enthält keine Stub Klassen
HelloWorldClient.jar enthält Stub Klassen
j2ee.jar ���� ����
appserv-rt.jar ����
generiertes Client JAR HelloWorldClient.jar ����
- ohne Stub Klassen
16
- Stubklassen generieren
HelloWorldClient.jar # Archive HelloWorldClient.jar ejb\_HelloWorld_Stub.class ejb\_HelloWorldHome_Stub.class ejb\HelloWorld.class ejb\HelloWorldBean.class ejb\HelloWorldHome.class META-INF\sun-j2ee-ri.project META-INF\MANIFEST.MF META-INF\application.xml META-INF\sun-application.xml ejb-jar-ic.jar ejb-jar-ic.jar\META-INF\ejb-jar.xml ejb-jar-ic.jar\META-INF\sun-ejb-jar.xml ejb-jar-ic.jar\META-INF\MANIFEST.MF #
17
Konsole [cmd]:
Das folgende Batch Programm führt die "Hello EJB World" HelloWorldClient.class Applikation ohne Entwicklungsumgebung aus:
ohne Stub-Files und ohne Environment Properties:
- cd …\ee0\bin wechselt zum Projekt \bin Verzeichnis
- java –cp CLASSPATH Settings <J2EE_HOME>\lib\j2ee.jar; J2EE Library <J2EE_HOME>\lib\appserv-rt.jar; für RMI-IIOP . aktuelles Verzeichnis client.HelloWorldClient Client Applikation
mit Stub-Files und mit Environment Properties:
- cd …\ee0\bin wechselt zum Projekt \bin Verzeichnis
- java –cp CLASSPATH Settings <J2EE_HOME>\lib\j2ee.jar; J2EE Library <J2EE_HOME>\lib\appserv-rt.jar; für RMI-IIOP ..\deployment\HelloWorldClient.jar; generiertes ClientJar . aktuelles Verzeichnis client.HelloWorldClient Client Applikation
ApplicationClient (HelloWorldAppClient.jar) mit Deploytool erstellen und ausführen mit:
- appclient -client HelloWorldAppClient.jar ent –c iim Verzeichnis wo sich das JAR befindet
HelloWorldAppClient.jar: # Archive HelloWorldAppClient.jar client\HelloWorldClient.class ejb\HelloWorld.class ejb\HelloWorldHome.class META-INF\sun-j2ee-ri.project META-INF\application-client.xml META-INF\sun-application-client.xml META-INF\MANIFEST.MF #
18
HelloWorldAppClient generieren:
19
Interfaces of:
java.ejb
package
Beans Provider's Classes
java.rmi.Remote
java.ejb.EJBObject
getEJBHome() getHandle() getPrimaryKey() isIdentical() remove()
javax.ejb.EJBHome
getEJBMetaData() getHomeHandle() remove()
javax.ejb.EnterpriseBean
javax.ejb. - SessionBean - EntityBean
Container generated Classes
<guard> EJBObject
<factory> EJBHome
<enterprise bean> HelloWorldBean
<context> real context object
javax.ejb. EntityContext getEJBObject() getEJBLocalObject() getPrimaryKey()
javax.ejb.EJBContext getEJBHome() getEJBLocalHome() getCallerPrincipal() isCallerinRole() setRollbackOnly() getRollbackOnly() getUserTransaction()
HelloWorld
business methods
HelloWorldHome
create() findByPrimaryKey() findx()
javax.ejb. SessionContext getEJBObject() getEJBLocalObject
javax.ejb.EJBMetaData
getEJBHome() getHomeInterfaceClass() getPrimaryKeyClass() getRemoteInterfaceClass() isSession() isStatelessSession()
5 Inside EJB
5.1 EJB Klassen Diagramm
rmi = Remote Method Invocation
Remote Interface Home Interface
Runtime Classes
20
java.rmi.Remote
javax.ejb.EJBHome
getEJBMetaData() getHomeHandle() remove()
HelloWorldHome
create() findByPrimaryKey() findXXX()
5.2 EJB Komponenten
5.2.1 HOME Interface
Das HOME Interface definiert die Methoden der BEAN Komponenten zum:
- Erstellen
- Finden
- Löschen
- Zugreifen auf META Informationen - (Class Name, etc.)
Die Implementierung erfolgt durch die Implementation der "FACTORY Design Pattern" :
FACTORY: Erzeugen einer neuen Instanz durch einen Methodenaufruf eines Factory Objektes anstelle der Verwendung des "new" Konstruktors.
- Client, der das Bean erzeugt, hat keine direkte Referenz zur implementierten Klasse, sondern die Referenz eines Proxy Objektes (EJBObject)
- Der EJB Kontainer kann auch eine bereits bestehende Instanz einer EJB Komponente zurückgeben (pooling), anstatt eine neue Instanz zu bilden
- Das Erzeugen von Instanzen der EJB Komponenten ist vom EJB Container kontrolliert und nicht vom Client (Clients haben verschiedene Zugriffsrechte)
Klassendiagramm des EJB HOME Interface
beschreibt die Netzwerkfähigkeit eines Objektes
erzeugt eine Instanz von EJBMetaData erzeugt eine dauerhafte Instanz entfernt (löscht) das Enterprise Java Bean
erzeugt ein EJB (overloading possible) nur für ENTITY Beans mehrere finder Methoden sind möglich
21
5.2.2 REMOTE Interface
Das REMOTE Interface erlaubt dem Client den Zugriff auf:
- die Business Methoden
- das Home Interface (und dessen Methoden)
Implementierung erfolgt durch die Implementation der "GUARD Design Pattern"
GUARD: Alle Methodenaufrufe eines Client werden auf die entsprechenden Zugriffsrechte überprüft.
Klassendiagramm des EJB REMOTE Interface
beschreibt die Netzwerkfähigkeit eines Objektes
erzeugt Referenz zu HOME Interface robuste Referenz (netzwerkfähig) löscht EJB Instanz gibt PrimaryKey des EJB (throws RemoteException) vergleicht zwei REMOTE Interfaces
beschreibt den Geschäftsprozess (Business Methoden)
5.2.3 BEAN Implementation
Stellt die Funktionalität des Bean zur Verfügung
- Business Methoden des REMOTE Interface
- Implementation der "Methoden des HOME Interface"
Kein Client und auch keine andere Bean kann direkt auf dieses Objekt zugreifen.
java.rmi.Remote
javax.ejb.EJBObject
getEJBHome() getHandle() remove() getPrimaryKey() isIdentical()
HelloWorld Business Methods
22
5.2.4 Deployment Descriptor
Der Deployment Descriptor ist eine XML (eXtensible Markup Language) Datei und beschreibt die Deploymenteigenschaften.
Der Deployment Descriptor beeinflusst verschiedene Entwicklungslevel (Rollen).
Deployment Descriptor Beschreibungskriterien (Ausschnitt):
- wie das Bean installiert werden muss
- das Deployment (Installieren / Bereitstellen)
- die EJB Implementation / das HOME Interface / das REMOTE Interface
- Verbindungen zu anderen Quellen (EJB, DB, ...)
- die Umgebung des Beans (damit ist das Bean nicht an eine bestimmte Umgebung gebunden, lediglich die Konfiguration muss angepasst werden für eine andere Umgebung)
- Transaktionsvariablen (Transactions Attributes)
- Sicherheitsvariablen (Access Control Lists)
5.2.5 Überblick der Elemente einer EJB-Komponente
Die folgende Tabelle stellt alle möglichen Elemente einer EJB-Komponente im Überblick dar und zeigt welche Elemente bei welchen EJB-Typen zur Anwendung kommen.
Session Bean Entity Bean Element
local remote local remote
Message Driven Bean
Remote Home Interface ���� ����
Local Home Interface ���� ����
Remote Interface ���� ����
Local Interface ���� ����
Bean Klasse ���� ���� ����
Primary Key Klasse ����
Deployment Descriptor ���� ���� ����
23
5.2.6 EJB Rollen
Durch die Trennung der verschiedenen Schichten ergibt sich neben der daraus resultierenden Robustheit noch die Möglichkeit des parallelen Entwicklungsprozesses.
Dieser Aufgabenteilung sind die folgenden Rollen zugeordnet:
- Enterprise Bean Provider beschreibt die verwendeten Ressourcen
- Service Provider Hersteller eines J2EE Servers, z.B. Sun, BEA, IBM, Borland, etc.
- Container Provider stellt die Laufzeitumgebung für EJBs zur Verfügung
- Application Assembler verbindet die EJBs und Datenquellen untereinander
- Deployer installiert die Applikation in den entsprechenden Kontainer
- Systemadministrator (administriert Gesamtsystem, OS, J2EE-Server, etc.)
In der Praxis kann eine Person mehrere oder sogar alle Rollen übernehmen. Bei grösseren Projekten werden die Rollen jedoch häufig auf Teams aufgeteilt.
24
5.3 Zugriff auf ein EJB
Ein EJB erlaubt den Remote Zugriff nur über sein HOME Interface:
Der Client ermittelt zunächst per JNDI eine Referenz auf die Bean, welche unter dem Namen HelloWorldBean im Verzeichnisdienst (JNDI) registriert ist.
// Connection to JNDI Services InitialContext ic = new
InitialContext(Protokollparameter);
// Lookup Home Interface Object obj = ic.lookup("HelloWorldBean");
Die erhaltene generische Referenz wird durch Aufruf der statischen Methode narrow der Klasse PortableRemoteObject typsicher in eine Ausprägung der Home-Schnittstelle (HelloWorldHome) konvertiert.
// Typecasting due to RMI over IIOP HelloWorldHome home = (HelloWorldHome) PortableRemoteObject.narrow( obj, HelloWorldHome.class);
Der Aufruf der in dieser Schnittstelle durch den Anwender definierten create-Methode sorgt für die serverseitige Instanzierung der EJB, die als Ausprägung der Remote-Schnittstelle geliefert wird. Tatsächlich wird nicht das EJB-Objekt selbst durch den Methodenaufruf retourniert, sondern lediglich ein netzwerktransparenter Verweis darauf, der jedoch clientseitig einer lokalen Objektreferenz gleichgestellt verwendet werden kann.
25
Ferner wird serverseitig zur Kommunikation mit der EJB ein Home-Objekt erzeugt, welchem eine Stellvertreterrolle für den anfragenden Client zukommt. Der Aufruf der durch die EJB zur Verfügung gestellten Methode erfolgt identisch zu dem einer Lokalen.
// Create new Bean HelloWorld helloworld = home.create();
Die benötigten Business Methoden lassen sich nun über die erzeugte Objektinstanz aufrufen.
// Call Business Method(s) String result = helloworld.sayHello();
5.3.1 Sequenz Diagramm
lookup
reference to EJBHome create / find
reference to EJBObject
business methods
Client JNDI Service EJBHome EJBObject
EJB - Kontainer
Remote Remote Interface Objekt
Home Home Interface Objekt
Enterprise Java Beans
Client
obj
obj
obj
1. Anfrage nach Referenz 2. Erzeuge
EJB-Object
5. Aufruf
4. Aufruf
3. Referenz auf EJB Object
26
5.4 RMI (Remote Method Invocation)
- RMI, "Aufruf entfernter Methoden"
- Aufruf einer Methode eines entfernten Java-Objekts
- realisiert RPC (Remote Procedure Call)
- "Entfernt" bedeutet Objekt in anderen Virtuellen Maschine
Auf der Client-Seite kümmert sich der Stub – eine mit dem RMI-Compiler rmic erzeugte Klasse – um den Netzwerktransport.
Der Stub muss entweder lokal oder über das Netz für den Client verfügbar sein.
Entfernte Objekte können zwar auch von einem bereits im Programm bekannten entfernten Objekt bereitgestellt werden, für die erste Verbindungsaufnahme werden aber die Adresse des Servers und ein Bezeichner (ein RMI-URL) benötigt. Für den Bezeichner liefert ein Namensdienst auf dem Server eine Referenz auf das entfernte Objekt zurück. Damit dies funktioniert, muss das entfernte Objekt im Server sich unter diesem Namen zuvor beim Namensdienst registriert haben. Der RMI-Namensdienst wird über statische Methoden der Klasse java.rmi.Naming angesprochen. Der Namensdienst ist als eigenständiges Programm implementiert und wird RMI Registry genannt.
Kommunikationsprotokoll
- RMI ist Kommunikationsprotokoll für entfernte Aufrufe zwischen Java-Objekten
- Java-Standard-Klassenbibliothek um diese Aufrufe zu realisieren
- Klassenbibliothek ist Teil der Java 2 Standard Edition (J2SE)
Alternativ kann auch IIOP als Kommunikationsprotokoll eingesetzt werden. Für RMI sind zwei Ports reserviert. Port 1099 ist für die RMI-Registry reserviert, also den Namensdienst. Port 1098 für den Activator reserviert.
27
Client
Stub
Remote Reference
Layer
Server
Skeleton
Remote Reference
Layer
Netzwerkverbindung
5.4.1 RMI Kommunikationsmodell
virtuelle Kommunikation
reelle Kommunikation
Ablauf
1. Der Server registriert ein Remote Object bei der RMI-Registry unter einem eindeutigen Namen.
2. Der Client schaut bei der RMI-Registry unter diesem Namen nach und bekommt eine Objektreferenz, die seinem Remote Interface entsprechen muss.
3. Der Client ruft eine Methode aus der Objektreferenz auf (dass diese Methode existiert, wird durch das Remote Interface garantiert).
4. Der Server gibt dem Client die Rückgabewerte dieses Aufrufes, oder der Client bekommt eine Fehlermeldung (z. B. bei einem Verbindungsabbruch).
Activation
Als Ergänzung von RMI steht die sogenannte Activation ("Aktivierung") zur Verfügung. Ähnlich der RMI-Registry ist auch dies eine zentrale Anlaufstelle für RMI-Clients. Jedoch kann der Activator auch RMI-Server-Objekte erzeugen und neue Virtuelle Maschinen starten.
Anwendung
Bei der Kommunikation mit RMI hat der Client den Eindruck, Methoden von Objekten aufzurufen, die auf dem Server liegen. Folgende Kriterien sind Bestandteile von RMI:
- Nahtlose Unterstützung entfernter Aufrufe von Objekten in verschiedenen VM
- Callback-Unterstützung von Server zu Applet
- Integrierung des verteilten Objekt-Modells in Java unter Beibehaltung der Java-Semantik
28
- Unterschiede zwischen dem verteilten Objekt Modell und dem lokalen Java Objekt Modell sollen transparent gemacht werden
- Schreiben zuverlässiger Anwendungen so einfach wie möglich machen
- Bewahrung der Sicherheitsaspekte der JRE
Jeder Client benötigt zur Benutzung von Serverobjekten, die auf dem Server existieren, eine Beschreibung über die Fähigkeiten eines entfernten Objektes. Deshalb implementiert jedes Interface für entfernte Objekte, direkt oder indirekt, das Interface java.rmi.remote, damit wird das Objekt als ein "Remote-Objekt" gekennzeichnet. In diesem Interface sind keine Methoden definiert. Klassen, die das Interface implementieren, erlauben Clients deren Methoden entfernt (remote) aufzurufen.
Der Client erhält dann vom Broker-Tool (RMI-Registry) lediglich ein Stub-Objekt, das Remote-Objekt bleibt auf dem Server. Ein Stub ist eine Klasse, die das Remote-Interface implementiert und daher für den Client als Platzhalter für den Zugriff auf das Remote-Objekt dient.
Suche Registrierung Remote
Objekte
virtueller Aufruf
- Der Stub kommuniziert über TCP mit Skeleton Skeleton kennt das tatsächliche Applikationsobjekt
- leitet die Anfragen des Stubs an dieses weiter und gibt den Rückgabewert an ihn zurück
- Stub und Skeleton werden mit Tools generiert und verbergen die komplizierten Details der Kommunikation zwischen Server und Client
RMI - Registry
Server
Client
29
5.5 EJB Kommunikationsmodelle
An Prozesse beteiligte EJBs kommunizieren:
- synchron, entfernt
- synchron, lokal
- asynchron, nachrichtenbasiert
30
5.5.1 synchrone, entfernte Kommunikation
- Aufrufe erfolgen mittels RMI-IIOP
- Übertragung mittels "by-Value" Semantik (als Kopie )
Ablauf:
1. EJB-Container erzeugt EJBHomeObject
2. EJB-Container registriert Home-Object beim Namensdienst
3. Client fordert vom Namensdienst Referenz auf Home-Object
4. Namensdienst liefert Referenz auf das Home-Object
5. Client fordert über das Home Interface ein EJB von Home-Object an
6. EJBHome-Object erzeugt EJBObject
7. Home-Object liefert Referenz auf EJBObject
8. Client ruft über Remote Interface Geschäftsmethoden auf
9. EJBObject delegiert Methodenaufruf an die EJB-Instanz
31
5.5.2 synchrone, lokale Kommunikation
- synchrone Methodenaufrufe
- mittels "by-Referenz" (Adresszeiger auf Originaldaten)
Ablauf:
1. EJB-Container erzeugt EJBHomeObject
2. EJB-Container registriert Home-Object beim Namensdienst
3. Client fordert vom Namensdienst Referenz auf Home-Object
4. Namensdienst liefert Referenz auf das Home-Object
5. Client fordert über Local Home Interface EJB an
6. EJBLocalHome-Object erzeugt EJBLocalObject
7. LocalHome-Object liefert Referenz auf EJBObject
8. Client ruft über Local Remote Interface Geschäftsmethoden
9. EJBLocalObject delegiert Methodenaufruf an die EJB-Instanz
32
5.5.3 asynchron, nachrichtenbasierte Kommunikation
- Schnittstelle zwischen OO und nicht-OO Prozessen
Ablauf:
1. Aplikationsserver registriert Nachrichtenempfänger beim Namensdienst
2. EJB-Container registriert sich als Listener für Nachrichten 3. Client fordert vom Namensdienst Referenz des Nachrichtenempfängers
4. Namensdienst liefert Referenz auf Nachrichtenempfänger
5. Client sendet Nachrichten an Nachrichtenempfänger
6. Nachrichtenempfänger übermittelt Listener eingegangene Nachricht 7. Listener delegiert Nachricht an BeanInstanz
5.5.4 Überblick über die Kommunikationsmodelle
Aufrufmodell
EJB Typen synchron entfernt
synchron lokal
asynchrony nachrichtenbasiert
Stateless Session Bean ���� ����
Statefull Session Bean ���� ����
Entity Bean ���� ����
Message Driven Bean ����
33
6 Stateless Session Bean ( zustandslos)
modelliert einfacher Geschäftsprozess (z.B. Zinsberechnung)
kann keine Daten speichern
haben keine Identität Aufgabe muss mit einem Methodenaufruf erledigt sein, zweimaliger Aufruf des Beans garantiert nicht dieselbe Instanz auf dem Server
eine create() Methode, parameterlos
nutzt nicht alle Methoden
pooling:
- mehrere Clients rufen dasselbe Bean auf
- gemeinsame Nutzung von Sourcen
- weniger Objekte im Einsatz
- ABER: Bean ist single-threaded, ein Bean kann nur ein Client behandeln
6.1 Bean Life Cycle
Container initiated: Container initiated:
ejbRemove() Class.newInstance() setSessionContext(sc) ejbCreate()
Client initiated:
business methods
setSessionContext
- nach Instanzierung der Bean durch Container
- teilt der Bean SessionContext mit
- SessionContext definiert Umgebung der Bean-Instanz und übergibt Client Informationen
ejbCreate - nach setSessionContext durch Container
- initialisiert Bean z.B. Verbindungen /Datenbanken
ejbRemove
- wird durch Container aufgerufen
- nach remove des Remote Objektes
- reservierte Ressourcen werden freigegeben
- Container löscht Bean-Instanz
java.io.Serializable
javax.ejb.SessionBean
ejbActivate()
ejbPassivate() ejbRemove() setSessionContext()
mySessionBean
ejbCreate() business methods
javax.ejb.EnterpriseBean
Methode-Ready-Pool
does not exist
34
6.2 Übung ee1 : Zinsberechnung
Erstellen und deployen Sie ein Stateless Session Bean, das als Businessmethode die Zinsberechnung eines Geldbetrages amount über eine definierte Laufzeit years zu einem gegebenen Zinssatz rate mehreren Klienten zur Verfügung stellt. Die Attribute amount und years müssen clientspezifisch definiert werden. Der Zinssatz rate kann als ein Attribut der EJB oder clientspezifisch definiert werden.
Ansatz:
Entwicklung einer Geldanlage durch Zins und Zinseszins:
35
does not exist
Methode-Ready-Pool
Passive
7 Stateful Session Bean ( zustandsbehaftet )
modelliert Geschäftsprozess (z.B. Shopping Cart)
kann Daten speichern
Zustandsbehaftet (kann den Zustand eines best. Client speichern)
mehrmaliger Aufruf des Beans für einen Geschäftsablauf möglich
mehrere create() Methoden (mit unterschiedlichen Signaturen)
kein pooling
passivated: - wenig Ressourcen und Memory vorhanden
- bessere Performance
7.1 Bean Life Cycle
Container initiated: Container initiated: Class.newInstance() ejbRemove() timeout setSessionContext(sc) ejbCreate()
Client initiated: Client initiated: remove() create()
Client initiated: Container initiated:
business methods ejbActivate() ejbPassivate()
ejbPassivate
- wird vom Container aufgerufen - Bean wird zeitweilig aus Speicher entfernt - Bean kann (soll) Ressourcen freigeben - Bean bleibt weiterhin Client zugeordnet - für Client transparent
ejbActivate - wird vom Container aufgerufen (nach Business Methode) - Container holt Bean Instanz in Arbeitsspeicher zurück - Bean wird neu initialisiet
ejbRemove - wird durch Container aufgerufen - reservierten Ressourcen freigegeben - Container löscht Bean-Instanz
javax.ejb.SessionBean
ejbActivate() ejbPassivate() ejbRemove() setSessionContext()
mySessionBean
ejbCreate() business methods
javax.ejb.EnterpriseBean
java.io.Serializable
36
7.2 Übung ee2 : Kontoführung
Erstellen und deployen Sie ein Stateful Session Bean zur Konto-führung. Benützen Sie dazu die Variable private float accountBalance:
- Betrag deponieren (als Float) - Betrag abheben (als Float) - Saldo ausgeben (auf Konsole)
7.2.1 Konsolen Statements
Ergänzen Sie die Bean Methoden mit Konsolen Statements zur Überwachung der Aktivitäten des Applikations-Servers.
7.2.2 Environment Entries als InitialContext
Erweitern Sie die Business Logik und führen Sie auf allen Konten einen Zinssatz. Dabei ist es sinnvoll für alle Konten denselben Zinssatz zu definieren. Benützen Sie dazu die Variable private float rate:
- Zins (im Deployment Descriptor) als Environment Entry festlegen
- Suchen Sie nachdem das Bean deployed ist den entsprechenden Eintrag im DD und ändern Sie diesen ohne das Bean neu zu deployen.
Ansatz / Fragmente:
public void setSessionContext(SessionContext sc) { try { InitialContext ic = new InitialContext(); Context local = (Context) ic.lookup("java:comp/env"); Float interestrate = (Float) local.lookup("Zins"); rate = interestrate.floatValue(); ...
Environment Entry für "Zins" im Deploymenttool:
ejb-jar.xml
<env-entry> <env-entry-name>Zins</env-entry-name> <env-entry-type>java.lang.Float</env-entry-type> <env-entry-value>1.0</env-entry-value> </env-entry>
37
does not exist
Pooled
Ready
8 Entity Bean (Abbildung von Daten einer DB )
modelliert Abbildungen von persistenten Geschäftsdaten (DB) mehrere Clients können auf diese Entities zugreifen
verwendet identifizierbare Daten (primary key)
CMP - Container Managed Persistence: - Container speichert Bean in DB
- Bean-Provider muss sich nicht kümmern
- exakter Mechanismus ist nicht definiert !
- jedes Objekt hat einen Primary Key
BMP - Bean Managed Persistence: - Bean-Provider ist verantwortlich, dass die
Daten in der DB gespeichert werden
- Realisation mittels SQL, ...
- höherer Aufwand als CMP
- mehr Flexibilität als CMP
8.1 Bean Life Cycle
Container initiated: Container initiated:
unsetEntityContext() Class.newInstance() Object.finalize() setEntityContext()
Container initiated: Container initiated: ejbPassivate() ejbActivate() ejbRemove() ejbCreate(),ejbPostCreate() Client initiated: Client initiated: remove() create() Container initiated: Client initiated:
ejbLoad(), ejbStore() getter / setter
Pooled
- Instanz existiert, aber besitzt keine Indentität - Client ruft find- oder create-Methode auf - Bean Instanz aus Pool wird Identität (Primärschlüssel)
zuzuweisen
Ready - Instanz existiert, besitzt Identität - kann vom Client benutzt werden
java.io.Serializable
javax.ejb.EntityBean
ejbActivate() ejbPassivate() setEntityContext() unsetEntityContext() ejbLoad() ejbStore()
myEntityBean
ejbCreate() ejbPostCreate() ejbFindXXX() business methods
javax.ejb.EnterpriseBean
38
8.1.1 EJB-Container Life-Cycle- Methoden
Life Cycle Methode Beschreibung
setEntityContext() unsetEntityContext()
wird aufgerufen nach Erstellen / vor Entfernen der Entity Bean
ejbLoad() ejbStore() ladet / speichert die Entity Bean
ejbRemove() entfernt die Entity Bean ejbActivate() ejbPassivate() aktiviert / passiviert die Entity Bean
8.1.2 Persistenzoperationen einer Entity Bean
Operation:
ejbCreate
SQL Alias:
INSERT
- wird nach Erzeugen der EJB aufgerufen
- speichert Java-Objekt in Datenbank ab
- Methode nicht Bestandteil der Interfaces
- Parameter sind nicht festgelegt
Operation:
ejbFindByPrimaryKey
SQL Alias:
SELECT
- liefert Wert des Primärschlüssels
- Methode nicht Bestandteil der Interfaces
- Parameter sind nicht festgelegt
- Methode wird nicht durch Anwender aufgerufen, sondern findByPrimaryKey
Operation:
ejbRemove
SQL Alias:
DELETE
- entfernt das Java-Objekt aus Datenbank
- EJB-Objekt bleibt bestehen
Operation:
ejbStore
SQL Alias:
UPDATE
- synchronisiert Java-Objekt mit EJB-Objekt und aktualisiert so Datenbankinhalt
- Methode wird nach jedem Client Zugriff ausgeführt
39
DB: EnterpriseEducation PERSONBEAN
ID FNAME NAME
SUN ™ Applikationsserver CMP (1.x) Entity Bean
public id public name public fname
8.2 Modellieren von persistenten Geschäftsdaten
8.2.1 Übung ee3 : Personenverwaltung mit CMP 1.0
HOME Interface einer Entity Bean
- Deklariert die Bean-Lifecycle-Methoden
- Erweitert javax.ejb.EJBHome (erweitert java.rmi.Remote)
- Klasse, die dieses Interface implementiert (EJB Home) wird generiert
public interface PersonHome extends EJBHome { // create und finder Methoden deklarieren public Person create(String id, String name, String fname) throws CreateException, RemoteException;
// entsprechender Return Type festlegen [0..1] -> Person public Person findByPrimaryKey(String key) throws FinderException, RemoteException;
// entsprechender Return Type festlegen [0..*] -> Collection public Collection findAll() throws FinderException, RemoteException; }
REMOTE Interface einer Entity Bean
- Deklariert die Bean-Business-Methoden
- Erweitert javax.ejb.EJBObject (erweitert java.rmi.Remote)
- Klasse, die dieses Interface implementiert (EJB Object) wird generiert
- Wrapper des eigentlichen Beans
public interface Person extends EJBObject { // public setter und getter Methoden der Entitäten deklarieren public void setId(String id) throws RemoteException; public void setName(String name) throws RemoteException; public void setFname(String fname) throws RemoteException; public String getName() throws RemoteException; public String getFname() throws RemoteException; public String getId() throws RemoteException; }
40
BEAN Implementation einer Entity Bean
- Implementiert alle Methoden, die für den Lebenszyklus benötigt werden
- Signatur muss identisch sein mit der des Remote & Home Interfaces
- Implementiert javax.ejb.EntityBean (erweitert javax.ejb.EnterpriseBean)
public class PersonBean implements EntityBean {
// DB Felder als public Attribute definieren public String id = ""; public String name = ""; public String fname = ""; // public setter und getter Methoden der Entitäten definieren public String getId() {return id;} public void setId(String id) {this.id = id;} ... // Für jede create() Methode des Home Interfaces muss es eine // ejbCreate() Methode mit derselben Signatur geben public String ejbCreate(String id, String name, String fname) { // Belegen der Bean Attribute mit den Übergabeparameter this.id = id; this.name = name; this.fname = fname; // Rückgabewertes ist Primary_Key Attribute return id; } // Für jede create() Methode des Home Interfaces muss es eine // ejbPostCreate() Methode mit derselben Signatur geben public void ejbPostCreate(String id, String name, String fname) { } // sämtliche Kontainer Life Cycle Methoden müssen definiert werden public void setEntityContext(EntityContext arg0) throws EJBException, RemoteException { } public void unsetEntityContext() throws EJBException, RemoteException { } ... }
41
Deployment
Die Persistenz-Einstellungen im Deploytool sind im Entity TAB:
- Persistente Felder bestimmen - Primary Key Class Feld bestimmen - CMP Database definieren
mySQL Datasource anbinden mit:
- Connection Pool (im Sun AS™ definieren)
- JDBC Datasource (im Sun AS™ über JNDI definiert)
- CMP Database Mapping (in Deployment Tool)
Mit der admin Konsole des Sun AS™ ( http://localhost:4848 ) eine neue JDBC Resource und ein Connection Pool erstellen:
Die notwendige MySQLDriver.class ist vom entsprechenden DataSource-Vendor zu beziehen um dem Sun AS™ zur Verfügung zu stellen:
42
CMP Database Mapping per JNDI jdbc/ee (Sun AS™ JDBC Ressource):
Das Deploymenttool erstellt dann die entsprechenden xml Dateien wie auch ein Database-Schema Person_ejb-jar-ic.dbschema für das Erstellen der entsprechenden Tabelle(n):
Deployment Descriptor ejb-jar.xml (Ausschnitt)
<enterprise-beans> <entity> <ejb-name>PersonBean</ejb-name> <home>ejb.PersonHome</home> <remote>ejb.Person</remote> <ejb-class>ejb.PersonBean</ejb-class> <persistence-type>Container</persistence-type> <prim-key-class>java.lang.String</prim-key-class> <reentrant>false</reentrant> <cmp-version>1.x</cmp-version> <cmp-field><field-name>fname</field-name></cmp-field> <cmp-field><field-name>name</field-name> </cmp-field> <cmp-field><field-name>id</field-name></cmp-field> <primkey-field>id</primkey-field> </entity>
Deployment Descriptor sun-cmp-mappings.xml (Ausschnitt)
<sun-cmp-mappings> <sun-cmp-mapping> <schema>Person_ejb-jar-ic</schema> <entity-mapping> <ejb-name>PersonBean</ejb-name> <table-name>PERSONBEAN</table-name> <cmp-field-mapping> <field-name>fname</field-name> <column-name>PERSONBEAN.FNAME</column-name> </cmp-field-mapping> <cmp-field-mapping> <field-name>id</field-name> <column-name>PERSONBEAN.ID</column-name> </cmp-field-mapping> <cmp-field-mapping> <field-name>name</field-name> <column-name>PERSONBEAN.NAME</column-name> </cmp-field-mapping> </entity-mapping> </sun-cmp-mapping> </sun-cmp-mappings>
43
8.2.2 CMP/CMR in EJB 2.0
EJB 2.0 erweitert 1.x mit folgenden Eigenschaften:
- erweiterte Funktionalität für CMP für Entity Beans
- unterstützt CMR (Container-Managed Relationships)
- definiert EJB-QL für select und find Query Methoden
- Locale Interfaces unterstützen Zugriff zwischen Beans
Die Funktionsweise und die wesentlichen Unterschiede zu CMP 1.0 sind an einer trivialen EJB Kundenverwaltung erläutert. Ein Kunde besteht aus einem Namen und einer Adresse. Dafür werden zwei Entitäten geführt, realisiert durch zwei Entity Beans (CMP 2.0). Die Relation dieser beiden Entitäten wird in EJB's definiert.
8.2.3 Übung ee31 : Kundenverwaltung mit CMP 2.0
Das Besipiel definiert zwei CMP Entity Beans, die zwei Tabellen "Name" (Name, Vorname) und "Adresse" (Strasse, Ort) persistiert. Die 1:1 Relation zwischen den beiden Entitäten wird durch den EJB Kontainer realisiert:
Local Home-Interface der Address Bean (Entity Bean)
- keine java.rmi.RemoteException
public interface AddressLocalHome extends EJBLocalHome { public AddressLocal create(String street, String location) throws CreateException; // Methode findByPrimaryKey(...) muss deklariert werden public AddressLocal findByPrimaryKey(String id) throws FinderException; // optionale finder-Methoden können folgen }
DB: EnterpriseEducation NAMEBEAN
ID NAME FNAME
ADDRESSBEAN
ID STREET LOCATION
Applikationsserver CMP (2.x) EntityBean:Name
get / set id get / set name get / set fname get / set address
1 : 1
CMP (2.x) EntityBean:Address Relation
get / set id get / set street get / set location
44
Local-Interface der Address Bean (Entity Bean).
- getter/setter-Methoden für die Attribute der Entity Bean.
- keine RemoteException
public interface AddressLocal extends EJBLocalObject { public String getStreet(); public String getLocation(); }
Bean-Klasse der Entity Bean (mit CMP 2.0) Address.
Es werden alle im Local-Interface (AddressLocal.java) definierten Geschäftsmethoden und auch bestimmte callback-Methoden implementiert. Wesentliche Unterschiede zu CMP 1.0:
- Attribute nicht deklariert
- getter/setter-Methoden als abstrakte Methoden (werden vom Container implementiert)
- die Bean-Klasse ist folglich auch abstrakt public abstract class AddressBean implements EntityBean { private EntityContext context; // abstrakte getter/setter-Methoden - PERSISTENTE FELDER public abstract String getId(); public abstract void setId(String id); ... // Callback-Methoden (werden bei Bedarf vom Container aufgerufen) // Diese Methoden sind grösstenteils leer implementiert, da CMP // ejbCreate(...) legt eine neue Adresse an // Diese Methode wird vom Container automatisch aufgerufen, sobald // create() auf dem Home-Object aufgerufen wird. // Signature von create(...) und ejbCreate(...) muss übereinstimmen // @return null public String ejbCreate(String street, String location) throws CreateException { System.out.println("AddressEJB: ejbCreate called"); setId(street + location); setStreet(street); setLocation(location); return null; } // Lifecycle Methoden und Default Kunstruktor public void ejbPostCreate(String street, String location) { } public void ejbRemove() { } ... public AddressBean() { }
45
Local Home-Interface der Name Bean (Entity Bean)
- keine java.rmi.RemoteException
public interface NameLocalHome extends EJBLocalHome {
public NameLocal create(String id, String street, String location) throws CreateException;
// Methode findByPrimaryKey(...) muss deklariert werden public NameLocal findByPrimaryKey(String id) throws FinderException; // optionale finder-Methoden können folgen }
Local-Interface der Name Bean (Entity Bean)
- nur getter/setter-Methoden für die Attribute
- keine RemoteException
public interface NameLocal extends EJBLocalObject {
public AddressLocal getAddress(); public void setAddress(AddressLocal address); }
(Remote) Home Interface der Name Bean (RMI-IIOP)
public interface NameHome extends EJBHome {
public Name create(String id, String name, String fname, String street, String location) throws CreateException, RemoteException;
// Methode findByPrimaryKey(...) muss deklariert werden public Name findByPrimaryKey(String id) throws FinderException, RemoteException; // optionale finder-Methoden können folgen }
(Remote) Interface der Business Logik der Name Bean
public interface Name extends EJBObject { public String getFullName() throws RemoteException; public String getFullAddress() throws RemoteException; }
46
Bean-Klasse der Entity Bean (mit CMP 2.0) Name.
Es werden alle im Local-Interface und im Remote-Interface definierten Geschäftsmethoden und auch bestimmte callback-Methoden implementiert. Unterschiede zu CMP 1.0:
- Attribute einer Addresse sind nicht als Felder in der Java-Klasse deklariert
- getter/setter-Methoden als abstrakte Methoden deklariert (werden vom Container implementiert)
- die Bean-Klasse ist folglich auch abstrakt
public abstract class NameBean implements EntityBean { public NameBean() { }
// Nicht PERSISTENTE FELDER private EntityContext context; private AddressLocalHome addressLocalHome;
// abstrakte getter/setter-Methoden - PERSISTENTE FELDER public abstract String getId(); public abstract void setId(String id);
public abstract String getName(); public abstract void setName(String name); ...
//abstrakte getter/setter-Methoden - RELATIONEN public abstract AddressLocal getAddress(); public abstract void setAddress(AddressLocal address);
// Callback-Methoden (werden bei Bedarf vom Container aufgerufen) // Diese Methoden sind grösstenteils leer implementiert, da wir // Container-Managed Persistence verwenden
// ejbCreate(...) legt ein neues Produkt an // Diese Methode wird vom Container automatisch aufgerufen, sobald // create(.) auf dem Home-Object aufgerufen wird. Die Argumente // von create(.) und ejbCreate(.) müssen übereinstimmen. // @return null public String ejbCreate(String id, String name, String fname, String street, String location) throws CreateException { System.out.println("ejbCreate called");
setId(id);
setName(name);
setFname(fname);
return null;
}
public void ejbPostCreate(String id, String name, String fname, String street, String location) throws CreateException { System.out.println("ejbPostCreate called");
AddressLocal address = addressLocalHome.create(street, location);
setAddress(address);
}
47
// Business Methoden des REMOTE INTERFACE public String getFullName(){return getName() + ", " + getFname();} public String getFullAddress() { return getAddress().getStreet() + ", " + getAddress().getLocation();
}
// LIFECYCLE METHODEN public void setEntityContext(EntityContext context) { System.out.println("setEntityContextCalled");
this.context = context;
try {
Context ctx = new InitialContext(); Context localCtx = (Context) ctx.lookup("java:comp/env"); Object obj = localCtx.lookup("ejb/address"); addressLocalHome = (AddressLocalHome) PortableRemoteObject
.narrow(obj, AddressLocalHome.class);
} catch (NamingException e) {throw new EJBException(e);
}
}
...
Deployment:
Einstellung im Deploytool:
- EJB Referenz
- Relationship (CMR)
48
Diese Einstellungen resultieren in folgendem Eintrag im Deployment Descriptor ejb-jar.xml (Ausschnitt)
- Deploytool bildet sämtliche Interface Methoden
- definiert die benutzerspezifischen Parameter Transaction, Security, etc.
Deployment Descriptor: ejb-jar.xml (Ausschnitt)
… <relationships> <ejb-relation> <ejb-relationship-role> <multiplicity>One</multiplicity> <relationship-role-source> <ejb-name>NameBean</ejb-name> </relationship-role-source> <cmr-field> <cmr-field-name>address</cmr-field-name> </cmr-field> </ejb-relationship-role>
<ejb-relationship-role> <multiplicity>One</multiplicity> <cascade-delete/> <relationship-role-source> <ejb-name>AddressBean</ejb-name> </relationship-role-source> </ejb-relationship-role> </ejb-relation> </relationships> …
49
C Best Practice 9 Design Patterns
9.1 Einführung
Dieses Dokument gibt einen ersten Einblick in die Software Design Patterns und erläutert deren Sinn und Zweck. Die Einführung in die Welt der Software Design Patterns wird dabei anhand von drei der häufig verwendeten Patterns gemacht, dem Proxy-, dem Singleton- und dem Factory Method Pattern.
9.1.1 Zweck
Pattern heisst auf Deutsch übersetzt Muster oder Beispiel. Design Patterns stellen wiederverwendbare Lösungen zu häufig auftretenden Problemen in der Software Entwicklung dar. Sie kommen aus der Praxis und wiederspiegeln die Erfahrung von Experten. Die Verwendung solcher Muster erhöht die Qualität der Software und erleichtert die Kommunikation zwischen den einzelnen Entwicklern.
9.1.2 Geschichtliches
- Idee aus der Architektur.
- 1977 durch Christopher Alexander
- 1987 durch Cunningham und Beck
- entwarfen fünf Patterns für die User-Interface Programmierung
- 1994 durch Gamma, Helm, Vlissides und Johnson
- Design Patterns als Gang of Four
Die drei ersten in diesem Dokument vorgestellten Patterns (Proxy-, Singleton- und Factory Method Pattern) stammen aus dem Design Patterns Buch.
9.1.3 Referenzen
- Bien, Adam ( 2003 ), J2EE Patterns, Addison-Wesley
- etc.
50
9.2 Singleton Pattern
[Deutsch: Einzelfall, Einzelkarte]
- Kategorie der creational patterns
- Erzeugung von Objekten verlangt eine Entscheidung
- stellt sicher, dass nur eine Instanz einer Klasse erzeugt wird
- geeigneter Zugriffsmechanismus
9.2.1 Problem
Es ist oft notwendig, dass es von einer Klasse exakt eine Instanz gibt. Beispiele hierfür sind: Print-Spoolers, Datenbank-Manager oder Zugriffe auf das Dateisystem. Ein solches Problem wird typischerweise mit dem Singleton Pattern gelöst. Das Singleton Pattern weist die folgenden Eigenschaften auf:
- Es garantiert, dass nur eine Instanz einer Klasse erzeugt wird.
- Es stellt einen globalen Zugriffsmechanismus auf das Objekt zu Verfügung.
9.2.2 Lösung
Wie ersichtlich ist, besteht das Singleton Pattern aus nur einer Klasse und ist daher relativ einfach. Die Singleton Klasse hat eine statische Variable, welche auf die einzige Instanz der Klasse zeigt. Mittels der statischen Methode getInstance() wird eine Referenz auf die Instanz der Klasse zurückgegeben.
Singleton
instance
Singleton getInstance()operations
9.2.3 Implementation
In diesem Unterkapitel wird die Umsetzung des Patterns in Java aufgezeigt.
51
Der "Klassische Singleton"
- klassische Umsetzung des Singleton Pattern in Java
public class ClassicSingleton {
private static ClassicSingleton instance = null;
private ClassicSingleton() {
// Exists only to defeat instantiation.
}
public static ClassicSingleton getInstance() {
if(instance == null) {
instance = new ClassicSingleton();
}
return instance;
}
}
Der "Klassische Singleton" hat eine statische Referenz auf die einzige Singleton Instanz und diese wird über die statische Methode getInstance() zurückgegeben. Dabei sind folgende Betrachtungen zur Klasse ClassicSingleton zu bemerken:
1. Die ClassicSingleton Klasse verwendet für die Erstellung der Instanz
eine Technik welche als "lazy instantiation" bekannt ist, d.h. dass die Instanz der Klasse (Objekt) erst erstellt wird, wenn diese zum ersten mal gebraucht wird.
2. Der Konstruktor des ClassicSingleton ist als private deklariert. Damit wird sichergestellt, dass nicht mehrere Instanzen der Klasse erzeugt werden können.
3. Leider ist die ClassicSingleton Klasse nicht Thread-Safe! Wenn zwei Threads gleichzeitig die Methode getInstance() aufrufen ist es möglich, dass während der 1. Thread eine Instanz der Klasse erzeugt, der 2. Thread gerade in diesem Moment in den If-Block eintritt. Die Prüfung auf null ist zu diesem Zeitpunkt noch wahr und es wird somit eine zweite Instanz der Klasse ClassicSingleton erzeugt.
52
Der Thread-Safe Singleton:
Eine einfache Lösung, um das Singleton Pattern Thread-Safe zu programmieren, ist die Methode getInstance() mit dem Schlüsselwort synchronized zu versehen:
public synchronized static ClassicSingleton getInstance()
Diese Lösung funktioniert ausgezeichnet. Die Synchronisation der Methode wird aber nur beim aller ersten Mal benötigt. Da die Synchronisation bezüglich Performance eine sehr teure Operation ist (synchronisierte Methoden können bis zu 100 Mal langsamer sein), ist somit auch diese Lösung nicht optimal.
Eine bessere Lösung um das Singleton Pattern Thread-Safe zu programmieren, ist die statische Variable instance gleich bei der Deklaration zu initialisieren:
public class ThreadSafeSingleton {
private static ThreadSafeSingleton instance =
new ThreadSafeSingleton();
private ThreadSafeSingleton() {
// Exists only to defeat instantiation.
}
public static ThreadSafeSingleton getInstance() {
return instance;
}
}
Wie ersichtlich, wird die statische Member-Variable instance nun gleich bei der Deklaration initialisiert. Die Java Spezifikation stellt sicher, dass jeder Compiler die Initialisierung von statischen Membern-Variabeln nur einmal und immer beim ersten Zugriff vornimmt. Die ThreadSafeSingleton Klasse ist somit Thread-Safe und hat eine "lazy instantiation".
Zugriff:
Der Zugriff auf ein Singleton Objekt erfolgt mit: ThreadSafeSingleton singleton = ThreadSafeSingleton.getInstance(); singleton.doThis(); singleton.doThat();
53
9.3 Proxy Pattern
[Deutsch: Stellvertreter, Bevollmächtigter]
- fundamental patterns
- von grundlegenden und sehr wichtigen Patterns,
- z.B. Delegation oder Konzept der Interfaces
- dienen oft als Grundlage für andere Patterns
Das Proxy Pattern ermöglicht die Ersetzung eines Objektes durch einen Stellvertreter. Jeder Aufruf an das Objekt erfolgt indirekt über dessen Stellvertreter.
9.3.1 Problem
Es ist oft notwendig, dass bei einem Methodenaufruf eines Objektes, zusätzliche Funktionen ausgeführt werden müssen. Das Ausführen dieser Management-Funktion soll jedoch im Hintergrund geschehen, so dass der Benutzer nichts davon erfährt. Es gibt eine Vielzahl solcher Proxy Pattern Anwendungen.
Nachfolgend sind einige aufgelistet:
- Cache Proxy: Ein Proxy ermöglicht die temporäre Speicherung von Resultaten einer teuren Operation. Andere Benutzer können dann auch auf das Resultat zugreifen.
- Remote Proxy: Ein Proxy erzeugt die Illusion, dass ein Objekt, welches auf einem anderen Server existiert, ein normales lokales Objekt sei. Ein bekanntes Java-Beispiel ist die Remote Method Invocation (RMI).
- Access Proxy: Ein Proxy kontrolliert den Zugriff auf ein Objekt und kann an verschiedene Benutzer unterschiedliche Zugriffsrechte vergeben.
- Synchronization Proxy: Ein Proxy ermöglicht den gleichzeitigen Zugriff von mehreren Benutzern auf ein Objekt.
54
9.3.2 Lösung
Das Proxy Pattern besteht im wesentlichen aus einer Superklasse oder einem Interface, welche von der Proxy-Klasse wie auch der eigentlichen Service-Klasse verwendet werden. Durch diese Abstraktion wird sichergestellt, dass die Proxy-Klasse und die Service-Klasse dem Benutzer dieselben Methoden zur Verfügung stellen.
Der Benutzer ruft nun demnach eine Methode nicht auf dem eigentlichen Service-Objekt, sondern auf dem Proxy-Objekt auf. Auf dem Proxy-Objekt werden die definierten Management-Funktionen ausgeführt und der Aufruf wird an das eigentliche Service-Objekt weitergeleitet. Eine Antwort des Service-Objektes wird ebenfalls über das Proxy-Objekt dem Benutzer mitgeteilt.
<<interface>>IFService
doIt()
<<interface>>IFService
doIt()
AbstractServ ice
doIt()
....
AbstractServ ice
doIt()
....
ServiceProxy
doIt()
ServiceProxy
doIt()
ServiceProxy
doIt()
Service
doIt()
Service
doIt()
Service
doIt()
10..*
ServiceProxy
doIt()
ServiceProxy
doIt()
ServiceProxy
doIt()
Service
doIt()
Service
doIt()
Service
doIt()
10..*
9.3.3 Implementation
Ohne spezifische Management-Funktionen verwendet das Proxy Pattern nur eine Superklasse oder ein Interface. Der Schwerpunkt bei diesem Pattern liegt deshalb auch in der Umsetzung dieser Management-Funktionen in der Proxy Klasse.
Für die bessere Veranschaulichung des Proxy Patterns soll die Synchronisation einer Tabelle durch einen Proxy realisiert werden. Es gilt folgende Ausgangslage:
55
Eine Klassenbibliothek stellt für den Zugriff auf eine Tabelle die Klasse Table zur Verfügung, welche das Interface IFTable implementiert. Leider ist der Zugriff auf die Tabelle nicht synchronisiert. Die Aufgabe lautet die Klasse Table zu synchronisieren, ohne den Source Code zu verändern.
public interface IFTable {
public Object getElementAt(int row, int column);
public void setElementAt(Object element, int row, int column);
public int getNumberOfRows();
}
Die einfachste Lösung für die Implementierung einer Synchronisation ist die Verwendung des Proxy Patterns. Das Beispiel zeigt die Klasse RowLockTableProxy, welche diese Synchronisation vornimmt.
public class RowLockTableProxy implements IFTable {
Table realTable = null;
Integer[] locks = null;
public RowLockTableProxy(Table aRealTable) {
realTable = aRealTable;
locks = new Integer[realTable.getNumberOfRows()];
for(int row = 0; row < locks.length; row++;) {
locks[row] = new Integer(row);
}
}
public Object getElementAt(int row, int column) {
synchronized (locks[rows]) {
return realTable.getElementAt(row,column);
}
}
public Object setElementAt(Object element, int row, int column) {
synchronized (locks[rows]) {
return realTable.setElementAt(element,row,column);
}
}
public int getNumberOfRows(){
return realTable.getNumberOfRows();
}
}
56
CreationRequestor
newProduct.....
CreationRequestor
newProduct.....
ConcreteProduct
operation1operation2.....
ConcreteProduct
operation1operation2.....
<<interface>>IFFactory
createProduct(discriminator):Product
<<interface>>IFFactory
createProduct(discriminator):Product
Factory
createProduct(discriminator):Product
Factory
createProduct(discriminator):Product
1* Uses
Product
operation1operation2.....
Product
operation1operation2.....
1
*
Creates
1
*
Requests- Creation
requestor
creator
9.4 Factory Method Pattern
[Deutsch: Fabrik]
- creational patterns
- definiert ein Interface für die Erzeugung von Objekten
- überlässt instanziiert der Klasse Unterklassen
9.4.1 Problem
Eine Applikation (oder ein Framework) kann manchmal die Klasse eines zu erzeugenden Objektes zur Laufzeit nicht antizipieren (vorwegnehmen). Die Applikation kennt vielleicht nur die abstrakte Klasse oder das Interface, diese lassen sich aber bekanntlich nicht instanziieren. Sie weiss also nur wann sie ein neues Objekt erzeugen muss, nicht aber was für eine Klasse das Objekt hat.
Ein Beispiel hierfür sind Textverarbeitungsprogramme. Ein Textverarbeitungsprogramm muss mit einer Vielzahl von verschiedenen Dokumenttypen umgehen können. Für jeden Dokumenttyp müssen Highlevel Methoden wie Öffnen oder Speichern ausgeführt werden können. Die Umsetzung für jede dieser Methoden muss separat im entsprechenden Dokumententyp implementiert werden. Ein zweites Bespiel für das Factory Method Pattern ist der Mechanismus für das Erzeugen von Enterprise JavaBeans (EJBs).
9.4.2 Lösung
UML Klassendiagramm
57
Klasse Beschreibung
Product Die abstrakte Superklasse (oder das Interface) der Klassen, welche durch das Factory Method Pattern instanziiert wird.
ConcreteProduct Die konkrete Klasse. Objekte dieses Typs werden durch das Factory Method Pattern erzeugt.
CreationRequestor Die applikationsunabhängige Klasse, welche die instanziierten Objekte der Factory benützt.
IFFactory Das applikationsunabhängige Interface, das die Methode deklariert, welche zum Erzeugen der konkreten Objekte benötigt wird.
Factory Die applikationsspezifische Klasse implementiert das passende Factory Interface und besitzt die Methode zum Erzeugen der konkreten Objekte.
9.4.3 Implementation
Die zentrale Klasse des Factory Method Pattern ist die Klasse Factory. Diese beinhaltet die Methode createProduct(),, welche die "Factory Methode" ist und dem Pattern den Namen gibt. Damit verschiedene konkrete Produkte erzeugt werden können, benötigt die Methode createProduct()einen Parameter zur Unterscheidung.
Das nachfolgende Beispiel zeigt eine Factory zur Erzeugung von Dokumenten. Der Methode createProduct() wird als Parameter die Extension des Dokumentes mitgegeben. Anhand der Extension wird das konkrete Dokument (ConcreteProduct) erzeugt und zurückgegeben. Der Rückgabewert der Methode ist eine Referenz der abstrakten Superklasse (Product) des konkreten Dokumentes. Diese Referenz erhält der CreationRequester und kann so mit dem gewünschten Dokument arbeiten.
public class DocumentFactory implements IFDocumentFactory {
public Document createDocument(String ext) {
if (ext.equals("doc"))
return new WordDocument();
if (ext.equals("html"))
return new HTMLDocument();
}
}
58
Das nachfolgende Beispiel zeigt eine Factory, welche überhaupt keine Angaben über bestehende Klassen zur Kompilierungszeit benötigt.
public class DynDocumentFactory implements IFDocumentFactory {
public Document createDocument(String docClassName)
throws Exceptions {
Class docClass = Class.forName(docClassName);
return (Document)docClass.newInstance();
}
}
Ein Beispiel für die Verwendung des Factory Method Pattern ist die Erzeugung von EJBs. Dabei ist das Home Interface EJBHome (und deren Containerspezifische Implementierung) die Factory. Die Methoden create() bei einem Session Bean oder find() bei einem Entity Bean sind die entsprechenden Factory Methoden, welche das gewünschte Bean erzeugen.
// get the JNDI naming context and lookup the EJB Home interface
Context initialCtx = new InitialContext()
HelloWorldHome home = (HelloWorldHome) initialCtx.lookup("HelloWorld");
// use the Home Interface to create a bean object
// --> Factory Method Pattern
HelloWorld helloworld = home.create();
// invoke the business methods through the interface reference
helloworld.sayHello();
59
9.5 J2EE Pattern
Im Zusammenhang mit J2EE Applikationen sind spezielle Anforderungen erwünscht wie:
- Transparenz
- Stabilität
- Performance
Auch hierzu existieren Entwurfsmuster, die jedoch im Gegensatz zu den StrandartPattern, die weitgehend von der eingestzten Programmiersprache und der verwendeten Plattform unabhängig sind, meist Idioms darstellen (also programmiersprache- und oft auch releaseabhängige Lösungen).
Auch das MVC Muster kann im J2EE implementiert werden:
Die folgenden vier Idioms sind aus dem Buch "J2EE Patterns" von Adam Bien (ISBN: 3-8273-2124-7) zusammengetragen und stellen ein Ausschnitt der darin vorgestellten Pattern dar:
- Service Locator zur Kapselung der Technologie
- Business Delegate zur Vereinfachung der Schnittstelle
- Value Object zur Minimierung der Remote Aufrufe
- Session Fassade zur Kapselung, Caching, Transaktionssteuerung
60
DBMS
Client Applikation Server
EJB DATA
Service Locator - Zugriff auf JNDI - CACHE für ServerObjekte
9.5.1 Service Locator
Suche und Erzeugung von EJB zeitintensiv und fehleranfällig:
- Namensdiensten (JNDI)
- Komponentenverteilung (RMI-IIOP)
- Factorycaching (Home Interface)
Der Service Locator stellt ein Entwurfsmuster zur Kapselung der Technologie und eine Performancesteigerung zur Verfügung.
Problem:
Bei einem Zugriff auf eine EJB muss zuerst ein Namensdienst initialisiert und die Verbindung zum Server hergestellt werden.
Dazu werden produktspezifische Informationen benötigt. Die meisten JNDI Implementierungen basieren auf CORBA-Technologie, die eine Interpretation des Servers verlangt (z.B: "iiop://localhost:3700").
Dies kann bis zu mehreren Sekunden in Anspruch nehmen, da der Name zuerst von einem DNS aufgelöst werden muss.
Lösung:
- Ermitteln von Dienstleistungen durch Locator
- wiederholendes Downcasting verschwindet
Anforderungen an den Service Locator:
- bereits instanzierte Instanz des Home Objektes und Ressourcen werden gecached
- Handels (robuste Referenzen) werden gecached
- JNDI Technologie ist transparent für den Client
61
Implementation:
Der Service Locator kapselt die Zugriffe auf das JNDI und stellt ein Cache für die Serverschnittstellenobjekte zur Verfügung. Der Service Locator wird meist als Singelton implementiert, damit auch nur tatsächlich eine Instanz des InitialContext pro VM existiert.
ServiceLocator to cache HomeObject (Ausschnitt)
public EJBHome getHome(String name,boolean cached) throws Exception{
Object temp = null; if(cached) temp = this.homeCache.get(name); EJBHome home = null; if(temp !=null && temp instanceof EJBHome){ return (EJBHome)temp; }else{ Object ref = context.lookup(name); EJBMetaData meta = ((EJBHome)ref).getEJBMetaData(); home = (EJBHome) PortableRemoteObject.narrow( ref,meta.getHomeInterfaceClass()); if(!meta.isSession() || meta.isStatelessSession()) this.homeCache.put(name,home); } return home; } … public static void main(String[] args) throws Exception{ Hashtable hash = new Hashtable(); hash.put("java.naming.factory.initial", "org.jnp.interfaces.NamingContextFactory"); hash.put("java.naming.provider.url","iiop://localhost:3700"); } }
ServiceLocatorClient
public class ServiceLocatorClient { public static void main(String args[]) throws Exception{ HomeFinder finder = ServiceLocator.getInstance(); EJBHome home = finder.getHome("Test"); System.out.println("HomeClass" + home.getClass().getName()); TestHome testHome = (TestHome)home; Test test = testHome.create(); } }
62
DBMS
Client Applikation Server
EJB DATA
Business Delegate - Kapselung der BusinessLogik
9.5.2 Business Delegate
Der Remotezugriff auf einen Server erfordert die Implementation einer entsprechenden Technologie (z.B. RMI-IIOP). Ein Client ist aber nicht an der Technologie sondern vielmehr an der Geschäftslogik interessiert. Das Idiom des Business Delegate ermöglicht eine Kapselung der Technologie und somit eine Vereinfachung der Schnittstelle zur Geschäftslogik.
Problem:
Bei einem Zugriff auf die Geschäftslogik in einem EJB-Kontainer ist oft ein Remotezugriff notwendig. Ein Remotezugriff ist jedoch viel komplexer und zeitintensiver als ein Lokalzugriff. Zusätzlich müssen noch Exceptions (HostNotFoundException, StubNotFoundException, etc.) abgefangen werden.
Lösung:
- zentrale Session Bean
- Schnittstelle für Client
- kann Informationen an anderen Beans weitergeben
- Client produziert "Events"
- Business Delegate Idiom "verteilt" Events
63
Implementation:
Das Business Delegate stellt die Schnittstelle zwischen Client und Geschäftslogik zur Verfügung. Dabei kapselt dieses Idiom die Zugriffslogik. Das Business Delegate wird vom Client instanziert und benutzt, die notwendigen Services werden durch den Service Locator beschafft.
Business Delegate Interface (wird Client zur Verfügung gestellt)
public interface BusinessDelegateIF { public CustomerVO getCustomer(String id); public CustomersVO[] getAllCustomerForZip(String zipPrefix); public CustomersVO[] getAllCustomers(); ... }
Business Delegate (Kapselung der BusinessMethoden)
public CustomerVO getCustomer(String id){ CustomerVO customer = null; try{ customer = this.customer.findByPrimaryKey(id); }catch(RemoteException e){ throws new ProblemWithBusinessMethodeException(this.e); } return customer: } ...
64
DBMS Client Applikation Server
EJB DATA
Business Delegate
ValueObject
9.5.3 Value Object
Die Datenübertragung über das Netzwerk, die meistens von der Data Tier bis zur Client Tier und umgekehrt erfolgt, ist oft limitierender Faktor in J2EE Applikationen. Das Value Object Idiom verbessert die Performance und minimiert die Remote Methodenaufrufe.
Problem:
Der Zugriff auf ein EJB erfolgt oft über Remote Methodenaufrufe. Oft wird jedoch nur eine Teilmenge der benötigten Daten übermittelt (z.B: getter / setter Methoden). Sinnvoller ist es die gesammte benötigte Datenmenge (Datensatz) in einem Methodenaufruf zu übermitteln.
Enterprise Beans haben in der Regel ganze Gruppen von Attributen, die vom Client in der Gruppe gebündelt abgerufen und gesetzt werden können. Auf diese Weise muss nicht für jedes Attribut einzeln eine Methode zum Setzen und Abfragen aufgerufen werden. Der Client erhält die Attribute in einem Value Object gebündelt.
Lösung:
Die vielen "get"-Aufrufe werden bereits im EJB Container zusammengefasst und dem Client als Objekt übermittelt. Dieses Kontainer-Objekt besteht nur aus Zugriffslogik und keiner Geschäftslogik, ist somit ein Value Objekt und entspricht folgenden Anforderungen:
- minimieren der Remote Methodenaufrufe an den Server
- Geschäftsdaten als Value Object an den Client übergeben
- das Auslesen der Objekt Attribute findet clientseitig statt
65
Implementation:
Das Value Objekt wird durch eine serialisierbare Klasse repräsentiert, die lediglich zu Datenhaltungszwecken dient. Das Value Object wird auf der entfernten Maschine erzeugt und gefüllt, über das Netzwerk transferiert und lokal ausgelesen.
Value Object als serialisierbare Klasse
public class PersonVO implements Serializable{ public String id = null; public String fname = null; public String name = null;
public PersonVO(){}
public PersonVO(String id, String fname, String name) { this.init(id,fname,name); }
protected void init(String id, String fname, String name); this.id = id; this.fname = fname; this.name = name; }
public PersonVO(PersonVO person){ this.init(person.getId(),person.getFname(),person.getName()); }
public String getId(){ return this.id; } public String getFname(){ return this.fname; } public String getName(){ return this.name; }
public void setId(String id){this.id = id;} public void setFname(String fname){this.fname = fname;} public void setName(String name){this.name = name;} }
66
Grundsätzlich können Value Objects von folgenden Komponenten erzeugt werden:
- Data Access Objects
- Session Façade (einer Session Bean, die den Zugriff auf ein Entity Bean managed)
- Business Delegate
- Session Bean
- Entity Bean
- Komponente der Präsentationsschicht
Es handelt sich also grundsätzlich um Komponenten, die in der Geschäftslogik oder in der Integrationsschicht liegen und in der Lage sind, benötigte Daten zu beschaffen. Meistens werden jedoch die Value Objects von den Entity Beans erzeugt, da diese die notwendige "Persistence Schicht" repräsentieren.
Die CMP Entity Bean der EJB 2.0 ist ein "Value Object"!
Beispiel für eine EJB 2.0 CMP Persistenz:
public abstract class AddressBean implements EntityBean {
public abstract String getId(); public abstract void setId(String id); public abstract String getStreet(); public abstract void setStreet(String street); public abstract String getLocation(); public abstract void setLocation(String location);
public String ejbCreate(String street, String location) throws CreateException { setId(street + location); setStreet(street); setLocation(location); return null; } public AddressVO getAddressVO(){ return new AddressVO(getId(),getStreet(),getLocation()); } ... }
67
9.5.4 Session Façade
Die Geschäftslogik liegt typischerweise im EJB Container; diese wird durch Komponenten (EJBs) abgebildet. Ein Client, der diese Logik verwenden möchte muss den Zusammenhang der einzelnen Komponenten im Container kennen.
Problem:
Entity Beans bilden persistente Objekte ab, repräsentieren aber lediglich den Zustand der darunterliegenden Datenbank. Die EJBs sind in Bezug auf Wiederverwendbarkeit, Transaktionssteuerung sowie Zustandserhaltung nicht, oder nur mit sehr hohem Aufwand verbunden, vom Client trennbar.
Wenn ein Client auf verschiedene Entity Beans zugreift und verschiedene Methoden der Entity Beans aufruft, um eine Aufgabe zu erledigen, kann dies verschiedene Probleme mit sich bringen. Zum einen erhöht sich der Netzwerk Traffic, des weiteren wird die Workflow Logik auf den Client verlagert, zum anderen sind die Methodenaufrufe durch die client-seitige Inszenierung möglicherweise nicht in einen notwendigen Transaktionszusammenhang gestellt.
Die Entity Beans mit weiterer Processing Logik aufzublähen, ist nicht der richtige Lösungsansatz. Da die Entity Bean Schicht von der langfristigen Perspektive her aus verschiedenen Sichten und Aufgaben gesehen wird, wird der Einbau von Anwendungslogik zu Zwecken der Performance Verbesserung eher zu Wartungsproblemen führen.
Deshalb sollte die Anwendungslogik, die eine Kette von Aufrufen von Entity Bean Methoden widerspiegelt, in einer Session Bean implementiert werden. Der Client ruft dann eine Methode der Session Bean auf, um seine Aufgabe zu erledigen. Die Methode der Session Bean übernimmt die Aufrufe der Methoden der verschiedenen Entity Beans.
Lösung:
Was der Client möchte ist eine Schnittstelle, die ein Use Case abbildet. Dem Client kann es egal sein, wieviele Entity oder Session Beans diese Schnittstelle implementiert. Für den Client ist nur die korrekte Abbildung des Anwendungsfalles wichtig.
68
DBMS
Client Applikation Server
EJB
EJB
DATA
Session Façade
Das Session Façade definiert eine neue "Schicht", die als Session Bean implementiert ist und folgende Anfgorderungen erfüllt:
- Abschirmung und Entkoppelung des Client vor Subsystemen
- Erhalt der Unabhängigkeit der Subsysteme
- Vereinfachung der Business Schnittstelle
- Implementierung von Diensten wie Caching, Authorisierung, etc.
- Zustandsverwaltung des Client
- Transaktionssteuerung
Implementation:
In einer zusätzlichen Schicht, implementiert mit einer Session Bean, werden diese Anforderungen untergebracht. Falls ein Caching gefordert ist, muss die Session Bean statefull sein. Diese EJB entspricht in ihrer Funktionalität dem klassischen GoF Façade Pattern. Sie bietet eine einfache Schnittstelle und verbirgt die Komplexität der Subsysteme vor dem Client.
Session Façade um einen Datensatz zu ändern; eine Transaktion wird gestartet (Ausschnitt)
public void updatePerson (PersonVO person) throws Exception{ try{ getPerson(person.getId()).remove(); this.createPerson(person); }catch(Exception e){ throw new Exception("PersonBean.updatePerson " + e); } }
69
9.6 Weitere Pattern im J2EE Umfeld
9.6.1 Value Object Assembler
Der Value Object Assembler stellt Value Objects und Schichten dynamisch in Session Beans zusammen und kommuniziert diese an den Presentation Layer. Er reichert Value Objects um Attribute an, die nur in der Bearbeitungsschicht benötigt werden, aber nicht in den Business Objects.
9.6.2 Composite Entity
Business Objekte sind oft nicht einfache Strukturen, sondern Graphen von Attribut Knoten. Ein Beleg hat Belegzeilen, und jede Belegzeile kann wieder mehrere Kostenrechnungs-informationen enthalten. Um der Modellschicht eine grössere Konsistenz zu geben, ist es besser, wenn für die abhängigen Objekte eine zentrale Entity Bean geschaffen wird, über die eine Session Bean mit den abhängigen Objekten umgeht. Das zentrale Business Objekt steuert seine abhängigen Objekte – die meist selbst wieder Entity Beans sind.
9.6.3 Data Access Objects DAO
Das Data Access Object Pattern trennt das Interface für eine System Ressource von der tatsächlichen Zugriffsstrategie. Jede Enterprise Bean, die auf eine Backend Ressource wie eine Datenbanktabelle zugreift, kann/sollte eine zugehörige DAO Klasse für diese Ressource haben.
Dass das Laden und Speichern über JDBC und SQL geschieht, bleibt für die Anwendungsschicht verborgen. Wenn ein anderer Persistenz Mechanismus gewählt wird, kann der Code im DAO ausgetauscht werden, ohne dass die restliche Anwendung davon betroffen ist.
70
9.6.4 Core J2EE Patterns
http://java.sun.com/blueprints/corej2eepatterns/Patterns/index.html
71
10 Programmiereinschränkungen (Regeln)
1
kein Threads Management oder Synchronisation in (EJB) Beans
- ist Aufgabe des Applikationsservers
- Bean = einzelner Thread, keine Kongruenz
2
keine Klassenvariablen / -methoden verwenden
- verschiedene Prozesse bei Cluster-Deployment
3 kein stdin / -out verwenden
- Input- / Outputstream sind nicht definiert
4
kein direkter Zugriff auf Dateien oder Directories
- nicht definierter Speicherort bei Cluster-Deployment
5
keine native Libraries
- nicht definierter Speicherort bei Cluster-Deployment
6
keine this – Referenz
- SessionContext.getEJBObject(); - EntityContext.getEJBObject();
Der EJB Context javax.ejb.SessionContext und javax.ejb.EntityContext erlaubt den Zugriff auf das REMOTE Interface des aktuellen Beans. Dies ergibt eine Referenz auf das Bean selbst, die weitergegeben werden kann.
72
11 EJB Anwendungsbeispiele mit JBoss AS
JBoss™ als Open Source Applikationsserver hat einen potentiellen Markt im J2EE Umfeld. Für das Testen und Kennenlernen von J2EE Applikationen bietet JBoss zusammen mit dem Eclipse Entwicklungstool eine ready-to-use Plattform.
Entsprechende Installationsinformationen sind im Anhang aufgeführt. Die nachfolgenden Erläuterungen und Beispiele dienen zur Repetition der behandelten EJB Theorie und geben einen Einblick in das Aufsetzen von J2EE Applikationen mit dem JBoss AS (http.//www.jboss.org)
11.1 wiederverwendbare Komponenten
EJBs sind als wiederverwendbare, verteilte Komponenten konzipiert, welche relativ lose gekoppelt und in einer verteilten Umgebung einsetzbar sind.
Der Verteilungsaspekt dieser Komponenten ermöglicht die Trennung der Anwendung (Geschäftslogik), der Bedienerführung (Darstellungslogik) und der Datenerhaltung (Persistenz), denn ohne dem Deployen dieser Komponenten:
- jeder Fehler in Client-Programme kann Datenbankinhalt beschädigen
- Benutzer kann versuchen Geschäftslogik zu umgehen
- eine neue Version muss auf allen PCs installiert werden
- Modularisierung wird nicht gefördert
- Darstellung wie Verarbeitung ist festgelegt
Daher trennt man die Geschäftslogik von der Darstellung und installiert sie auf einem zentralen Server, der zwischen den Clients und dem Datenbankserver vermittelt, als 3-Tier Architecture.
EJB bilden Suns Ansatz, um die gewünschte Flexibilität zu erreichen. Die mittlere Schicht wird in Komponenten zerlegt, was auch die Änder- und Erweiterbarkeit unterstützt (und der Wiederverwendung, um den Aufwand zur Erstellung zu kompensieren). Zur Kommunikation zwischen den Komponenten dient gebräuchliche Middleware, vor allem RMI, aber auch (zum Client) CORBA oder Webdienste.
73
11.2 EJB Container
Ein EJB-Container in Verbindung mit einem Application Server nimmt den Programmierern erhebliche Arbeit ab:
- die Verteilung der Objekte:
- die Anbindung eines Webservers (lokal oder über RMI-IIOP), der die Kommunikation mit den Clients übernimmt
- die Anbindung der Clients oder anderer Enterprise Beans über RMI-IIOP
- den lokalen Zugriff auf andere Enterprise Beans
- die Anbindung von Clients oder anderen Anwendungen über Simple Object Access Protocol (SOAP) und Web Services Description Language (WSDL)
- den Datenbankzugriff (über JDBC)
- die Thread-Verwaltung und Synchronisation EJBs müssen nicht thread-sicher sein
- die Prozessverwaltung um die Last optimal bewältigen zu können
- Zuverlässigkeit und eventuell sogar Lastverteilung auf mehrere Server
- Zustandsverwaltung Objekte werden bei Bedarf aktiviert und deaktiviert
- Pooling von z.B. Datenbankverbindungen
- Transaktionen und Wiederherstellung
- auf Wunsch den Datenaustausch mit der Datenbank ohne (sichtbares) SQL
- Sicherheit
- Werkzeuge zur Systemadministration
74
11.3 EJB Ausprägungen
Entity Beans
- besitzen einen dauerhaften (persistenten) Zustand
- modellieren Objekte im Anwendungsbereich
- stellen Datenbehälter mit Regeln zur Sicherung eines konsistenten Zustands dar
- bilden Datensätze in einer Datenbank-Tabelle ab
Session-Bean
- zustandsbehaftet, werden sie bei Bedarf erzeugt und sind einem bestimmten Client zugeordnet, dessen Sitzung sie verwalten, ihr Zustand wird nicht gespeichert und geht nach Gebrauch verloren
- zustandslos, verwalten sie Sitzungen, sind aber austauschbar und können daher in einem Pool gehalten werden. Das macht sie wesentlich leistungsfähiger als die Beans mit Zustand. Sie können eine Webdienst-Schnittstelle haben (neu in EJB 2.1)
- modellieren Geschäftsvorgänge (Tätigkeiten, Anwendungsfälle) im Anwendungsbereich
- dient zur Kommunikation mit dem Client
- nehmen oft die Dienste von Entity-Beans und anderen Session-Beans in Anspruch
MessageDriven-Bean (ab EJB 2.0)
- sind zustandslos
- dienen zur asynchronen Kommunikation, d.h. für Anfragen, auf die keine unmittelbare Antwort erwartet wird
- sind nicht über eine Schnittstelle, sondern über eine Topic- oder Queue-Destination ansprechbar
- werden durch ein Ereignis aktiviert
- Verwendung gleicht der von zustandslosen Session-Beans
75
11.4 EJB Schnittstellen
Jede Enterprise Bean kann eine oder mehrere der folgenden Schnittstellen implementieren:
- remote Interfaces erlauben den Zugriff über RMI-IIOP, sei es von aussen oder lokal
- local Interfaces (neu in EJB 2.0) erlauben den Zugriff nur innerhalb des gleichen Application Servers (in den auch ein Webserver integriert sein kann). Diese Zugriffe sind effizienter und haben die normale Java-Semantik und die gleichen Parameter wie Remote Interfaces
Sowohl von local wie auch von remote Schnittstellen gibt es je zwei Ausprägungen:
- Remote Interface, enthält die Methoden der Anwendung
- Home Interface, dient zur Verwaltung der Enterprise Bean
- Webdienst-Schnittstellen als Service Endpoint Interface für die Stateless Session-Bean (neu in EJB 2.1), dabei ist nur die Remote Schnittstelle implementiert ( extends Remote )
11.5 EJB Bestandteile
Eine Enterprise Bean besteht aus mehreren Teilen:
Bean-Klasse
class AnwendungBean implements EntityBean { class AnwendungBean implements SessionBean { class AnwendungBean implements MessageDrivenBean { ... }
Interfaces
interface Anwendung extends EJBLocalObject/EJBObject/Remote {
...
}
interface AnwendungHome extends EJBLocalHome/EJBHome {
...
}
76
Deployment-Descriptor
... <enterprise-beans> <entity> <ejb-name>Anwendung1EJB</ejb-name> <home>Anwendung1Home</home> <remote>Anwendung1</remote> <ejb-class>Anwendung1Bean</ejb-class> ... </entity> <session> <ejb-name>Anwendung2EJB</ejb-name> <home>Anwendung2Home</home> <remote>Anwendung2</remote> <ejb-class>Anwendung2Bean</ejb-class> ... </session> ... </enterprise-beans>
Verpackt in eine jar-Datei (EJB 2.0)
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE ejb-jar PUBLIC "-//Sun Microsystems, Inc.//DTD EnterpriseJavaBeans 2.0//EN" "http://java.sun.com/dtd/ejb-jar_2_0.dtd"> <ejb-jar> ... </ejb-jar>
Verpackt in eine jar-Datei (EJB 2.1)
<?xml version="1.0" encoding="UTF-8"?> <ejb-jar xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation = "http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/ejb-jar_2_1.xsd" version="2.1"> ... </ejb-jar>
Zwischen den Versionen ist man von DTDs auf XML-Schema umgestiegen.
Die Schnittstellen und der Deployment-Descriptor können von Werkzeugen aus der Bean-Klasse erzeugt werden, etwa durch XDoclet (http://sourceforge.net/projects/xdoclet). Dabei werden die entsprechenden javadoc-Kommentare ausgewertet.
Den Deployment-Descriptor erfassen viele Application Server auch per Formular.
77
11.6 EJB Implementation
- die Bean-Klasse muss einen parameterlosen Konstruktor besitzen
- die Schnittstelle EnterpriseBean erweitert die Schnittstelle Serializable, damit handelt es sich um eine echte Bean
- die Bean-Klasse muss die Methoden aus allen im Deployment-Descriptor angesprochenen Schnittstellen implementieren - allerdings nicht unmittelbar. Diese Schnittstellen zeigen an, was man von ausserhalb des Application Servers sieht. Beim Deployment werden Klassen erzeugt, die sie implementieren. Die Bean-Klasse muss entsprechende Methoden bereitstellen, die die eigentlichen Aktionen enthalten:
- bei Entity-Beans müssen zu jeder createXYZ-Methode aus dem Home-Interface zwei Methoden ejbCreateXYZ und ejbPostCreateXYZ mit der gleichen Signatur implementiert werden
- bei Session-Beans muss zu jeder createXYZ-Methode aus dem Home-Interface die Methoden ejbCreateXYZ mit der gleichen Signatur implementiert werden
- bei MessageDriven-Beans muss eine Methode ejbCreate implementiert werden
- bei Entity-Beans muss zu jeder findXYZ-Methode aus dem Home-Interfcae eine Methode ejbFindXYZ mit der gleichen Signatur implementiert werden
- bei Entity-Beans muss zu jeder Methode XYZ des Home-Interface eine Methode ejbHomeXYZ mit der gleichen Signatur implementiert werden
- zusätzlich muss jede Methode der Anwendung aus dem Remote-Interace mit der gleichen Signatur implementiert werden
78
ejb-jar.xml ENC Elements (ENC = Enterprise Naming Context)
jboss.xml ENC Elements (ENC = Enterprise Naming Context)
11.7 EJB Deployment Descriptors
Die für den Deployprozess notwendigen Deployment Descriptoren, die wir bis anhin mit dem Deploytool erstellt haben möchten wir näher betrachten:
- ejb-jar.xml
- jboss.xml
- application.xml
- application-client.xml
- jboss-client.jar
- jbosscmp-jdbc.xml
ejb-jar.xml : beschreibt Bean auf logischer Ebene
- Namen der Java-Klassen
- Namen der Attribute
- Transaktionsverhalten
- Security Mapping
- Spezifikation der Query-Methoden
- Resource Referenzen
jboss.xml : bescheibt Informationen für den Application Server
- JNDI-Mapping: Name unter dem das Home-Interface gefunden wird
- Resource Referenzen
<jboss> <enterprise-beans> <session> <ejb-name>moneyexchange</ejb-name> <jndi-name>ejb/moneyexchange</jndi-name> <resource-ref> <res-ref-name>jdbc/ExchangeTable</res-ref-name> <jndi-name>java:/mySQLDS</jndi-name> </resource-ref> </session> </enterprise-beans> </jboss>
79
application.xml : beschreibt eine ganze Enterprise Applikation
Die graphische Representation zeigt die Struktur des J2EE application.XML Schema. <application> <display-name> MoneyExchange </display-name> <module> <ejb> MoneyExchange.jar </ejb> </module> </application>
application-client.xml : beschreibt First Tier Client Program
Alle gültigen application-client.xml Deployment Descriptoren müssen dem abgebildeten XML Schema oder einer entsprechenden DTD Definition folgen und beschreiben:
- Client Beschreibung
- Environment Entries
- EJB Referenzen
- Resource Referenzen
- Resource Environment Referenzen
<application-client> <display-name> MoneyExchangeClient </display-name> <ejb-ref> <ejb-ref-name> ejb/MoneyExchange </ejb-ref-name> <ejb-ref-type> Session </ejb-ref-type> <home> beans.MoneyExchangeHome </home> <remote> beans.MoneyExchange </remote> </ejb-ref> </application-client>
80
jboss-client.xml : Informationen für den Application Server
- Versionsnummern, ...
- jndi-name : Name unter dem das Home-Interface gefunden wird
- ejb-ref : Resource Referenzen
<jboss-client> <jndi-name>MoneyExchangeClient</jndi-name> <ejb-ref> <ejb-ref-name>ejb/MoneyExchange</ejb-ref-name> <jndi-name>moneyexchange</jndi-name> </ejb-ref> </jboss-client>
jbosscmp-jdbc.xml : O/R-Mapping für die Datenbank (AS-spezifisch)
datasource : Information für DB-Connect
- jndi-name : Name unter dem das Home-Interface gefunden wird
<jbosscmp-jdbc> <defaults> <datasource> java:/DefaultDS </datasource> <datasource-mapping> MySQL </datasource-mapping> <create-table>true</create-table> <remove-table>true</remove-table> </defaults> <enterprise-beans> <entity> <ejb-name>Product</ejb-name> <table-name>ProductTable</table-name> </entity> </enterprise-beans> </jbosscmp-jdbc>
81
12 Übung ee4 : DB-Anbindung Stateless Session Bean
In diesem Beispiel soll eine Datenquelle von einer Session Bean aus angesprochen werden. Während der erste Lösungsansatz einer standart JDBC Verbindung beschreibt, konzentriert sich der zweite Lösungsansatz auf den Lookup des Datasource Objektes per JNDI.
12.1 JDBC API
Klassen und Schnittstellen der:
java.sql
JDBC API
12.2 Währungsrechner mit Session-Beans
Erstellen Sie ein Stateless Session Bean zum Umrechnen von Währungskursen ( z.B. CHF > EUR), die Währungskurse sollen durch eine DB-Tabelle persistent gehalten werden und durch das EJB repräsentiert werden.
Client Attribute : final int amount = 250; final String changeTo = "EUR";
Die Basiswährung ist "CHF"
12.2.1 Datenbankanbindung mit Session-Beans
Lesen Sie den Umrechnungskurs aus der mySQL Datenbank "ee" und erweitern Sie Ihre Applikation mit z.B. USD, GBP, etc.
Erstellen Sie eine entsprechende Tabelle "rates" in der mySQL DB und definieren Sie die Kurse.
Alternative: Benutzen Sie das entsprechende Jakarta-Ant Target "run-sql-script" das in der build.xml Datei vorbereitet ist.
Für die Datenbank Anbindung fokussieren wir zwei Varianten: "JDBC" und "JNDI Lookup":
82
12.2.2 JDBC Connection
Ergänzen Sie den Source der Bean mit den notwendigen Statements um die JDBC Datenquelle rates abzufragen und übergeben Sie die Währungseinheit als Parameter der Business-Methode:
Ansatz: JDBC Connection in MoneyExchangeBean.java
String SQLQuery = "SELECT rate FROM rates WHERE ... final String user = "..."; final String pass = "..."; final String url = "jdbc:mysql://localhost/ee";
Class.forName("com.mysql.jdbc.Driver"); Connection con = DriverManager.getConnection(url, user, pass); Statement stm = con.createStatement(); Resultset rs = stm.executeQuery(SQLQuery);
12.2.3 JNDI lookup Connection
Benutzen Sie den Namingservice um über einen lookup die Datenquelle an das Bean anzubinden. Der für den JNDI lookup massgebende Name wird im Deployment Descriptor definiert:
ejb-jar.xml (Ausschnitt)
<resource-ref> <res-ref-name>jdbc/ExchangeTable</res-ref-name> <res-type>javax.sql.DataSource</res-type> <res-auth>Container</res-auth> </resource-ref>
jboss.xml (Ausschnitt)
<resource-ref> <res-ref-name>jdbc/ExchangeTable</res-ref-name> <jndi-name>java:/mySQLDS</jndi-name> </resource-ref>
[JBoss_Home]/server/ee/deploy/mysql-ds.xml (Ausschnitt)
<datasources> <local-tx-datasource> <jndi-name>mySQLDS</jndi-name> <connection-url> jdbc:mysql://localhost:3306/ee </connection-url>
Ansatz: JNDI lookup Datenbank Connection in MoneyExchangeBean.java
InitialContext ic = new InitialContext(); DataSource ds = (DataSource) ic.lookup("java:comp/env/jdbc/ExchangeTable");
83
13 Übung ee5 : Robuste Referenzen
13.1 Handles
Handles definieren robuste Referenzen auf Instanzen, die man zwischen Maschinen (netzwerkfähig) austauschen kann:
- persistent (dauerhaft) - transferable (verschiebbar) - serializable (in nachfolgende Packete zerlegbar) - provided by container - consists one method, that returns the Home / Remote Interface - guaranteed to work across client JVM's and server
Class Definition
public interface Handle extends Serializable { public EJBObject getEJBObject() throws RemoteException; }
public interface HomeHandle extends Serializable { public EJBHome getEJBHome() throws RemoteException; }
Creating / Storing a Handle am Beispiel eines HomeHandle
Home home = ... HomeHandle home_handle = home.getHomeHandle();
ObjectOutputStream oos = new ObjectOutptStream( new FileOutputStream (new File("myHomeHandle.ser")));
oos.writeObject(home_handle); oos.close();
Using a Handle am Beispiel eines HomeHandle
ObjectInputStream ois = new ObjectInputStream( new FileInputStream("myHomeHandle.ser"));
ois.close();
HomeHandle home_handle = (HomeHandle)ois.readObject();
Object obj = home_handle.getEJBHome(); Home home = (Home)PortableRemoteObject.narrow( obj, Home.class);
Für den Handle des Remote Objectes ist die Anwendung analog, anstelle des HomeHandle tritt das Object Handle. Ob der Handle oder HomeHandle für späteren Beanzugriff persistiert wird ist von der Applikations und der Zugriffslogik abhängig.
84
13.2 Kontoführung mit Stateful Session Bean
Entwickeln Sie eine triviale Kontoführung mit Handels um mehrere Konten parallel zu buchen.
Führen Sie für mehrere "Kunden" individuelle Konten, um:
- Betrag zu deponieren (als Float)
- Betrag abzuheben (als Float)
- Saldo auszugeben (auf der Konsole)
1. Deklarieren Sie die verschiedenen Business-Methoden im Remote Interface und definieren Sie diese in der Bean Klasse.
2. Konzipieren Sie ein Client-Testprogramm um Ihre Applikation zu testen.
3. Ergänzen Sie die Bean Methoden mit Konsolen Statements System.out.println zur Überwachung der Aktivitäten des AS. Überprüfen Sie die entsprechende LOG-Datei.
4. Definieren Sie einen Zinssatz für alle Ihre "Kunden". Der Zinssatz ist für alle Konten gleich. Suchen Sie nach einer geeigneten Möglichkeit um den Zinssatz ändern zu können. Implementieren und Überprüfen Sie Ihre Wahl.
13.2.1 Bean Identität mit Handle speichern
Um in der Client-Applikation mehrere Konten parallel zu führen kann die getHandle Methode benützt werden.
Definieren Sie individuelle Konten der Klasse Handle:
private static Handle handle_1; private static Handle handle_2; private static Handle handle_3;
Erzeugen Sie das Home Objekt:
private static AutomaticTellerHome erzeugeHomeObjekt() throws NamingException {
InitialContext ctx = new InitialContext(…); Object ref = ctx.lookup("account"); home = (AutomaticTellerHome) PortableRemoteObject.narrow(
ref,AutomaticTellerHome.class); return home; }
85
Erzeugen Sie für jeden Account eine eigene Bean-Instanz mit der create Methode. Benützen Sie die getHandle Methode des Remote Interfaces um die Bean Instanzen zu "sichern":
Bean-Insanz:
public static Handle erstelleAccount(AutomaticTellerHome home) throws CreateException, RemoteException {
AutomaticTeller at = home.create(); return at.getHandle(); }
Um die Business-Methoden auf den individuellen Accounts ausführen zu können, brauchen Sie den richtigen "Handle"; diesen bekommen Sie, indem Sie auf dem entsprechenden Handle Objekt die getEJBObjekt Methode aufrufen.
Erstellen Sie ein Methode getRemoteObjekt, die das für Sie erledigt.
getRemoteObjekt
private static AutomaticTeller getRemoteObjekt(Handle handle) throws RemoteException {
return (AutomaticTeller) javax.rmi.PortableRemoteObject
.narrow(handle.getEJBObject(), AutomaticTeller.class); }
Testen Sie nun Ihre "Bank", indem Sie auf den bereitgestellten Konten individuelle Beträge buchen und abheben.
13.2.2 Handle persistent in Datei speichern
Speichern Sie die Handle mit Hilfe eines FileOutputStream Objektes in eine Datei und lesen Sie diese in einer anderen Client-Applikation wieder aus.
Testen Sie Ihre Applikation. (Beweis!)
86
14 Übung ee6 : EJB QL (CMP 2.0)
Um die Funktionsweise der Suchmethoden des Home-Inteface zu erläutern ist eine kurze Betrachtung der EJB Querry Language erforderlich.
14.1 EJB QL
findXYZ:
Bei CMP muss die Methode findByPrimaryKey immer deklariert werden, jedoch wird sie durch die Bean-Klasse nicht implementiert. Weitere Methoden findBy... (das By ist eine Namenskonvention) dürfen deklariert werden und werden ebenfalls nicht implementiert. Ihr Ergebnistyp ist das (local oder remote) Remote-Interface oder eine java.util.Collection davon.
public Name findByPrimaryKey(String id) throws FinderException, RemoteException;
public Collection findByName(String name) throws FinderException, RemoteException;
Zu jeder findBy...-Methode (ausgenommen findByPrimaryKey) muss es einen entsprechenden Eintrag im Deployment-Descriptor geben:
ejb-jar.xml (Ausschnitt Finder QL)
<entity> ... <persistence-type>Container</persistence-type> ... <query> <query-method> <method-name>findBy...</method-name> <method-params> <method-param>Type</method-param> ... </method-params> </query-method> <ejb-ql>SELECT ... FROM ... WHERE ...</ejb-ql> </query> ... </entity>
Zu jedem Parameter wird die entsprechende Java-Klasse/Schnittstelle angegeben. Wenn es keine Parameter gibt, gibt es keine method-param Tags. Der Eintrag (Tag) method-params bleibt jedoch erhalten.
87
selectXYZ:
Solche Methoden sind nur bei CMP zulässig. Sie werden nicht deklariert (der Name selectXYZ taucht auch nirgendwo auf) und durch abstrakte Methoden in der Entity-Bean implementiert:
CMP Bean Klasse
public abstract AnwendungBean implements EntityBean { ... public abstract Type ejbSelectXYZ(...) throws FinderException; ... }
Type ist hier deutlich flexibler als bei den findXYZ-Methoden: Neben dem Remote-Interface ist jeder beliebige (serialisierbare) Java-Typ zulässig, so dass man auch Attributwerte zurückliefern kann, und neben java.util.Collection ist auch java.util.Set möglich. Die ejbSelectXYZ-Methoden ihrerseits werden durch einen Eintrag query im Deployment-Descriptor beschrieben, genau wie die findXYZ-Methoden.
Die EJB QL selbst ist eine kleine Untermenge von SQL.
Eine Abfrage SELECT ... FROM ... WHERE ... besteht aus folgenden Teilen:
SELECT: - DISTINCT
- COUNT, SUM, AVG, MIN, MAX (seit EJB 2.1)
- a, b, c, sind Objekte und liefern einen einzelnen Wert
FROM:
- Liste von Tabellen (bzw. abstrakten Schemata) der Form Table AS t
- Aufzählungen der Form IN (Collection) AS c
WHERE (optional):
- NOT, AND, OR; =, <>, <, <=, >, >= (Vorsicht mit XML!)
- [NOT] BETWEEN, [NOT] IN, [NOT] LIKE, IS [NOT] NULL, IS [NOT] EMPTY, [NOT] MEMBER OF
- +, -, *, / Zahlen, Zeichenketten
- CONCAT, LENGTH, LOCATE, SUBSTRING, ABS, SQRT und MOD
88
Die Parameter einer findXYZ- oder ejbSelectXYZ-Methode werden durch ?1, ?2, ... angesprochen.
ORDER BY (optional):
(seit EJB 2.1) Hier steht ein Pfadausdruck der Form a, b, c, der direkt vom SELECT-Ausdruck abhängen muss, gefolgt von ASC (Voreinstellung) oder DESC.
Beispiel
public Collection<Customer> findAll() throws RemoteException,FinderException;
public Collection<Customer> findByComputerCount(
int computerCount)throws RemoteException, FinderException;
resultiert in:
SELECT OBJECT (c) FROM Customer c
SELECT OBJECT (c) FROM Customer c WHERE c.computerCount >= ?1
14.2 Primary Key Klasse
Die Primary Key Klasse ist nur für Entity Beans notwendig. Sie kapselt die Felder, die den Primary Key der Datenbank repräsentieren in einem eigenen Objekt. Ist der Primary Key in der Datenbank durch ein einzelnes Feld mit einem Basic Datentyp konzipiert, so darf der Primary Key im Bean als Standard Java Klasse (z.B: java.lang.Integer oder java.lang.String) definiert sein. Natürlich müssen die Datenfelder typengleich sein. (Primitive Datentypen wie int, float oder boolean sind nicht möglich). Dabei wird die Klasse des Primary Keys und bei CMP das entsprechende Feld im Deployment Descriptor definiert:
<prim-key-class>java.lang.Integer</prim-key-class> <primkey-field>id</primkey-field>
Die Alternative ist eine eigene PrimaryKeyClass zu definieren. Die Klasse muss serializable sein und Implementationen der Methoden hashcode() and equals(Object)definieren.
89
Für CMP sind die folgenden Punkte massgebend:
- Die Felder der Primary Key Klasse müssen als public deklariert werden.
- Die Primary Key Klasse muss einen Default Konstruktor haben.
- Die Namen der Felder der Primary Key Klasse müssen Teil der CMP Felder der Bean Klasse sein.
Beispiel einer PrimaryKeyKlasse
public class PersonBeanPK implements java.io.Serializable { public int id; public PersonBeanPK(int id) { this.id = id; } public PersonBeanPK() { }
public int hashcode() { return id; } public boolean equals(Object other) { ... }
14.3 ProductShop
Entwickeln und Testen Sie einen ProductShop mit einer CMP 2.0 Entity Bean, die auf eine mySQL DB mit den Feldern productID und name und price zugreift.
Realisieren Sie eine PrimaryKeyKlasse, die das Datenbankfeld productID repräsentiert.
Definieren Sie entsprechende Finder Methoden wie:
- findByName
- findAllProducts
90
Ansatz:
findByName Methode im ProductHome Interface:
public Collection findByName(String name) throws FinderException, RemoteException;
entsprechendes <query> tag im Deployment Descriptor ejb-jar.xml <query> <query-method> <method-name>findByName</method-name> <method-params> <method-param>java.lang.String</method-param> </method-params> </query-method> <ejb-ql> SELECT OBJECT(a) FROM ProductBean As a WHERE a.name = ?1 </ejb-ql> </query>
Erstellen Sie eine XML Datei (Deployment Descriptor), mit der Sie das Datenbankmapping definieren. Diese Datei ergänzt die Einstellungen der Datei standardjbosscmp-jdbc.xml im \conf Verzeichnis des AS:
jbosscmp-jdbc.xml
<jbosscmp-jdbc> <defaults> <datasource>java:/DefaultDS</datasource> <datasource-mapping>mySQL</datasource-mapping> <create-table>true</create-table> <remove-table>true</remove-table> </defaults> <enterprise-beans> <entity> <ejb-name>Product</ejb-name> <table-name>ProductTable</table-name> </entity> </enterprise-beans> </jbosscmp-jdbc>
91
14.3.1 Summe aus allen Produkten
Soll das Total des "Warenkorbes" bestimmt werden, so können mit der getPrice Methode des Remote Interfaces die Preise mittels Iteration summiert werden:
Summe aller Produkte
double sum = 0; Iterator i = home.findAllProducts().iterator();
while (i.hasNext()) { Product prod = (Product)
PortableRemoteObject.narrow(i.next(),Product.class); sum += prod.getPrice(); } System.out.println("Summe aller Produkte: " + sum);
Die Methode getPrice ist eine treue Operation und bei grossen Datenbeständen ist diese Variante nicht sehr sinnvoll. Als Alternative sollen die Preise der Produkte im EJB Container summiert werden. Dazu bauen wir die Methode getAllPriceTotal() und fügen unserem EJB Local Interfaces hinzu für einen lokalen Zugriff innerhalb des EJB Kontainers:
neue Finder Methode im Home Interface:
public double getAllPriceTotal() throws RemoteException;
Alle Methoden des Home Interface müssen durch eine entsprechende MethodenSignature in der Bean Klasse vertreten sein (analog create(...) Methoden), also z.B: durch die Methode
public double ejbHomeGetAllPriceTotal() { … }
92
getHomeAllPriceTotal()könnte wie folgt aussehen:
getHomeAllPriceTotal() Methode in der Bean Implementation
public double ejbHomeGetAllPriceTotal() { double sum = 0.0; try { Collection c = this.ejbSelectAllPrices(); Iterator i = c.iterator(); while (i.hasNext()) { sum += ((ProductLocal) i.next()).getPrice(); } } catch (Exception e) { … } return sum; }
entsprechende <query> im ejb-jar.xml Deployment Descriptor
<query> <query-method> <method-name>ejbSelectAllPrices</method-name> <method-params></method-params> </query-method> <result-type-mapping>Local</result-type-mapping> <ejb-ql> SELECT OBJECT(p) FROM ProductBean As p </ejb-ql> </query>
Die Local Interfaces sind identisch zu den [Remote]Interfaces mit dem Unterschied, dass die Local Interfaces keine RemoteExceptions werfen, da sie ja "nur" einen lokalen Zugriff machen.
93
15 Übung ee62 : PersonBean mittels BMP Entity Bean
15.1 BMP – Bean Managed Persitance
- kapseln Datenbankinhalte durch Objekte
- sind instanziierbar und zugreifbar
- Verwaltung der Daten erfolgt durch ein DBMS
- Verwaltung der Objekte erfolgt durch den EJB-Container
- Persistenzlogik transparent
- serverseitige Realisieren
Bean Managed Persistence
- Bean obliegt Umsetzung der Persistenzlogik
Container Managed Persistence
- Persistenzlogik durch EJB-Container realisiert
Wie bereits für die Realisierung von Session Beans eingeführt, werden auch zur Publikation der extern zugänglichen Schnittstellen Home und Remote Interfaces benötigt. Dieser Schnittstellentyp dient auch für Entity Beans zur Aufnahme der Verwaltungsoperationen zur Erzeugung (create) und zur Suche existierender (findByPrimaryKey) EJBs.
Home Interface
Die Home-Schnittstelle zeigt die create-Operation zur Erzeugung einer neuen EJB-Instanz.
- Übergabeparameter dienen zur Konstruktion des neuen Objekts
- Interpretation durch die Bean-Implementierung
- Schnittstelle findByPrimaryKey liefert Entity-Bean anhand ihres Primärschlüssels
Hinsichtlich der verwendeten Typen zeigt sich bereits hier, dass eine Abbildung der Java Typen auf die des eingesetzten Persistenzsystems stattfinden muss.
Bei BMP wo die EJB selbst die Persistenz verwalten muss ist diese Abbildung manuell durch den Programmierer bereitzustellen.
94
Remote Interface
- Geschäftsfunktionen
- Operationen zum Zugriff auf die verwalteten Daten, nicht jedoch zur technischen Verwaltung und Interaktion mit dem Bean-Container.
Per Konvention muss diese Schnittstelle als Spezialisierung der Schnittstelle EJBObject definiert sein. Diese Standardschnittstelle definiert allgemeine Interaktionsformen, wie:
- Löschen (remove)
- Vergleich (isIdentical)
- Ermittlung des Primärschlüsselwertes (getPrimaryKey)
- Vergleich zweier serverseitiger EJB-Objekte (isIdentical)
- Wert des Primärschlüssels (getPrimaryKey)
Zur Löschung von datenbankresistenten Objekten wird remove eingesetzt. Der Aufruf dieser Methode entfernt ausschliesslich die durch die EJB repräsentierten Datenbanktupel, die programmiersprachliche Objektrepräsentation bleibt jedoch über die gesamte Laufzeit (sofern nicht durch Gültigkeitsbereiche oder explizite NULL-Setzung explizit anders gehandhabt) intakt.
95
15.2 BMP Person Bean
Erstellen Sie eine Entity Bean zur Personenverwaltung mit Bean Managed Persistence. Jedes Personen-Objekt enthält Daten zu Name, Geburtsdatum und Wohnort.
Der Name dient als eindeutige Identifikation und daher datenbankseitig als Primärschlüssel. Die notwendige Datenbanktabelle wird durch folgenden SQL-Ausdruck erzeugt:
CREATE TABLE PERSON( Name VARCHAR(20) PRIMARY KEY, Birthdate DATE, City VARCHAR(30));
Ansatz:
create und findByPrimary im BMPPersonHome Interface:
public interface BMPPersonHome extends EJBHome { public Person create(
int year, int month, int day, String name, String city) throws CreateException, RemoteException;
public Person findByPrimaryKey(String name)
throws FinderException, RemoteException; }
einige Business Methoden:
public interface Person extends EJBObject { public int getAge() throws RemoteException; public String getCity() throws RemoteException; public void setCity(String city) throws RemoteException;
Die mit getAge in der Remote-Schnittstelle veröffentlichte Operation soll keinen direkt abgespeicherten Wert liefern, sondern diesen dynamisch zur Ausführungszeit anhand der verfügbaren Daten berechnen.
spezifische Business Methode
public int getAge() { return (new GregorianCalendar().get(Calendar.YEAR) - birthdate.get(Calendar.YEAR));
96
Innerhalb der datenbankzugreifenden Methoden muss durch den Anwender die Abbildung der Java-Datentypen auf die des verwendeten Datenbankmanagementsystems erfolgen. Die mit dem Präfix ejb versehenen Methoden zeigen dies für die lesenden und schreibenden DB-Zugriffe. So kann die im Beispiel für name und city verwendete Java-Repräsentation String vergleichsweise leicht in den SQL-Typ VARCHAR abgebildet werden sofern alle Methoden sicherstellen, dass nur konforme Werte eingefügt werden.
Exemplarisch soll das mit den Methoden ejbCreate und setCity gezeigt werden.
setStreet
public void setCity(String city) throws RemoteException { if (city.length() <= 30) { this.city = city; } else { throw new RemoteException("cannot update city"); } }
Für programmiersprachliche Typen, die nicht direkt in DB-Typen abbildbar sind, muss im Falle der Bean Managed Persistence der Bean-Entwickler selbst Sorge für die adäquate Abbildung tragen. Der Java-Datumstyp GregorianCalendar soll manuell in die durch das DBMS erwartete ISO 8601-konforme Darstellung überführt werden.
97
Datumstyp Umrechnung
public String ejbCreate(int y, int m, int d, String name, String city) throws CreateException {
this.name = name; this.birthdate = new GregorianCalendar(y, m, d); this.street = street; Statement stmt = getStatement(); // open con and return stmt String s = new String("INSERT INTO PERSON VALUES ('" + name + "','" + birthdate.get(Calendar.YEAR) + "-" + birthdate.get(Calendar.MONTH) + "-" + birthdate.get(Calendar.DATE) + "'," + "'" + street + "'" + ");"); try { stmt.executeUpdate(s); } catch (SQLException e) { e.printStackTrace(); } } else { throw new CreateException("Invalid values supplied"); } return name; }
Analog zur ejbCreate Methode ist der Bean Provider verantwortlich für die Existenz der ejbRemove, ejbStore, ejbFindByPrimaryKey Methoden. Zusätzlich zu allen notwendigen Bean Life-Cycle Methoden können sämtliche Business Methoden mitverwaltet werden.
Business Methoden
public int ejbHomeGetAge() { return 0; }
public String ejbHomeGetCity() { return new String(); }
98
Ansatz für den Client Code
Person p1 = home.create(1981, 1, 1, "Leonie", "cityA"); Person p2 = home.create(1972, 2, 2, "Lukas", "cityB"); System.out.println("Leonies Alter: " + p1.getAge()); System.out.println("Leonies PK : " + p1.getPrimaryKey()); p1.remove(); Person p3 = home.findByPrimaryKey("Lukas"); System.out.println("Lukas wohnt in : " + p3.getCity()); p3.setCity("cityC"); System.out.println("Lukas neuer Wohnort: " + p3.getCity()); System.out.println("Lukas alter Wohnort: " + p2.getCity()); System.out.println("sind p2 und p3 das gleiche Java Objekt ? "
+ (p2==p3));
System.out.println("Sind p2 und p3 das gleiche EJBObject ? " + p2.isIdentical(p3));
Überlegen Sie sich wie die Ausgabe aussieht bevor Sie Ihre Applikation testen ! Output:
Leonies Alter: ___
Leonies PK: ______
Lukas wohnt in: ________
Lukas neuer Wohnort: ________
Lukas alter Wohnort: ________
sind p2 und p3 das gleiche Java Objekt ? ________
Sind p2 und p3 das gleiche EJBObject ? ________
99
ejb-jar.xml (Ausschnitt)
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN' 'http://java.sun.com/dtd/ejb-jar_2_0.dtd'> <ejb-jar> <display-name>Ejb1</display-name> <enterprise-beans> <entity> <display-name>PersonBean</display-name> <ejb-name>PersonBean</ejb-name> <home>beans.PersonHome</home> <remote>beans.Person</remote> <ejb-class>beans.PersonBean</ejb-class> <persistence-type>Bean</persistence-type> <prim-key-class>java.lang.String</prim-key-class> <reentrant>False</reentrant> <security-identity> <description></description> <use-caller-identity></use-caller-identity> </security-identity> </entity> </enterprise-beans> … <assembly-descriptor> <container-transaction> <method> <ejb-name>PersonBean</ejb-name> <method-intf>Home</method-intf> <method-name>create</method-name> <method-params> <method-param>int</method-param> <method-param>int</method-param> <method-param>int</method-param> <method-param>java.lang.String</method-param> <method-param>java.lang.String</method-param> </method-params> </method> <trans-attribute>Never</trans-attribute> </container-transaction> … </assembly-descriptor> </ejb-jar>
100
16 Servlets
16.1 Vor- und Nachteile dynamischer Web-Inhalte
Es existieren eine Reihe von Lösungen zur Darstellung aktueller (dynamischer) und nutzerspezifischer Daten im Internet, welche sich im Hinblick auf Erstellungs- und Wartungsaufwand sowie in der Performance bei der Bereitstellung von Daten unterscheiden:
- Statische, häufig aktualisierte HTML-Seiten sind eine sehr leistungsfähige Lösung. Jedoch ist der Aktualisierungs- und Wartungsaufwand nicht vertretbar. Eine individuelle Datenpräsentation für jeden Nutzer ist nicht möglich.
- Eine weit verbreitete Lösung sind Server-basierte Programme wie CGI (Common Gateway Interface), die dynamische HTML-Seiten generieren. Diese bieten eine gute Performance, wenn sie nativ (in Maschinencode) implementiert sind, und erlauben eine Datenbankanbindung. Die Performance ist jedoch gering, wenn sie in Skriptsprachen (z.B. Perl) realisiert sind. Das Ablaufen von CGI-Programmen in eigenen Prozessen erzeugt einen hohen Ressourcenverbrauch (Speicher, Ausführungszeit).
- Web-Server-Erweiterungen stellen eine weitere Variante dar, dynamische HTML-Inhalte zu erzeugen, z.B. durch das ISAPI von Microsoft und das NSAPI von Netscape. Diese ermöglichen ebenfalls eine Datenbankanbindung, haben aber den entscheidenden Nachteil, dass sie nicht portabel sind.
- Eine gute Integration mittels Java bietet die Lösung über Applets. Sie ermöglichen eine gute Wartung, besitzen aber wiederum den Nachteil, dass nicht alle Browser Applets voll unterstützen bzw. nur eine bestimmte Version.
- Servlets stellen häufig eine bessere Alternative zu den vorgestellten Technologien dar, um Daten im Internet oder Intranet dynamisch bereitzustellen. Sie bieten die folgenden Vorteile:
- Web-Browser-unabhängig, da nur HTML
- Schnelle Bereitstellung, da innerhalb Prozess als Thread
- Sichere Verarbeitung, da innerhalb eines Prozesses
- Plattformunabhängiger Einsatz, da in Java entwickelt
101
Web-Browser
Servlet-Engine
Web-Server
Applications
16.2 Grundlagen
Über das Java Servlet API, welches unter anderem durch die J2EE installiert wird, können Sie Servlets entwickeln, die dynamische Web-Inhalte zur Verfügung stellen. Servlets können ausser HTML z.B. auch XML, WML, Bild- oder PDF-Dateien bereitstellen. Prinzipiell ist jedes Datenformat als Rückgabe möglich. Da Servlets in Java implementiert werden, können Sie z.B. über JDBC Informationen aus Datenbanken verarbeiten.
16.3 Funktionsweise
Als Client wird ein Web-Browser genutzt. Die benötigten Fähigkeiten des Browsers hängen von der vom Servlet erzeugten Ausgabe ab. So kann ein Servlet reinen HTML-Code nach dem HTML-Standard 2.0 erzeugen, aber auch HTML-Code, der zusätzlich Java Script, CSS Style Sheets und dynamisches HTML enthält.
Über den Web-Browser gibt der Client einen URL an, der ein Servlet auf einem Web-Server startet. Die Anfrage wird zuerst vom Web-Server entgegengenommen. Dieser erkennt, dass es sich um ein Servlet handelt und leitet die Anfrage des Clients an dieses weiter. Das Servlet wertet übergebene Parameter aus und erzeugt eine Ausgabe, z.B. eine HTML-Seite, die Informationen zu einem bestimmten Software-Produkt enthält. Dieses wird an den Web-Server übergeben, der diese wiederum an den Client weiterleitet. Ändern sich nach dem Aufruf des Servlets Produktdaten, werden die aktualisierten Daten bei der nächsten Anforderung verwendet.
Die HTML-Seite wird damit dynamisch erstellt (bei Bedarf) und enthält immer die zu diesem Zeitpunkt aktuellsten Informationen.
http "pull" HTML Der Teil des Web-Servers, der für die Abarbeitung der Servlets zuständig ist, wird häufig auch als Servlet-Engine oder Servlet-Container bezeichnet. Durch die Integration eines Servlets in diesen Container wird es automatisch über die Servlet-Engine dem Web-Server zur Verfügung gestellt und kann von Clients genutzt werden.
102
JVM
Servlet basierter Webserver
Prozess
Auftrag A
Auftrag B Servlet B
Servlet A
Servlet C Auftrag C
16.4 Lebenszyklus Container Shutdown
started destroy Methode
Beim ersten Servlet Aufruf erstellt der Container das Servlet und ruft die init Methode auf
Container ruft die service Methode auf, übergibt die Request Parameter und erneuert (leert) das Response Objekt.
Für jeden neuen Auftrag wird ein neuer Thread erzeugt, der das betreffende Servlet ausführt. Die Threads laufen alle in der gleichen JVM innerhalb des gleichen Prozesses. Dadurch können sie relativ einfach miteinander kommunizieren, und die Verarbeitung von Client-Anfragen ist durch leichtgewichtige Prozesse (Threads) nicht sehr ressourcenaufwendig.
Web-Server
Start
Process Requests
Destroy
103
16.5 Übung ee7 : Servlet – ein Beispiel
Erstellen eines Trivial-Servlets, das einen HTTP Response (Response von Tomcat Web-Server) erzeugt. Erstellen Sie dazu ein TOMCAT Java Project. Das entsprechende Plugin muss dazu installiert sein. Die Installationsanleitung ist im Anhang zu finden.
Wenn durch das Plugin ein TOMCAT Projekt erzeugt wird ist die Verzeichnisstruktur vorgegeben und ein entsprechendes src Verzeichnis und ein Verzeichnis für den build-Path WEB-INF/classes bereitgestellt. Erstellen Sie in einer Packagestruktur \mypackage die Servlet Java Klasse HelloServlet.java und leiten Sie diese von der Superklasse HttpServlet ab: @inRequest Parameters send vom Client (Browser) @inRespons HTML sent to Client (Browser) neue Klasse Erzeugen und definieren Sie die service Methode:
public class HelloServlet extends HttpServlet { public void service( HttpServletRequest inRequest, HttpServletResponse inResponse) throws IOException, ServletException { ... } }
104
ResponseWrite Object instanzieren:
Writer aResponseWriter = inResponse.getWriter();
Inhalt als HTML Code:
inResponse.setContentType("text/html");
gewünschten HTML erzeugen:
aResponseWriter.write(<HTML CODE>);
z.B:
aResponseWriter.write("<html><head>\n"); aResponseWriter.write("<title>1st Servlet</title>\n"); aResponseWriter.write("<body>\n"); aResponseWriter.write("<h1>My first SampleServlet!</h1>\n"); aResponseWriter.write("</body></html>\n");
ResponseWriter Ausgabe:
aResponseWriter.flush();
web.xml (muss im WEB-INF Verzeichnis sein)
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd"> <web-app> <display-name>Servlet Test Application</display-name> <description>Schreibt eine Begrüssung</description> <servlet> <servlet-name>Hello</servlet-name> <servlet-class>mypackage.HelloServlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>Hello</servlet-name> <url-pattern>/start</url-pattern> </servlet-mapping> </web-app>
105
server.xml im Verzeichnis [TOMCAT_ROOT]\conf (wird durch TOMCAT Plugin automatisch erstellt)
<Context path="/ee7" reloadable="true" docBase="C:\sbb\workspace\ee71" workDir="C:\sbb\workspace\ee71\work" />
Ausgabe im Browser Fenster
16.6 Übung ee71 : Web Browser als EJB Client
Erstellen Sie ein Servlet das alle Produkte der Übung ee6 in einem Browser darstellt. Die Klassen des EJB bleiben unverändert. Einzig die Schnittstelle zwischen Servlet Engine (TOMCAT) und EJB-Kontainer (JBoss) muss erstellt werden. Dazu ist es sinnvoll eine Java Klasse als Bean einzusetzen. Die public Methode getProducts() gibt alle Produkte der EJB als Collection retour:
Ansatz
public Collection getProducts() throws Exception { Collection products = null; try { Context ctx = new InitialContext(); home = (ProductHome) PortableRemoteObject.narrow ctx.lookup("Product"),ProductHome.class); products = home.findAllProducts(); } catch (Exception e) { } return products; }
106
Die EJB Bean Klassen sind vorteilhaft im neuen Projekt untergebracht. Die entsprechende Verzeichnisstruktur zeigt alle Source Dateien. Die Client Applikation ProduktClient.java ermöglicht einen direkten Zugriff auf den EJB Kontainer (siehe ee6) während das Bean ProductClientBean.java als Schnittstelle zwischen Servlet und EJB fungiert. Um der TOMCAT VM den Zugriff auf den (REMOTE) EJB-Kontainer von JBoss zu ermöglichen ist das Archiv jbossall-client.jar vom Verzeichnis [JBoss_Home]/client ins /lib Verzeichnis unterhalb des WEB-INF zu stellen.
Browser Ausgabe
107
Web-Browser
JSP-Seite
Web-Server JSP-Engine
Java-Datei (Servlet)
Servlets
17 JSP JavaServer Pages
Sun Microsystems hat die JavaServer Pages (JSP) für die Realisierung der Präsentationsschicht einer Webanwendung entwickelt. Sie integrieren Businesskomponenten und existierende Systeme elegant ins Web. Die JSP-Technik basiert auf dem Java-Servlet-API und dient im Wesentlichen zur einfachen Erzeugung von HTML- und XML-Ausgaben eines Webservers. Wie PHP, ASP oder Perl können Autoren direkt HTML oder XML mit einer Skriptsprache mischen. Natürlich hat sich Sun hier für Java entschieden, um so die Möglichkeiten der vorhandenen robusten und zahlreichen Java-APIs einzubringen. Wie auch Servlets ermöglichen JSP die Erstellung dynamischer Webinhalte mit dem Unterschied das JSP aus statischem HTML und dynamischen JAVA Elementen besteht.
17.1 Grundidee
- Ähnliche Vorgehensweise wie bei Server Side Includes
- Funktionalität und Syntax erinnern an Active Server Pages (ASP).
- Blocks (Scriptlet) werden in statische HTML- Seiten eingefügt.
17.2 Funktionsweise http (http) HTML (HTML) compiler *.class
1. Aufruf HTML
JSP
Eine JSP-Seite ist ein Textdokument und besteht aus:
- HTML- Code
- JSP-Code / JSP-Tags
- Java Anweisungen
Beim ersten Client Request auf eine JSP Seite analysiert die JSP-Engine des Web-Servers das HTML Dokument und erstellt dynamisch ein Servlet. Alle weiteren Client Aufrufe werden dann vom automatisch erstellten Servlet behandelt. Die Umwandlung der JSP-Seite in ein Servlet ist für den Entwickler und auch für den Anwender völlig transparent.
108
17.3 Organisation
Web Applications sind zusammengehörende Webserver-Programmpakete mit einer definierten Hierarchie-Struktur. Sie werden im Webserververzeichnis \webapps als war Archive gespeichert.
17.4 Aufbau von JavaServer Pages
17.5 Kommentare <%<%<%<%-------- ... JSP- Kommentar... --------%>%>%>%>
Beispiel: <%-- Das ist ein JSP Kommentar --%>
17.6 Ausdrücke / Expressions
Eine Expression beginnt mit <%= und endet mit %>. Eine Expression <%= count %> würde übersetzt in out.println(count); und würde den Inhalt der Variablen count in Textform in die Ergebnisseite einfügen.
Beispiel <%= "Hallo" %><br> <%= "zwei + drei : " 2 + 3 %><br> <%= new Date() %><br>
Ausgabe: Hallo zwei + drei : 5 Thu Jan 01 00:08:30 GMT+01:00 2000
JSP-Seite - Ausdrücke - Skriptlets - Deklarationen - Direktiven
Ressourcen - HTML-Datei - JSP-Datei
Datei - ASCII- Datei - JSP-Datei
Tag-Libraries - JSP-Tags
JSP-Seite - Ausdrücke - Skiptlets - Deklarationen - Direktiven
Java Klasse
Java Bean Eigenschaften - setter - getter
109
17.7 Direktiven
Direktiven sind Informationen für die JSP Engine, um die Auswertung der JSP-Seite zu steuern. Eine Direktive hat die Form einer Variablenzuweisung: <%@ type varname="value" %>
- include- Direktiven, um Inhalte anderer Dateien einzufügen:
<%@ include file="head.jsp" %>
- page- Direktiven zur Kontrolle bestimmter Aspekte des Servlets:
<%@ page content-type="text/plain" %>
- content-type: definiert den Content-Type der erzeugten Seite. Default: "text/html":
<%@ page content-type="text/plain" %>
- import: übergibt eine kommaseparierte Liste der Importe:
<%@ page import="java.io.*,java.util.*" %>
- extends: spezifiziert die Elternklasse des Servlets:
<%@ page extends="MyHttpServlet" %>
- implements: übergibt eine kommaseparierte Liste der Interfaces:
<%@ page implements="Serializable"%>
- method: Spezifiziert die Servletmethode, die den generierten Code enthalten und Client- Requests behandeln soll. Default: "service":
<%@ page method="doPost"%>
- language: Spezifiziert die Back-End Scriptsprache Default: "java":
<%@ page language="java"%>
Beispiel:
<%@ page language="java" info="JSP Beispiel" %> <%@ page import="java.util.*" %> <%@ include file="mein_eigenes.jsp" %>
110
17.8 Deklarationen
Deklarationen dienen zur Definition von Methoden und Attributen. Sie werden durch ein Tag <%! ... Deklaration... %> definiert.
Beispiel:
<%! int i = 0 %> <%! private int getNextInt() { i++; return i; } %>
17.9 Skriptlets
Definieren Blöcke zur Programmierung in der eingestellten Sprache. Der Code eines Skriptlets wird erst nach einem Request ausgeführt.
- Scriptlet-Tag wird eingeleitet durch <% und beendet durch %> .
- Ein Scriptlet kann folgende vordefinierte Variablen benutzen:
- request : HttpServletRequest Objekt
- response : HttpServletResponse Objekt
- out : PrintWriter Objekt
- in : BufferedReader
Beispiel:
<%@ page import = "java.util.*" %> <html> <head> <title>Zufallsfarbe</title> </head> <% if(new Random.()nextDouble() > 0.5) { %> <body bgcolor="#FF0000"> <% } else { %> <body bgcolor="#00FF00"> <% } %> </body> </html>
111
generierter Servlet-Code:
out.write("<html>\r\n <head>\r\n "); out.write("<title>Zufallsfarbe></title>\r\n "); out.write("</head>\r\n "); if(new java.util.Random.()nextDouble() > 0.5) { out.write("<body bgcolor="#FF0000">\r\n "); } else { out.write("<body bgcolor="#00FF00">\r\n "); } out.write("</body>\r\n </html>\r\n ");
Alternative zum Beispiel:
<%@ String bg; if (new java.util.Random.()nextDouble() > 0.5) bg = "<body bgcolor=\"#FF0000\">"; else bg = "<body bgcolor=\"#00FF00\">"; %> <%= bg %>
112
17.10 Aktionen
Aktionen sind Anweisungen an die JSP-Engine.
- Aktionen werden verwendet:
- bei der Verwendung von JavaBeans
- beim Erzeugen von Tag Libs (eigener Aktionen)
- zum Einbinden externer Ressourcen
- Integration in JSP-Seite durch XML-Syntax
- Beschreibung durch Attribute
- Beginnt mit <jsp:aktion Tag und wird durch /> Tag abgeschlossen
- Standardaktionen (vordefiniert):
- <jsp:forward page> zur Weiterleitung an eine andere Ressource
- <jsp:plugin> zum Einbinden von Applets
- <jsp:getProperty> liest den Wert einer Bean-Eigenschaft
- <jsp:setProperty> setzt den Wert einer Bean-Eigenschaft
- <jsp:include> zum Einbinden externer Ressourcen
- file="... - zur Übersetzungszeit
- page="... - bei Anforderung
- <jsp:useBean> ermöglicht den Zugriff auf Java-Beans
- Attribute: - id= definiert eindeutiger Name
- scope= definiert Gültigkeitsbereich des Objektes:
- page - innerhalb dieser Seite
- request - Verzweigungen innerhalb dieser Anforderung
- session - innerhalb der Session
- application - innerhalb der Applikation / Web-Anwendung
Beispiel:
<jsp:useBean id="myBean" class="MyBean" scope="page"/>
113
17.11 Fehlerbehandlung Es muss unterschieden werden zwischen:
Übersetzungsfehler
- übermittelt einen HTTP-Fehler 500 (Server Error) an den Client
Ausführungsfehler
- in der entsprechenden catch Anweisung
- nichtbehandelte Laufzeitfehler leiten den Request an die entsprechende URL (Attribut: errorPager) weiter
17.12 Vordefinierte Variablen
Innerhalb einer JSP-Seite sind einige Variablen vordefiniert, die innerhalb von Scriptlets und Ausdrücken verwendet werden können:
application (ServletContext)
speichert Daten, die von mehreren JSP-Seiten genutzt werden können, z.B. DB Zugriff
config (ServletConfig)
übergibt Initialisierungen der Servlet-Konfiguration
exception enthält Exception-Objekt bei einer Exception, falls: <%@ page errorPage = "true" %>
out(PrintWriter) gibt die Daten an die HTML-Seite aus
page(this) stellt die Referenz auf das Servlet während der Laufzeit der JSP-Seite zur Verfügung
pageContext (PageContext)
ermöglicht den Zugriff auf die Attribute der JSP-Seite
request (HttpservletRequest)
enthält Informationen über die aktuellen Anforderungen an die JSP-Seite (Parameter, etc.)
response (HttpServletResponse)
bearbeitet den HTTP Response Header / HTTP Status Code
session (Httpsession) speichert Informationen über die aktuelle Session
114
Browser DB EJB JSP
17.13 Übung ee8: JSP Währungsrechner
Diese Übung beschreibt eine vier Layer Web Anwendung mit JSP's und EJB. Nachfolgend das Deployment Diagramm mit den Komponenten:
CLIENT-TIER WEB-TIER LOGIG-TIER DATA-TIER Browser Tomcat JBoss mySQL HTTP RMI JDBC
localhost:8080/ee8 JavaServerPages MoneyExchange ee Currency.jsp Stateless Session - rates Currency_CDBC.jsp ID,BASECUR,RATE Currency_DBTags.jsp
Die Anwendung soll die Umrechnung eines Betrages von einer Währung in eine andere ermöglichen.
Die Währungen und die entsprechenden Wechselkurse sind in der mySQL DB abgelegt.
Das Stateless Session Bean wird zur Umrechnung (Business Logik) benutzt.
Für die JDBC Anbindung von einem JSP wird die Custem TagLib dbtag.jar benutzt.
Informationen zu dieser TagLib und die notwendigen jar Archive sind erhältlich von http://jakarta.apache.org/taglibs/
Erstellen Sie eine entsprechende Applikation mit JSPs. Benutzen Sie dazu die Referenzbeispiele der lokalen TOMCAT Installation. Ansatz : Browser Window
115
Ansatz: JSP mit DBTags um mySQL DB abzubinden
<%@ taglib uri="http://jakarta.apache.org/taglibs/dbtags"
prefix="sql" %>
<%-- open a database connection --%>
<sql:connection id="conn1">
<sql:url>jdbc:mysql://localhost:3306/ee</sql:url>
<sql:driver>org.gjt.mm.mysql.Driver</sql:driver>
<sql:userId>root</sql:userId>
<sql:password> </sql:password>
</sql:connection>
<%-- get the requestet parameter --%>
<sql:statement id="stmt1" conn="conn1">
<sql:queryselect id from rates order by 2>
<sql:resultSet id="rset1">
<sql:getColumn position="1"/>
</sql:resultSet>
</sql:statement>
<%-- close a database connection --%>
<sql:closeConnection conn="conn1"/>
Ansatz: JSP mit JDBC um mySQL DB anzubinden
<%@ page import = "java.sql.*" %>
<% String con = "jdbc:mysql://localhost:3306/ee"; String user = "root"; String pass = ""; Class.forName("org.gjt.mm.mysql.Driver"); Connection connection =
DriverManager.getConnection(con,user,pass); Statement statement = connection.createStatement();
SQLQuerry = "select basecur,rate from rates where id = " + jdbc_from; rs = statement.executeQuery(SQLQuerry); rs.next(); String base = rs.getString(1); String exch_rate = rs.getFloat(2);
statement.close(); connection.close(); %>
116
Subject interface Principal
SamplePrincipalCredential
SamplePrincipal
SamplePrivateCredential
0..*
0..*
0..* public Credentials
private Credentials
Object
18 J2EE Security
18.1 EJB-Security
- sowenig wie möglich programmatische Sicherheit
- deklarative Sicherheitseinstellungen (Server)
- Authentisierung von Clients
- Kommunikationsformen zwischen Client und Server
- Kommunikation zwischen Containern
- Umsetzung eines rollenbasierten Zugriffsschutzes
- "Security Identity Propagation" innerhalb Systems
- Weiterreichen der Identität eines EJB-Client
- Java Authentication and Authorisation Service (JAAS)
Ein Client wird bei seiner Anmeldung am System zunächst als ein unidentifiziertes Subject angesehen. Nach erfolgreicher Authentisierung werden diesem Client-Subject (u.A. mehrere) sogenannte Principals und Credentials zugeordnet. Principals werden über das java.security.Principal-Interface implementiert und assoziieren das Client-Subject mit einem Benutzernamen oder –konto. Zuordnung von Principals und Credentials an ein Subject:
117
Principals werden später wiederum bestimmten Rollen zugeordnet, die Teil der umzusetzenden Sicherheitspolitik des Systems sind.
- principal-to-role-mapping
- Mapping Tool (z.B Abgleich mit einer Datenbank)
- Principals mit Rollen von Aufruf zu Aufruf weiterpropagiert
- sind über EJBContext abfragbar
- sichere Übertragungsverfahren erforderlich
- SSL (Secure Sockets Layer) bei J2EE–konformen Anwendungen
- SSL bietet Datenverschlüsselung und Überprüfung der Datenintegrität
- Mechanismen um authentisierten Clients Rollen zuzuordnen
- durch das gesamte System zu propagieren
- Container prüft, ob eine Rolle oder Identität Zugriff hatt
Als Option steht allerdings noch die Möglichkeit offen, EJB immer dieselbe Rolle propagieren zu lassen, unabhängig vom auf-rufenden Subject. Ein Bean kann z.B immer die Rolle "Guest" propagieren, um etwa den niedrigsten Sicherheitslevel einzunehmen, egal ob der Aufrufende nun in die Rolle "Customer" oder "Admin" fällt.
… <security-identity> <runAs-specified-identity> <role-name>guest</role-name> </runAs-specified-identity> </security-identity> …
118
18.2 Security Roles Security Rollen werden in verschiedenen Entwicklungsbereichen definiert. Die Bearbeitungsschritte unterscheiden sich u.A. in der Art der Deklarierung im Deploymentdescriptor. Bean Provider (EJB-Entwickler)
- "so wenig wie möglich" Sicherheitsfragen
- wiederverwendbaren Komponenten
- Umsetzung von Geschäftsabläufen
- Sicherheitspolitik nicht hart im Code eingebettet
- über den Container kontrollierbar und konfigurierbar
Ist es nicht möglich, auf die "programmatische Sicherheit" zu verzichten (z.B. Aktionen, die von der Tageszeit oder von einem Konto-Betrag abhängig sind) muss dieses innerhalb des Beans implementiert werden.
Die zur Überprüfung dieser Bedingungen nötigen Werte werden schliesslich erst zur Laufzeit bestimmt und verändert. Dem Programmierer ist es innerhalb des EJB-Codes möglich, die Rollen des aufrufenden Subjects zu ermitteln. Er kann dann im Code den Zugriff direkt und dynamisch kontrollieren. Über das vom Container bereitgestellte EJBContext-Objekt javax.ejb.EJBContext für EJB bzw. HttpServletRequest-Objekt für beispielsweise JSP, können die folgenden Methoden aufgerufen werden:
ejbContext.getCallerPrincipal(); ejbContext.isCallerInRole("admin");
httpServletRequest.isUserInRole("admin"); httpServletRequest. getUserPrincipal();
Die Methode getCallerPrincipal() bzw. getUserPrincipal() hat als Rückgabewert ein Principal-Object, das die Identität des Aufrufenden Subjects beinhaltet. Mit Hilfe von isCallerInRole(String role) bzw. isUserInRole(String role) ist die direkte boolsche Abfrage der Rollenzugehörigkeit möglich.
119
Da vom Standpunkt des Programmierers aus noch keine systemweiten Rollen eingeführt wurden, kann der Programmierer über den Deploymentdescriptor eigene Rollen einführen. Diese Rollen sollten grösstenteils allgemein und logisch auf eine Geschäftsstruktur angewendet werden können. So wird es höchstwahrscheinlich in einem Bank-EJB, das Kontendaten abruft, eine Rolle "Kunde" bzw. "Angestellter" oder "Admin" geben. Es müssen dazu im Deploymentdescriptor Rollenreferenzen eingeführt werden.
Der Entwickler erstellt damit vorerst logische Rollen, die später vom Assembler den tatsächlichen Rollen im System zugeordnet werden.
… <security-role-ref> <description>administrators role</description> <role-name>admin</role-name> </security-role-ref> …
Später ist es möglich, die letztendlichen Rollen des Systems im Deploymentdescriptor auf diese logischen Rollen des Programmierers abzubilden. Application Assembler
- EJB-Komponenten zusammenzustellen
- verkaufsfertig zu konfigurieren
- deklariert auf Einsatzzweck zugeschnittene Rollen
- werden den Rollen des Bean-Providers zugeordnet
Ohne Zuordnung der Rollenreferenzen auf Rollen des Systems sind diese Rollenreferenzen ohne Bedeutung. Diese erzwungene Zuordnung von logischen Rollen auf die tatsächlich verwendeten Rollen verhindert, dass der Programmierer nur ihm bekannte Rollen einführen kann. Eine geheim deklarierte Rolle wie etwa "Programmierer" müsste also auch vom Assembler/Deployer deklariert und abgesegnet werden, um im System wirken zu können. Somit wird diese Art von programmatischen Hintertürchen vermieden.
Weiterhin muss der Assembler festlegen, welche spezifischen Methoden der einzelnen EJB von welcher Rolle aufgerufen werden dürfen. Dies geschieht mittels method permissions.
120
Diese Permissions werden für jedes Bean einzeln vergeben. Alle diese Schritte manifestiert der Assembler wieder im Deploymentdescriptor.
… <assembly-descriptor> <security-role> <description> This role includes guests who are allowed limited access </description> <role-name>guest</role-name> </security-role> <security-role> <description> This role includes the customers </description> <role-name>customer</role-name> </security-role> <security-role> <description> This role should be assigned to the personnel (authorized to perform administrative functions) </description> <role-name>staff</role-name> </security-role> … </assembly-descriptor> …
Der nächste Auszug zeigt die Einführung der method-permissions für ein einzelnes Bean. Zu den jeweiligen Rollen (guest, customer, staff) werden die für sie erlaubten Methoden deklariert.
Innerhalb des <method-name>-Elements können die folgenden drei Werte stehen:
- der Name der erlaubten Methode
- der Name und eventuelle Parameter, um sie eindeutig zu identifizieren
- ein *, um alle Methoden für eine Rolle freizugeben
Das <method-intf> Element definiert das entspechende Interface :
- Home, Remote, LocalHome oder Local
121
<method-permission> <role-name>guest</role-name> <method> <ejb-name>EJBSecurity</ejb-name> <method-intf>Home</method-intf> <method-name>*</method-name> </method> <method> <ejb-name>EJBSecurity</ejb-name> <method-intf>Remote</method-intf> <method-name>getPrincipalInfo</method-name> </method> </method-permission> … <method-permission> <role-name>staff</role-name> <method> <ejb-name>EJBSecurity</ejb-name> <method-name>*</method-name> </method> <method-permission>
Deployer
- eigene Rollen zum System
- gute Spezifikation des Assemblers
- Rollenreferenzen des Programmierers
Es ist Aufgabe des Deployers, das auf seine Bedürfnisse angepasste Sicherheitssystem zu administrieren.
- Zuordnung von Benutzern auf Rollen festgelegen
- Principal-to-Role-Mapping pro Applikation im Container
- Deploymentdescriptor nicht applikationsübergreifend
Pro Applikations-jar-File werden die Rollen deklariert, die für jede Anwendung anders sein können und individuell "gemappt" werden müssen.
Principal-to-Role-Mapping <security-role-ref> <role-name>admin</role-name> <role-link>staff</role-link> </security-role-ref>
122
18.3 Client-Tier Sicherheit
18.3.1 ApplicationClients
Seit der Version 2.0 ist es für J2EE-kompatible Server verpflichtend, eine Unterstützung für den Java Authentication and Authorisation Service (JAAS) zu bieten. Damit ist es möglich, Application-Clients zu authentifizieren. JAAS implementiert eine Version des Pluggable Authentication Module (PAM) Frameworks und erlaubt den Einsatz von eigens entwickelten Loginmodulen. Diese Loginmodule werden auf Seiten des Clients eingesetzt. So ist es verschiedenen Applicationclients möglich, auch verschiedene Loginvarianten zu unterstützen.
- Name/Passwort-Dialoge
- externer Hardware und Smartcards
- Zertifikate weiterreicht
Die Loginmodule selbst steuern den Loginvorgang und sammeln Authentisierungsdaten über sogenannte Callbackhandler. Darüber werden auch Satusinformationen vom Server an den Client zurückgereicht. Die jeweilige Applikation auf Client-Seite muss dazu dem Server u.A. mindestens eine Klasse anbieten, die das Interface javax.security.auth.callback.CallbackHandler implementiert. Durch die Benutzung über solche Interfaces bleibt die Implementierung von Loginmodulen austauschbar.
Ist der Einsatz von JAAS nicht erwünscht, kann der Container den Vorgang der Authentisierung über voreingestellte Mechanismen komplett selbst übernehmen. Die Vorgehensweise dabei ist allerdings abhhängig von der Implementierung.
Dazu ist die Clientsoftware entsprechend einzurichten. MyCallbackHandler, die javax.security.auth.callback.CallbackHandler implementiert.
MyCallbackHandler handler = new MyCallbackHandler(name, pwd); LoginContext lc = new LoginContext("default", handler); lc.login();
123
18.3.2 WebClients
Die Spezifikation erlaubt prinzipiell drei Arten von Webclient-Authentisierung, die über den Server einstellbar sein müssen:
- http bzw. http über SSL (https) – Es werden http-Formulare mit einfacher Login/Passwort-Abfrage benutzt.
- formular – Agiert auch über http/https. Diese Einstellung erlaubt jedoch eigens definierte und umfangreichere Abfragen. Es können Mechanismen wie Cookies bzw. Session-Ids benutzt werden.
- client-certificate – Erlaubt die Authentifizierung von Webclients über Zertifikate. Für diese Option muss zur gegenseitigen Authentisierung (mutual authentication) natürlich auch auf Client-Seite ein X.509-Certificate installiert sein.
Der im Mid-Tier genauer beschriebene rollenbasierte Zugriffsschutz wird auch bei Webapplikationen vom Container übernommen. Es sind auch bei Webanwendungen programmatische statt vom Container übernommene Sicherheitsabfragen möglich:
Über das HttpServletRequest Interface kann mit der Methode isUserInRole festgestellt werden, ob der Benutzer in einer bestimmten Rolle ist.
Um die Identität (in Form eines java.security.Principal) zu erhalten, kann die Methode getUserPrincipal verwendet werden. 18.4 JNDI Sicherheit
- Client erhält nach JNDI Anfrage einen Verweis auf ein EJB-HomeInterface
- Client generiert Verweis auf Remote-Interface des EJB
Gelänge es, einem Client oder dem Container einen falschen JNDI-Namespace zuzuspielen, könnte man ihnen darüber auch falsche Home-Interfaces und folglich falsche und böswillige Objektreferenzen zukommen lassen. Authentisierungsdaten könnten so z.B durch spoofing eines Loginvorgangs abgefragt werden. Andererseits muss auch der JNDI-Dienst gesichert werden, da sonst auch unberechtigte Server Einträge in dem Dienst vorgenommen werden können.
Die J2EE-Spezifikation rät zur Sicherung der Name-Services und zur Verwendung von "CORBA specified naming services" (Cos-Naming) über eine sichere Verbindung. Die Umsetzung allerdings ist den Serverentwicklern überlassen, da auch die verschiedenen CORBA-
124
Implementierungen nicht immer eine Sicherung ihrer Namensdienste unterstützen. Im folgenden sei eine Client-Initialisierung des JNDI-Kontextes exemplarisch dargestellt:
… // Set up the environment properties Hashtable h = new Hashtable(); h.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.cosnaming.CNCtxFactory"); h.put(Context.PROVIDER_URL, "iiop://localhost:3700"); h.put(Context.SECURITY_PRINCIPAL, "username"); h.put(Context.SECURITY_CREDENTIALS, "password"); // Get an InitialContext return new InitialContext(h); …
18.5 Realms
Bei der J2EE-Spezifikation werden Realms als eine Gruppe von Benutzern definiert, die alle mit dem selben Mechanismus authentisiert werden (ein Realm wäre etwa "certificate" und "ldap", wie beim Sun ONE Application Server). Realms werden auch manchmal als "security policy domains" bezeichnet. Innerhalb dieser Realms gelten dann die Zuordnungen von Rollen an Benutzer. Bei der Verwendung verschiedener Loginverfahren über JAAS ist es möglich, das System in Realms für jedes Verfahren einzuteilen. Das ist aber abhängig von der jeweiligen Implementierung, ebenso wie z.B. Einteilungen in LDAP-Realms und Betriebssystem-Realms.
18.6 Legacy Tier
Es gibt zwei Möglichkeiten, den Container, bzw. die Beans die in ihm laufen, gegenüber Legacy-Systemen wie etwa Datenbanken oder Gateways zu authentisieren. Die Systeme an sich erfordern meist die Eingabe eines Namen und Passworts oder benutzen andere Loginvarianten. Die beiden Möglichkeiten sind "Container-Managed" und "Bean-Managed".
125
18.7 Declarative vs Programmatic Security
Web Tier EJB Tier declarativ programmatic
Zugriffskontrolle Web
Resources Bean Methods
Deployment Descriptor
Programm
Deklaration web.xml ejb-jar.xml Deployment Descriptor
Programm
Umsetzung Web
Container EJB Container Container Programm
Codierung Servlet / JSP EJB Bean "all or
nothing" Logikbasiert
18.8 J2EE Security Architecture
18.9 Role Mapping
JBOSS (Vendorspecific)
J2EE
User: "admin"
User: "user"
User: "guest"
Principal: admin
Principal: user
Principal: guest
Role: staff
Role: customer
Role Reference: staff
Role Reference: customer
126
18.10 ejb-jar.xml Security Elemente
Die folgende Graphik zeigt die Security Related Elements des ejb-jar.xml Deployment Descriptors.
18.11 Übung ee9 : J2EE Security
Erstellen Sie ein ApplicationClient der sich am JBoos Applikationsserver mittels username / password identifiziert und anschliessend seiner Security Policy entsprechende Businessmethoden aufruft:
Ansatz: SecurityTestClient
public class SecurityTestClient { public static void main(String args[]) throws Exception {
/* username, password, role * admin admin staff * user user customer * guest guest guest */
String name = "admin"; String pass = "admin"; String role = "staff";
char[] password = pass.toCharArray();
System.setProperty("java.security.auth.login.config", "[JBoss-Home]/client/auth.conf");
127
try { AppCallbackHandler handler = new
AppCallbackHandler(name, pass);
LoginContext lc = new LoginContext("SecurityTest", handler); lc.login();
Properties env = new Properties(); env.load(new FileInputStream("resources/jndi.properties")); InitialContext initial = new InitialContext(env);
SecurityTestHome home = (SecurityTestHome) initial.lookup("ejb/Security");
SecurityTest st = home.create();
System.out.println("Principal : " + name _ + " wants to getPrincipalInfo : " _ + st.getPrincipalInfo(role)); System.out.println("Principal : " + name _ + " wants to doSomething : " _ + st.doSomething(role)); st.remove(); lc.logout(); } catch (Exception e) { System.err.println("Failed :"); Throwable t = e; while (t != null) { System.err.println("Type: " + t.getClass().getName()); System.err.println("Message: " + t.getMessage()); t = t.getCause(); } } } }
18.11.1 Übung ee91 : EJB Security
Die Security Policies für die "user" und die "roles" werden in zwei text-basierten Dateien abgebilded und im root Verzeichnis in der JAR Datei bereitgestellt:
128
users.policies
admin=admin user=user guest=guest
roles.properties
admin=staff user=customer guest=guest
Die entsprechenden Business Methoden werden declarativ im Deployment Descriptor ejb-jar.xml definiert:
ejb-jar.xml
<method-permission> <role-name>customer</role-name> <method> <ejb-name>EJBSecurity</ejb-name> <method-intf>Home</method-intf> <method-name>*</method-name> </method> <method> <ejb-name>EJBSecurity</ejb-name> <method-intf>Remote</method-intf> <method-name>doSomething</method-name> </method> </method-permission>
Die programmatische Sicherheit kommt im Sourcecode zur Geltung:
Business Methode doSomething der SecurityTestBean.java
public String doSomething(String role) throws FailedLoginException { Principal p = sc.getCallerPrincipal(); if (sc.isCallerInRole(role)) { return "Principal (" + p + ") identifies as Role \"" _ + role + "\""; } else { throw new FailedLoginException("wrong Principal / wrong Role"); } }
129
19 Transaktionen
Allgemein der kleinste, unteilbare und daher an einem Stück ununterbrochen abzuarbeitende Prozess einer Anwendung. Transaktionen werden daher vollständig oder gar nicht abgearbeitet. Speziell ist häufig eine logisch zusammenhängende Folge von Operationen in einer Datenbank gemeint, die die Datenbank von einem konsistenten in einen weiteren konsistenten Zusand überführt. 19.1 Transaktionskonzepte
Die vier Eigenschaften von Transaktionen bezeichnet man als ACID-Prinzip:
Atomicity (Atomarität = unteilbar): Eine Transaktion wird entweder vollständig oder gar nicht ausgeführt. Resultate teilweise ausgeführter Transaktionen sind nie nach aussen sichtbar.
Consistency (Konsistenz = zusammenhaltend): Eine Transaktion bewirkt immer den Übergang von einem konsistenten Datenbankzustand in einen anderen konsistenten Datenbankzustand. Falls durch eine Transaktion Integritätsbedingungen verletzt werden, wird die Transaktion abgebrochen und die Datenbank im Ursprungszustand belassen.
Isolation (Isolation = getrennt): Parallel ablaufende Transaktionen sehen nichts von Parallelität. Jede Transaktion sieht während ihrer Ausführung stets nur einen konsistenten, während der Transaktion von aussen unveränderten, Datenbankzustand.
Durability (Dauerhaftigkeit = persistent): Sobald eine Transaktion beendet ist, ist der von ihr bewirkte Zustandsübergang dauerhaft. Die durch die Transaktion vorgenommenen Änderungen können nicht mehr verschwinden.
19.1.1 Lokale und verteilte Transaktionen
Transaktionen, bei deren Durchführung nur lokale Daten betroffen sind und nicht mehrere Ressourcen verwendet werden müssen, werden als lokale Transaktionen (local transactions) bezeichnet.
130
Wenn dagegen mit mehreren Daten, die auf verteilten Systemen liegen, gearbeitet wird, spricht man von einer verteilten Transaktion (distributed transaction) oder einer globalen Transaktion (global transaction).
Um eine globale Transaktion durchzuführen, muss sie in Teil-transaktionen aufgeteilt werden.
In dem Sequenzdiagramm startet die Applikation (BOT = begin of transaction) zunächst eine Teil-transaktion 1 auf der ersten Datenbank und ändert den Wert A. Von Teiltransaktion 1 erfolgt eine positive Rückmeldung. Daraufhin startet die Applikation eine zweite Teiltransaktion auf der zweiten Datenbank und ändert ebenfalls den Wert A, worauf sie auch hier eine positive Rückmeldung erhält. Nun kann an die erste Datenbank ein Commit übermittelt werden und die Teiltransaktion 1 ist beendet. Das Gleiche geschieht mit der zweiten Teiltransaktion, und damit wurde die gesamte Transaktion positiv abgeschlossen.
19.1.2 Zwei Phasen Commit
Allerdings kann es zu inkonsistenten Zuständen kommen, falls die Datenbank, die für Teil-transaktion 2 zuständig ist, vor dem Empfang der zweiten Commit-Anweisung ausfällt. Beim Neu-start der Datenbank wird diese die Teiltransaktion 2 und damit auch den Wert A zurücksetzen, weil sie nicht korrekt beendet wurde. Dadurch haben die Datenbanken unterschiedliche Daten für Wert A.
Um solche Fehlerfälle abzufangen, bedarf es erweiteter Protokolle, z.B. des Zwei-Phasen-Commit-Protokolls (2PC-Protokoll). In der ersten Phase teilt die Applikation den Ressourcen der Teiltransaktionen mit, dass sie sich vorbereiten sollen ("Prepare-to-Commit"). Wenn die Antworten ("Ready to Commit") aller Knoten positiv waren, wird die zweite Phase eröffnet, und die Applikation sendet ein Commit an die Knoten ("Commit Phase").
131
19.2 Java Transaction API und Java Transaction Service
- JTS spezifiziert Implementierung eines Transaktionsmanagers
- bietet Java Transaction API als Programmierschnittstelle an
Damit können Programmierer, Applikationsserver und transaktionsunterstützende Ressourcen den Dienst verwenden. Für jede transaktionsunterstützende (XA-kompatible) Ressource wird ein Ressourcenmanager eingesetzt.
Die Koordination von Transaktionen über die Grenzen eines Ressourcenmanagers hinaus wird durch den Transaktionsmanager realisiert und hat nun die folgenden Aufgaben:
- Initiierung von Start, Abbruch und Abschluss von Transaktionen.
- Über Transaktionsmanager erfolgt die Realisierung globaler, verteilter Transaktionen. Für eine globale Transaktion werden die beteiligten Ressourcen von dem Transaktions-manager verwaltet.
- Der erfolgreiche Abschluss globaler Transaktionen wird mittels des Zwei-Phasen-Commit-Protokolls koordiniert.
- Die Kooperation eines Transaktionsmanagers mit anderen Transaktionsmanagern kann über CORBA erfolgen.
Der Zugriff auf einen Java Transaction Service erfolgt mit der Java Transaction API, die aus drei Schnittstellen besteht: javax.transaction.UserTransaction:
- begin(), rollback() commit() starten, zurückführen oder commited
- getStatus() Status abfragen
- setTransactionTimeout() Timeout setzen
- setRollbackOnly() Transaktion auf jeden Fall beenden
javax.transaction.TransactionManager:
- Methoden der UserTransaction
- suspend() Transaktion vorübergehend angehalten
- resume() wieder aufnemen
132
Java Client Anwendung oder Applikationsserver
Transaktions- Manager DB
DB
JMS- Server
Ressourcen- Manager
Ressourcen- Manager
Ressourcen- Manager
javax.transaction.Transaction und javax.transaction.xa.XAResource:
- alle Methoden aus UserTransaction
- enlistResource() Registrieren
- delistResource() Deregistrieren einer Ressource innerhalb Transaktion
enlistResource() erhält als Parameter einerseits die Ressource selbst – als Objekt, das die XAResource-Schnittstelle implementiert – und andererseits einen als Objekt typisierten Parameter, der den Ressourcenmanager identifiziert und mit diesem interagiert, um das Zwei-Phasen-Commit durchzuführen.
Die XARessource-Schnittstelle ist ein Java-Mapping des XA-Standards nach der X/Open-Spezifikation. Die wichtigsten Methoden dieser Schnittstelle sind:
- der Beginn der Ausführung mit der Zuordnung zu einer globalen
Transaktion durch Aufruf von start()
- das Einholen der Entscheidung über ein Commit mittels prepare()
- das Beenden der Ausführung mit end()
- das Abschliessen / Zurücksetzen der Transaktion mit commit() / rollback()
JDBC
JMS
133
19.3 User-Transaktionen
Um sicherzustellen, dass die Transaktionen einer Applikation den ACID-Prinzipien folgen, sind sorgfältiges Entwerfen und Implementieren nötig. Jede nachträgliche Änderung kann teuer werden. Um die Implementierung zu unterstützen, hat die EJB-Spezifikation zwei Typen von Transaktionsverwaltung vorgesehen:
- implizite (container-managed transactions) Transaktionssteuerung
- explizite (bean-managed transactions) Transaktionssteuerung
In allen EJBeans ausser den Entity-Beans kann zwischen den beiden Transaktionssteuerungen gewählt werden. Bei den beiden Entity-Beans ist seit der Spezifikation 2.0 nur noch die implizite Transaktionssteuerung möglich: Wenn eine Entity-Bean in einer Client-Transaktion aufgerufen wird, werden erst einmal mit ejbLoad die Daten von der Datenbank geladen. Es werden entsprechende Locks in der Datenbank gesetzt und die Entity-Bean mit den Werten der Datenbank "gefüllt". Dann werden ein oder mehrere Geschäftsmethoden aufgerufen, und dann wird die Client-Transaktion "commited". Daraufhin ruft der Container ejbStore auf, um die Datenbank mit den neuen Werten zu aktualisieren. Die Locks in der Datenbank werden wieder entfernt. Die Transaktion in der Entity-Bean sollte also die ejbLoad, die Geschäftsmethoden und ejbStore umfassen.
Wenn nun Bean-Managed-Transactions (BMT) verwendet werden würde, müsste in ejbLoad mit begin() die Transaktion begonnen und in ejbStore mit commit() beendet werden. Das Problem dabei ist, dass der Container die Methoden aufruft und nicht der Client. Dadurch kann nicht garantiert werden, dass die Methoden auch tatsächlich in dieser Reihenfolge aufgerufen werden. Es könnten mehr Transaktionen begonnen als beendet werden. Infolge der Container-Verwaltung sind BMT in Entity-Beans nicht erlaubt. Das Element <transaction-type> im Deployment-Deskriptor legt fest, welche Transak-tionsverwaltung verwendet werden soll. Der Wert ist entweder Bean oder Container.
134
19.3.1 Bean Managed Transaction
Mit Hilfe der BMT, ist es möglich, Transaktionen explizit zu steuern. Dies kann umfassen:
- Transaktionen mit anderen EJBeans
- Transaktionen mit Datenbanken über JDBC
Es kann nötig sein, die Transaktionssteuerung selbst zu übernehmen, wenn z.B. einige Ressourcen nicht vom Transaktions-Manager gesteuert werden können. BMT können jedoch keine verschachtelten Transaktionen verwalten.
Um die explizite Transaktionssteuerung zu ermöglichen, unterstützt EJB die Java Transaction API (JTA). Die darin enthaltene Klasse UserTransaction stellt eine Schnittstelle zum Transaktions-Manager zur Verfügung, mit der der Gültigkeitsbereich einer Transaktion verwaltet werden kann. In dieser Schnittstelle können folgende Methoden aufgerufen werden:
- begin() leitet eine neue Transaktion ein Der Thread, der die neue Transaktion erzeugt hat, wird mit dieser verbunden. Falls innerhalb dieser Transaktion Beans verwendet werden, die bereits existierende Transaktionen unterstützen, wird die Transaktion an sie weitergereicht.
- commit() beendet aktuelle Transaktion
- rollback() Transaktion zurückführen Um im Falle eines Fehlers die Transaktion wieder zurückzuführen und die schon durchgeführten Aktualisierungen rückgängig zu machen.
- setRollBackOnly() merkt Transaktion für Zurückführen vor Die Transaktion wird nach ihrer Beendigung in jedem Fall zurückgeführt, ob sie nun erfolgreich war oder nicht.
- setTransactionTimeout(int seconds) Lebenszeit festlegen Mit dieser Methode wird festgelegt, wie lange die Transaktion existieren darf, bevor ein Timeout auftritt. Falls diese Methode nicht verwendet oder der Wert 0 übergeben wird, gilt der Default-Wert des Transaktions-Managers. Diese Methode muss unmittelbar nach begin() aufgerufen werden.
- getStatus() Abfrage des aktuellen Transaktions-Status Liefert einen Integer-Wert zurück, der mit denen in der Schnittstelle javax.transaction.Status definierten Konstanten verglichen werden kann.
135
Um eine BMT verwenden zu können, wird das entsprechende <transaction-type> Tag mit Bean beschrieben.
<transaction-type>Bean</transaction-type>
Dann wird eine Verbindung zum Transaktions-Manager des EJB-Server hergestellt und über den Container ein UserTransaction-Objekt geholt.
Context jndiContext = new InitialContext(); UserTransaction trans = (UserTransaction) jndiContext.lookup("java:comp/UserTransaction"); ...
oder:
SessionContext ejbContext; UserTransaction trans = ejbContext.getUserTransaction(); trans.begin(); ... trans.commit();
<interface> UserTransaction:
interface UserTransaction { void begin(); void setTransactionTimeout(int seconds); void commit(); void rollback(); void setRollbackOnly(); int getStatus(); }
Die möglichen Werte der Methode getStatus finden sich als Konstanten in der Schnittstelle javax.transaction.Status.
136
19.3.2 Container-Managed-Transactions
- Steuerung der Transaktionen durch Container
- Vorteil kein zusätzlicher Code in Geschäftslogik
- alles innerhalb try-catch-Blocks gehört zur Transaktion
Falls bei der Ausführung des Blocks ein Fehler auftritt, werden alle schon durchgeführten Anweisungen rückgängig gemacht. Diese Methode hat allerdings den Nachteil, dass keine verschachtelten Transaktionen möglich sind. Ein weiterer Aspekt ist, dass das Verhalten der Bean geändert werden kann, ohne die Implementierung ändern zu müssen. Zusätzlich wird das Risiko einer fehlerhaften Verwendung von Transaktions-Protokollen wie JTA reduziert. Das Transakionsverhalten kann über den Deployment-Deskriptor gesteuert werden, der die Transaktions-Attribute für die gesamte Bean oder für jede Bean-Methode einzeln festlegt. Ein Beispiel soll den Unterschied verdeutlichen:
CMT auf Bean Ebene
<assembly-descriptor> <container-transaction> <method> <ejb-name>AdressBean</ejb-name> <!-- Hiermit werden alle Methoden angesprochen --> <method-name>*</method-name> </method> <!-- Jetzt kommt das Transaktions-Attribut. Es kann die Werte "NotSupported", "Supports", "Required", "RequiresNew", "Mandatory" oder "Never" bekommen. --> <!-- Alle Methoden bekommen das Attribut "Required". --> <trans-attribute>Required</trans-attribute> ...
Wie man dagegen einzelne Methoden unterschiedlich konfigurieren kann, soll der folgende Ausschnitt aus einem Deployment-Descriptor zeigen:
CMT auf Methoden Ebene
<container-transaction> <method> <ejb-name>AdressBean</ejb-name> <method-name>getVorname</method-name> </method> <trans-attribute>Required</trans-attribute> </container-transaction>
137
<container-transaction> <method> <ejb-name>AdressBean</ejb-name> <method-name>getVorname</method-name> <method-param>format</method-param> </method> <trans-attribute>Required</trans-attribute> </container-transaction> ...
Mit dem Eintrag <method-name> können überladenen Methoden unterschiedliche Trans-aktions-Attribute zugewiesen werden:
- Required: immer in einer Transaktion laufen Falls schon eine Transaktion läuft, wird die Methode ein Teil von ihr, andernfalls wird eine neue Transaktion vom Container gestartet. Die neue Transaktion umfasst allerdings nur die Required-Bean und die von ihr benutzten Beans. Wenn die Required-Methode beendet ist, wird auch die Transaktion beendet.
- RequiresNew: neue Transaktion starten Wenn der aufrufende Client bzw. Bean selbst zu einer Transaktion gehört, wird diese ausgesetzt, bis die "RequiresNew"-Methode beendet ist.
- Supports: zur laufenden Transaktion einbeziehen Jedoch nur wenn dieser eine Transaktion hat. Falls der Aufrufer zu keiner Transaktion gehört, wird auch keine neue Transaktion vom Container erzeugt.
- Mandatory: gehört immer zur Transaktion des Clients Das entspricht dem Gegenteil des Never-Attribut. Falls der aufrufende Client mit keiner Transaktion verbunden ist, tritt eine Exception auf.
- NotSupported: erzeugt/unterstützt keine Transaktionen Falls der aufrufende Client Teil einer Transaktion ist, wird diese Transaktion während der Ausführung der Methode ausgesetzt (unterbrochen).
- Never: darf nicht in eine Transaktion einbezogen werden Falls ein Client innerhalb einer Transaktion diese Methode aufrufen sollte, tritt eine Exception auf. Wenn man also vermeiden möchte, dass die Clients, die diese Methode aufrufen, Transaktionen verwenden, dann kann man das mit diesem Attribut erreichen.
138
Allerdings lassen sich nicht alle Transaktions-Attribute mit allen Beans nutzen. Die folgende Tabelle zeigt, welche Kombinationen möglich sind:
Transaktions-Attribut
Stateless Session Bean
Stateful Session Bean
Entity Bean
Message Driven Bean
Required ���� ���� ���� ����
RequiresNew ���� ���� ���� ����
Mandatory ���� ���� ���� ����
Supports ���� ���� ���� ����
NotSupported ���� ���� ���� ����
Never ���� ���� ���� ����
Für CMP EntityBeans ist es sinnvoll nur Required, RequiresNew oder Mandatory als Transaktionsattribut zu verwenden, damit die Datenbankzugriffe zuverlässig bleiben.
Auf einer Collection, die von einem HomeInterface einer CMP Enitity-Bean geliefert wird, darf man nur innerhalb einer Transaktion zugreifen, und zwar derjenigen, in der sie erzeugt wurde. Für solche Methoden des HomeInterface soll man daher nicht RequiresNew als Transaktionsattribut verwenden.
Beim Auftreten einer Exception wird eine laufende Transaktion abgebrochen. Darunter versteht man eine RuntimeException (insbesondere EJBException). Ausserdem vernichtet in diesem Fall der EJB-Container die Bean, weil er sich nicht mehr sicher ist, dass ihr Inhalt noch brauchbar ist. Der Aufrufer erhält eine RemoteException bzw. EJBException, die in irgendeiner Form als Fehlermeldung ausgegeben wird.
Alle Ausnahmen ausser RuntimeExceptions und RemoteExceptions (einschliesslich Unterklassen) zählen als ApplicationExceptions. Sie werden an den Aufrufer weitergegeben. Wenn möglich, wird die Transaktion fortgeführt. Ob dies nicht gelungen ist, kann man mit dem Methodenaufruf context.getRollbackOnly() herausfinden; context ist vom Typ EJBContext. Mit context.setRollbackOnly() kann man den erfolglosen Abbruch der laufenden Transaktion erzwingen.
139
19.3.3 JDBC Transaktionen
Die JDBC-Transaktionen sind Transaktionen, die vom Transaktions-Manager des Datenbank-managementsystems (DBMS) verwaltet werden. Mit Hilfe der java.sql.Connection-Schnittstelle ist es möglich, Datenbank-Transaktionen selbst zu steuern. Der standardmässig eingeschaltete AutoCommit-Modus sollte vorher mit setAutoCommit(false) ausgeschaltet werden.
Der Beginn einer Transaktion erfolgt implizit mit der ersten SQL-Anweisung. Es können dann weitere SQL-Anweisungen folgen, bis schliesslich die gesamte Transaktion mit commit() bestätigt oder mit rollback() zurückgenommen wird. Beispiel con.setAutoCommit(false); stmt.executeUpdate("INSERT INTO Tabelle VALUES (Wert1,...);"); if (error) { con.rollback(); } else { con.commit(); }
19.4 Übung ee10 : EJB Transaction
Wie bereits erwähnt laufen alle Methodenaufrufe einer Enterprise Bean innerhalb einer Transaktion. Normalerweise erstreckt sich die Transaktion sogar über entfernte Methodenaufrufe (nicht aber auf die Benutzung von Webdiensten). Wenn eine Methode eine Exception auslöst (bzw. eine Nachricht, als Folge davon, nicht bestätigt wird), wird die Transaktion erfolglos abgebrochen (rollback). Nur wenn alles gut geht, wird die Transaktion erfolgreich abgeschlossen (commit).
Das liegt daran, dass wir im Deployment-Descriptor bisher immer Folgendes geschrieben haben: <assembly-descriptor> ... <container-transaction> ... <trans-attribute>Required</trans-attribute> </container-transaction> ... </assembly-descriptor>
140
mögliche Werte für das Tag <trans-attribute>:
Never : Die Methoden dürfen nicht im Rahmen einer Transaktion aufgerufen werden.
NotSupported : Es ist egal, ob die Methoden im Rahmen einer Transaktion aufgerufen werden. In jedem Fall werden die Methodenaufrufe ausserhalb einer Transaktion abgewickelt.
Supports : Falls die Methoden im Rahmen einer Transaktion aufgerufen werden, werden diese Transaktionen weitergeführt, andernfalls werden die Methodenaufrufe eben ausserhalb einer Transaktion abgewickelt.
Required : Falls die Methoden im Rahmen einer Transaktion aufgerufen werden, werden diese Transaktionen weitergeführt, andernfalls wird eine Transaktion begonnen.
RequiresNew : Es ist egal, ob die Methoden im Rahmen einer Transaktion aufgerufen werden. In jedem Fall wird eine (Unter-) Transaktion begonnen. (Dies kann ziemlich aufwendig werden.)
Mandatory : Die Methoden müssen im Rahmen einer Transaktion aufgerufen werden.
19.4.1 Transaktionssteuerung
Erstellen Sie eine Bankkontenverwaltung mit einem BMP Entity Bean, das einen Übertrag von einem Konto A zu einem Konto B ermöglicht. Negative Saldos auf einem der Konten soll dabei mit einer entsprechenden Transaktionssteuerung unterbunden werden.
Ein Konto definiert sich durch eine id einem owner und einer balance
mysql> desc accounts; +---------+-------------+------+-----+---------+-------+ | Field | Type | Null | Key | Default | Extra | +---------+-------------+------+-----+---------+-------+ | id | char(3) | | PRI | 0 | | | owner | varchar(50) | YES | | NULL | | | balance | double | YES | | NULL | | +---------+-------------+------+-----+---------+-------+
141
SQL Skript : accounts Table
CREATE TABLE `accounts` ( `id` char(3) NOT NULL default '0', `owner` varchar(50) default NULL, `balance` double default NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1; # Dumping data for table 'accounts' INSERT INTO accounts VALUES("1","Client 1","100"); INSERT INTO accounts VALUES("2","Client 2","200");
Ansatz: BankClient.java
final Bank bank = home.create(); final Account a1 = bank.getAccount("1"); final Account a2 = bank.getAccount("2"); printAccount(a1); printAccount(a2); final double amount = 100;
Thread t1 = new Thread() { public void run() { try { System.out.println("Thread: transfer 1 -> 2 : " + amount); bank.transfer(a1, a2, amount); System.out.println("Thread finished"); } catch (Exception e) {e.printStackTrace();} } };
t1.start(); Thread.sleep(2000);
printAccount(a1); printAccount(a2);
Output: ID : 1 OWNER : Client 1 BALANCE : 100.0
ID : 2 OWNER : Client 2 BALANCE : 200.0 Thread started : transfer 1 -> 2 : 100.0 Thread finished ID : 1 OWNER : Client 1 BALANCE : 0.0 ID : 2 OWNER : Client 2 BALANCE : 300.0
142
Wird bei einem Übertrag der Saldo des "Client 1" kleiner als Null so soll die Transaktion nicht durchgeführt und die bereits ausgeführten Datenänderungen rückgängig gemacht werden: Ansatz: BankBean.java (Fragment)
public class BankBean implements SessionBean {
private SessionContext context; private AccountHome accountHome;
public Account getAccount(String number) { log(); try { return accountHome.findByPrimaryKey(number); } catch (Exception e) { throw new EJBException(e.getMessage()); } }
public void transfer(Account from, Account to, double amount) throws IllegalOperationException { log(); try { to.deposit(amount); from.withdraw(amount); } catch (IllegalOperationException e) { context.setRollbackOnly(); } catch (Exception e) { throw new EJBException(e.getMessage()); } … }
Ansatz: AmountBean.java (Fragment)
public class AccountBean implements EntityBean {
public void deposit(double amount) throws IllegalOperationException {
log(); balance += amount; if (balance < 0) throw new IllegalOperationException(
"balance becomes less than 0"); }
143
public void withdraw(double amount) throws IllegalOperationException { log(); balance -= amount; if (balance < 0) throw new IllegalOperationException(
"balance becomes less than 0"); } … }
Ansatz: IllegalOperationException.java
package beans;
public class IllegalOperationException extends Exception { public IllegalOperationException(String reason) { System.out.println(reason); } }
Testen Sie den SampleCode und stellen Sie sicher, dass die Transaktionssteuerung funktioniert. Die Konsolestatements (LogDatei) des Applikationsservers erläutern die Sequenz:
file:///[jboss.home]/server/ee/log/server.log 17:24:33,500 INFO [STDOUT] beans.BankBean@14bfb68[16604072]: transfer 17:24:33,500 INFO [STDOUT] beans.AccountBean@1881bb1[16604072]: deposit 17:24:33,500 INFO [STDOUT] beans.AccountBean@1667cff[16604072]: withdraw 17:24:33,500 INFO [STDOUT] balance becomes less than 0 ...
Testen und überprüfen Sie anhand der Methoden-Transaktionsattribute das transaktionale Verhalten der EJB Applikation: Klasse BankBean AccountBean
Methoden transfere() deposit() withdraw()
getBalance() getOwner()
Transaktions- Verhalten
Required Required Required ���� Required RequiresNew Required ���� Supports Required Supports ���� Required Supports NotSupported ���� Required Supports Required ���� NotSupported Required Required ����
Transaktionsattribut
NotSupported NotSupported NotSupported ����
144
20 Message Driven Beans
- Session- und Entity-Bean sind Remote-Procedure-Call Komponenten
- Aufruf synchron vom Client
- Message-Driven-Bean dagegen unterstützt asynchrone Kommunikation
- Client muss nicht warten bis Server Aufgabe erledigt hat
Um dies zu realisieren, wird von der Message-Bean keine direkte Schnittstelle zur Verfügung gestellt, sondern vom Client eine Nachricht an einen Message-Server (Nachrichten-Server) geschickt. Sie wird vom Container aufgerufen, wenn eine Nachricht für sie eintrifft.
Bei Inbetriebnahme (deployment) der Bean auf dem Server wird daher bestimmt, auf welche Nachrichten die Message-Driven-Bean reagieren soll (subscribe). Was sie dann machen soll, wird in der onMessage-Methode festgelegt.
20.1 JMS
- JMS ist API für Zugang zu Messaging-Systemen
- JMS definiert Schnittstelle, aber ohne Implementierung
Vorteil für Software-Hersteller besteht darin, dass sie ihre existierenden Messaging-Produkte mit JMS-Schnittstellen versehen können, ohne sie wesentlich ändern zu müssen. Bei der Integration von EJB mit JMS spielt die Message-Driven-Bean die zentrale Rolle. Da sie weder Remote- noch Home-Interface hat, greift der Client per JMS auf diese Bean zu. Er findet sie indirekt über die Auswahl einer Message-Queue (Point-to-Point-Verbindung) oder eines Message-Topics (Publish/Subscribe-Mechanismus) mittels JNDI (Java Naming and Directory Service). Der Deployment Descriptor (DD) legt fest, für welches der beiden Messaging-Modelle die Message-Driven-Bean zuständig ist.
Bean Provider programmiert die Message-Driven-Bean und implementiert die Business-Methode in onMessage().
Container Provider aktiviert die MDB und ruft onMessage() bei Eintreffen einer Message.
145
Die Message-Driven-Bean ermöglicht den asynchronen Aufruf von EJBeans und realisiert nebenläufige Nachrichten. EJBeans lassen sich nun wie jeder andere JMS Message Listener ansprechen. Nachrichten erzeugen mit der JMS API
Das Erzeugen und Absenden einer Nachricht über JMS erfolgt in sechs Schritten. 1. Treiber lokalisieren 2. Verbindung erzeugen 3. Session erzeugen 4. Destination lokalisieren 5. Consumers / Producers erzeugen 6. Nachricht senden / empfangen
Lokalisieren des JMS-Treibers:
- Treiber für das JMS-Produkt laden
- durch lookup(CONNECTION_FACTORY)
- CONNECTION_FACTORY ist JNDI-Name des Treibers, der die Schnittstelle ConnectionFactory implementiert
Erzeugen der JMS-Verbindung:
- JMS-Verbindung ist aktive Verbindung zu JMS-Provider
- kapselt Netzwerk-Kommunikation
- wie JDBC wird Treiber verwendet, um Connection anzufordern
- zwei Connection-Klassen, TopicConnection und QueueConnection.
Erzeugen einer JMS Session:
- JMS Session ist Hilfsobjekt
- Nachrichten senden oder empfangen
- legt Eigenschaften des Nachrichtenaustauschs fest
- definiert Transaktion
- zwei JMS Session Klassen, TopicSession und QueueSession.
146
Lokalisieren einer JMS Destination:
JMS Destination ist Kommunikationskanal Nachrichten werden zugesendet oder empfangen Auswahl des Kanals erfolgt über lookup(CHANNEL) CHANNEL ist JNDI-Name des Kanals Erzeugen eines JMS Consumers oder eines JMS Producers: Senden oder Empfangen der Nachricht:
- Nachricht wird erstellt als : Text, Bytes, Streams, Objects oder Maps
- Nachricht wird instantiiert und über den Producer gesendet
- Consumer empfängt Nachricht
Dieser gesamte Ablauf ist bei beiden Kommunikationsmodellen gleich. Es gibt für jedes Interface zwei Ausprägungen analog zu den beiden Kommunikationsmodellen. Erzeuger-Interface
Point-to-Point Publish / Subscribe
ConnectionFactory QueueConnectionFactory TopicConnectionFactory
Connection Queue Connection TopicConnection
Destination Queue Topic
Session QueueSession TopicSession
MessageProducer QueueSender TopicPublisher
MessageConsumer QueueReciever, -Browser TopicSubscriber
147
20.2 MDB
- EJB Komponente
- dient dem Empfang von Nachrichten
- werden über Queues oder Topics eines JMS-Servers gesendet
Die Eigenschaften einer MDB lassen sich wie folgt zusammenfassen:
Im Gegensatz zu den anderen EJBeans besitzt die MDB kein Remote, Home, Local-Home oder Local-Interface. Sie wird ausschliesslich über Nachrichten verwendet. Die MDB hat nur eine einzige Geschäftsmethode. Die Methode onMessage(Message) wird immer dann vom Container aufgerufen, wenn eine Nachricht für die MDB eingetroffen ist. Sie akzeptiert eine JMS Message. Standardmässig sollte in dieser Methode zuerst geprüft werden, ob auch die richtige Nachricht eingetroffen ist.
Eine MDB liefert keine Rückgabewerte oder Exceptions. Falls der Client Rückgabewerte benötigt, müssen diese wiederum als Nachricht abgeschickt werden. Dies macht der Container aber nicht automatisch, sondern muss in der Geschäftsmethode implementiert werden. Dies gilt ebenso für den Fehlerfall. Natürlich kann ein Systemfehler auftreten, dieser wird aber nur vom Container registriert.
Eine MDB ist zustandslos und verhält sich wie eine Stateless-Session-Bean.
Eine MDB kann ein permanenter (durable) oder nicht-permanenter (non-durable) Empfänger sein. Als permanenter Empfänger kann die MDB selbst dann die Nachrichten empfangen, die an einen Topic gesendet wurden, wenn sie nicht aktiv war. Der JMS-Server speichert die Nachrichten und überträgt sie, wenn die MDB wieder aktiv ist. Als nicht-permanenter Empfänger gehen die Nachrichten dagegen verloren.
148
20.2.1 Bean Life Cycle
Container initiated: Container initiated: ejbRemove() setMessageDrivenContext ejbCreate()
Container initiated: onMessage()
setSessionContext - wird vor ejbCreate ausgeführt
- gibt Zugang zu Informationen über Laufzeit-Umgebung
ejbCreate
- wird vom Container ausgeführt
- Verbindungen (JNDI) zu Ressourcen initialisieren
- Referenzen anderer EJ-Beans initialisieren
- Datenbankverbindungen sollten hier nicht geöffnet werden, da sie sonst für die gesamte Existenz der MDB belegt sind
ejbRemove
- wird vom Container aufgerufen um Pool zu verkleinern
- Schliessen von Ressourcen
onMessage - Falls eine Nachricht eintrifft, wird onMessage ausgeführt
20.3 Übung ee11 : MDB Wetterstation
Wie bereits bei der Betrachtung des Java Message Service (JMS) aufgezeigt gibt es zwei verschiedene Arten von Mechanismen, nämlich:
Topic:
- Newsletters oder Beitrags in einer Newsgroup
- Jeder Abonnent bekommt die Nachricht zu sehen.
Queue:
- Call-Center
- Nur der erste freie Bearbeiter, der den Anruf entgegennimmt, hat damit zu tun.
In beiden Fällen muss man eine Destination einrichten, in dem der Absender die Nachricht ablegt und aus dem der Empfänger die Nachricht holt.
Methode-Ready-Pool
does not exist
149
Bevor man einen Briefkasten benutzen kann, muss man ihn im EJB-Behälter einrichten. Dazu dient der proprietäre Deployment-Descriptor jbossmq-service.xml:
<server> <mbean code="org.jboss.mq.server.jmx.Topic" name="jboss.mq.destination:service=Topic,name=TestTopic"> <depends optional-attribute-name="DestinationManager"> jboss.mq:service=DestinationManager </depends> </mbean> <mbean code="org.jboss.mq.server.jmx.Queue"
name="jboss.mq.destination:service=Queue,name=TestQueue"> <depends optional-attribute-name="DestinationManager"> jboss.mq:service=DestinationManager </depends> </mbean> </server>
Übung ee11: Wetterstation
Konzipieren Sie einen WetterTopic MDB das eine Wettermessage definiert: Log: file:///[jboss.home]/server/ee/log/server.log 10:49:46,437 INFO [STDOUT] WetterMDB: Wetter=Sonnig Wind=West Temp=18.7C 10:49:46,437 INFO [STDOUT] WetterMDB: Wetter=Sonnig Wind=Ost Temp=3.7C 10:49:46,453 INFO [STDOUT] WetterMDB: Wetter=Wolkig Wind=Ost Temp=2.9C
Ansatz: WetterBean.java (Fragment)
public void onMessage(javax.jms.Message message) { try { MapMessage mapMessage = (MapMessage) message; System.out.println("WetterMDB: " + Wetter=" + mapMessage.getString("Wetterlage") + " Wind=" + mapMessage.getString("Windrichtung") + " Temp=" + mapMessage.getDouble("Temperatur") + "C"); } catch (Exception ex) { System.out.println(ex.getMessage()); ex.printStackTrace(); } }
150
Ansatz: WetterClient.java Fragment)
public class WetterClient { public static void main(String[] args) throws Exception { Hashtable props = new Hashtable(); props.put("java.naming.factory.initial", "org.jnp.interfaces.NamingContextFactory"); props.put("java.naming.provider.url","jnp://localhost:1099"); props.put("java.naming.factory.url.pkgs", "org.jboss.naming:org.jnp.interfaces"); props.put("jnp.socket.Factory", "org.jnp.interfaces.TimedSocketFactory"); Context ctx = new InitialContext(props); TopicConnectionFactory qcf = (TopicConnectionFactory) ctx .lookup("ConnectionFactory"); Topic topic = (Topic) ctx.lookup("topic/WetterTopic"); TopicConnection connect = qcf.createTopicConnection(); TopicSession session = connect.createTopicSession(
false, TopicSession.AUTO_ACKNOWLEDGE); connect.start(); TopicPublisher publisher = session.createPublisher(topic);
String[] wetterlagen = { "Sonnig", "Wolkig", "Regen" }; String[] windrichtungen = { "Nord", "West", "Sued", "Ost" }; for (int i = 0; i < 10; i++) { int rndm = (int) (Math.random() * 300); String sWetterlage = wetterlagen[rndm % 3]; String sWindrichtung = windrichtungen[rndm % 4]; double dTemperatur = (double) (rndm - 50) / 10; MapMessage msg = session.createMapMessage(); msg.setString("Wetterlage", sWetterlage); msg.setString("Windrichtung", sWindrichtung); msg.setDouble("Temperatur", dTemperatur); publisher.publish(msg); System.out.println("-> Wetter=" + sWetterlage + " Wind=" + sWindrichtung + " Temparatur=" + dTemperatur + "C"); } session.close(); connect.close(); } }
151
D EJB 3.0
21 Alles wird viel einfacher!
Viele Entwickler haben erkannt, dass EJB viel zu kompliziert ist, da man für jede Enterprise Bean mehrere Artefakte entwickeln muss:
- Ausser der Beanklasse selbst, braucht man einige Interfaces
- Man braucht etliche XML-Deskriptordokumente, die nicht trivial sind
- In der Beanklasse werden diverse Callbackmethoden benötigt, die entweder trivial (und darum nur lästig) oder aber relativ knifflig zu programmieren sind
21.1 EJB 3.0 Spezifikation
Folgende Ziele gelten für die neue Spezifikation:
- Elimination der Deskriptoren
- Kapselung der Abhängigkeiten von der Umgebung und dem JNDI-Zugriff mit Hilfe der in Java 5 neu eingeführten Annotationen sowie durch Dependency Injection
- Enterprise Beans sollten so weit vereinfacht werden, dass sie eine grössere Ähnlichkeit mit POJOs bzw. JavaBeans besitzen
- Elimination der speziellen Remote Interfaces (remote und local); hierfür sollten normale Javainterfaces ausreichen
- Elimination der Home Interfaces
- Elimination von Callbacks. Nicht alle Callbacks waren lästig bzw. überflüssig, man hat solche übriggelassen (bzw. neue eingeführt), die besonders sinnvoll erscheinen
- Verbesserte Möglichkeiten für das Testen (z. B. Unit Tests) ausserhalb des AS
152
21.2 EJB 3.0 Features
einfacheres EJB API
EJB 3.0 eliminiert das Home Interfaces und verlangt für die Bean Klassen keine Implementation der APIs mehr. Session Beans, Message Driven Beans und Entity Beans sind nun triviale Java Beans, die sich auf die Implementation der Businesslogik konzentrieren. EJB sind nun einfache Java Klassen (POJO) ohne überladene Interfaces. Entity Beans folgen nun der normalen objektorientierten (O-O) Entwurfsmuster und profitieren von Vererbung, Polymorphismus und den standart OO-Konstrukten. Java Annotationen
EJB 3.0 nützt die seit JDK 5.0 eingeführte Java Annotation als Alternative für das Nennen der Deploymentparameter. Die EJB 3.0 Specifikation definieren eine Vielzahl von Annotationen, die Bean Typ, Dependency Injection, Transaction, Security, Callbacks, Object-Relational Mapping, Relations, etc. beschreiben. Deployment Descriptors dienen weiterhin und können Annotationen überschreiben. JBoss AS und Hibernate als OR-Mapping unterstützen Annotationen. Dependency Injection
Komplexe Szenarien für das Anbinden von EJBs oder Ressourcen verschwinden. Durch die @Inject, @EJB, und @Resource Annotationen
werden diese Abhängigkeiten transparent durch den Kontainer an die Java Beans angebunden.
153
Optionale Callbacks
Entwickler müssen nur noch die Callbacks implementieren die sie brauchen. Auch hier erlauben Annotationen @PostConstruct, @PreDestroy, @PrePersist, oder @PostPersist Java Bean Methoden mit den
Callbacks zu verbinden um entsprechende Event Benachrichtigungen zu erhalten.
Entity Manager API
Der Entity Manager API ist neu in EJB 3.0 und ermöglicht Java Bean Instanzen sich mit einem EntityManager zu synchronisieren. JBoss AS wie auch Hibernate unterstützen dieses neue API. einfachere Persistenz und erweiterte Queries
EJB 3.0 standardisiert das Java Persistenz Modell. Dabei spielt Hibernate eine wichtige Rolle bei der Definition dieses API. Etliche Java Annotationen wurden definiert um das Object-Relational Mapping zu definieren. EJB 3.0 erweitert auch die EJB-QL, die nun auch dynamische Queries, Subqueries, bulk Updates, und bulk Deletes unterstützt.
Einsatz ausserhalb des Kontainers
Die EJB 3.0 Persistenz Spezifikation erlaubt den Gebrauch des neuen Persistenz API auch in normalen Java Anwendungen. JBoss EJB 3.0 ermöglicht den Gebrauch von Session Beans und Message Driven Beans auch ausserhalb des JBoss AS in standalone Programme, Junit Tests, standalone Tomcat, und auch in anderen ASs.
154
21.3 Meta-Annotationen
ermöglichen:
- Generierung von Interfaces
- Steuerung des Laufzeitverhaltens von EJB-Komponenten
- Eliminierung der Deployment Deskriptoren
- Demarkation von Injection-Punkten
für:
- Klassen
- Methoden
- Parameter
- Attribute
Verwendung von Meta-Annotationen im Quellcode:
@Stateless // NEU @Remote (HelloEJB3WorldBean.class) // NEU public class HelloEJB3WorldBean { // ohne impl.SessionBean String sayHello(){ return "Hello EJB3 World!"; }
generierter Code für das Interface:
public interface HelloEJB3WorldBean { String sayHello() throws RemoteException;
generierter Deployment Descriptor
… <session> <ejb-name>HelloEJB3World</ejb-name> <home>ejb3.HelloEJB3WorldHome</home> <remote>ejb3.HelloEJB3World</remote> <ejb-class>ejb3.HelloEJB3WorldBean</ejb-class> ... </session> ...
155
21.4 JNDI Kapselung
- ermöglicht Testen von EJBKomponenten
- J2EE-Applikationsserver als Testumgebung nicht mehr zwingend notwendig
- über setter-Methoden werden einer Komponente zur Laufzeit entsprechende Informationen zur Verfügung gestellt (injiziert).
- DI : Dependency Injection
- IOC : Inversion of Control (Hollywood-Prinzip: "don't call us – we call you")
Neue Methode <Object lookup(String name)> ist zum EJBContext hinzugefügt, erlaubt direkter Zugriff für Beans auf den JNDI-Server, ohne extra Code:
Zugriffsvarianten:
- @EJB = Referenz auf EJB-Komponenten
- @Resource = Referenz auf Ressourcen
@Stateless public class MySessionBean { @Resource(name="myDB") private DataSource customerDB; public void myMethod (String myString) { try { Connection conn = customerDB.getConnection(); ... } catch (Exception ex) { ...} } }
@Session public class MySessionBean { private DataSource customerDB; @Resource private void setCustomerDB(DataSource customerDB) { this.customerDB = customerDB; } public void myMethod (String myString) { ... Connection conn = customerDB.getConnection(); ...
156
Injection von "Singletons" im Container
- @Resource javax.ejb.SessionContext ctx;
- @Resource javax.ejb.MessageDrivenContext ctx;
- @Resource javax.ejb.TimerService timer;
- @Resource javax.ejb.UserTransaction ut;
- @Resource javax.ejb.EntityManager manager;
21.5 Configuration by Exception
Spezifiziertes Default-Verhalten von EJB-Komponenten mit dem Ziel der Reduzierung der Entwicklungszeit
Beispiel:
- EJB-Komponenten (Session Beans) sind per default "lokal" zugreifbar und erlauben eine explizite Steuerung durch Verwendung der Annotationen
- @Local und @Remote für das Interface bzw. die Bean-Klasse
- auf Attribute von Entity Beans wird per default über get/set-Methoden zugegriffen und erlaubt eine explizite Steuerung durch Verwendung der Werte der Annotation
- @Entity(access=PROPERTY) und @Entity(access=FIELD)
21.6 Callback-Annotationen für Lifecycle Events
- vordefinierte Callbacks
- gekennzeichnet durch Annotationen (z.B. @PostConstruct, @PreDestroy)
- Session Beans, Message-Driven Beans, Entity Beans
21.7 Interzeptor-Methoden
- Abfangen von Geschäftsmethodenaufrufen
- ermöglicht die Ausführung von beliebigem Code
- z.B. technische Prüfungen, Security
- Session Beans, Message-Driven Beans
157
21.8 Stateless Session Bean
Das Home Interface (und deren create Methode) entfällt, dadurch ist der Zugriff auf die EJB Komponente aus Sicht des Clients vereinfacht:
Version 2.1
public static void main(...) throws Exception { InitialContext ctx = new InitialContext(); Object o = ctx.lookup("MyEJB3"); MyEJB3Home home = (MyEJB3Home)
PortableRemoteObject.narrow(o, MyEJB3Home.class); MyEJB3 myEJB3 = home.create();
Version 3.0
public static void main(...) throws Exception { InitialContext ctx = new InitialContext(); MyEJB3 myEJB3 = (MyEJB3) ctx.lookup("MyEJB3"); ... // do something
- Business (Remote) Interface muss weiterhin vorhanden sein:
- als einfaches Java-Interface (POJI), ohne extens (EJBObject / EJBLocalObject)
- somit auch keine RemoteExceptions mehr in den Methoden
- Business (Remote) Interface kann auch generiert werden
- Bean-Klasse muss nicht mehr das Callback-Interface javax.ejb.SessionBean implementieren
- ejbRemove() gibt es nicht mehr, ist für eine Stateless Session Bean sowieso eine völlig überflüssige Methode
- @Stateless annotiert Bean-Klasse als Stateless Session Bean
Component Interface (Remote- oder Business Interface):
public Interface EJB3 { public void sayHello(); }
Bean Klasse:
@Stateless public class EJB3Bean implements EJB3 { public void sayHello() { return "Hello EJB3 World!"; }
158
21.9 Statefull Session Bean
Das Home Interface (und deren create Methode) entfällt, dadurch ist der Zugriff auf die EJB Komponente aus Sicht des Clients vereinfacht:
- Initialisierung erfolgt durch Geschäftsmethode (ev. über Annotation)
- create Methode kann im Component Interface vorhanden sein
Business (Remote) Interface muss weiterhin vorhanden sein:
- als einfaches Java-Interface (POJI), ohne extens EJBObject, ...
- somit auch keine RemoteExceptions mehr in den Methoden
- Business (Remote) Interface kann auch generiert werden
- Bean-Klasse muss nicht javax.ejb.SessionBean implementieren
- remove() (durch @Remove) kann beliebige Methode der Bean Klasse sein
- @Stateful annotiert Bean-Klasse als Stateful Session Bean
Component Interface (Remote- oder Business Interface):
public Interface AutomaticTellerEJB3 { public void depositMoney(float amount); public void withdrawMoney(float amount); public float getAccountBalance(); @Remove public void closeAccount(); }
Bean Klasse:
@Stateful public class AutomaticTellerEJB3Bean implements AutomaticTellerEJB3 { public void depositMoney(float amount) { accountBalance += amount); } public void withdrawMoney(float amount) { accountBalance -= amount); } public float getAccountBalance() { return accountBalance; } @Remove public void closeAccount() { ... // do something do cleanup } }
159
21.10 Message Driven Bean
Ein MDB muss entweder mit @MessageDriven Annotation gekennzeichnet werden oder das Callback-Interface javax.ejb.MessageDrivenBean implementieren.
21.11 Entity Bean
Der Schwerpunkt bildet die CMP mit einer Weiterentwicklung der Persistenzfunktionalität, eine einfachere CMP/BMP Nutzung und einen höheren Leistungsumfang.
- Ziel: Simplifizierung von Entity Beans durch POJOs
- konkrete (keine abstrakte) Klasse
- @Entity annotiert Bean-Klasse als Entity Bean
- leichtgewichtiges Domänen-Objekt
- Entity Beans sind nicht mehr direkt entfernt zugreifbar!
Zugriff erfolgt nur noch über neu eingeführten javax.ejb.EntityManager zum:
- Erzeugen und Löschen von persistenten Entity-Instanzen
- Finden von Entitäten über Primärschlüssel
- Abfragen über Entitäten
160
Beispiel
@Stateless public class Product { EntityManager em; @Inject public void setEntityManager(EntityManager em) { this.em = em; } public int createProduct(String name, double price) { Product product = new Product(name, price); em.create(order); return order.getId(); } public Product find(int id) { return em.find(Product.class, id); } public void enterProduct(int custID, Product newProduct) { Customer cust = (Customer)em.find("Customer", custID); cust.getProducts().add(newProduct); newProduct.setCustomer(cust); } }
Entity Beans beherrschen nun Vererbung und Polymorphie:
- Polymorphe EJB QL-Abfragen sind nun zulässig
- kein Home Interface mehr nötig
- kein Business Interface mehr nötig (technisch gesehen)
- JavaBean-Stil
- Attribute sind nur per getter/setter-Methoden zugreifbar
- Eliminieren der komplexen, aufwendigen und fehleranfälligen Deployment Deskriptoren
- Beziehungen etc. werden in den Klassen per Annotationen deklariert
- kein DTO (Data Transfere Object) für Transport von Entity Bean-Daten
mehr notwendig
- Entity Bean selbst wird transferiert (detached object)
- nach Änderungen am "detached object" können diese mit dem persistenten Zustand zusammengebracht werden (reattached object)
161
Beispiel: Bean Klasse
@Entity @Table(name = "PURCHASE_ORDER") public class Order implements java.io.Serializable { private int id; private double total; private Collection<LineItem> lineItems; @Id(generate = GeneratorType.AUTO) public int getId() { return id; } public void setId(int id) { this.id = id; } public double getTotal() { return total; } public void setTotal(double total) { this.total = total; } public void addPurchase(
String product, int quantity, double price) { if (lineItems == null) lineItems = new ArrayList<LineItem>(); LineItem item = new LineItem(); item.setOrder(this); ... } @OneToMany(cascade = CascadeType.ALL, fetch = FetchType.EAGER) @JoinColumn(name = "order_id") public Collection<LineItem> getLineItems() { return lineItems; } public void setLineItems(Collection<LineItem> lineItems) { this.lineItems = lineItems; } }
162
21.12 EJB QL
Weiterentwicklung der EJB QL sind:
Sub Queries
SELECT goodCustomer FROM Customer goodCustomer WHERE goodCustomer.balance < ( SELECT avg(c.balance) FROM Customer c )
GroupBy / Having
SELECT c.status, avg(c.filledOrderCount), count(c) FROM Customer c GROUP BY c.status HAVING s.status IN (1, 2)
Explizite Inner-Joins und Outer-Joins / Projection
SELECT c.id, c.status FROM Customer c JOIN c.orders o WHERE o.count > 100
Liefert ein Array von java.lang.Object
SELECT new CustomerDetails(c.id, c.status, o.count) FROM Customer c JOIN c.orders o WHERE o.count > 100
Liefert ein Array von CustomerDetails
Bulk updates, Bulk deletes
DELETE FROM Customer c WHERE o.status = "inactive" AND c.orders IS EMPTY
Auch werden native SQL-Abfragen unterstützt und weiter zusätzliche Funktionen in der WHERE-Klausel sind zulässig:
- UPPER, LOWER, TRIM, POSITION, CHARACTER_LENGTH, CHAR_LENGTH, BIT_LENGTH, CURRENT_TIME, CURRENT_DATE, CURRENT_TIMESTAMP
163
Dynamische Abfragen, Named-Queries
// Erzeugen einer NamedQuery ... @NamedQuery( name="findAllCustomersWithName", queryString = " SELECT c FROM Customer c WHERE c.name LIKE :custName" ) ... // Nutzen einer NamedQuery ... @Inject public EntityManager em; customers = em.createNamedQuery("findAllCustomersWithName") .setParameter("custName", "Smith") .listResults(); ...
Polymorphe Abfragen
Liefert als Ergebnis nicht nur den spezifizierten Typ, sondern auch alle dazugehörigen Subtypen.
164
21.13 Zusammenfassung
- Statt komplexer Komponenten einfache POJOs / POJIs
- Verkürzung der Entwicklungszeit
- Wegfall von überflüssigen Interfaces (Home Interface, Remote Interface und der Typen-Callback Interfaces)
- Bessere und einfachere Modellierbarkeit
- Einfache Java-Klassen mit allen Vorteilen von Container-Komponenten
- Statt Deployment Deskriptoren Meta-Annotation im Java-Code
- Nur noch eine Codebasis
- Erlaubt nun Prüfungen zur Kompilierungszeit
- Inversion of Control / Dependency Injection
- Configuration by Exception
- Vereinfachung der Entwicklung (Reduzierung Code und Entwicklungszeit)
- Mit EJB 3.0 wird die Komponententechnologie erheblich einfacher und gleichzeitig mächtiger.
- EJB 3.0 wird die Entwicklung von komponenten-basierten Systemen beschleunigen
- Konkurrenz .NET
- Das leidige Thema der konkurrierenden Persistenzstrategien innerhalb von J2EE/J2SE wird mit EJB 3.0 endlich behoben
165
E Aufsetzen und Konfiguration der Entwicklungsumgebung 22 Entwicklungstools für J2EE
Der Markt bietet neben kommerziellen AS Produkten, die mehr oder weniger hohe Lizenzkosten beinhalten auch einige Open-Source Projekte an. Dieses Skript und die aufgeführten Beispiele fokussieren bewusst auf OS Tools um das Testen der Lerninhalte so einfach wie möglich zu gestalten.
Die folgenden Installationsanleitungen und die Beschreibung der Entwicklungs-Tools basieren auf den im Skript aufgeführten Beispielsübungen und deren Lösungen.
Die Beispiele in diesem Skript basieren auf den nachfolgend installierten Versionen. Neue Releases sind meist "down-kompatible", eventuelle Anpassungen an den Source Code der Beispiele müssen gemäss den entsprechenden Handbüchern gemacht werden. Die Beispiele sind auch auf einer EJB 3 konformen Umgebung einsetzbar, entsprechen jedoch nicht der EJB 3 Spezification.
23 Java J2SE / J2EE Installation
Neben einem JDK (z.B. JDK1.5) muss für die Entwicklung von J2EE Applikationen die J2EE Umgebung von Sun™ installiert werden (z.B. J2EESDK1.4). Beide Dateien, sowie etliche Dokumentationen können unter http://java.sun.com bezogen und lokal installiert werden.
J2SE installieren:
ausführen: jdk-1_5….exe
von: [CD]\install\j2se oder von http://java.sun.com
J2EE installieren:
ausführen: j2eesdk-1_4….exe
von: [CD]\install\j2ee oder von http://java.sun.com
166
24 Eclipse als Entwicklungsumgebung
Eclipse.org ist die Plattform für mehr Hintergrundinformationen betreffend der Eclipse Entwicklungsumgebung:
- Basiert auf Initiative von IBM
- Mitarbeit: Borland, webgain, GNX, serena, Rational, redhat, SuSe, TogetherSoft, ...
- Entwickelt von mehr als 1200 Software Entwicklern von mehr als 150 führenden Software Herstellern aus mehr als 60 verschiedenen Ländern
( einige ) Plattform Komponenten:
- Ant ( integration of Ant scripting )
- Compare ( universal compare facility )
- Debug ( generic execution and debug framework )
- Help ( platform help system )
24.1 Installation
Die aktuelle Version von Eclipse kann als ZIP Datei von http://www.eclipse.org oder direkt unter http://mirror.switch.ch/mirror/eclipse/downloads/ bezogen werden und folgendermassen installiert werden:
zu einem lokalen Verzeichnis dekomprimieren (Verzeichnisstruktur sollte keine Leerzeichen enthalten, wie z.B. "Eigene Dateien"):
entpacken: eclipse-SDK-3.2-win32.zip
von: [CD]\install\eclipse
nach: ...\ee
bevorzugte Plug-Ins installieren, z.B: Quantum DB Explorer:
entpacken: Quantum_2.4.5_for_Eclipse_3.zip
von: [CD]\install\eclipse plugins
nach: ...\ee\eclipse\
167
bevorzugte Plug-Ins installieren, z.B: XMLBuddy:
entpacken: xmlbuddy_2.0.72.zip
von: [CD]\install\eclipse plugins
nach: ...\ee\eclipse\plugins
weitere Eclipse Plug-Ins unter:
http://www.eclipseplugincentral.com
24.2 Eclipse starten
Im Insallationsverzeichnis auf das entsprechende Icon klicken.
168
25 JBoss AS
JBoss war ursprünglich als EJB Kontainer konzipiert, wurde aber zu einem kompletten Applikations Server für J2EE Applikationen weiterentwickelt.
Entstanden 1999 - JBoss ist das Produkt einer OpenSource Developer Community die das erklärte Ziel hatte, den besten J2EE-compliant Applikationsserver auf dem Markt zu entwickeln
- 1000 Developer weltweit
- JBoss ist heute wahrscheinlich der verbreitetste EJB Server
- 4000 Downloads des EJB Servers pro Tag (mehr als manche kommerzielle Hersteller insgesamt haben)
- Die Distribution erfolgt unter LGPL License, d.h. JBoss kostet keine Lizenzgebühren.
- JBoss hat sich als eine vitale Alternative zu überpreisten EJB Servern im kommerziellen Umfeld entwickelt.
25.1 Installation
Die aktuelle Version von JBoss kann als ZIP Datei von http://www.jboss.org bezogen werden und folgendermassen installiert werden:
zum lokalen Verzeichnis C:\ee dekomprimieren (Verzeichnisstruktur sollte keine Leerzeichen enthalten, wie z.B. "Eigene Dateien")
entpacken: jboss-4.0.4.GA.zip
von: [CD]\install\jboss oder http://www.jboss.org
nach: ...\ee\
JAVA_HOME Umgebungsvariable als Benutzer- oder Systemvariablen entsprechend der installierten JDK Version definieren/ergänzen:
169
25.2 JBoss AS starten / stoppen
- das run.bat Skript in \bin Verzeichnis der JBoss Installation ausführen
- mit http://localhost:8080 den JBoss Server testen.
- CTRL+C, shutdown.bat oder über die Management Konsole http://localhost:8080/jmx-console kann der JBoss Applikations Server gestoppt werden.
25.3 JBoss Verzeichnisstruktur
Das Installationsverzeichnis enthält fünf Ordner:
- bin Skript Files
- client JAR Dateien für Client Applikationen, jbossall-client.jar enthält sämtliche Lybraries
- docs enthält XML DTD für JBoss Referenzen sowie example J2EE Connector Architecture Dateien für das Anbinden von externen Ressourcen (z.B. MySQL, etc.)
- lib JBoss microkernel JAR Lybraries
- server die verschiedenen server Konfigurationen
- all startet alle zur Verfüfung stehenden Dienste wie: RMI-IIOP, Clustering und WEB-Service
- default started in der standart Konfiguration
- ee (erstellter) benutzerspezifischer Server für die EnterpriseEducation Beispiele: ee4, ... (als Kopie des default Verzeichnis)
- minimal minimum Requirement für den JBoss AS mit: JNDI und URL Deployment Scanner ohne: WEB- oder EJB Container, ohne JMS
170
Der entsprechende Server ist, wenn gestartet (z.B. run –c default), auch zugleich das entsprechende Verzeichnis, indem alle Deployments stattfinden und alle LOGs geschrieben werden. Die Verzeichnisstruktur beschreibt:
- conf enthält die jboss-service.xml Datei, die den core Service spezifiziert
- data Verzeichnis für die Hypersonic Datenbank
- deploy HOT-Deployment Verzeichnis für JAR, WAR und EAR Dateien
- lib JAR Dateien für die Server Konfiguration und Ressourcen z.B. "fremde" JDBC Drivers, etc.
- log Verzeichnis für die Logging Informationen
- tmp Temporäres Verzeichnis für Deployment, etc.
- work JSP-Kompilationsverzeichnis für Tomcat
25.4 Benutzerspezifischer Server einrichten
Als Default wird der default Sever gestartet. Alle serverspezifischen Informationen sind im entsprechenden Verzeichnis. Mit den Beispielsapplikationen benutzen wir mySQL als Datenbank. Um einen entsprechenden benutzerspezifischen Server ee für die EnterpriseEducation Beispiele zu definieren sind die folgenden Schritte massgebend:
[JBoss_Home]\server\default Verzeichnis kopieren zu "ee"
kopieren: Verzeichnis
von: [JBoss_Home]\server\default
nach: [JBoss_Home]\server\ee
171
Der JDBC Treiber wird als "MySQL Connector" auf der offiziellen Website von MySQL angeboten, wobei die im Root des heruntergeladenen TAR- oder ZIP Verzeichnis befindliche JAR-Datei von Bedeutung ist. Diese im JAR-Format befindliche Java-Bibliothek muss in den /lib Ordner der JBoss Installation kopiert werden - damit erhält der Application Server den Zugriff darauf, und die Voraussetzung, mit dem MySQL Server kommunizieren zu können.
JDBC Driver mysql-connector-java-3.0.15-ga-bin.jar oder aktuellen Connector/J von http://www.mysql.com ins Verzeichnis [JBoss_Home]\server\ee\lib kopieren:
kopieren: mysql-connector-java-5.0.3-bin.jar
von: [CD]\install\mysql
http://www.mysql.com
nach: [JBoss_Home]\server\ee\lib
Die logische Repräsentation der MySQL Datenbank innerhalb der J2EE Programme wird nicht, wie vermutet, durch ein direktes Verwenden des JDBC-Treibers geschaffen, sondern über eine abstrakte Datenbankschnittstelle, DataSource genannt. Durch eine neu anzulegende Konfigurationsdatei im /deploy Ordner der JBoss Installation können DataSources zentral durch den Namens- und Verzeichnisdienst verwaltet werden.
In /docs/examples/jca/mysql-ds.xml befindet sich eine Vorlage, die den Verhältnissen entsprechend angepasst werden muss.
mySQL DataSource Konfigurationsdatei mysql-ds.xml:
kopieren: mysql-ds.xml
nach: [JBoss_Home]\server\ee\deploy
anpassen: benutzerspezifisch konfigurieren
172
<?xml version="1.0" encoding="UTF-8"?>
<datasources> <local-tx-datasource> <jndi-name>mySSqlDS</jndi-name> <connection-url> jdbc:mysql://localhost:3306/ee </connection-url> <driver-class>com.mysql.jdbc.Driver</driver-class> <user-name>root</user-name> <password></password> </local-tx-datasource> </datasources>
25.5 Benutzerspezifischer JBoss-Server starten
Um den neu erstellten Server "ee" zu starten muss vorgängig mySQL installiert, sowie die entsprechende Datenbank "ee" mit den entsprechenden Benutzerrechten erstellt sein.
- cd\ C:\ee\ jboss-4.0.4.GA\bin\
- run -c ee
Das entsprechende Script um den Server zu stoppen ist:
- shutdown -S
173
26 mySQL Datenbankserver installieren und Datenbank erstellen
mySQL ist eine der verbreitetsten Open Source Datenbanken und wird von vielen Organisationen kommerziell benutzt.
26.1 Installation
entpacken: mysql-noinstall-5.0.24-win32.zip
von: [CD]\install\mysql
oder http://www.mysql.com
nach: c:\ (entziptes Verzeichnis (entziptes Verzeichnis (entziptes Verzeichnis (entziptes Verzeichnis umbenennenumbenennenumbenennenumbenennen zu zu zu zu mysqlmysqlmysqlmysql!)!)!)!)
mySQL kann bei der Installation und beim Starten des DBMS Dienstes Probleme verursachen wenn diese mySQL Distribution nicht im c:\ (root) Verzeichnis liegt:
26.2 mySQL-Tools
Zur windowbasierten Administration von mySQL DBMS können verschiedene Tools installiert werden, z.B:
entpacken: mysql-gui-tools-noinstall-5.0-r2-win32
von: [CD]\install\mysql
oder http://www.mysql.com
nach: c:\
174
26.3 EnterpriseEducation DB anlegen
Mit Administrationstool oder per Konsole den Datenbankserver starten und die Datenbank "ee" erstellen:
- c:\>set path %PATH%;c:\mysql\bin - c:\>mysqld-nt.exe --install - c:\>net start mysql - c:\>mysqladmin -u root create ee - c:\>mysql –u root –D ee
- mysql> GRANT ALL PRIVILEGES ON ee.* TO 'Ihr_Name'@localhost IDENTIFIED BY 'Ihr_Password'
175
27 EJB Applikation mit Eclipse / JBoss
Für das Deployen einer mit der Eclipse Plattform erstellten EJB Applikation steht eine build.xml Datei zur Verfügung. Diese muss im root Verzeichnis des Eclipse Projectes liegen und implementiert die folgenden Targets:
- deploy Deployment von Sample Applikationen
- run-client-application Ausführen von Client Applikation
- run-sql-script Ausführen von SQL Statements
Apache Ant ist ein Java basiertes Build Tool und ist integrierter Bestandteil der Eclipse Entwicklungs- umgebung. Information und Beispielanwendungen sind unter http://ant.apache.org erhältlich.
Apache Ant build.xml Script für die Enterprise Education Beispiele:
<?xml version="1.0" encoding="UTF-8" ?> <!-- Enterprise Education: deploy : Deployment von ee Applikationen run-client-application : Ausführen von Client Applikation run-sql-script : Ausführen von SQL Statements Author : s.metzler Datum : 2006-08-20 Version : 3.0 --> <project name="EnterpriseEducation Packaging and Deploy Script" default="deploy" basedir="."> <!-- Property Datei: Applikationsspezifische Parameter --> <property file = "${basedir}/properties/enterpriseeducation.properties" />
176
<!-- Resources dir: jndi.properties Datei für den Client --> <property name="resources.dir" value="${basedir}/resources" /> <!-- Client Classpath: Classpath Parameter für den Client --> <path id="client.classpath"> <pathelement location="${resources.dir}" /> <fileset dir="${jboss.home}/client"> <include name="**/*.jar" /> </fileset> </path> <!-- Build Classpath: Classpath Parameter für den Build Prozess --> <path id="build.classpath"> <path refid="client.classpath" /> <pathelement location="${build.dir}" /> <pathelement location="${servlet.jar}" /> </path> <!-- SQL Classpath: Classpath Parameter für die Datenbankanbindung --> <path id="sql.classpath"> <pathelement location="${mysql.driver.jar}" /> </path> <!-- depoly target: Deployment von Sample Applikationen --> <!-- ++++++++++++++++++++++++++++++++++++++++++++++++++ --> <target name="deploy"> <mkdir dir="${build.dir}" /> <!-- Bean Klassen kompilieren --> <javac destdir="${build.dir}" classpathref="build.classpath"> <src path="${src.dir}/${ejb.dir}" /> </javac> <!-- Client Klassen kompilieren --> <javac destdir="${build.dir}" classpathref="build.classpath"> <src path="${src.dir}/${client.dir}" /> </javac> <!-- Bean Archivedatei löschen --> <delete file="jar/${app.name}.jar" />
177
<!-- Bean Deployment Descriptor kopieren --> <copy file="dd/ejb-jar.xml" tofile="${build.dir}/ejb-jar.xml" overwrite="true" />
<copy file="dd/jboss.xml" tofile="${build.dir}/jboss.xml" overwrite="true" />
<!-- Bean Archivedatei bilden --> <jar jarfile="jar/${app.name}.jar"> <metainf dir="${build.dir}" includes="ejb-jar.xml, jboss.xml" /> <fileset dir="${build.dir}"> <include name="${ejb.dir}/**" /> </fileset> </jar>
<!-- Bean Archivedatei deployen --> <copy file="jar/${app.name}.jar" todir="${jboss.deploy.dir}" />
<!-- Client Archivedatei löschen --> <delete file="jar/${app.name}AppClient.jar" />
<!-- Client Deployment Descriptor(en) kopieren --> <copy file="dd/application-client.xml" tofile="${build.dir}/application-client.xml" overwrite="true" />
<copy file="dd/jboss-client.xml" tofile="${build.dir}/jboss-client.xml" overwrite="true" />
<!-- Client Archivedatei bilden --> <jar jarfile="jar/${app.name}AppClient.jar"> <metainf dir="${build.dir}" includes="application-client.xml, jboss-client.xml" /> <fileset dir="${build.dir}"> <include name="${resources.dir}/jndi.properties" /> <include name="${client.dir}/**" /> <include name="${ejb.dir}/${app.name}Home.class" /> <include name="${ejb.dir}/${app.name}.class" /> </fileset> <fileset dir="${resources.dir}"> <include name="jndi.properties" /> </fileset> </jar>
178
<!-- Tempöräres Build Verzeichnis löschen --> <delete dir="${build.dir}" /> </target> <!-- run-client-application target: Ausführen von Client Applikation --> <!-- +++++++++++++++++++++++++++++++++++++++++++++++++++ --> <target name="run-client-application" depends="deploy"> <java classname="client.${app.name}Client" fork="yes"> <classpath> <pathelement path="jar/${app.name}AppClient.jar" /> <path refid="client.classpath" /> <pathelement path="${java.class.path}" /> </classpath> </java> </target> <!-- run-sql-script target: Ausführen von SQL Statements --> <!-- +++++++++++++++++++++++++++++++++++++++++++++++++++ --> <target name="run-sql-script"> <sql classpathref="sql.classpath" driver="com.mysql.jdbc.Driver" url="jdbc:mysql://localhost/${database}" userid="${user}" password="${password}" src="sql/${sql.data}" /> </target> </project>
Die Parameter des InitialContext :
PROVIDER_URL, NITIAL_CONTEXT_FACTORY, und
URL_PKG_PREFIXES sind in einer Property Datei definiert:
resources/jndi.properties
# Definiert die JBoss Server Context Properties
java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory java.naming.provider.url=jnp://localhost:1099 java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces
Die zur Ausführung dieses Skripts notwendigen applikationsspezifischen Parameter sind in einer Property Datei untergebracht:
179
properties/enterpriseeducation.properties
# Enterprise Education Properties # zum Deployen und Ausführen der JBoss Beispiele
# Pfad des Projekt Verzeichnis ee.home=D:/ee
# JBoss-spezifische Einstellungen # ------------------------------- jboss.home=${ee.home}/jboss-4.0.4.GA
# Pfad des JBoss Server jboss.server=${jboss.home}/server/ee
# Pfad des deploy Ordner jboss.deploy.dir=${jboss.server}/deploy
# den Pfad des Servlet Archives angeben servlet.jar=${jboss.server}/lib/javax.servlet.jar
# Applikations-spezifische Einstellungen # ------------------------------------- # Name der Applikation app.name=MoneyExchange
# Source Verzeichnis src.dir=${basedir}/src
# Beans Verzeichnis ejb.dir=beans
# Client Verzeichnis client.dir=client
# Build Verzeichnis (temporäres Verzeichnis) build.dir=${basedir}/build
# Name der ClientApplikation j2ee.clientName=MonexExchangeClient
# Datenbank-spezifische Einstellungen # ------------------------------------- # Connector/J Archive mysql.driver.jar=${ee.home}/lib/mysql-connector-java-5.0.3-bin.jar
# SQL Skript Datei sql.data=create_rates_table.sql
# Benutzereinstellungen für DBMS user=root password= database=ee
180
Das Apache Ant Skript verlangt zusammen mit den applikationsspezifischen Parametern nach einer entsprechenden Struktur innerhalb der Eclipse Entwicklungsumgebung. Diese ist wie folgt abgebildet (Beispiel MoneyExchange):
Project: ee4 (EnterpriseEducation Beispiel 4)
- ee4 Projektordner
- bin default output folder
- beans wird generiert
- client wird genertiert
- dd Deployment Descriptor Dateien
- jar generierte JAR Dateien
- properties Property Dateien
- resources Resource Dateien
- sql SQL Skript Dateien
- src source folder on build path
- beans Home Interface Class Remote Interface Class Bean Implementation Class
- client Client Applikations Class
- build.xml Apache Ant Datei liegt im Project-Verzeichnis!
Classpath Einstellungen:
181
28 Tomcat
Tomcat Version 5 implementiert die Servlet 2.4- und JavaServer Pages 2.0 Specifikation, definiert durch den Java Community Process http://www.jcp.org/ und beinhaltet viele zusätzliche Funktionen die eine Entwicklung und das Deployen von Web Applikationen unterstützen.
28.1 Server Architektur
Web Applokationen liegen im Verzeichnis [Tomcat_Home]\webapps\. Per Default soll ein \WEB-INF\ Ordner die Deploydateien enthalten.
Der entsprechende Eintrag in der Webserver-Konfiguration-sdatei [TOMCAT_HOME]\conf\server.xml weist auf das entsprechende Verzeichnis der WEB-Applikation.
Ressourcen, die direkt zum Client geschickt werden oder vom Client aus ansprechbar sind, wie z.B. .jsp-, .html- und .gif-Dateien sowie clientseitig nutzbare .class-Applets, befinden sich nicht unterhalb des Verzeichnisses WEB-INF, sondern parallel dazu.
- Unter /WEB_INF/classes befinden sich Servlets, JavaBeans und andere Serverseitige .class-Dateien.
- Unter /WEB_INF/lib befinden sich .jar-Archive.
- /WEB_INF/web.xml ist die Konfigurations- datei der Web Application.
- In die Webserver-Konfigurationsdatei [TOMCAT_HOME]\conf\server.xml muss die Web Application mit einem Context-Element angemeldet werden.
182
Beschreibung des Context Tags
ElementElementElementElement AttributeAttributeAttributeAttribute BeschreibungBeschreibungBeschreibungBeschreibung DefaultDefaultDefaultDefault
Context path URL Fragment, identifiziert Kontext none, must be specified
docBase Path zum Projektverzeichnis none, must be specified
reloadable Erlaubt das "Reloading" der Servlets true
debug Debug Level für das Logging 0
Beispiel eines Eintrags in der Webserver Konfigurationsdatei:
<Context path="/examples" docBase="webapps/examples" debug="0" reloadable="true" >
oder:
<Context path="/ee4" docBase="C:\ee\workspace\ee4" debug="0" reloadable="true" >
28.2 Installation
entpacken:
jakarta-tomcat-5.0.28.zip
von: [CD]\install\tomcat oder von http://jakarta.apache.org/site/binindex.cgi
nach: ...\ee\
Tomcat Plug-In installieren
entpacken: tomcatPluginV31.zip
von: [CD]\install\eclipse plugins
nach: ...\ee\eclipse\plugins
Um einen Portkonflikt mit dem JBoss AS zu vermeiden muss der Port in der Datei ..\conf\server.xml umkonfiguriert werden.
- <Connector port="8090" …
183
- Tomcat starten mit : http://localhost:8090
Recommended
