In this activity we bring Swarm to the table. We look the basic concepts for building Swarm services and discover how to build and run it. This includes basic configuration options, like bind address, ports and logging.

In the previous step all services have been deployed to a single JVM (WildFly). Now we separate the order, catalog and user services and run each in their own JVM (could be thought of as another another host).

step 2.png
Figure 1. Each service within a separate JVM

Concepts

  • Swarm plugin

  • Uberjar

  • Fraction auto discovery

Tasks

  • Add a dependency to the Swarm BOM to the top level pom.xml, so all modules inherit the Swarm dependencies if needed. This includes the Swarm maven plugin.

  • Prepare each service module (pom.xml) to include the Swarm maven plugin (i.e. order, user, catalog)

  • Do a top level build (mvn clean install). This will create the -swarm.jar artifacts in all modules that you’ve added the Swarm plugin.

  • Run each service from the command-line java -jar <service-name>-swarm.jar -Dswarm.bind.address=<PUBLIC_IP> -Dswarm.port.offset=<PORT_OFFSET>

Note
Make sure you explicitly bind the services to <PUBLIC_IP>, i.e.: java -jar <service-name>-swarm.jar -Dswarm.bind.address=<PUBLIC_IP> -Dswarm.port.offset=<PORT_OFFSET>

Outcome

  • Swarm packages the required runtime components and your service into a distinct .jar file

  • You can each run service separately, without deploying it on WildFly.

  • The user interface, remaining on WildFly, still works as expected.

Documentation

Alternative activities

  • mvn -Dswarm.bind.address=<PUBLIC_IP> wildfly-swarm:run

  • Inspect the build process or resulting jar to see what things get packaged