Re: Issue CAMEL-17154: Request for comment and review

[Steve973 <st...@gmail.com>]

Hi, Claus.  Thanks for the feedback.  I think my perspective is a little
bit different, so let's look at it a slightly different way, and see what
you think.

To me, the usefulness of Camel comes with having so many things to choose
from.  Anything isolated might have quite limited usefulness when viewed on
its own.  But, the fact that you can compose your integration through
routing and mediation from a huge arsenal of components, processors, and
other tools, means that you can do quite a lot.  Now, Camel core already
has a dynamic router.  What is your opinion of its usefulness?  The
implementation, as it currently stands, is not inherently dynamic.  It uses
a routing slip, and you would have to "roll your own" routing slip that is
actually dynamic.  The re-circulation behavior is interesting, but it is a
misinterpretation of the control channel.

I see your point about the in-memory-only queue.  But, with the idea of
composition that I discussed above, a route that feeds the Dynamic Router
component can consume messages from anywhere, and the destination URIs can
be literally any of the endpoints that you can set up and use with Camel.
It is as scalable as a developer wants to make it.  It provides something a
bit similar to the dynamic router processor in core, but it is much more
dynamic without having the requirement of the developer to make the slip
dynamic.  It provides additional use cases to the dynamic router processor
in core.

This seems directly applicable to your statement about Camel being the
"glue".  This is yet more glue; I had originally wanted to make this
available alongside the current dynamic router in core, but I took your
advice and made it a component, instead.  Is it not OK for a component to
provide more glue?

Thanks,
Steve

On Fri, Jan 7, 2022 at 6:08 AM Claus Ibsen <cl...@gmail.com> wrote:

> Hi Steve
>
> We can see from your work that you have put a lot of effort and
> devotion into this, with an example and blog post as well.
>
> However you say that the reason you wanted this was due to the dynamic
> pattern in the EIP book.
>
> The issue is that the EIP book is about messaging and integration
> patterns and that these patterns
> does not apply to all software projects.
>
> The dynamic pattern as in the EIP book is actuall a pattern in
> messaging systems like ActiveMQ, Kafka, RabbitMQ, and all the many of
> them out there.
> They all offer a way for clients to subscribe and unsubscribe to
> topics (and or queues) and very often have filtering as well so a
> client can say they the only want message that matches X criteria.
>
> In other words its a domain that is for a messaging system, and this
> gets quickly complex when you have distributed systems, and HA with
> failover, and now also with "the cloud", and even across multiple
> cloud vendors with hybrid cloud.
> Your implementation in Camel would be very limited in use-case as its
> a single context / in-memory only "queue".
>
>
> If on the other hand there was a new messaging system (called foobar),
> and it was a well used system, then it would be worthwhile to
> implement a camel component for such system.
> In other words Camel is the glue to systems, but its "not a "server"
> system itself".
>
>
>
>
>
>
>
>
>
>
>
> On Sat, Dec 25, 2021 at 4:44 PM Steve973 <st...@gmail.com> wrote:
> >
> > Hello.  I have sent a few messages here on this list about an alternate
> > Dynamic Router EIP component implementation that I have been working on.
> > If anyone has some time, I would like to get more community input and
> > opinion on what I have done so far.  You can see the ticket here:
> >
> > https://issues.apache.org/jira/browse/CAMEL-17154
> >
> > It contains a link to the component module on my fork of the Camel repo
> (in
> > the comments), and I have included a blog post draft ODT attachment that
> > introduces this component, why I wanted to implement it, and basic
> > discussion on how to use it.
> >
> > If any of you would be kind enough to take a quick glance and let me know
> > what you think, I would be quite grateful.
> >
> > Happy holidays, if you are celebrating.  Take care, and be well,
> regardless.
> >
> > Thanks,
> > Steve
>
>
>
> --
> Claus Ibsen
> -----------------
> http://davsclaus.com @davsclaus
> Camel in Action 2: https://www.manning.com/ibsen2
>

Re: Issue CAMEL-17154: Request for comment and review

[Claus Ibsen <cl...@gmail.com>]

Hi Steven

Thanks for your patience in my slow feedback.


