Runtime Reconfiguration Pattern

Intent

This pattern allows the externalizing and runtime behavior variability without requiring application redeployment.The Runtime Reconfiguration pattern is also known as the Runtime Variability pattern.

Context and problem

A business service can be composed of multiple short processing flows connected together. It is possible to change the internal behavior of the service without changing its public interface by rearranging the internal processing steps. In the Reusable Route pattern, we have seen how to reuse Camel routes by linking them together at deployment time. From an object-oriented point of view, that approach is similar to the structural Bridge design pattern where an abstraction (API in the integration world) and its implementation (the actual processing flow in the integration world) can vary independently.

Sometimes, the service’s structure and processing steps do not change; instead, the behavior of the individual processing elements must change at runtime. Perhaps a Message Filter EIP will have to use a regularly updated blocklist, or dynamically changing destinations for a Content Based Router (CBR). Certain configuration parameters affecting the processing flow will have to be regularly updated by the business. In similar situations, we need the ability to alter and reconfigure the behavior of a service without making code modifications or restarting the application every time.

Forces and solution

The solution for the above challenges is similar to the Strategy design pattern from the object-oriented world. The Strategy pattern lets us encapsulate behavior and vary it independently from the clients at runtime. Bridge and Strategy patterns have a similar structure but differ in the problem they solve. Bridge is a structural pattern that decouples the abstraction from the implementation at compile-time, whereas Strategy is a behavioral pattern that allows the changing of the behavior of an object at runtime.

The key for runtime behavior variability is to encapsulate and externalize the varying behaviors from the main processing flow through an extension point. This allows the processing flow and the dynamic behavior to have independent lifecycles and interact through this extension point.

Mechanics

Let’s see a few concrete examples that demonstrate different ways of achieving runtime behavior variability, i.e., the Runtime Reconfiguration pattern. We will start from simple approaches such as reconfiguration through property files and then go on to full dynamic runtime through a rule engine as part of the routing process.

Configuration-based variability

This category is self-explanatory, but we will mention it here for completeness. Using the properties component to decouple endpoints and EIP configurations from Camel routes is a good practice.

We will come back to this later ...