Turn the web frontend into a service

At this point the web frontend still resides with WildFly. So we turn it into a Swarm service before we proceed, to be able to run it locally. Make sure to also advertise it as a service, like we did in Step 3. Once this is done we don’t need WildFly anymore. It’s good to terminate the process to avoid port conflicts.

When you turn the everest module into a swarm service, you change the packaging of war to jar. This also requires you to move the web resources from src/main/webapp to src/main/resources.

Introducing fault-injection techniques and hystrix for resilience.

Before thinking about resilience it’s actually useful to inject faults to demonstrate the need for enhanced fault handling capabilities. Appendix A contains some information on how to use a fault-injection proxy to easily achieve this.

Once we can simulate faults, we implement a circuit breaker using Hystrix and complete this activity by installing the Hystrix dashboard to monitor IPC interactions and the system state.

Hystrix runs the command in it’s own thread pool. Doing that in a EE environment requires you to think twice about what that demarcation actually means.
step 5.png
Figure 1. Fault detection and handling


  • Bulkheads and circuit breaking (hystrix)

  • Fault injection techniques


  • Start each service, but this time include the web frontend that moved from WildFly: java -Dswarm.project.stage=production -Dswarm.bind.address=<PUBLIC_IP> -Dconsul.host=<CONSUL_IP> -jar target/everest-web-swarm.jar

  • Focus on a single service, for instance the order service and it’s client invocation. (The client to the order service is the web frontend)

  • Redirect traffic through the fault injection proxy. For the sake of simplicity you may just change the service lookup URL in ConsulDiscovery.java

  • Prepare the Fault-injection proxy to introduce random errors (i.e. HTTP 503, see Appendix A)

  • Use the web frontend to order books and watch it fail randomly

  • Add the hystrix dependency to the maven pom.xml (everest module)

  • Add a hystrix command to the order client that can handle (i.e. compensate) the faults


  • You can run the web frontend using java -jar (no need for WildFly deployment anymore)

  • After adding the circuit breaker, your service client you handle the faults gracefully

  • The web frontend remains operational, the service doesn’t cascade through the system

Alternative Activities

  • Caching of the catalog service responses to fallback gracefully

  • Examine possible circuit thresholds (i.e. at what point do we permanently open the circuit)?

  • Replace the home baked service lookup for the frontend with the topology service. It’s bound to JNDI (see WildFly Swarm documentation)