Java EE 7: Geschäftsanwendungen

EJB-Client

LinkedIn Learning kostenlos und unverbindlich testen!

Jetzt testen Alle Abonnements anzeigen
Um die Funktion zu testen, bietet sich die Implementierung eines JUnit Test Cases an. Dies ist allerdings nicht trivial, denn den Zugriff auf die Komponenten, die der Server bereitstellt, muss man selbst implementieren.

Transkript

Das Testen einer Java-EE-Applikation ist nicht ganz triviel. Üblicherweise macht man dies mit Hilfe von, beispielsweise JUnit Test Cases. Diese laufen jedoch außerhalb der Java-EE-Applikation, was eigentlich auch gewünscht ist. Aber wie müssen nun innerhalb der JUnit Test Cases dafür sorgen, dass wie uns mit dieser Java-EE-Apllikation verbinden können. In diesem Video werden wir uns deshalb damit auseinandersetzen, wie wir uns als externer Client, also als extern nutzende Komponente mit einer Java-EE-Applikation in Verbindung setzen können, Wie wir sie also aufrufen können, und wir werden das Ganze für unsere CustomerBean implementieren, und zwar mit Hilfe eines JUnit Test Cases. Das Prinzip ist dabei relativ einfach: Ein EJB Client arbeitet stets immer nur mit einem Remote View. Das heißt, er sieht LocaBean, Local View und No Interface Views einfach nicht. Die Implementierung erfolgt dementsprechend anhand des Interfaces und der Proxy wird automatisch generiert. So weit, so einfach. Die Schwierigkeiten beginnen aber genau an der Stelle, wo der Proxy generiert werden soll, denn dafür muss ein sogenanntes Lookup vorgenommen werden. Der EJB Client muss selbstständig ein Lookup vornehmen, das heißt, er muss selbstständig nach der Komponente suchen und sich damit verbinde. Das Ganze geschieht per JNDI und das setzt voraus, dass wir den genauen JNDI-Pfad kennen, unter dem eine Komponente im Java-EE-Application Server veröffentlicht worden ist. Ebenfalls müssen wir das Zugriffsprotokoll kennen. Da gibt es verschiedene, zum Beispiel Remoting, oder Http-Remoting Ebenfalls müssen sich die Client Komponenten, also die Sachen, die der Client sehen soll. Das sind in unserem Fall, beispielsweise das CustomerDAO und die Entitäten und die Enumerations im Klassen-Pfad des Clients befinden, sonst kann er damit nicht arbeiten. Und natürlich muss auch ein Remote Interface bekannt sein. Sind alle diese Voraussetzungen erfüllt, arbeiten sind wir mit dem InitialContext. Den müssen wir konfigurieren und können ihn dann verwenden. Dabei kann es zu einigen durchaus fiesen Fallstricken kommen. Zum Beispiel der Fallstrick, dass das JNDI Lookup nicht erfolgreich ist. Dem kann man durch eine Google-Suche, beziehungsweise durch etwas experimentieren meistens Abhilfe schaffen. Ebenfalls gibt es einen ganz typischen Fallstrick, der weniger auf der technischen Ebene, als vielmehr auf der Implementiererebene liegt, nämlich dass der Implementierer sich die Zustandslosigkeit, beispielsweise von Singleton Session Beans nicht verinnerlicht hat, und deswegen versucht mit Dingen zu arbeiten, die gar nicht mehr da sind. Und ganz häufig die Objekte, die ausgetauscht werden, sind nicht als Serialisable implementiert. Das ist übrigens in unserer Applikation bisher der Fall. Deswegen wird das einer der ersten Sachen sein, die wir einpassen bevor wir ein EJB Client nutzen können. Um unsere Komponenten für ein, wie auch immer gearteten EJB Client nutzbar zu machen, müssen Sie das Interface "Serialisable" implementieren. Das ist zum Glück nur ein Marker Interface, das bedeutet, wir müssen hier gar nichts weiter an Code implementieren, wir notieren einfach nur "implements Serialisable". Damit das Ganze ordnungsgemäß funktioniert, lassen wir uns ebenfalls die automatische serialVersionUID generieren, das passiert bei jedem Kompilierungsvorgang automatisch und dient dem Auseinanderhalten von Versionen von Klassen. Das Ganze machen wir bei allen drei Entitäten. Also auch hier, bei der Address Entität, Serialisable implementieren und die serialVersionUID generieren lassen und dasselbe dann nocheinmal für die Communication Entität. Nachdem wir diese Vorausarbeit geleistet haben, sind wir nun in der Lage für einen noch nicht existierenden EJB Client alle benötigten Komponenten zu exportieren. Dies machen wir, indem wir einen Rechtsklick auf das EJB Projekt machen, und über das Kontextmenü die Option "Export" und dann die Zusatzoption "Export" auswählen. Hier wählen wir auf dem Bereich Java den Eintrag "JAR file" aus, klicken auf "Next" und entfernen nun die Häkchen vor den Dingen, die wir nicht exportieren wollen, weder .classpath noch .project Dateien wollen wir exportieren, auch nicht das Bildunterverzeichnis und aus unserem EBJ Modul wollen wir auf jeden Fall nicht exportieren die Implementierungen der Beans. Das ist klassische Geschäftslogik, die niemanden etwas angeht. genau dasselbe gilt für das META-INF Verzeichnis. Nachdem wir so festgelegt haben, dass die Interfaces die Entitäten und die Enums exportiert werden, können wir festlegen, wohin das Ganze exportiert werden soll. Und wir können diesem exportierten oder zu exportierenden JAR Archiv einen Namen geben. Ein Klick auf "Next" und auf "Finish" führt den Vorgang aus und wir haben nun einen Export vorgenommen, der von einem Client genutzt werden kann. Nun können wir unser Projekt einmal starten. Zu diesem Zweck führen wir einen Rechtsklick auf das Customer Management Projekt aus und wählen aus dem Kontextmenü die Option Run AsRun On Server. Wir wählen unseren WildFly Server aus und lassen das Projekt auf dem Server deployen. Dies dauert einige Sekunden und ist der Server hochgefahren und Eclipse wird versuche eine noch nicht existierende Webseite zu öffnen. Wechseln Sie nun in die Konsole. In der Konsole können Sie zum einen erkennen, dass wir hier diverse Hibernate Ausgaben haben, die uns aber im Moment noch nicht interessieren. Zum anderen, wenn Sie etwas hochscrollen, sehen Sie hier die JNDI Namen über die die Komponenten erreichbar sind. Uns interessiert der oberste Eintrag, nämlich "java:global", und dann kommt ja ein längerer Pfad. Alles was sich hinter "java:global" befindet, ist für uns von Interesse und wir sollten uns diese Zeichenfolge merken, denn über diese Zeichenfolge können wir von einem externen Testprojekt aus, dann mit unserer EJB interagieren. Und dieses externe Testprojekt werden wir nun anlegen. Zu diesem Zweck machen wir im Package Explorer einen Rechtsklick und wählen New Java Project. Wir können diesem Projekt einen schönen Namen geben, zum Beispiel CustomerManagementTests. Wir können alle Standardeinstellungen so stehen lassen. Bevor wir irgendetwas implementieren, müssen wir diesem Projekt erst einmal zwei Referenzen hinzufügen. Zu diesem Zweck machen wir einen Rechtsklick auf "Properties" und wechseln in den Bereich "Java Buid Path". Hier gibt es den Reiter "Libraries". Hier klicken wir auf "Add External JARs" und suchen das Verzeichnis, indem wir unsere Client Klassen vorhin exportiert haben. Wir öffnen dieses JAR Archive und fügen es damit hinzu. Nun klicken wir noch einmal auf "Add External JARs" und wechseln in dem Ordner, in dem der WildFly Server installiert worden ist. Das ist C, WildFly, vielleicht noch einen Unterordner und dann haben wir hier ein Bereich Bin und dadrin gibt es einen Ordner "Client". Und hier interessiert uns die jboss_client.jar Datei. Dir fügen wir ebenfalls als Referenz hinzu, klicken OK und haben damit den Build Path unseres Projektes ordnungsgemäß konfiguriert. Nun können wir per Rechtsklick auf das Projekt und dann dem Kontetmenüeintrag "New" an JUnit Test Case unserem Projekt hinzufügen. Diesen JUnit Test Case nennen wir "CustomerBeanTester" und er befindet sich im Package "com.cm.tests". Nun setzen wir noch das Häkchen vor der Option "setUp" generieren. SetUp ist eine spezielle Methode, die automatisch von jedem UNit Test ausgeführt wir und klicken auf die Schaltfläche "Finisch" Wir fügen JUnit zu unserem Build Path hinzu, falls das noch nicht der Fall sein sollte und löschen die Methode "Test", die sich jetzt hier schon drin befindet. Wie gesagt, die setUp Methode wird vor jedem Test ausgeführt, und die nutzen wir, um in dieser Methode unsere EJB zu referenzieren. Zunächst einmal generieren wir hier eine drei Catch Klausel, um Fehler, die beim Zugriff auf die EJB auftreten können abzufangen. Nun legen wir ein Hashtable vom Typ "String" und "Comparable" an. Diese Hashtable wird unsere Einstellungen für die Verbindungsaufnahme beinhalten. Wir fügen ebenfalls einige Einstellungen hinzu. Zum Beispiel, dass wir die "org.jboss.naming.remote.client .InitialContextFactory" benutzen wollen. Das Ganze machen wir mit Hilfe einer Konstanten, die sich innerhalb des Context Interfaces aus dem javax.naming Package befindet. Ebenfalls fügen wir eine Jboss spezifische Eigenschaft hinzu, nämlich dass der EJB Context aktiviert werden sollen, ausgedrückt über die "jboss.naming.client.ejb.context". Nun benötigen wir noch Informationen darüber, Wie auf unsere EJB zugegriffen werden kann. Dies geschieht über das Http-Remoting Protokoll, der Server ist unsere aktuelle Maschine, wir geben einen Benutzernamen und ein Kennwort an. Der nächste Schritt besteht nun darin, eine Instanz der InitialContext Klasse zu erzeugen. Dieser Instanz übergeben wir die eben festgelegten Einstellungen als Parameter in den Konstruktor. Zum Abrufen unserer EJB benötigen wir nun deren Lookup Namen, also den Namen, den diese Bean im JNDI haben wird. Das ist der Name, den wir vorhin schon im [unverständlich] des Applikation Servers gesehen haben und uns gemerkt haben. Und mit Hilfe dieses Namens und dem InitialContext den wir gerade eben erzeugt haben, können wir nun den eigentlichen Abruf oder den eigentlichen Zugriff auf unsere Bean vornehmen. Das Ganze speichern wir uns in einer Variablen auf Instanzebene, die wir natürlich als "privat" markieren und somit nun aus allen Methoden, die wir schreiben werden, heraus noch nutzen können. Lassen Sie uns nun einen Testfall erzeugen. Dieser Testfall ist eine ganz normale Methode, die mit der @Test-Annotation versehen ist. Innerhalb dieser Methode nehmen wir einfach nur an, beziehungsweise überprüfen wir, dass die CustomerDAO Instanz, die wir ja in der setUp Methode erzeugt haben, nicht Null ist. Ist dieser Test erfolgreich, wissen wir, dass wir grundsätzlich auf unseren Server zugreifen können. Wenn dies geklappt hat, können wir nun eine Customer Instanz anlegen und mit Werten befüllen. Die Customer Instanz ist unsere Entität, die wir vorhin mit exportiert haben. Das Geburtsdatum ist etwas schwierig zu setzen. Das müssen wir mit Hilfe einer JavaUtilCalendar Instanz machen und wir sollten unserem Kunden auch noch ein Geschlecht mitgeben, das machen wir über "Gender.Male" oder Female, je nachdem was Sie bevorzugen. Nun können wir diesen Kunden speichern und uns das Ergebnis zurückgeben lassen. Das machen wir über die Methode "create" der CustomerDAO Instanz, die wir vom Server abgerufen haben. Und auch hier wollen wir überprüfen, ob das Ganze erfolgreich war. Und diese Überprüfung können wir am einfachsten dadurch vornehmen, dass wir sagen, der ID Wert, der zurückgegebenen Instanz, muss ungleich Null sein. Weil Null ist der Standardwert und wenn das Speichern erfolgreich war, dann muss die Rückgabe eben einen anderen Wert beinhalten. Dies können wir am einfachsten überprüfen, indem wir den Test ausführen. Zu diesem Zweck machen wir einen Rechtsklick auf den Test und wählen Run AsJUnit Test. Nach einigen Sekunden ist der Test durchlaufen, und wir sehen hier, dass alles erfolgreich war, dass die Tests alle bestanden sind, ein grüner Balken signalisiert, dass alles gut war. Ein Blick in die MySQL Workbench erlaubt es uns erstens festzustellen, dass alle Tabellen automatisch erzeugt worden sind, und zweitens eine Abfrage auszuführen und dann das Ergebnis zu sehen. Unser Kunde ist erfolgreich angelegt und gespeichert worden. In diesem Video haben wir uns damit befasst, wie wir einen externen Client für eine Java-EE-Applikation aufsetzen können. Wir haben diesen Client konfiguriert und haben ihn über JNDI mit einer Bean in unserer Java-EE-Applikation interagieren lassen. Ebenso haben wir einen JUnit Test geschrieben, mit dessen Hilfe wir sicherstellen können, dass alles genau so funktioniert, wie wir uns das vorstellen, und zwar programmatisch, ohne dass wir irgendwelche Kommandozeilen, Ausgaben oder Konsolenausgaben überprüfen müssen.

Java EE 7: Geschäftsanwendungen

Verfolgen Sie, wie eine komplette Business-Applikation unter dem Einsatz des gesamten Java-Enterprise-Techologiestacks ensteht.

5 Std. 2 min (39 Videos)
Derzeit sind keine Feedbacks vorhanden...

Dieser Online-Kurs ist als Download und als Streaming-Video verfügbar. Die gute Nachricht: Sie müssen sich nicht entscheiden - sobald Sie das Training erwerben, erhalten Sie Zugang zu beiden Optionen!

Der Download ermöglicht Ihnen die Offline-Nutzung des Trainings und bietet die Vorteile einer benutzerfreundlichen Abspielumgebung. Wenn Sie an verschiedenen Computern arbeiten, oder nicht den ganzen Kurs auf einmal herunterladen möchten, loggen Sie sich auf dieser Seite ein, um alle Videos des Trainings als Streaming-Video anzusehen.

Wir hoffen, dass Sie viel Freude und Erfolg mit diesem Video-Training haben werden. Falls Sie irgendwelche Fragen haben, zögern Sie nicht uns zu kontaktieren!