A Java 2 EnterpriseEdition

Transkript

1 A Java 2 EnterpriseEdition 1 Java Plattform Die Java Plattform ist in drei Editionen aufgeteilt: J2ME Micro Edition robuste, flexible Umgebung für: - Mobil-Telefone, PDAs - embedded devices VM und Standart Java APIs für Kommunikationsprozesse. J2SE Standard Edition Die J2SE definiert: - JRE, VM, etc. - JDK Stellt die Basis für J2EE dar. J2EE Enterprise Edition 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 Systemoder Anwendungssoftware Fehlertoleranz - Hardwareredundanz, Softwareredundanz 1

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) EJB (Enterprise Java Beans) - nur JAVA - entwickelt für Geschäftsprozesse - Sicherheits- und Verbindungslogik ist integriert 2

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 3

4 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 ORACLE JDBC DB2 - JMS (Java Messaging Service) ermöglicht den Zugriff zu Message Orientated Middleware, z.b. ibus,ibm MQSeries BEATuxedo JTA J2EE JMS IBM MQSeries ibus JNDI DNS LDAP COS 2.3 Namenskonventionen Item Syntax Beispiel Enterprise Bean Name (DD) EJB JAR Display Name (DD) <name>bean <name>jar HelloWorldBean 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 4

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) HelloWorld.ear HelloWorld.jar - WEB-Anwendungen HTML-Seiten, Servlets, JSP, gif- und jpg-bilder in einer *.war Datei (web application archive) HelloWorldClient.jar HelloWorldWeb.war - 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: 5

6 2.5 Multi-Tier Application Das Verteilen einer Applikation richtet sich meistens nach dem "seperation of concern" Aspekt der OOA Schicht Architektur RMI = Remote Method Invocation IIOP = Internet Inter ORB Protocol WEB Browser HTML, Applets HTTP WEB Server Java Servlets JSP J2EE Client Container J2EE Client DATA stand alone Java Client C++ Client RMI-IIOP Applikation Server EJB IIOP CLIENT-Tier LOGIK-Tier DATA-Tier J2EE Server mit WEB- und BusinessTier J2EE Server mit JavaBean Komponenten als Interface J2EE Server mit WEB-, BusinessTier und EIS Tier 6

7 B Enterprise JavaBeans 3 EJB Definition Development, Distribution, Deployment of Java-Based Server-Side Software Components Entwicklung, Verteilung Umsetzung (von Modellen) Militär: Truppenbereitstellung / Installation Java basierten serverseitigen 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 7

8 3.1 EJB Architektur - EJBs existieren innerhalb von Containern - Applikations-Server stellt Dienste zur Verfügung Client EJB EJB EJB Applikation Server Client Client EJB CONTAINER Services Transaction Security Distribution Persistance Naming 3.2 EJB Typen Enterprise-Bean interface javax.ejb.enterprisebean Session Bean interface javax.ejb.sessionbean Entity Bean interface javax.ejb.entitybean Message Driven Bean interface javax.ejb.messagedrivenbean Session Bean stateless Session Bean statefull Entity Bean CMP Entity Bean BMP Message Bean 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 Nachrichtenempfä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 Clientzuordnung, "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 8

