On Sat, Jan 8, 2022 at 4:09 PM 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 >
That is a good break-down and perspective > 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. > Yes I can see the validation, when you accept that it's not a messaging system with client/server actors. So when you say that you can subscribe/unsubscribe then it's not on the same page as it would be with a JMS/Kafka client that subscribes to a broker system. I wonder if you could research if you can make the subscription simpler, as I think it's a little bit of a "hurdle" that Camel users would need to construct a java object to subscribe for basic subscription. You could have sub context for the action and channel, so if you just want to subscribe you can send an empty message to dynamic-router:control/subscribe/my-channel?id=123 You could also allow to auto-gen uuid for the subscription id, so if id is omitted then one is returned String uid = requestBody(....) Anyway that is food for thoughts for improvements. What you have sent today as PR - lets review it. I can see its usefulness and its potential if you continue to work on it. > 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 > > -- Claus Ibsen ----------------- http://davsclaus.com @davsclaus Camel in Action 2: https://www.manning.com/ibsen2
