A couple of things have bothered me with regard to the current implementation of the Dynamic Router EIP, because I believe that the EIP description was misinterpreted. I think that the current implementation is well enough for use cases where it is appropriate, and it provides a useful feature that works reliably. I think that it is a very loose interpretation of the EIP, and it misses some key points that makes the Dynamic Router EIP worthy of being its own pattern.
If we look at the EIP at https://www.enterpriseintegrationpatterns.com/DynamicRouter.html we see that the key concepts are: 1. Control Channel: A Dynamic Router implementation should provide a control channel, by which potential recipients can provide their rules that indicate if they can process a message. The current implementation does not seem to have any notion of a control channel. It appears that the current implementation interprets the Control Channel as a way for messages to be continuously re-circulated back through the Dynamic Router. 2. Recipient Registration: A Dynamic Router implementation should accept special registration messages via the Control Channel, at run-time, to allow a potential recipient to announce its presence and to provide the conditions under which it can handle a message. While nothing precludes the user of the Dynamic Router from implementing this, themselves, there is nothing in the current implementation to provide this. 3. Dynamic Rule Base: The Dynamic Router stores the registration information for each participant in a rule base that is not fixed, or static. This is the same as the previous point: any rule base is created as a decision tree at compile time, or the user must create their own Dynamic Rule Base mechanism. 4. Real-time Rules Evaluation and Routing: When a message arrives, the Dynamic Router evaluates all rules that are currently in the Dynamic Rule Base, and then routes the message to the recipient whose rules are fulfilled. Because of the two previous points, this is left up to the user to implement. 5. No Dynamic Router Dependency on Recipients: Recipients do not need to care about the Dynamic Router, and they do not need to care about evaluating rules. If they are able to process the message, the message will be sent to the recipient. I propose to create a "Dynamic Router 2", or to enhance the current Dynamic Router Processor with the key features that it is missing, and to allow control over more of its operation: 1. Add a Control Channel on which recipients will provide their registration information, or on which they will unregister. 2. Add a Dynamic Rule Base where the recipients' registration information will be maintained. 3. Modify the re-circulation behavior so that a flag for re-circulation can be used to turn it on or off. 4. Allow selection between two delivery methods of "first" or "all" to indicate if only the first recipient (where a message passes all of its rules) should receive the message, or if all suitable recipients should receive it. 5. When multiple recipients are suitable for accepting a message, and the Dynamic Router is set to deliver to all suitable recipients, the messages will be delivered in the same manner as a Recipient List. 6. The registration message will include a recipient ID, an ordered set of expressions that evaluate to true or false, and the recipient's Endpoint, where messages that pass its rules evaluation will be sent. In the Camel Java DSL, it might look like this: from("direct:start") // Either create with a rulebase object containing all of the rules .dynamicRouter(dynamicRuleBaseBean) // or create without the parameter and supply it this way .withRuleBase(dynamicRuleBaseBean) // boolean to enable or disable the current message recirculation behavior (until null) .withMessageRecirculation(false) // send to first suitable recipient, or to all that are suitable .withRecipientMode(DynamicRouterRecipientMode.FIRST); This way, the control channel is a bean that the Dynamic Router can read, and recipients can modify it when they come online, or depart, or when their rules need to be updated. I am also considering the possibility of using some kind of actual message channel so that a separate object does not have to exist outside of the Dynamic Router; it would be created and maintained by the DR, and recipients would send registration, deregistration, and update messages to it. If anyone has ideas about this, I would appreciate hearing them. Thank you for your time, and I look forward to hearing everyone's feedback. Steve