9 3.3 Elemente einer EJB Komponente Die EJB besteht aus mindestens vier Komponenten: Home Interface - definiert Schnittstelle (Sichtbarkeit) was sieht der Client von dieser Komponente Datei: ejb/helloworldhome.class Remote Interface - definiert Dienste (Business Methoden), die dem Client zur Verfügung stehen Datei: ejb/helloworld.class Home Interface Client Remote Interface EJB Implementation Bean Implementierung - definiert und implementiert alle Methoden, die im Home- und Remote Interface deklariert sind Datei: ejb/helloworldbean.class EJB Container Deployment Descriptor Deployment Descriptor - XML Datei zur Beschreibung der Komponente (Dateiangaben, Pfadangaben, Datenbankverbindungen und das Verhalten, z.b: Zugriffskontrolle, Transaktionsverhalten) Datei: ejb-jar.xml HelloWorld.jar Java ARchive (*.jar) ejb / HelloWorld.class Remote Interface ejb / HelloWorldHome.class Home Interface ejb / HelloWorldBean.class Bean Implementation ejb-jar.xml Deployment Descriptor 9

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 HelloWorld.jar 3. deployen Sun Application Server 4. HelloWorldClient.class 10

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) { 11

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(); 12

13 4.7 "Hello EJB World" Bean mit Tool deployen Applikations-Server starten / stoppen - Start > Sun Microsystems > Application Server PE > Start / [Stop] Default Server - Testen ob der Server läuft mit: 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 13

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 ( ) das Packen der Applikation und das Deployen der Komponenten durchführen: z.b: - HelloWorld.ear asant deploy asadmin deploy # 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 # --user <user-name> --password <password> --host <hostname> --port <admin-port> HelloWorld.jar 14

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 15

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 # 16

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 # 17

18 HelloWorldAppClient generieren: 18

19 5 Inside EJB 5.1 EJB Klassen Diagramm rmi = Remote Method Invocation Interfaces of: java.ejb package java.rmi.remote javax.ejb.enterprisebean java.ejb.ejbobject getejbhome() gethandle() getprimarykey() isidentical() remove() javax.ejb.ejbhome getejbmetadata() gethomehandle() remove() javax.ejb. - SessionBean - EntityBean javax.ejb.ejbmetadata getejbhome() gethomeinterfaceclass() getprimarykeyclass() getremoteinterfaceclass() issession() isstatelesssession() Remote Interface Home Interface HelloWorld business methods HelloWorldHome create() findbyprimarykey() findx() <enterprise bean> HelloWorldBean Beans Provider's Classes <guard> EJBObject <factory> EJBHome <context> real context object Container generated Classes Runtime Classes javax.ejb. EntityContext getejbobject() getejblocalobject() getprimarykey() javax.ejb. SessionContext getejbobject() getejblocalobject javax.ejb.ejbcontext getejbhome() getejblocalhome() getcallerprincipal() iscallerinrole() setrollbackonly() getrollbackonly() getusertransaction() 19

20 5.2 EJB Komponenten 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 java.rmi.remote javax.ejb.ejbhome getejbmetadata() gethomehandle() remove() beschreibt die Netzwerkfähigkeit eines Objektes erzeugt eine Instanz von EJBMetaData erzeugt eine dauerhafte Instanz entfernt (löscht) das Enterprise Java Bean HelloWorldHome create() findbyprimarykey() findxxx() erzeugt ein EJB (overloading possible) nur für ENTITY Beans mehrere finder Methoden sind möglich 20

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 java.rmi.remote beschreibt die Netzwerkfähigkeit eines Objektes javax.ejb.ejbobject getejbhome() gethandle() remove() getprimarykey() isidentical() erzeugt Referenz zu HOME Interface robuste Referenz (netzwerkfähig) löscht EJB Instanz gibt PrimaryKey des EJB (throws RemoteException) vergleicht zwei REMOTE Interfaces HelloWorld Business Methods beschreibt den Geschäftsprozess (Business Methoden) 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. 21

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) Ü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. Element Session Bean Entity Bean local remote local remote Remote Home Interface Local Home Interface Remote Interface Local Interface Message Driven Bean Bean Klasse Primary Key Klasse Deployment Descriptor 22

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. 23

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. 24

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(); 4. Aufruf 5. Aufruf Remote Remote Interface Objekt obj Client 3. Referenz auf EJB Object obj Home Home Interface Objekt obj Enterprise Java Beans EJB - Kontainer 1. Anfrage nach Referenz 2. Erzeuge EJB-Object Sequenz Diagramm Client JNDI Service EJBHome EJBObject lookup reference to EJBHome create / find reference to EJBObject business methods 25

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. 26

