07.04.2017

Eine Schritt-für-Schritt Anleitung, wie man dieses Vorhaben konkret in Code umsetzt, finden Sie in meinem Artikel Zwei WARs kommunizieren auf einem Tomcat – Code

WAR steht bekanntlich für Web application ARchive und beinhaltet eine Webapplikation. Mehrere Webapplikationen können ganz einfach auf einem Tomcat deployed werden, indem sie in den Ordner Webapps vom Tomcat Server kopiert werden.

Nun ist es aber auch möglich, dass diese zwei Applikationen miteinander kommunizieren – Und ganz konkret meine ich damit: Dass zwei WAR Dateien gegenseitig ihre Java Methoden aufrufen und so Informationen austauschen oder Operationen anstossen können.

Zuerst einmal braucht es ein Shared Jar

Damit die beiden Applikationen miteinander reden können, braucht es zuerst eine JAR Datei mit den Schnittstellen. Konkret ist dies ein Java Projekt, welches public interfaces beinhaltet und welches am Ende in einer JAR Datei endet. Dieses muss dann auch auf den Tomcat deployed werden.

Diese Interfaces beinhalten die Methodenköpfe (Signaturen), welche von einem der beiden Webapplikationen implementiert werden müssen. Mithilfe dieser JAR Datei ist aber beiden Webapplikationen klar, wie die Schnittstellen zwischen ihnen aussehen und welche Parameter sie übergeben können.

Im Shared Projekt sind dann also die Interfaces, in einer der beiden Webapplikationen die effektive Implementation dieser Interfaces.

Das Geheimnis: Shared Class Loader

Wie ich in meinem Artikel Was ist ein class path/class loader in Tomcat? geschrieben habe, werden die Ressourcen von verschiedenen class loaders beim Starten von Tomcat geladen.

Wenn zwei Webapplikationen dieselbe JAR Datei verwenden, ist das normalerweise kein Problem. Beide Applikationen bekommen einfach eine Kopie davon und können unabhängig voneinander auf diese zugreifen. In unserem Fall wollen wir aber etwas anderes: Die JAR Datei soll quasi die Brücke zwischen den beiden WAR Dateien sein.

Damit Tomcat eine JAR Datei als externes Repository ladet, muss diese in den catalina.properties beim shared loader im richtigen Format angegeben werden:

shared.loader=file:/pfad/zur/datei/meinJar.jar

Deveveloper Tipp 1: Während man aktiv an der Applikation arbeitet, kann man alternativ auch einfach den Klassenordner zu den Klassen angeben, die am Schluss im Shared Jar verwendet werden:

shared.loader=C:/MyApplication/MyAppShared/target/classes

Und wie funktioniert das nochmals?

Ganz einfach: Man hat zwei WAR Webapplikationen, die man auf einen (!) Tomcat kopiert. Die kennen sich aber normalerweise nicht. Da wir aber nun noch eine JAR Datei mit den Schnittstellen laden, und dieses dem Tomcat shared beziehungsweise parent class loader mitteilen, kennen beide WAR Files diese Interfaces. Eine Webapplikation kann diese Interfaces nun implementieren und die andere Webapplikation kann diese aufrufen, womit die beiden Applikationen miteinander kommunizieren können.

Deveveloper Tipp 2: Wenn man an einer Webapplikation arbeitet, und die andere nicht zur Verfügung hat, kann man in einem Testprojekt selber die Implementation eines Interfaces vornehmen. So kann man zum Beispiel eine Methode einbauen, bei der die andere Webapplikation eigentlich eine Liste von Namen aus einer Datenbank lesen müsste – stattdessen gibt man für Testzwecke einfach hartcodiert eine Liste von ein paar Namen zurück.

Die zwei WAR Dateien müssen die JAR Datei als Dependency in der pom.xml Datei angeben. Das wiederum heisst, dass man am Besten Maven Projekte erstellt.

Gerne weise ich hier nochmals auf meinen Artikel Zwei WARs kommunizieren auf einem Tomcat – Code hin, der das Ganze als Codebeispiel zeigt und nach dessen Lektüre alles viel klarer sein sollte.