Schritt 5: Session Beans

Transkript

1 Prof. Dr. Th. Letschert FB MNI JEE Schritt 5: Session Beans Session Beans Übersicht Session Beans dienen dazu serverseitige Geschäftsprozesse zu realisieren. Es gibt sie drei Zustands Varianten: Stateless Stateful Singleton Eine Stateless Session Bean ist nicht unbedingt zustandslos, sie hat keinen Client spezifischen Zustand. D.h. ruft ein Client eine Methode einer solchen Bean auf und verändert dabei deren Zustand, dann ist nicht garantiert, dass diese Veränderung in einem folgenden Aufruf durch den gleichen Client sichtbar ist. Bei einer Stateful Session Bean ist dagegen genau das garantiert. Modifikationen des Zustands einer Bean sind in Folgeaufrufen durch den gleichen Client sichtbar. Eine Singleton Session Bean hat die Eigenschaft, dass ihr keine Client spezifischen Zustände zugeordnet sind, sondern nur ein globaler Zustand, der für alle Clients sichtbar ist. Zustandsänderungen durch einen Client sind damit auch für andere Clients sichtbar. Session Beans können auf unterschiedliche Arten erstellt werden. Es gibt sie in den Deploymenmt Varianten völlig ohne Interface mit lokalem Interface mit entferntem Interface Session Beans mit ihren Interfaces Bean mit Remote Interface Session Beans sind Komponenten eines im Prinzip verteilten Systems. Sie können aus der Ferne, d.h. aus einem anderen Prozess heraus, angesprochen werden. Dazu ist prinzipiell ein nicht unbeträchtlicher technischer Aufwand notwendig. Ein Server Prozess muss laufen, er muss Verbindungen annehmen, eintreffende Anfragen dekodieren, die richtigen Methode des richtigen Objekts aufrufen, das Ergebnis kodieren und über die Verbindung zurück senden. All dies ist für den EJB Programmierer weitgehend transparent. Allerdings kann er die Mechanismen nicht völlig ignorieren. Er muss sich bewusst sein, dass auf Clientseite ein Proxy Objekt erzeugt wird das die Daten sendet und empfängt. Damit werden alle Daten per Wertübergabe transferiert: Eine Operation auf Referenzen ist nicht möglich. Das Proxy Objekt muss die gleiche Schnittstelle haben wie das Objekt, das es vertritt. Seine Implementierung ist natürlich eine radikal andere. Die Schnittstelle wird als Remote Interface definiert. Das Interface wird von der Bean Klasse und dem (automatisch erzeugten) Proxy Objekt implementiert.