27 5.4.1 RMI Kommunikationsmodell Client Stub Remote Reference Layer virtuelle Kommunikation reelle Kommunikation Netzwerkverbindung Server Skeleton Remote Reference Layer 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 27

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. RMI - Registry Client Suche Registrierung virtueller Aufruf Server Remote Objekte - 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 28

29 5.5 EJB Kommunikationsmodelle An Prozesse beteiligte EJBs kommunizieren: - synchron, entfernt - synchron, lokal - asynchron, nachrichtenbasiert 29

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 30

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 31

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 Überblick über die Kommunikationsmodelle EJB Typen synchron entfernt Aufrufmodell synchron lokal Stateless Session Bean Statefull Session Bean Entity Bean Message Driven Bean asynchrony nachrichtenbasiert 32

33 6 Stateless Session Bean ( zustandslos) java.io.serializable javax.ejb.enterprisebean javax.ejb.sessionbean ejbactivate() ejbpassivate() ejbremove() setsessioncontext() mysessionbean ejbcreate() business methods 6.1 Bean Life Cycle 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 Container initiated: ejbremove() does not exist Methode-Ready-Pool Container initiated: Class.newInstance() setsessioncontext(sc) ejbcreate() Client initiated: business methods - nach Instanzierung der Bean durch Container setsessioncontext ejbcreate ejbremove - teilt der Bean SessionContext mit - SessionContext definiert Umgebung der Bean- Instanz und übergibt Client Informationen - nach setsessioncontext durch Container - initialisiert Bean z.b. Verbindungen /Datenbanken - wird durch Container aufgerufen - nach remove des Remote Objektes - reservierte Ressourcen werden freigegeben - Container löscht Bean-Instanz 33

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: 34

35 7 Stateful Session Bean ( zustandsbehaftet ) java.io.serializable javax.ejb.enterprisebean javax.ejb.sessionbean ejbactivate() ejbpassivate() ejbremove() setsessioncontext() mysessionbean ejbcreate() business methods 7.1 Bean Life Cycle does not exist 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 Container initiated: Class.newInstance() timeout Container initiated: ejbremove() setsessioncontext(sc) ejbcreate() Client initiated: remove() Client initiated: business methods Methode-Ready-Pool Client initiated: create() Container initiated: ejbactivate() ejbpassivate() Passive ejbpassivate ejbactivate ejbremove - wird vom Container aufgerufen - Bean wird zeitweilig aus Speicher entfernt - Bean kann (soll) Ressourcen freigeben - Bean bleibt weiterhin Client zugeordnet - für Client transparent - wird vom Container aufgerufen (nach Business Methode) - Container holt Bean Instanz in Arbeitsspeicher zurück - Bean wird neu initialisiet - wird durch Container aufgerufen - reservierten Ressourcen freigegeben - Container löscht Bean-Instanz 35

36 7.2 Übung ee2 : Kontoführung Erstellen und deployen Sie ein Stateful Session Bean zur Kontoführung. Benützen Sie dazu die Variable private float accountbalance: - Betrag deponieren (als Float) - Betrag abheben (als Float) - Saldo ausgeben (auf Konsole) Konsolen Statements Ergänzen Sie die Bean Methoden mit Konsolen Statements zur Überwachung der Aktivitäten des Applikations-Servers 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> 36

37 8 Entity Bean (Abbildung von Daten einer DB ) java.io.serializable javax.ejb.enterprisebean javax.ejb.entitybean ejbactivate() ejbpassivate() setentitycontext() unsetentitycontext() ejbload() ejbstore() myentitybean ejbcreate() ejbpostcreate() ejbfindxxx() business methods 8.1 Bean Life Cycle 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 Container initiated: unsetentitycontext() Object.finalize() Container initiated: ejbpassivate() ejbremove() Client initiated: remove() Container initiated: ejbload(), ejbstore() does not exist Pooled Ready Container initiated: Class.newInstance() setentitycontext() Container initiated: ejbactivate() ejbcreate(),ejbpostcreate() Client initiated: create() Client initiated: getter / setter Pooled Ready - 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 - Instanz existiert, besitzt Identität - kann vom Client benutzt werden 37

