Redhat goes Microservice: Wildfly Swarm

Microservices sind im Moment in aller Munde und bei einigen Global Playern auch schon längst in Produktion (z. B. Netflix). Eine der Grundideen ist, eine Anwendung in kleine, in sich abgeschlossene fachliche Einheiten zu unterteilen, die jeweils eigenständig lauffähig sind (ohne Application Container) und untereinander über leichtgewichtige Protokolle kommunizieren (z. B. REST über HTTP). Die bisherigen Microservice-Frameworks verpacken in das WAR/JAR “nur” Webcontainer (Tomcat bei Spring Boot, Jetty bei Dropwizard). Von den klassischen Anbietern der Java EE Application Servern gab es bisher noch nicht viel, um self-contained Microservices zu erzeugen.

Das bisherige Programmiermodell von Java EE Anwendungen bestand eher darin, ein schlankes JAR/WAR mit dem Anwendungscode zu erstellen und dieses in einen Application Server zu deployen, welcher alle Java EE Implementierungen enthält. Der Microservice-Trend erklärt nun dieses klassische Deployment-Modell für tot, da in den meisten Fällen immer genau eine Anwendung in einem extra zu Verfügung gestellten Application Container installiert wurde.

Redhat hat nun mit Wildfly Swarm erste Alpha-Versionen zur Verfügung gestellt, um sogenannte Fat Jars zu bauen, in die neben der eigentlichen Anwendung auch der Wildfly Application Server integriert wird. Dabei sollen nur so viele Komponenten von WildFly zum Einsatz kommen, wie tatsächlich nötig sind, damit die Anwendung ihre Aufgabe erfüllen kann.

Herunterladen kann man Wildfly Swarm nirgends, es ist direkt über Maven Central verfügbar. Zum Aktivieren muss man in der pom.xml ein Plugin einbinden:

<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 für die Ausführung des Fat Jars notwendigen Teile des Wildflys gibt man dann als Dependencies an:

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

Das ausführbare JAR kann ganz einfach mit “mvn package” gebaut und anschließend ausgeführt werden. Der eingepackte Wildfly wird entsprechend hochgefahren, um die Java EE Anwendung zu starten.

mvn package
java -jar ./target/myproject-1.0-swarm.jar

Aktivierbare Subsysteme sind zum Beispiel Undertow für Servlets, JAX-RS, JNDI, Transactions, Messaging, Weld (CDI) u. a. Diese Subsysteme kann man auch programmatisch aktivieren und hat so die volle Kontrolle über die Server-Konfiguration (ähnlich wie bei Spring Boot). Dazu muss man eine Klasse mit einer main-Methode erstellen und diese in der MANIFEST.MF eintragen:

public class Main {

    public static void main(String[] args) throws Exception {
        new Container()
            .subsystem(new LoggingFraction()...)
            .subsystem(new UndertowFraction()...)
            .socketBindingGroup(new SocketBindingGroup()...)
            .start();
    }
}

Bob McWhirter (Leiter Forschungs- und Prototyp-Abteilung bei Redhat) empfiehlt Swarm im Moment noch nicht für den produktiven Einsatz. Er ist aber optimistisch, mit Hilfe der Community aktuelle Fehler zu beheben und bald ein stabiles Release anbieten zu können.

Short URL for this post: http://wp.me/p4nxik-2nR
This entry was posted in Build, config and deploy, Java EE, Java Runtimes - VM, Appserver & Cloud, Uncategorized and tagged , , , . Bookmark the permalink.

Leave a Reply