[
https://issues.apache.org/jira/browse/CAMEL-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17465228#comment-17465228
]
Steve Storck commented on CAMEL-17154:
--------------------------------------
[~davsclaus] I have pushed up a revision that I think is much more suitable.
Instead of using the seda component for the control channel, this update in my
fork of the repository uses an internal specialized channel for control
messages where participants can send their rules and a destination endpoint
URI. I also decided to forego the "robustness" strategy outlined in the
previous comment. If the dynamic router restarts, then it seems the entire
context/route would restart. If the subscriptions are lost, then that sounds
like the app restarted, so the participants would re-send their subscription
information anyway.
I have created a draft blog post to announce this component for whichever
release it makes it into. I am attaching the file to this ticket for review.
If you have time to check out my implementation, you can find it at
https://github.com/Steve973/camel/tree/CAMEL-17154/components/camel-dynamic-router
> Create alternate dynamic router implementation that allows registration
> -----------------------------------------------------------------------
>
> Key: CAMEL-17154
> URL: https://issues.apache.org/jira/browse/CAMEL-17154
> Project: Camel
> Issue Type: New Feature
> Components: camel-core
> Affects Versions: Future
> Reporter: Steve Storck
> Assignee: Steve Storck
> Priority: Minor
> Attachments: AddingProcessorToCore.md
>
>
> Since the current Dynamic Router processor is missing the implementation of
> some key concepts (including a control channel, and recipient registration),
> I need an alternate implementation of Dynamic Router that more closely
> implements the Dynamic Router enterprise integration pattern so that I can
> use this implementation in the cases where the original Dynamic Router would
> be less appropriate.
> If we look at the EIP at
> [https://www.enterpriseintegrationpatterns.com/DynamicRouter.html] we see
> that the key concepts are:
> * 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.
> * 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.
> * 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.
> * 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.
> * 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" with the key features that it is
> missing, and to allow control over more of its operation:
> * Add a Control Channel on which recipients will provide their registration
> information, or on which they will unregister.
> * Add a Dynamic Rule Base where the recipients' registration information
> will be maintained.
> * Modify the re-circulation behavior so that a flag for re-circulation can
> be used to turn it on or off.
> * 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.
> * 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.
> * 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.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