On Fri, Jan 7, 2022 at 9:07 PM Steve973 <st...@gmail.com> wrote:
>
> Hi, Claus.  Thanks for the feedback.  I think my perspective is a little
> bit different, so let's look at it a slightly different way, and see what
> you think.
>
> To me, the usefulness of Camel comes with having so many things to choose
> from.  Anything isolated might have quite limited usefulness when viewed on
> its own.  But, the fact that you can compose your integration through
> routing and mediation from a huge arsenal of components, processors, and
> other tools, means that you can do quite a lot.  Now, Camel core already
> has a dynamic router.  What is your opinion of its usefulness?  The
> implementation, as it currently stands, is not inherently dynamic.  It uses
> a routing slip, and you would have to "roll your own" routing slip that is
> actually dynamic.  The re-circulation behavior is interesting, but it is a
> misinterpretation of the control channel.
>

Yes I agree the current dynamic router is more of a dynamic routing
list with a while loop.
But it does dynamic routing, but not 100% according to the 15 years
old design from the EIP book.

But in retrospect it would have been better to have added an option on
the existing routing slip,
to turn it into a dynamic mode, and thus we had it as a single EIP.



> I see your point about the in-memory-only queue.  But, with the idea of
> composition that I discussed above, a route that feeds the Dynamic Router
> component can consume messages from anywhere, and the destination URIs can
> be literally any of the endpoints that you can set up and use with Camel.
> It is as scalable as a developer wants to make it.  It provides something a
> bit similar to the dynamic router processor in core, but it is much more
> dynamic without having the requirement of the developer to make the slip
> dynamic.  It provides additional use cases to the dynamic router processor
> in core.
>

It's scalable within a single CamelContext.


> This seems directly applicable to your statement about Camel being the
> "glue".  This is yet more glue; I had originally wanted to make this
> available alongside the current dynamic router in core, but I took your
> advice and made it a component, instead.  Is it not OK for a component to
> provide more glue?
>

Yes sure it shows the versatility of Camel that it is very pluggable.


> Thanks,
> Steve
>
> On Fri, Jan 7, 2022 at 6:08 AM Claus Ibsen <cl...@gmail.com> wrote:
>
> > Hi Steve
> >
> > We can see from your work that you have put a lot of effort and
> > devotion into this, with an example and blog post as well.
> >
> > However you say that the reason you wanted this was due to the dynamic
> > pattern in the EIP book.
> >
> > The issue is that the EIP book is about messaging and integration
> > patterns and that these patterns
> > does not apply to all software projects.
> >
> > The dynamic pattern as in the EIP book is actuall a pattern in
> > messaging systems like ActiveMQ, Kafka, RabbitMQ, and all the many of
> > them out there.
> > They all offer a way for clients to subscribe and unsubscribe to
> > topics (and or queues) and very often have filtering as well so a
> > client can say they the only want message that matches X criteria.
> >
> > In other words its a domain that is for a messaging system, and this
> > gets quickly complex when you have distributed systems, and HA with
> > failover, and now also with "the cloud", and even across multiple
> > cloud vendors with hybrid cloud.
> > Your implementation in Camel would be very limited in use-case as its
> > a single context / in-memory only "queue".
> >
> >
> > If on the other hand there was a new messaging system (called foobar),
> > and it was a well used system, then it would be worthwhile to
> > implement a camel component for such system.
> > In other words Camel is the glue to systems, but its "not a "server"
> > system itself".
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Sat, Dec 25, 2021 at 4:44 PM Steve973 <st...@gmail.com> wrote:
> > >
> > > Hello.  I have sent a few messages here on this list about an alternate
> > > Dynamic Router EIP component implementation that I have been working on.
> > > If anyone has some time, I would like to get more community input and
> > > opinion on what I have done so far.  You can see the ticket here:
> > >
> > > https://issues.apache.org/jira/browse/CAMEL-17154
> > >
> > > It contains a link to the component module on my fork of the Camel repo
> > (in
> > > the comments), and I have included a blog post draft ODT attachment that
> > > introduces this component, why I wanted to implement it, and basic
> > > discussion on how to use it.
> > >
> > > If any of you would be kind enough to take a quick glance and let me know
> > > what you think, I would be quite grateful.
> > >
> > > Happy holidays, if you are celebrating.  Take care, and be well,
> > regardless.
> > >
> > > Thanks,
> > > Steve
> >
> >
> >
> > --
> > Claus Ibsen
> > -----------------
> > http://davsclaus.com @davsclaus
> > Camel in Action 2: https://www.manning.com/ibsen2
> >



-- 
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2