[jira] [Updated] (CAMEL-17154) Create alternate dynamic router implementation that allows registration

["Steve Storck (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CAMEL-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Steve Storck updated CAMEL-17154:
---------------------------------
    Attachment: AddingProcessorToCore.md

> 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)