38 8.1.1 EJB-Container Life-Cycle- Methoden Life Cycle Methode Beschreibung setentitycontext() unsetentitycontext() ejbload() ejbstore() ejbremove() ejbactivate() ejbpassivate() wird aufgerufen nach Erstellen / vor Entfernen der Entity Bean ladet / speichert die Entity Bean entfernt die Entity Bean aktiviert / passiviert die Entity Bean Persistenzoperationen einer Entity Bean Operation: ejbcreate SQL Alias: INSERT Operation: ejbfindbyprimarykey SQL Alias: SELECT - wird nach Erzeugen der EJB aufgerufen - speichert Java-Objekt in Datenbank ab - Methode nicht Bestandteil der Interfaces - Parameter sind nicht festgelegt - 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: - entfernt das Java-Objekt aus Datenbank - EJB-Objekt bleibt bestehen DELETE Operation: ejbstore SQL Alias: UPDATE - synchronisiert Java-Objekt mit EJB-Objekt und aktualisiert so Datenbankinhalt - Methode wird nach jedem Client Zugriff ausgeführt 38

39 8.2 Modellieren von persistenten Geschäftsdaten Übung ee3 : Personenverwaltung mit CMP 1.0 SUN Applikationsserver CMP (1.x) Entity Bean public id public name public fname DB: EnterpriseEducation PERSONBEAN ID FNAME NAME 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; 39

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 {... 40

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 ( ) 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: 41

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> 42

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 Ü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: Applikationsserver CMP (2.x) EntityBean:Name get / set id get / set name get / set fname get / set address CMP (2.x) EntityBean:Address get / set id get / set street get / set location 1 : 1 Relation DB: EnterpriseEducation NAMEBEAN ID NAME FNAME ADDRESSBEAN ID STREET LOCATION 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 43

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 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() { 44

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; 45

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. 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); 46

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) 47

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> 48

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 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 Geschichtliches - Idee aus der Architektur durch Christopher Alexander durch Cunningham und Beck - entwarfen fünf Patterns für die User-Interface Programmierung 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 Referenzen - Bien, Adam ( 2003 ), J2EE Patterns, Addison-Wesley - etc. 49

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 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 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 Implementation instanc e Singleto n Singleton getinstanc e() operatio ns In diesem Unterkapitel wird die Umsetzung des Patterns in Java aufgezeigt. 50

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. 51

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(); 52

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 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. 53

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. Abstrac tserv ice doit()... <<inte rface>> IFService doit() ServiceProxy Service ServiceProxy Service doit() doit() doit() doit() 0..* 1 0..* 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: 54

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(); 55

56 9.4 Factory Method Pattern [Deutsch: Fabrik] - creational patterns - definiert ein Interface für die Erzeugung von Objekten - überlässt instanziiert der Klasse Unterklassen 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) Lösung UML Klassendiagramm Product operation1 operation2... * * Uses CreationRe questor 1 newproduct... 1 re questor Requests- Creation ConcreteProduct operation1 operation2... cre ator * <<interface >> IFFactory cre ateproduct(discriminator):product Creates 1 Factory cre ateproduct(discriminator):product 56

57 Klasse Product ConcreteProduct CreationRequestor IFFactory Factory Beschreibung Die abstrakte Superklasse (oder das Interface) der Klassen, welche durch das Factory Method Pattern instanziiert wird. Die konkrete Klasse. Objekte dieses Typs werden durch das Factory Method Pattern erzeugt. Die applikationsunabhängige Klasse, welche die instanziierten Objekte der Factory benützt. Das applikationsunabhängige Interface, das die Methode deklariert, welche zum Erzeugen der konkreten Objekte benötigt wird. Die applikationsspezifische Klasse implementiert das passende Factory Interface und besitzt die Methode zum Erzeugen der konkreten Objekte 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(); 57

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(); 58

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: ) 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 59

60 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 Client Applikation Server DBMS EJB DATA Service Locator - Zugriff auf JNDI - CACHE für ServerObjekte 60

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(); 61

