camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <>
Subject Re: [DISCUSS] Camel 3.0 - Core of the routing engine
Date Tue, 19 Feb 2013 21:49:40 GMT
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


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
> |
> | twitter: @raulvk <>
> On Tue, Feb 19, 2013 at 7:34 PM, Hadrian Zbarcea <> wrote:

Christian Schneider

Open Source Architect
Talend Application Integration Division

View raw message