Refactor router hierarchy to provide consistent approach for managing router mappings dynamically (e.g., ControlBus) [INT-1377]

[spring-operator]

Oleg Zhurakousky opened INT-1377 and commented

This would result in support for Dynamic Router pattern.

---

Affects: 2.0 M6

Sub-tasks:

• Add documentation about Dynamic Router support [INT-1514] #5507 Add documentation about Dynamic Router support

Issue Links:

• Inconsistent State Possible During Router Mapping Update [INT-2347] #6327 Inconsistent State Possible During Router Mapping Update

• Any multi-channel router should support channel name patterns [INT-1189] #5197 Any multi-channel router should support channel name patterns

[spring-operator]

Oleg Zhurakousky commented

Few notes as to what is being addressed as part of this refactoring
The goal is to unify router hierarchy to make it more consistent and make routers dynamic (see Dynamic Router pattern http://www.eaipatterns.com/DynamicRouter.html)

• Define ChannelResolver(CR) at the base AbstractMessageRouter. Default implementation of CR is going to be BeanFactoryChannelResolver. Remove MapBasedChannelResover. Later on we can add additional ChannelResolver implementations to optimize resolution process (e.g., CachingChanelResolver that could maintain a map of resolved channels with a refresh functionality)

• Define ChannelIdentifierMap<String, String> at the base AbstractMessageRouter and expose JMX friendly accessors/modifiers to change mappings at runtime.

The routing flow:

Initialization - If mapping is provided (e.g., PayloadTypeRouter - requires, HeaderValueRouter - optional) create channel identifier map as Map<String populating it with mapping data.
Runtime - 3 steps: 1) Compute channelIndicator. 2) Determine channelName (if mapping exists, get the channelName otherwise channelIndicator is the channelName), 3)Resolve channelName to the actual MessageChannel by delegating to ChannelResolver.

AbstractSingleChannelRouter is no longer needed.

Make PayloadTypeRuter and ErrorMessageExceptionTypeRouter more flexible with regard to dealing with payload types that might not have been available to the SI configuration during the compile time to accommodate scenarios where a particular payload type might have been loaded by a different Class Loader which is very common in the distributed, multi-class loader environment such as OSGi or even cross ApplicationContext message exchanges. Withe the state of the current refactoring, this functionality has already been implemented.
However one must be aware, that although iterating through payload type hierarchy for the type that is not visible to a current Class Loader is simple and doable, the payload type names that are entered into channelIdentifierMap are not pre-validated. They are just String values that have fully qualified class name - the name which will be compared to the type names during the introspecting the actual payload types. So the bottom line it is String.equals comparison.

[spring-operator]

Oleg Zhurakousky commented

Router hierarchy was restructured and now every router extends from AbstractMessageRouter.
AbstractMessageRouter also defines channelIdentifierMap which is a map of channelIdentifiers - the value that gets computed by the router (e.g., payloadTYpe for PTR and headerValue for HVR) to channelName.
So the flow is now as simple as this:

1. compute channel identifier
2. check if mapping exists for channelIdentifier in the channelIdentifierMap. If exists get the channel name othewise, the channelIdentifier becomes a channelName
3. Send channelName to ChannelResolver to resolve to real channel