62 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 Client Applikation Server DBMS EJB DATA Business Delegate - Kapselung der BusinessLogik 62

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:... 63

64 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 Client Applikation Server EJB DBMS DATA Business Delegate ValueObject 64

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; 65

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());... 66

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. 67

68 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 Client Applikation Server EJB EJB DBMS DATA Session Façade 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); 68

69 9.6 Weitere Pattern im J2EE Umfeld 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 Composite Entity Business Objekte sind oft nicht einfache Strukturen, sondern Graphen von Attribut Knoten. Ein Beleg hat Belegzeilen, und jede Belegzeile kann wieder mehrere Kostenrechnungsinformationen 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 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. 69

70 9.6.4 Core J2EE Patterns 70

71 10 Programmiereinschränkungen (Regeln) kein Threads Management oder Synchronisation in (EJB) Beans - ist Aufgabe des Applikationsservers - Bean = einzelner Thread, keine Kongruenz keine Klassenvariablen / -methoden verwenden - verschiedene Prozesse bei Cluster-Deployment kein stdin / -out verwenden - Input- / Outputstream sind nicht definiert kein direkter Zugriff auf Dateien oder Directories - nicht definierter Speicherort bei Cluster- Deployment keine native Libraries - nicht definierter Speicherort bei Cluster- Deployment keine this Referenz - SessionContext.getEJBObject(); - EntityContext.getEJBObject(); 6 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. 71

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.// 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. 72

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 73

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 74

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 {... 75

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" " <ejb-jar>... </ejb-jar> Verpackt in eine jar-datei (EJB 2.1) <?xml version="1.0" encoding="utf-8"?> <ejb-jar xmlns=" xmlns:xsi=" xsi:schemalocation = " 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 ( Dabei werden die entsprechenden javadoc-kommentare ausgewertet. Den Deployment-Descriptor erfassen viele Application Server auch per Formular. 76

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 77

78 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 ejb-jar.xml ENC Elements (ENC = Enterprise Naming Context) jboss.xml : bescheibt Informationen für den Application Server - JNDI-Mapping: Name unter dem das Home- Interface gefunden wird - Resource Referenzen jboss.xml ENC Elements (ENC = Enterprise Naming Context) <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> 78

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> 79

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> 80

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 JDBC API Klassen und Schnittstellen der: java.sql 12.2 Währungsrechner mit Session-Beans JDBC API 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" 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-sqlscript" das in der build.xml Datei vorbereitet ist. Für die Datenbank Anbindung fokussieren wir zwei Varianten: "JDBC" und "JNDI Lookup": 81

82 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); 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"); 82

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. 83

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 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; 84

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 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!) 85

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 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. 86

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 87

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 >=? 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. 88

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) { 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 89

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> 90

91 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() { 91

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. 92

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. 93

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. 94

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)); 95

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. 96

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(); 97

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? 98

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' ' <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> 99

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 100

101 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 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. Web-Browser http "pull" HTML Web-Server Servlet-Engine Applications 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. 101

102 16.4 Lebenszyklus Web-Server Destroy Container Shutdown started destroy Methode Start Process Requests 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. Auftrag A Auftrag B Auftrag C Servlet basierter Webserver JVM Servlet A Servlet B Servlet C Prozess 102

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 Parameters send vom Client (Browser) 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: z.b: aresponsewriter.write(<html CODE>); 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" " <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> 104

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; 105

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 106

