This activity demonstrates the “default” way of installing services as regular .wars on WildFly, with two exceptions:

  • The services already use Consul for lookup and registration

  • All services interact over REST/HTTP, although being deployed to the same JVM

This step provides an overview of code that exists, possible service boundaries, module dependencies and allows you to make yourself familiar with the application use cases using the web frontend (which is something we want to retain)

step 1.png
Figure 1. Components within single JVM


  • Moving from In-VM communication to remote invocations (REST)

  • Service as single .war deployments

  • Service registration and discovery


  • Build the whole project. This results in several .war files

  • Deploy each .war file (order,catalog,user & everest) to WildFly. This can be achieved using mvn wildfly:<deploy|undeploy> in each respective module directory or through the WildFly admin console.

  • Access the everest web interface running on WildFly (http://<WILDFLY_IP>:8080/everest-web) and make yourself familiar with the application. Try to browse books, put one in your cart and checkout to complete the “purchase”.


  • The whole application, previously installed as a single deployment now runs on WildFly and it works as expected (choose books, add to cart, checkout, etc)

  • Although deployed to a single VM, the services already use the service registry (consul) to for lookup (opposed to let’s say JNDI).

  • Once all services are deployed, you can invoke the REST interfaces as well (i.e. using cUrl), i.e. http://<WILDFLY_IP>:8080/catalog/resources/catalog/


  • The existing sources, in particular the order, user, catalog for the services. Furthermore the services module for the consul integration and the “everest” module that contains the frontend.