Hi, It took me a while to find the time, but this idea is now logged in the Camel 3.0 ideas page. We'll spin off a dedicated page as the definition continues evolving.
BTW - I also added a ToC to the page to simplify browsing. Regards, Raúl Kripalani | Apache Camel Committer | Enterprise Architect, Program Manager, Open Source Integration specialist http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani http://blog.raulkr.net | twitter: @raulvk On Tue, Feb 19, 2013 at 9:49 PM, Christian Schneider <ch...@die-schneider.net> wrote: > I also thought about a future routing engine some time ago and I think your > ideas make sense. > When we remove the possibility of routing steps to simply call processors > then we have to reflect the possible > branches in the model itself. So it is pretty natural to introduce something > like a RoutingDecider. > > We have to experiment a bit to see how to implement the different model > elements camel currently provides > but generally what you wrote looks good to me. > > For the crosscutting concerns I think we could define something like aspects > that the routing engine then applies at runtime. > This will make it much simpler and straightforward to implement them > > Christian > > > Am 19.02.2013 22:08, schrieb Raul Kripalani: >> >> It's a big undertaking but I feel we're at the right moment to redesign >> the >> core of Camel, make it leaner and pull in the routing concepts into the >> API >> model itself. It's basically now or never. >> >> One of the cornerstones of what I have in mind is to diversify the concept >> of the Processor into its several specialisations, e.g. by introducing the >> concept of a RoutingDecider, Actions, etc. >> >> For instance, EIPs like ChoiceProcessor and FilterProcessors could >> implement RoutingDecider. Instead of actually invoking the next processor >> (which is what they do now), they would return it to the Routing Core >> (RC). >> The RC would be in charge of actually invoking the processor. >> >> LogProcessor, ConvertBodyTo, Delayer, etc. would be Actions: they execute >> one scoped operation and they return the Exchange to the RC. >> >> Cross-cutting concerns like Instrumenting (InstrumentationProcessor), Unit >> of Work Management, DelegateAsyncProcessor, etc. would belong somehow in >> the RC itself. >> >> Error handlers would just be a referred to, rather than woven at several >> steps. If a step in the routing chain throws an Exception, the RC would >> invoke the Error Handling "box". >> >> To me, each route would be an instantiation of a RoutingCore, where the >> direct: endpoint is capable of bridging RoutingCores together. >> >> I hope this makes sense to you as much as it does to me ;) >> >> Regards, >> >> *Raúl Kripalani* >> >> Apache Camel Committer >> Enterprise Architect, Program Manager, Open Source Integration specialist >> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani >> http://blog.raulkr.net | twitter: @raulvk <http://twitter.com/raulvk> >> >> >> On Tue, Feb 19, 2013 at 7:34 PM, Hadrian Zbarcea <hzbar...@gmail.com> >> wrote: >> > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > Talend Application Integration Division http://www.talend.com >
