Session Beans & Servlet Integration. Ralf Gitzel

Transkript

1 s & Servlet Integration Ralf Gitzel 1

2 Themenübersicht Ralf Gitzel 2

3 Übersicht Motivation Aufbau einer Stateless s Stateful s Web Client Offene Antwort von letzter Stunde: Folie 55 3

4 Motivation für s Ralf Gitzel ralf_gitzel@hotmail.de 4

5 Motivation Web Container Servlet Sichtbarer Einstiegspunkt für das Servlet EJB Container DB Persistence Provider Entity 5

6 Mögliche Clients für eine Session Bean Servlet GUI-basierte Java Anwendung EJB Container Bel. Anwendung Web Service Entity 6

7 Client Szenarien Servlet Servlet Lokaler Zugriff Entfernter Zugriff 7

8 Rolle der s Stellen Geschäftslogik nach außen zu Verfügung Der JEE Client (z.b. ein Servlet) greift über die s auf die EJB Applikation zu Die s stellen die Session der JEE Anwendung dar 8

9 Session im EJB Kontext Session: Eine (virtuelle) Verbindung zwischen dem Client und dem Server, die eine endliche Zeitspanne anhält Lange Session: Stateful (merkt sich Daten zwischen Aufrufen) Kurze Session: Stateless (jeder Aufruf ist eine neue Session) 9

10 s Session Länge (lang vs. kurz) Entfernter vs. Lokaler Zugriff Stateful: Merkt sich den Zustand der Bean Stateless: Zustandslos, jeder Aufruf wie neu s Remote Interface Local Interface EJB Container Verschiedene Client Typen 10

11 Gruppendiskussion Was sind Vorteile einer gegenüber normalen Javaklassen im Servlet? Praktisches Beispiel: Was motiviert uns das Minimo-System auf EJBs umzustellen? 11

12 Aufbau der Ralf Gitzel 12

13 Elemente einer Remote Interface Interface(s) Local Interface Web Service Iface 13

14 Interfaces Jede muss mindestens ein Interface haben Methodennamen dürfen nicht mit der Buchstabenfolge ejb beginnen Ein Interface kann nur eine Annotation haben, d.h. man muss jedes Interface einzeln definieren 14

15 Local Annotation 15

16 Remote Annotation Alle Parameter müssen Serializable sein Einsatz wird hier nicht vertieft 16

17 Web Service Interface Kann nur für Stateless s definiert werden, da Web Services immer zustandslos Annotation, ohne Parameter Wird hier nicht weiter vertieft 17

18 Klasse Markierung mit Annotation: Stateless oder Stateful Implementiert Interface(s) Darf keine abstrakte oder final Klasse sein Methoden dürfen nicht final sein Kann von anderen Klassen erben (auch von anderen Klassen) Kann auch Methoden enthalten, die nicht im Interface definiert sind (diese dürfen aber auch nicht mit ejb beginnen) Muss einen parameterlosen Konstruktor haben 18

19 Stateless vs. Stateful Session Beans: @Stateless Jeder Aufruf ist eine neue Session, alle Daten sind vergessen! 19

20 Stateless vs. Stateful Session Beans: Stateful Eine Session, d.h. Daten werden zw. den Aufrufen gespeichert! 20

21 Vererbung der werden nicht vererbt Life Cycle Annotationen an den Methoden werden vererbt (s. später) 21

22 Stateless s Ralf Gitzel ralf_gitzel@hotmail.de 22

23 Stateless Implementierung (I) A.doX() A.doX() A.doX() EJB Container Klasse A A Objekt 1 A Objekt 2 A Objekt n Bean Pool Klasse B 23

24 Stateless Implementierung (II) EJB Container Klasse A A Objekt 1 A Objekt 2 A Objekt n Bean Pool Klasse B Client bekommt eine zufällige Instanz aus dem Pool zugewiesen! 24

25 Stateless Implementierung (III) Aufrufe hintereinander können bei unterschiedl. Objekten der gleichen Klasse enden! 1. Aufruf 2. Aufruf EJB Container Klasse A A Objekt 1 A Objekt 2 A Objekt n Bean Pool Klasse B 25

26 Gruppendiskussion Erklärt diese Implementierung, warum Stateless s keinen Zustand speichern können? Welche Vorteile bietet die Implementierung als Pool? 26

27 Local Interface der Bean Interface: minimo.help.ipersontaskmatcher im Projekt SessionBeansEJB Client-Aufruf erfolgt in minimo.servlet.setupassignpersonpagehandler 27

28 Beispiel Stateless (Parameter optional und im Moment unwichtig) Implementiert das Local Interface Klasse: minimo.help.persontaskmatcher im Projekt SessionBeansEJB 28

29 Client für s Wie besprochen über Dependency Injection (@EJB) In Ausnahmefällen JNDI Lookup (s. später) 29

30 Stateful s Ralf Gitzel ralf_gitzel@hotmail.de 30

31 Stateful Implementierung (I) Client I A.doX() EJB Container Klasse A Client II 1-zu-1 Zuordnung bis zum Ende der Session A.doX() A Objekt für I A Objekt für II 31

32 Passivierung Aktiv, d.h. im Hauptspeicher Keine Client Aktivität Erneute Client Aktivität Hält die Belastung des Hauptspeichers durch inaktive Sessions gering. Timeout: Sehr lange nicht verwendete Sessions werden ganz beendet. Passiv, d.h. auf der Platte gespeichert 32