2 Zu einer Session Bean gehört also eine implementierende Klasse und ein Remote Interface. In unserer Compute EJB hatten wir das Remote Interface: import public interface GlobalComputeBeanRemote { String compute(string operator, String operand1, String operand2); und als implementierende Klasse import javax.ejb.localbean; import javax.ejb.stateless; import javax.jws.webservice; * Session Bean implementation class public class GlobalComputeBean implements GlobalComputeBeanRemote { * Default constructor. public GlobalComputeBean() public String compute(string operator, String operand1, String operand2) { Die Annotation Stateless informiert den Container darüber, dass es sich um eine Stateless Session Bean handelt. Sie kann mit einem optionalen Parameter versehen werden, mit dem JNDI Name gesetzt wird und einer Beschreibung die vom Applikationsserver verwendet werden kann. description="die rechnende Bean") public class GlobalComputeBean implements GlobalComputeBeanRemote { Wird kein Name angegeben, dann ist der (voll qualifizierte) Name der Klasse der JNDI Name der Bean. Es ist sicher sinnvoll bei der Vergabe der Namen einem sinnvollen Schema zu folgen. Z.B.: import public interface ComputeBeanRemote { String compute(string operator, String operand1, String description="die rechnende Bean") public class ComputeBeanImpl implements ComputeBeanRemote { 2

3 Bean mit Local Interface Wird eine Bean nicht über Prozessgrenzen hinweg genutzt, also nur innerhalb der gleichen JVM Instanz, dann handelt es sich um einen lokalen Aufruf. Der Aufruf Mechanismus ist in dem Fall wesentlich einfacher. Ein Aufruf durch ein Servlet der gleichen Applikation ist beispielsweise immer ein lokaler Aufruf. Auch für einen lokalen Aufruf wird ein Interface benötigt. Die Definition ist äquivalent zur der eines entfernten Interfaces. Das Interface wird public interface ComputeBean { String compute(string operator, String operand1, String operand2); Die Implementierung implementiert public class ComputeBeanImpl implements ComputeBeanRemote { Invertierte Local / Remote Annotation Die Local und die Remote Annotationen können invertiert verwendet werden: Das Interface wird dann nicht versehen. Die implementierende Klasse holt dies nach. Beispielsweise wird das Interface definiert: public interface ComputeBean { String compute(string operator, String operand1, String operand2); In der Implementierung wird dann statt dessen die Interface public class ComputeBeanImpl implements ComputeBeanRemote { Mit der Remote Annotation kann genauso verfahren werden. Session Beans ohne Lokales Interface Eigentlich sollte eine Komponente immer ein definiertes Interface haben. Auf das lokale Interface kann aber trotzdem verzichtet werden. Mit der vor der Implementierungsklasse wird gesagt, dass es sich um eine Session Bean mit no-interface view handelt. Sie kann lokal über alle öffentlichen Methoden zugegriffen werden public class ComputeBeanImpl { Die Annotation ist unnötig, wenn die Bean Klasse kein Interface explizit implementiert. In dem Fall wird sie so behandelt, als sei sie mit annotiert. Die Methoden dürfen nicht final sein, denn der Container generiert via Ableitung eine Proxy Klasse über die der tatsächliche Zugriff abläuft. 3

4 Stateless Session Beans Kein Conversational State Stateless Session Beans sollten für alle Aufgaben verwendet werden, bei denen keinerlei Zustandsinformationen innerhalb der Bean verwaltet werden sollen. Typischerweise sind ist das bei einfachen Berechnungen der Fall. Der Zustand der Konversation mit bestimmten Clients kann natürlich extern gespeichert und verwaltet werden. Das ist aber normalerweise wenig sinnvoll. Es ist einer Stateless Session Bean auch erlaubt Objektvariablen zu verwenden. Modifikationen der Objektvariablen sind aber nicht unbedingt für nachfolgende Methodenaufrufe des gleichen Clients sichtbar. Stateless Session Beans werden vom Container nach eigenen Regeln erzeugt und in Pools verwaltet. Methodenaufrufe werden dann rein nach Effizienz Gesichtspunkte einer Bean zugeordnet. Damit kann keine conversational state in einer solchen Bean verwaltet werden. Wer weiß, welche Bean Instanze dem nächsten Methodenaufruf zugeordnet wird. Diese Art der Verwaltung macht Stateless Session Beans besonders effizient, so dass sie grundsätzlich für alle Aktivitäten verwendet werden sollen, die vom individuellen Client unabhängig sind. Life Cycle Wie es sich für eine Container Komponente gehört, hat jede Session Bean einen Lebenszyklus der vom Container gesteuert wird. Der Lebenszyklus einer Stateless Session Bean ist besonders einfach: does not exist method ready pool Die Bean wird vom Container erzeugt und in den method ready Pool eingefügt. Ab dann ist sie bereit Methoden auszuführen. Mit annotierten Methoden kann die Bean sich in die Zustandsübergänge public class GlobalComputeBean implements GlobalComputeBeanRemote public void initialize() { date = new Date(); // schreibt in die Log-Datei: System.out.println("GlobalComputeBean put into method ready pool at public void finalize() { Stateful Session Beans Life Cycle Eine Stateful Session Bean hat einen etwas komplexeren Lebenszyklus, als eine Stateless Session Bean. Da sie mit einem Client verbunden ist, muss sie eventuell sehr langlebig sein. Der Container muss eine Stateful Session Bean nicht während ihrer gesamten Lebenzeit im Hauptspeicher vorhalten. Der Container kann sie vorübergehend auslagern. Dieses Auslagern wird passivate genannt und das darauf folgende spätere Einlagern nennt sich activate. 4

5 Auf beide Ereignisse kann die Bean zusätzlichen Methoden public class MyBeanImpl implements MyBean public void initialize() public void finalize() public void getreadyforsleeping() public void getreadyforworkagain() { Conversational State Stateful Session Beans werden genau einem Client zugeordnet. Verwendet also ein Servlet eine Stateful Session Bean, dann wird dem Servlet exklusiv eine Stateful Session Bean zugeordnet, die dann einen Servlet spezifischen Conversational State verwaltet. Nehmen wir unser Standardbeispiel des zählenden Rechners: import javax.ejb.localbean; import javax.ejb.stateful; * Session Bean implementation class public class CountingBean { private int counter = 0; * Default constructor. public CountingBean() { public String compute(string operator, String operand1, String operand2) { String result = "?"; counter++; int v1 = Integer.parseInt(operand1); int v2 = Integer.parseInt(operand2); if ( operator.equals("add") ) result = " "+(v1 + v2); else if ( operator.equals("sub") ) result= "Value: "+(v1 - v2); else throw new IllegalArgumentException("Unexpected Operation: "+operator); result = result + " Counter: " + counter; catch (Exception e) { result = "ERROR: " + e; return result; 5

6 Das Servlet dazu: package servlets;. import compute.countingbean; * Servlet implementation class public class ComputeServlet extends HttpServlet { private static final long serialversionuid = private CountingBean computebean; HttpServlet#doPost(HttpServletRequest request, HttpServletResponse response) protected void dopost(httpservletrequest request, HttpServletResponse response) throws ServletException, IOException { response.setcontenttype("text/html;charset=utf-8"); PrintWriter out = response.getwriter(); out.println("<html><body>"); String operand1 = request.getparameter("zahl1"); String operand2 = request.getparameter("zahl2"); String operator = request.getparameter("operation"); String result = computebean.compute(operator, operand1, operand2); out.println("ergebnis: " + result); catch (NumberFormatException e) { out.println("fehlerhafte Eingabe"); out.println("</body></html>"); Man darf dabei nicht die unterschiedlichen Konzepte einer Session vermischen. Die Web Anwendung verwaltet Benutzer Sessions. Dies haben aber nichts mit dem conversational state der Bean zu tun. Servlets werden wieder verwendet. Ein Servlet ist typischerweise in vielen Benutzer Sessions involviert. Der Partner der Bean ist ein Servlet. Es gibt eine Session zwischen Bean und Servlet. D.h. der Zähler wird mit jedem Zugriff erhöht und die (End ) Benutzer sehen die Erhöhung durch andere (End ) Benutzer. Wenn wir eine Stateful Session Bean haben wollen, deren conversational state an eine (End Benutzer Session gebunden ist, dann muss die Bean von einem Objekt angesprochen werden, dass spezifisch für eine End Benutzer Session ist. Beispielsweise ein HttpSession Objekt. Eine solche Bindung kann leider nicht über die ach so bequeme Dependency Injection erzeugt werden. Expliziter Zugriff auf eine Session Bean Wenn wir explizit, also ohne Dependency Injection auf eine Bean zugreifen wollen, dann muss sie Remote sein. Wir definieren darum die Bean zum zählenden Rechen neu mit einem Remote Interface: import public interface CountingBean { 6

7 public String compute(string operator, String operand1, String operand2); und der Implementierung: import javax.ejb.localbean; import javax.ejb.stateful; * Session Bean implementation class public class CountingBeanImpl implements CountingBean { private int counter = 0; * Default constructor. public CountingBeanImpl() { public String compute(string operator, String operand1, String operand2) { String result = "?"; counter++; int v1 = Integer.parseInt(operand1); int v2 = Integer.parseInt(operand2); if ( operator.equals("add") ) result = " "+(v1 + v2); else if ( operator.equals("sub") ) result= "Value: "+(v1 - v2); else throw new IllegalArgumentException("Unexpected Operation: "+operator); result = result + " Counter: " + counter; catch (Exception e) { result = "ERROR: " + e; return result; So jetzt kann das Servlet eine Session spezifische Bean erzeugen: package servlets; import java.io.ioexception; import java.io.printwriter; //import javax.ejb.ejb; import javax.naming.initialcontext; import javax.naming.namingexception; import javax.servlet.servletexception; import javax.servlet.annotation.webservlet; import javax.servlet.http.httpservlet; import javax.servlet.http.httpservletrequest; import javax.servlet.http.httpservletresponse; import javax.servlet.http.httpsession; import compute.countingbean; * Servlet implementation class public class ComputeServlet extends HttpServlet { private static final long serialversionuid = 1L; //@EJB 7

8 private CountingBean computebean; HttpServlet#HttpServlet() public ComputeServlet() { super(); HttpServlet#doGet(HttpServletRequest request, HttpServletResponse response) protected void doget(httpservletrequest request, HttpServletResponse response) throws ServletException, IOException { dopost(request, response); HttpServlet#doPost(HttpServletRequest request, HttpServletResponse response) protected void dopost(httpservletrequest request, HttpServletResponse response) throws ServletException, IOException { response.setcontenttype("text/html;charset=utf-8"); HttpSession session = request.getsession(); if (session.isnew()) { InitialContext ctx = new InitialContext(); computebean = (CountingBean) ctx.lookup("compute.countingbean"); session.setattribute("compute_bean", computebean); else { computebean = (CountingBean) session.getattribute("compute_bean"); catch (NamingException e) { e.printstacktrace(); PrintWriter out = response.getwriter(); out.println("<html><body>"); String operand1 = request.getparameter("zahl1"); String operand2 = request.getparameter("zahl2"); String operator = request.getparameter("operation"); String result = computebean.compute(operator, operand1, operand2); out.println("ergebnis: " + result); catch (NumberFormatException e) { out.println("fehlerhafte Eingabe"); out.println("</body></html>"); So nun hat jede Benutzersession ihre eigene stateful Session Bean. Singleton Session Beans Von einer Singleton Session Bean erzeugt der Container nur eine Instanz. Die Definition erfolgt mit Hilfe der Wie alle anderen kann eine Singleton Bean lokal, remote oder Interface los sein. Sie unterstützt die gleichen Lifecycle Annotationen wie eine Stateless Bean. Gibt es mehrere Singleton Beans in einer Applikation, dann kann deren Start mit Annotation in eine (Halb ) Ordnung gebracht werden. Annotation erlaubt die Angabe einer Liste von Singleton Beans, die vor dieser zu aktivieren sind. Beispiel: 8

9 public class MySecondSingletonBeanImpl implements MySecondSingletonBean { Nebenläufigkeit und Session Beans Stateless und Statefull Beans Stateless Session Beans werden generell nicht nebenläufig genutzt, für jeden zugreifenden Thread wird eine eigene Instanz aus dem Pool verwendet. Falls keine weitere Instanz im Pool verfügbar ist, dann werden die Zugriffe serialisiert. In jedem Fall ist der Zugriff auf eine Instanz einer Stateless Bean niemals nebenläufig. Stateful Session Beans werden nicht in Pools verwaltet sondern haben eine feste Beziehung zu ihrem Kunden. Dieser Kunde kann nebenläufige Zugriffe auf eine Instanz einer Stateful Session Bean ausführen. Der Container muss diese dann serialisieren. Die Zeit die ein Kunde wartet bis er an der Reihe ist, kann mit Annotation konfiguriert werden. Da ein nebenläufiger Zugriff ausgeschlossen ist, sollte Stateful und Stateless Session Beans keine Synchronisationkonstrukte verwenden. Singleton Beans Instanzen einer Singleton Bean werden grundsätzlich nebenläufig genutzt. Zur Sysnchronisation kann man sich einer von zwei Methoden bedienen: 1. Container Managed 2. Bean Managed Bei einer Bean mit Container Managed Concurrency übernimmt der Conainer das Lock Management. Der Anwendungsentwickler muss lediglich bei jeder Methode angeben, welche Art von Lock verwendet werden soll. Möglich ist damit eine Leser/Schreiben Synchronisation die mit Annotationen Eine Methode ohne entsprechende Annotation wird so behandelt, als sei annotiert. Wird eine Stateless Bean mit ConcurrencyManagement(BEAN) annotiert, dann handelt es sich um eine Bean mit Bean Managed Concurrency. Der Anwendungsentwickler kann dann den gegenseitigen Ausschluss nach eigenem Ermessen realisieren. Asynchrone Methoden Bei einem synchronen Methoden Aufruf blockiert der Aufrufer bis die Methode endet. Bei einem asynchronen Aufruf wartet der Aufrufer nicht auf das Ende der Methode. Annotiert man eine Methode mit Asynchronous dann wird sie asynchron aufgerufen. Eine asynchrone Methode hat typischerweise kein Ergebnis, d.h. sie hat den Ergebnistyp void. Eine asynchrone Methode kann außer noch den Ergebnistyp Future<V> für irgendeinen Typ V haben. In dem Fall liefert der Aufruf sofort ein Objekt vom Typ Future<V>. Dieses Objekt repräsentiert die laufende Berechnung und kann später genutzt werden, um auf auf das Ergebnis vom Typ V der Berechnung zurück zu greifen. 9

10 Asynchrone Methoden sind also eine legale Art im EJB Container Threads zu erzeugen. Als Beispiel nehmen wir wieder die Bean von oben und modifizieren sie. Zunächst wird die Methode im Interface annotiert: import java.util.concurrent.future; import javax.ejb.asynchronous; import public interface CountingBean public Future<String> compute(string operator, String operand1, String operand2); Die Implementierung wird angepasst. Natürlich ist das hier wenig sinnvoll. Eine sinnvolle Anwendung müsste die Möglichkeiten nutzen, die die Arbeit Futures bieten. import java.util.concurrent.future; import javax.ejb.asyncresult; import javax.ejb.localbean; import javax.ejb.stateful; * Session Bean implementation class public class CountingBeanImpl implements CountingBean { private int counter = 0; * Default constructor. public CountingBeanImpl() { public Future<String> compute(string operator, String operand1, String operand2) { String result = "?"; counter++; int v1 = Integer.parseInt(operand1); int v2 = Integer.parseInt(operand2); if ( operator.equals("add") ) result = " "+(v1 + v2); else if ( operator.equals("sub") ) result= "Value: "+(v1 - v2); else throw new IllegalArgumentException("Unexpected Operation: "+operator); result = result + " Counter: " + counter; catch (Exception e) { result = "ERROR: " + e; // Future (aus bekanntem Wert) als Ergebnis: return new AsyncResult<String>(result); Das Servlet muss jetzt natürlich darauf vorbereitet sein, dass ein Future public class ComputeServlet extends HttpServlet { private static final long serialversionuid = 1L; //@EJB 10

11 private CountingBean computebean; HttpServlet#HttpServlet() public ComputeServlet() { super(); HttpServlet#doGet(HttpServletRequest request, HttpServletResponse response) protected void doget(httpservletrequest request, HttpServletResponse response) throws ServletException, IOException { dopost(request, response); HttpServlet#doPost(HttpServletRequest request, HttpServletResponse response) protected void dopost(httpservletrequest request, HttpServletResponse response) throws ServletException, IOException { response.setcontenttype("text/html;charset=utf-8"); HttpSession session = request.getsession(); if (session.isnew()) { InitialContext ctx = new InitialContext(); computebean = (CountingBean) ctx.lookup("compute.countingbean"); session.setattribute("compute_bean", computebean); else { computebean = (CountingBean) session.getattribute("compute_bean"); catch (NamingException e) { e.printstacktrace(); PrintWriter out = response.getwriter(); out.println("<html><body>"); String operand1 = request.getparameter("zahl1"); String operand2 = request.getparameter("zahl2"); String operator = request.getparameter("operation"); // Future erzeugen (Berechnung anstossen) Future<String> futureresult = computebean.compute(operator, operand1, operand2); // Ergebnis aus Future abholen: out.println("ergebnis (aus Future): " + futureresult.get()); catch (NumberFormatException e) { out.println("fehlerhafte Eingabe"); catch (InterruptedException e) { e.printstacktrace(); catch (ExecutionException e) { e.printstacktrace(); out.println("</body></html>"); 11