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