107 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 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 Funktionsweise http Web-Browser HTML Web-Server JSP-Engine 1. Aufruf HTML JSP-Seite Eine JSP-Seite ist ein Textdokument und besteht aus: - HTML- Code - JSP-Code / JSP-Tags - Java Anweisungen (http) Servlets (HTML) compiler *.class JSP Java-Datei (Servlet) 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. 107

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 Aufbau von JavaServer Pages Datei - ASCII- Datei - JSP-Datei Ressourcen - HTML-Datei - JSP-Datei JSP-Seite - Ausdrücke - Skiptlets - Deklarationen - Direktiven Java Klasse Tag-Libraries - JSP-Tags JSP-Seite - Ausdrücke - Skriptlets - Deklarationen - Direktiven Java Bean Eigenschaften - setter - getter 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 : " %><br> <%= new Date() %><br> Ausgabe: Hallo zwei + drei : 5 Thu Jan 01 00:08:30 GMT+01:

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" %> 109

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> 110

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 %> 111

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"/> 112

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 Vordefinierte Variablen Innerhalb einer JSP-Seite sind einige Variablen vordefiniert, die innerhalb von Scriptlets und Ausdrücken verwendet werden können: application (ServletContext) config (ServletConfig) exception out(printwriter) page(this) pagecontext (PageContext) request (HttpservletRequest) response (HttpServletResponse) session (Httpsession) speichert Daten, die von mehreren JSP- Seiten genutzt werden können, z.b. DB Zugriff übergibt Initialisierungen der Servlet- Konfiguration enthält Exception-Objekt bei einer Exception, falls: <%@ page errorpage = "true" %> gibt die Daten an die HTML-Seite aus stellt die Referenz auf das Servlet während der Laufzeit der JSP-Seite zur Verfügung ermöglicht den Zugriff auf die Attribute der JSP-Seite enthält Informationen über die aktuellen Anforderungen an die JSP-Seite (Parameter, etc.) bearbeitet den HTTP Response Header / HTTP Status Code speichert Informationen über die aktuelle Session 113

114 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 Browser JSP EJB DB 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 Erstellen Sie eine entsprechende Applikation mit JSPs. Benutzen Sie dazu die Referenzbeispiele der lokalen TOMCAT Installation. Ansatz : Browser Window 114

115 Ansatz: JSP mit DBTags um mysql DB abzubinden taglib uri=" 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(); 115

116 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: Subject 0..* interface Principal SamplePrincipal 0..* Object SamplePrincipalCredential public Credentials 0..* private Credentials SamplePrivateCredential 116

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 aufrufenden 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> 117

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. 118

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. 119

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 120

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> 121

122 18.3 Client-Tier Sicherheit 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(); 122

123 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 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- 123

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 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". 124

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 User: "admin" Principal: admin User: "user" Principal: user User: "guest" Principal: guest JBOSS (Vendorspecific) Role: staff Role: customer J2EE Role Reference: staff Role Reference: customer 125

126 18.10 ejb-jar.xml Security Elemente Die folgende Graphik zeigt die Security Related Elements des ejb-jar.xml Deployment Descriptors Ü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"); 126

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(); Ü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: 127

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"); 128

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 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 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. 129

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 Teiltransaktionen aufgeteilt werden. In dem Sequenzdiagramm startet die Applikation (BOT = begin of transaction) zunächst eine Teiltransaktion 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 Zwei Phasen Commit Allerdings kann es zu inkonsistenten Zuständen kommen, falls die Datenbank, die für Teiltransaktion 2 zuständig ist, vor dem Empfang der zweiten Commit-Anweisung ausfällt. Beim Neustart 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"). 130

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 131

132 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() Transaktions- Manager DB Java Client Anwendung oder Applikationsserver JDBC JMS Ressourcen- Manager DB Ressourcen- Manager Ressourcen- Manager JMS- Server 132

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. 133

134 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. 134

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. 135

136 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> 136

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. 137

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. 138

139 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> 139

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 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 : ID : 2 OWNER : Client 2 BALANCE : Thread started : transfer 1 -> 2 : Thread finished ID : 1 OWNER : Client 1 BALANCE : 0.0 ID : 2 OWNER : Client 2 BALANCE :

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"); 142

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[ ]: transfer 17:24:33,500 INFO [STDOUT] beans.accountbean@1881bb1[ ]: deposit 17:24:33,500 INFO [STDOUT] beans.accountbean@1667cff[ ]: 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() getbalance() withdraw() getowner() Required Required Required Required RequiresNew Required Supports Required Supports Transaktionsattribut Required Supports NotSupported Required Supports Required Transaktions- Verhalten NotSupported Required Required NotSupported NotSupported NotSupported 143

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 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. 144

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. 145

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 146

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. 147

