[
https://issues.apache.org/jira/browse/CAMEL-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17453435#comment-17453435
]
Steve Storck commented on CAMEL-17154:
--------------------------------------
After looking into adding the processor to camel-core, and after talking with
[~davsclaus], I decided that this EIP would be better to implement as a
component. I have been using Kamelet and Bean as two examples to help to get
me started. As of now, I have coded an initial implementation, some unit
tests, and I have taken a first pass attempt at creating the asciidoc, though I
have a few questions about some of the links to other documents that I see in
the adoc files of Kamelet and Bean.
This is going to be similar to the content-based router with a recipient list
and a rule base that can change at runtime based on messages sent via the
control channel. That control channel will reside in the
DynamicRouterComponent class as a method annotated with {{@Consume}} that looks
at the {{controlChannelUri}} property for the URI that it consumes from. The
default is a {{direct:}} endpoint, so this module will need to include that
dependency.
At this point, I am not sure if the dynamic router component will be a
singleton or prototype for instantiation. The router, like the direct
component, can include a name in the URI for partitioning the router. This
means that it can be configured to have a logically separate set of
participating recipients, and their rules, for every named partition. I have a
few things to think about, and the outcome will determine if I have to change
my initial implementation. I am leaning towards allowing multiple
instantiation (prototype), so that the component URI will contain an ID for the
router, followed by an optional partition name (where "default" is used if
omitted), and a control channel URI parameter.
The EIP description recommends either of 2 strategies for robustness. Either a
participant's subscription is persisted, thereby allowing the rule base to be
reinstated if the component fails and needs to restart, or for the router to
send an announcement message for participants to (re)subscribe.
I will also eventually enable spring autoconfiguration. Perhaps all dynamic
routers will have an annotation that allows for automatic configuration in
spring, but I have nothing more than vague ideas at the moment.
> 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)