33 Gruppendiskussion Was ist der Nachteil, was ist der Vorteil gegenüber einer Stateless Session Bean? Warum sind nicht alle s stateful? 33

34 Zusätzliche Programmier-Regeln Speicherung des Zustandes in den Instanzvariablen Instanzvariablen müssen serialisierbar sein (wegen möglicher Passivierung) Stateful s müssen explizit zerstört werden (s. Beispiel)! 34

35 Beispiel: Erschaffung einer WorkOrder Schritt 1: WorkOrder anlegen Schritt 2: Details einfüllen (kann übersprungen werden) Schritt 3: WorkOrder anzeigen und Prozess beenden 35

36 Bean Klasse Aufruf dieser Methode beendet die Session Anmerkung: Es kann mehrere Methoden geben! 36

37 Client Dependency Injection: Wenn eine Stateful eine andere Stateful SB verwendet Nicht: Wenn Stateless oder ein Servlet eine Stateful verwenden! Lösung für Servlets: Session Objekt des Servlets + JNDI Lookup (s. später) 37

38 Tipps zur Verwendung von Stateful s Lieber Stateless als Stateful (wenn möglich) Wegen der Kosten der Passivierung/Aktivierung und Clustering möglichst wenig Daten in einer Stateful speichern (z.b. lieber Lookup-Namen als ganzes Person-Objekt) Remove-Methode immer verwenden um verwaiste Sessions zu vermeiden (Anmerkung: Falls beim Server Passivierungsintervalle eingestellt werden können, kann en falscher Wert mehr Performanceschaden als nutzen verursachen) 38

39 Web Client Ralf Gitzel 39

40 JNDI vs. Injection Für Stateless s reicht i.d.r. Dependency Injection Für Stateful s benötigen wir einen JNDI Lookup 40

41 Konzept des JNDI Aufrufs aus einem Servlet (Automatisch) im Context anmelden Bean Informationen einstellen Context vom Container holen Eine Referenz auf die Bean aus dem Context holen Für weitere Verwendung in der HttpSession ablegen 41

42 JNDI Lookup Code im Servlet Klasse: minimo.servlet.workorderhandler (wird von CreateWorkOrder,jsp aufgerufen) 42

43 JNDI Code Lookup ohne echte Erklärung 1. JNDI Lookup vorbereiten (Namen aus dem EJB Deployment Descriptor verwenden! 2. für Attribut verwenden 3. ContextLookup: Ersten Teil einfach übernehmen, zweiter Teil ist der Name 4. Gewonnene Referenz in Session speichern, damit immer der richtige User zu dieser Bean geführt wird! 43

44 Name für den JNDI Lookup Anmerkung: Kann über das Attribut name Annotation 44 verändert werden

45 Weitere Verwendung der Stateful Am Ende: Aufruf Methode Auslesen aus der HttpSession Referenz auf das nicht mehr gültige Objekt aufgeben minimo.servlet.createdetailedworkorderfinalhandler 45

46 Lernziele Ralf Gitzel 46

47 Lernziele Stateful vs. Stateless verstehen Stateless programmieren können Stateful programmieren können Client mit/ohne JNDI Lookup erstellen können 47

48 Übungsaufgabe Ralf Gitzel 48

49 Aufgabenstellung Bauen Sie den Currency Converter der letzten Vorlesung so um, dass er sich alle bisherigen Ergebnisse merkt. Löschen der alten Ergebnisse erfolgt explizit über einen Link auf der Seite. 49

50 Bonusmaterial Ralf Gitzel 50

51 Probleme und Antworten Warum kriege ich eine NullPointerException bei Verwendung der Dependency Injection (z.b. Verwende ich die richtigen Versionen von EJB (3.0) und Servlets (2.5)? Manchmal ist Undeploy/Server-Stop/Server-Start/Deploy keine schlechte Idee. Was sagt das Glassfish/JBoss Server Log? Stateful? Dann brauchen wir JNDI und nicht Injection! Warum ist alles so langsam? Evtl. läuft der Server im Hintergrund und führt für jede Änderung ein Hot Deploy durch Server stoppen! 51

52 Voller Lebenszyklus der Stateful Sehr lange inaktiv Zerstörung Neue Anfrage Nicht existent Aktiviert Client länger Inaktiv Erneute Anfrage oder sehr lange inaktiv Passiviert (Auf Festplatte Ausgelagert) 52

53 LifeCycleCallBacks (I) Wenn man Ressourcen wie JDBC, Messaging usw. verwendet, dann muss man ggf. zu verschiedenen Zeitpunkten Ressourcen initialisieren oder freigeben Hierzu verwendet man die LifeCycleCallback Methoden, die automatisch aufgerufen werden, wenn ein bestimmter Zustand erreicht wird 53

54 LifeCycle Callbacks ist keine Callback Methode! Nach der Initialisierung der Klasse. (Z.B. Datenbank Kurz vor der Zerstörung. (Z.B. Datenbank Vor der Passivierung einer Stateless. (Z.B. Datenbank Nach der Aktivierung 54

55 Gruppendiskussion letzte Stunde: Was ist hier falsch? 55

56 Antwort zu letzter Stunde Web Container Servlet Web Container Servlet Java Klasse (Hello User) EJB Container EJB Container (Hello User) (Hello User) Das war gewollt Das passiert tatsächlich 56