148 Bean Life Cycle Container initiated: does not exist ejbremove() Methode-Ready-Pool Container initiated: setmessagedrivencontext ejbcreate() Container initiated: onmessage() setsessioncontext ejbcreate - wird vor ejbcreate ausgeführt - gibt Zugang zu Informationen über Laufzeit-Umgebung - 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 onmessage - wird vom Container aufgerufen um Pool zu verkleinern - Schliessen von Ressourcen - 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. 148

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(); 149

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(); 150

151 D EJB 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 151

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. Annotationen werden diese Abhängigkeiten transparent durch den Kontainer an die Java Beans angebunden. 152

153 Optionale Callbacks Entwickler müssen nur noch die Callbacks implementieren die sie brauchen. Auch hier @PrePersist, 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. 153

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 // (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: = Referenz auf EJB-Komponenten = Referenz auf public class MySessionBean private DataSource customerdb; public void mymethod (String mystring) { try { Connection conn = customerdb.getconnection();... catch (Exception ex) public class MySessionBean { private DataSource private void setcustomerdb(datasource customerdb) { this.customerdb = customerdb; public void mymethod (String mystring) {... Connection conn = customerdb.getconnection();

156 Injection von "Singletons" im Container javax.ejb.sessioncontext ctx; javax.ejb.messagedrivencontext ctx; javax.ejb.timerservice timer; javax.ejb.usertransaction ut; 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 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 Callback-Annotationen für Lifecycle Events - vordefinierte Callbacks - gekennzeichnet durch - 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 156

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 annotiert Bean-Klasse als Stateless Session Bean Component Interface (Remote- oder Business Interface): public Interface EJB3 { public void sayhello(); Bean public class EJB3Bean implements EJB3 { public void sayhello() { return "Hello EJB3 World!"; 157

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() kann beliebige Methode der Bean Klasse sein 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 public void closeaccount(); Bean public class AutomaticTellerEJB3Bean implements AutomaticTellerEJB3 { public void depositmoney(float amount) { accountbalance += amount); public void withdrawmoney(float amount) { accountbalance -= amount); public float getaccountbalance() { return public void closeaccount() {... // do something do cleanup 158

159 21.10 Message Driven Bean Ein MDB muss entweder Annotation gekennzeichnet werden oder das Callback-Interface javax.ejb.messagedrivenbean implementieren 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 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 159

160 public class Product { EntityManager 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) 160

161 Beispiel: = "PURCHASE_ORDER") public class Order implements java.io.serializable { private int id; private double total; private Collection<LineItem> = 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(); = CascadeType.ALL, fetch = = "order_id") public Collection<LineItem> getlineitems() { return lineitems; public void setlineitems(collection<lineitem> lineitems) { this.lineitems = lineitems; 161

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 162

163 Dynamische Abfragen, Named-Queries // Erzeugen einer name="findallcustomerswithname", querystring = " SELECT c FROM Customer c WHERE c.name LIKE :custname" )... // Nutzen einer 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. 163

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 164

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 "downkompatible", 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 bezogen und lokal installiert werden. J2SE installieren: ausführen: von: jdk-1_5.exe [CD]\install\j2se oder von J2EE installieren: ausführen: von: j2eesdk-1_4.exe [CD]\install\j2ee oder von 165

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 oder direkt unter bezogen werden und folgendermassen installiert werden: zu einem lokalen Verzeichnis dekomprimieren (Verzeichnisstruktur sollte keine Leerzeichen enthalten, wie z.b. "Eigene Dateien"): entpacken: von: nach: eclipse-sdk-3.2-win32.zip [CD]\install\eclipse...\ee bevorzugte Plug-Ins installieren, z.b: Quantum DB Explorer: entpacken: von: nach: Quantum_2.4.5_for_Eclipse_3.zip [CD]\install\eclipse plugins...\ee\eclipse\ 166

167 bevorzugte Plug-Ins installieren, z.b: XMLBuddy: entpacken: von: nach: xmlbuddy_ zip [CD]\install\eclipse plugins...\ee\eclipse\plugins weitere Eclipse Plug-Ins unter: Eclipse starten Im Insallationsverzeichnis auf das entsprechende Icon klicken. 167

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 JBoss ist das Produkt einer OpenSource Developer Community die das erklärte Ziel hatte, den besten J2EE-compliant Applikationsserver auf dem Markt zu entwickeln Developer weltweit - JBoss ist heute wahrscheinlich der verbreitetste EJB Server 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 Installation Die aktuelle Version von JBoss kann als ZIP Datei von bezogen werden und folgendermassen installiert werden: zum lokalen Verzeichnis C:\ee dekomprimieren (Verzeichnisstruktur sollte keine Leerzeichen enthalten, wie z.b. "Eigene Dateien") entpacken: von: nach: jboss ga.zip [CD]\install\jboss oder JAVA_HOME Umgebungsvariable als Benutzer- oder Systemvariablen entsprechend der installierten JDK Version definieren/ergänzen: 168

169 25.2 JBoss AS starten / stoppen - das run.bat Skript in \bin Verzeichnis der JBoss Installation ausführen - mit den JBoss Server testen. - CTRL+C, shutdown.bat oder über die Management Konsole kann der JBoss Applikations Server gestoppt werden 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 169

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: von: nach: Verzeichnis [JBoss_Home]\server\default [JBoss_Home]\server\ee 170

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 ga-bin.jar oder aktuellen Connector/J von ins Verzeichnis [JBoss_Home]\server\ee\lib kopieren: kopieren: von: nach: mysql-connector-java bin.jar [CD]\install\mysql [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 Namensund 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: nach: anpassen: mysql-ds.xml [JBoss_Home]\server\ee\deploy benutzerspezifisch konfigurieren 171

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 ga\bin\ - run -c ee Das entsprechende Script um den Server zu stoppen ist: - shutdown -S 172

173 26 mysql Datenbankserver installieren und Datenbank erstellen mysql ist eine der verbreitetsten Open Source Datenbanken und wird von vielen Organisationen kommerziell benutzt Installation entpacken: von: nach: mysql-noinstall win32.zip [CD]\install\mysql oder c:\ (entziptes Verzeichnis umbenennen zu umbenennen zu mysql!) 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: von: nach: mysql-gui-tools-noinstall-5.0-r2-win32 [CD]\install\mysql oder c:\ 173

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' 174

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 Entwicklungsumgebung. Information und Beispielanwendungen sind unter 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 : Version : > <project name="enterpriseeducation Packaging and Deploy Script" default="deploy" basedir="."> <!-- Property Datei: Applikationsspezifische Parameter --> <property file = "${basedir/properties/enterpriseeducation.properties" /> 175

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" /> 176

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.nameappclient.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.nameappclient.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.namehome.class" /> <include name="${ejb.dir/${app.name.class" /> </fileset> <fileset dir="${resources.dir"> <include name="jndi.properties" /> </fileset> </jar> 177

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.nameclient" fork="yes"> <classpath> <pathelement path="jar/${app.nameappclient.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: 178

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 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 bin.jar # SQL Skript Datei sql.data=create_rates_table.sql # Benutzereinstellungen für DBMS user=root password= database=ee 179

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: 180

181 28 Tomcat Tomcat Version 5 implementiert die Servlet 2.4- und JavaServer Pages 2.0 Specifikation, definiert durch den Java Community Process und beinhaltet viele zusätzliche Funktionen die eine Entwicklung und das Deployen von Web Applikationen unterstützen 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-Konfigurationsdatei [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 Konfigurationsdatei der Web Application. - In die Webserver-Konfigurationsdatei [TOMCAT_HOME]\conf\server.xml muss die Web Application mit einem Context-Element angemeldet werden. 181