Hi, Claus. I am just checking in to see if expanding on my rationale for the component helped at all, and if you have any additional thoughts. In short, is it ok for a component to be "glue"?
Thanks, Steve On Sat, Jan 8, 2022 at 10:09 AM Steve973 <steve...@gmail.com> wrote: > Hello. I would like to add a little more to this conversation, since you > mentioned my reason for contributing this code. My motivation to add this > EIP component was because a couple of years ago, I read about the dynamic > router EIP within Camel, and I thought that it would be perfect for what I > needed to do in my project at work. It looked like my clients could > register with the dynamic router processor, but further reading of the docs > and my own use of it revealed that this was not how it was implemented. I > was not able to use it for my use case, but I had to move on and implement > this behavior myself. > > Now that I had some time, I thought that I would contribute this idea to > Camel so that others would be able to use this particular type of "glue" > right out of the box that fits use cases that are like others in camel, but > expanded in certain areas that include, but are probably not limited to: > > - the content-based router (choice), but the choices are fully > subscriber-initiated and do not need to be known at compile time > - the dynamic router (processor in Camel core), and I outlined the > differences in the previous email, so no need to re-hash here > - the message filter, but instead of creating the filter at compile > time, consumers provide their own filter at runtime > - the selective consumer, but turned the other way around: instead of > sending messages to (potentially a list of) recipients, and letting them > all determine which messages to process or discard, this component allows a > consumer to subscribe with its filter so that the router can handle this > (centrally) and only send messages to the (first) appropriate subscriber. > If we need a recipient list mode, that can easily be added so that it sends > to all matching recipients. > - the "To Dynamic" EIP, but the sender does not need to know about > dynamic recipients, and variables do not have to be set > > I hope this shows how this contribution is not only "glue", but that it is > useful glue that provides simplified routing for developers that have use > cases that overlap in the list of features above. While you could achieve > anything in software by composing a solution of several different pieces, > and implementing the glue that helps them to work together and, in this > case, also implementing the runtime registration of recipients, this > component ties these things together and makes it simple. It is not > intended to be its own messaging system, but to facilitate messaging to, > and from, other sources where the decision is truly runtime-based. Indeed, > you might have another messaging system that provides filtering, etc, but > this component introduces a new feature to provide this in a way that is > independent of other components/transports, and can, therefore, be used as > a dynamic integration point between completely different messaging systems. > > Thanks again, > Steve > > On Fri, Jan 7, 2022 at 6:08 AM Claus Ibsen <claus.ib...@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 <steve...@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 >> >
