Ansprechen des Models im JUnit-Test

Ist das Build-Skript erstellt, getestet und fehlerfrei, ist das System bereit für den nächsten Schritt: In der Admin-Konsole des GlassFish-Servers müssen Sie nun den Upload bestimmen und können bald danach die Webapplikation bereits direkt aus dieser Konsole heraus starten!

In diesem Film sehen Sie die Veränderung bzw. Erweiterung des ant-Build-Skripts in Richtung automatischer Updates: Wichtigster Punkt ist es, das .war-File in den Ordner 'autodeploy' zu kopieren. - Danach bekommt der Client ohne weiteres Zutun die immer aktuellste Version Ihrer Webapplikation.

In einer allgemeinen Einführung stellt der Autor die Platzierung der Enterprise Java Beans ('EJB') in einem Diagramm dar. Damit werden die Vorteile durch den Einsatz von EJBs schneller klar: Trennung der Geschäftslogik von der Darstellungsschicht, Wiederverwendbarkeit und Portabilität.

Je nach Aufruf unterscheidet man zwischen zwei Typen von Enterprise Java Beans: Die synchrone Version nennt sich 'Session Beans', die asynchrone 'Message Driven Beans'. Diese beiden unterscheiden sich in der Dauer und dem Zeitpunkt der Verbindung zwischen den drei beteiligten Instanzen: Client - Application-Container - Backend.

Die Einführung der EJBs zieht einige Veränderungen im bestehenden Workspace mit sich: Ordner müssen neu angelegt und der Build-Prozess erweitert werden. Außerdem stellt der Autor die Verwendung des Interfaces 'Serializable' sicher und sorgt für 'serialVersionUIDs'.

Wichtig für die Session Beans ist die Schnittstelle, über die sie aufgerufen werden. Daher befasst sich dieser Film auch besonders mit der Implementierung der Remote-Interfaces.

Wenn erst einmal das Remote-Interface und die implementierende Klasse angelegt sind, fehlt nur noch der Client: Über einen 'NJDI-Namen' und ein Objekt vom Typ 'InitialContext()' kann der Zugriff vom Client auf die serverseitige Methode erfolgen.

'Message Driven Beans' sind asynchron aufgerufene serverseitige Komponenten. Ein Messaging-Service garantiert dabei, dass eine Nachricht vom Client exakt einmal bei einer Nachrichten-getriebenen Komponente landet. Dafür müssen Sie eine Klasse anlegen, einen Listener anmelden - und diesen auch konfigurieren!

Für den Client müssen Sie wieder einmal eine neue Klasse anlegen, die die Aufgabe übernimmt, der serverseitigen Komponente über JMS Nachrichten zuzusenden. Sie bauen Verbindungen und Sessions auf, erzeugen und versenden die Nachrichten und beenden die Applikation.

Festhalten - hier kommt ein geniales Java-System für alle, die Daten aus Instanzen in Datenbanken speichern - oder Daten aus Datenbanken für Objektinstanzen verwenden möchten: Die JPA bietet entsprechende Methoden an und überwacht über den 'Entity Manager' die Konsistenz der Daten!

Welche Schritte sind nötig, um JPA in Ihren eigenen Anwendungen unterzubringen - und welche Bestandteile müssen mindestens vorhanden sein? Eine Konfigurationsdatei, einige 'Pojos' mit Annotations für den Entity Manager ... Und ein Client, der das Ganze aufruft.

Damit JPA auf Datenquellen zugreifen kann, müssen diese in der Administratorkonsole angelegt werden. Dieser Film zeigt die Optionen für 'JDBC Resources' und 'Connection Pools' und die Verbindung zur Konfigurationsdatei 'persistence.xml'.

Nun geht es darum, der vorhandenen Klasse 'SessionClient' beizubringen, die vorbereiteten und am Application-Server angelegten Datenzugriffe auch tatsächlich umzusetzen. Im Beispiel legt der Autor mehrere Objekte an und lässt eines davon später wieder suchen.

Klaus Baumgartner demonstriert die Verfolgung der Datenquellen-Definition von der xml-Konfigurationsdatei über den Pool-Namen bis hin zur Connection und dem echten Namen der SQL-Datenbank. Danach nutzt er das OpenSource-Tool 'SQuirreL', um die JDBC-Datenbank einzusehen.

Jedes Pojo ('Plain Old Java Object') sollte eine ID haben, damit die JPA es schafft, diese Objekte zur Laufzeit eindeutig zu Datensätzen in der DB zuzuordnen. Dafür sind nun einige Nachbesserungen an verschiedenen Stellen notwendig.

Wenn immer wieder dieselbe Abfrage durchgeführt wird, ist es sinnvoll, diese Query zu benennen. Das funktioniert über Annotations und erspart Ihnen einiges an Tipparbeit.

Wenn ein Pojo für sich alleine steht, ist die Umsetzung in die Tabelle klar – was aber, wenn es dazu eine Sub-/Superklasse gibt? Klaus Baumgartner stellt zwei mögliche Lösungen vor: Entweder werden alle Daten aller Klassen in einer Tabelle gespeichert oder pro Klasse eine eigene Tabelle verwaltet.

Für JEE5-Programmierer ist es wesentlich zu wissen, welche Zustände es für JPA Entitäten gibt: Im Wesentlichen sind es drei Zustände, die eine Entität haben kann, bis es irgendwann zum vierten, dem gelöschten Zustand kommt ...

Der Großteil des Wegs liegt hinter Ihnen, schon jetzt ist die Applikation dank serverseitiger Java-Programmierung weit vorangeschritten. Nun verändert Klaus Baumgartner die Model-Schnittstelle, um den File-Provider durch ein Remote-Interface zu ersetzen.

Wenn bloß alles so einfach wäre: Da die bereits verwendete Factory-Klasse eine Methode erbt, die eine 'providerClass' anspricht, muss nur die entsprechende Methode implementiert werden und dabei ein Remote Interface bestimmt werden.

Diese Bean enthält die serverseitige Implementierung der Businesslogik und das Remote Interface, über das der Client die Bean anspricht. Interessant ist die Umsetzung der Methoden zur Bearbeitung der Entitäten, wobei es sich der Autor auf raffinierte Art und Weise einfach macht.

Um die Web-Oberfläche dazu zu bringen, statt des File-Providers den EJB-Provider zu verwenden, muss die Konfiguration verändert werden. Eine einzige Zeile in einer Initialisierung definiert, welcher Provider beim Deployment eingesetzt wird: Ändern Sie diesen, wird mit dem nächsten Deployment ein EJB-Provider verwendet!

Die Java Enterprise Edition 5 ist viel umfangreicher, als es dieses Video-Trainig zeigen kann. Klaus Baumgartner nutzt den letzten Film, um Ihnen einige Themen schmackhaft zu machen, die tiefer in das Thema JEE5 führen.