[
https://issues.apache.org/jira/browse/CAMEL-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on CAMEL-17154 started by Steve Storck.
--------------------------------------------
> 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
>
> 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.3.4#803005)
