Hi, Claus. I have created a ticket to simplify the control channel messages for the Dynamic Router EIP component: https://issues.apache.org/jira/browse/CAMEL-17500
When you have a chance, please have a look and let me know if this is complete enough for the next update to the component. Thanks, Steve On Tue, Jan 11, 2022 at 8:04 AM Claus Ibsen <claus.ib...@gmail.com> wrote: > 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 >
