[
https://issues.apache.org/jira/browse/CAMEL-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17473107#comment-17473107
]
Claus Ibsen commented on CAMEL-17154:
-------------------------------------
Steve, can you send a PR about the blog post to camel-website.
Take a look at some of the other blog posts, as you cannot use absolute urls to
the camel website itself, eg http:camel.apache.org links will fail - there is
some "xref:" or "link:" you need to do instead.
> 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, eip
> Affects Versions: Future
> Reporter: Steve Storck
> Assignee: Steve Storck
> Priority: Minor
> Labels: camel-component, dynamic-router, eip
> Fix For: 3.15.0
>
> Attachments: AddingProcessorToCore.md, camel-dynamic-router-blog.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 EIP component" 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.
> * Since the EIP description does not mention any re-circulation behavior, it
> will not provide that feature. Users can route a response back to the
> dynamic router if they need to.
> * The first recipient with rules that all match the exchange will be
> selected, and the exchange will be routed to its destination URI.
> * The registration message will include a recipient ID, a simple or complex
> Camel Predicate that evaluates to true or false, and the recipient's
> Endpoint, where messages that pass its rules evaluation will be sent.
> * Recipients will be able to unsubscribe at any time. Likewise, they can
> also subscribe at any time.
> * The rules will exist while a participant is subscribed, and only fur the
> duration of runtime – each time the Camel Context starts up, participants
> will have to register.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
