Der Schwarm: Java EE Microservices mit WildFly

Seit Kurzem ist die erste Alpha des neuen WildFly-Beiwagen Swarm verfügbar. Es soll sich damit genau so viel Applikationsserver zusammen mit der eigentlichen Anwendung verpacken lassen wie nötig ist, um ein ausführbares Java-Archiv zu erhalten. Dieses "single jar application"- oder auch "fat jar"-Konzept wird oftmals als der richtige Ansatz für Microservices-Architekturen angesehen.

Derzeit häufen sich die Neuigkeiten aus dem Bereich Java EE. Neben dem neuesten Release-Kandidaten des WildFly-9-Anwendungsservers ist auch von Java EE 7 ein sogenanntes Maintainance Release (MR) vorbereitet worden. Und auch der Java EE 8 JSR ist ja schon seit längerem offiziell verfügbar. Dennoch hinken diese Neuigkeiten aus dem klassischen Java-EE-Stack den aktuellen Entwicklungen hinterher. Die Worte "Container" oder "Microservices" sucht man in der Spezifikation vergebens. Zumindest für die auf Basis von WildFly erstellten Anwendungen schließt sich diese Lücke ein kleines Stückchen.

WildFly Swarm: ausführbare Microservices

Swarms "single jar application"- oder auch "fat jar"-Konzept wird von einigen als der richtige Ansatz für Microservices-Architekturen angesehen. Ohne darüber jetzt weiter philosophieren zu wollen, ist es durchaus spannend, sich dieses neue Release etwas genau anzuschauen. Beim folgenden Beispiel möchte ich betonen, dass es einfach nur ein Beispiel für eine Technik ist und sie nicht den einzig richtigen Weg für Microservices darstellt.

Gegeben sei eine einfache, Maven-basierte Java-EE-7-Webanwendung. Im pom.xml steht als Abhängigkeit nur:

<dependency>
        <groupId>javax</groupId>
        <artifactId>javaee-web-api</artifactId>
        <version>7.0</version>
        <scope>provided</scope>
    </dependency>

Es wird eine 6-KByte-WAR-Datei gebaut. Läuft sie auf WildFly, führt ein Aufruf von http://localhost:8080/swarm/rs/customer zu einer simplen JSON-Ausgabe:

{
    "firstName": "Markus",
    "lastName": "Eisele",
    "streetAddress": "Werner-von-Siemens-Ring 14",
    "city": "Grasbrunn",
    "pcode": "85630",
    "phoneNumbers": [
        {
            "type": "mobile",
            "number": "111-111-1111"
        },
        {
            "type": "home",
            "number": "222-222-2222"
        }
    ]
}

Soweit ist das alles nicht spannend. Um aus dieser einfachen Anwendung ein eigenständig ausführbares Archiv zu machen, kommt jetzt Swarm ins Spiel. Dazu muss dem gerade erstellten Projekt einfach ein neues Plug-in hinzugefügt werden:

<plugin>
   <groupId>org.wildfly.swarm</groupId>
   <artifactId>wildfly-swarm-plugin</artifactId>
   <version>${version.wildfly-swarm}</version>
   <executions>
       <execution>
           <phase>package</phase>
           <goals>
              <goal>create</goal>
           </goals>
       </execution>
   </executions>
</plugin>

Die Versionsnummer setzt man am besten via Property im Maven pom.xml. Derzeit ist Swarm als 1.0.0.Alpha1 verfügbar. Eine kleine Warnung sei hier für Windows-Anwender ausgesprochen. Genau diese Version läuft noch nicht auf Windows. Der neueste Master enthält den Fix aber schon, und wer Swarm selbst schnell lokal baut und den 1.0.0.Alpha2-SNAPSHOT verwendet, kann das Ergebnis auch auf Windows anschauen.

Das Plug-in macht aber nicht die ganze Arbeit allein. Über die Abhängigkeiten (Dependencies) sind noch die verwendeten Java-EE-Features hinzuzufügen. Für das kleine Beispiel ist das nur die JAX-RS-Funktion:

<dependency>
<groupId>org.wildfly.swarm</groupId>
<artifactId>wildfly-swarm-jaxrs</artifactId>
<version>${version.wildfly-swarm}</version>
<scope>provided</scope>
</dependency>

Dann kann das Projekt via mvn package gebaut werden. Neben dem erwarteten Ergebnis, der swarm-sample-1.0-SNAPSHOT.war-Datei, ist jetzt auch das deutlich größere swarm-sample-1.0-SNAPSHOT-swarm.jar im target/-Verzeichnis gelandet. Es hat jetzt knapp 30 MByte.

Das fette JAR testen

Bleibt eigentlich nur noch der Start und Test der nicht ganz so kleinen JAR-Datei:

java -jar swarm-1.0-SNAPSHOT-swarm.jar 

Die Ausgabe gibt einen Hinweis auf diverse Versionen der verwendeten Subsysteme. Jetzt noch der Test:

C:\>curl -v http://localhost:8080/rs/customer
* Connected to localhost (::1) port 8080 (#0)
> GET /rs/customer HTTP/1.1
> User-Agent: curl/7.30.0
> Host: localhost:8080
> Accept: */*
>
< HTTP/1.1 200 OK
< Connection: keep-alive
< Content-Type: application/json
< Content-Length: 221
< Date: Fri, 08 May 2015 07:59:00 GMT
<
{"firstName":"Markus","lastName":"Eisele","streetAddress":
     "Werner-von-Siemens-Ring 14","city":"Grasbrunn",
          "pcode":"85630","phoneNumbers
":[{"type":"mobile","number":"111-111-1111"},
     {"type":"home","number":"222-222-2222"}]}* Connection #0 to 
           host localhost left intact

Wer noch weitere Spezifikationen einsetzen will, findet auf dem Swarm-Blog mehr Details. Unterstützt werden aktuell Servlet, JAX-RS mit ShrinkWrap, DataSource via Deployment, Messaging und einiges andere mehr.

Feedback und Mitarbeit ist erwünscht. Wer möchte, findet alle Informationen auf dem @WildFlySwarm-Twitter-Handle. Wer Funktionen vermisst oder Fehler findet, kann direkt beim GitHub Projekt mitarbeiten. ()