MicroProfile with fault tolerance and configuration
In times of ever changing business requirements, it is very important for Java EE to have the ability to react fast and accurate to those changes. As of now its heavyweight process is a great handicap compared to more lightweight frameworks such as Spring. In this context heavyweight means that the whole process of including new features and releasing new versions of the whole stack takes multiple times (even years!). That’s where MicroProfile, a part of the Eclipse Foundation, comes into play.
But in the past few releases, more and more very useful specifications were included, for example MicroProfile Config and MicroProfile Fault Tolerance. Let’s find out what they are basically good for and how to work with them.
Eclipse MicroProfile config
MicroProfile config is a solution to externalize configuration from microservices. The configuration properties are provided by so called ConfigSources, which are ordered according to their ordinal, with a higher value taking priority over a lower one. For example, in Websphere Liberty this means that if the same configuration is set in server.env (ordinal=300) and in microprofile-config.properties (ordinal=100), then the value from server.env will be used. By default, there are 3 default ConfigSources:
All META-INF/microprofile-config.properties files on the ClassPath. (default ordinal=100, separately configurable via a config_ordinal property inside each file)
The following diagram demonstrates MicroProfile Config running in WebSphere Liberty. The server.env contains configurations with the ordinal of 300, while the files jvm.options and bootstrap.properties provide configurations with the ordinal of 400.
The default values can be specified in the file microprofile-config.properties within the application and the value can be overwritten for each deployment later on.
Fault tolerance is about leveraging different strategies to guide the execution and result of some logic. Retry policies, bulkheads, timeouts and circuit breakers are popular concepts in this area. They dictate whether and when executions should take place, and fallbacks offer an alternative result when an execution does not complete successfully. Since covering all these aspects would be way too much at once, we will focus on just one of those: Circuit Breaker.
A circuit breaker offers a way of failing fast by automatically failing execution to prevent a system overload and indefinite wait or timeout by the clients.
Now that you have a basic idea what MicroProfile Config and MicroProfile Fault Tolerance mean, let’s see how property configuration and a circuit breaker work from a technical point of view.
After adding the MicroProfile dependency in you pom.xml, you can set up a simple class and just @Inject the configuration, which will then be available to the outside. Of course this is a very basic example of the configuration usage. It comes especially in handy when deploying your application to different environments and you are in the need of different values for the same property key.
/** If one request fails in a rolling window of 2 requests, the circuit
* will be opened. The circuit will remain in the open state for 5 seconds
* and then switch to half-open state. During the half-open state,
* if a request fails, the circuit will switch back to open state.