[
https://issues.apache.org/jira/browse/CAMEL-17154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Storck updated CAMEL-17154:
---------------------------------
Description:
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.
was:
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.
> 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, Camel Dynamic Router Component
> (Blog Post Draft).pdf
>
>
> 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)
