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: > Comments inline. > Cheers, > Hadrian > > > On 02/19/2013 01:09 PM, Claus Ibsen wrote: > >> On Tue, Feb 19, 2013 at 11:04 AM, Christian Schneider >> <ch...@die-schneider.net> wrote: >> >>> Hi Claus, >>> >>> do you think it is possible to refactor camel core in this way (to >>> implement a real routing engine)? After the refactorings I already did I >>> am not sure it would work. >>> >>> >> Yes it is possible. The main switch is to use a runtime iterator based >> model, that decides at runtime >> which next processor to invoke. Instead of the current "static" approach. >> > > I know for a fact that it's much more complicated than that and I am more > with Christian on that. While I think it's possible, it's far, far from > just an iterator. > > > >> >> Another aproach instead of refactoring would be to first define a new >>> really slim API for components and implement it using the current >>> camel-core. >>> Then we would change each component to use the new API. When all >>> components are switched it will be much easier to change the core as we >>> do not have to >>> refactor all components to make the build work again. We discussed this >>> idea at last Apachecon with Guillaume, Christian Müller and Charles. >>> Then it was mainly in the light of having a small self contained API but >>> I think it would also help with the routing engine. >>> >>> >> The change in the routing engine should be internal facing only, and >> all the tests should ideally pass. >> There may be a few gremlins in the tests that has some internal >> assumptions. But any end user scenario >> of unit tests should have the goal of pass as is. To ensure backwards >> compatability. >> > Agree that the routing engine should be a change internal to the runtime. > The tests we have are not unit tests and in principle I agree with the goal > of them passing as is after the refactoring. However I believe that with > the tests in the current shape it will be cost (time/energy) prohibitive to > refactor the core. > > > >> So there is no need to change any unit tests. Also the unit tests we >> have today serve as good use-cases >> for people to understand how to use Camel and its routes / components. >> > > Actually in my opinion changing the tests is an absolutee must for 3.0 to > have a chance of being more than lipstick. If we give that up, we'll give > up refactoring the api as well. That's what my crystal globe tells me. > > > > >> >> >> Christian >>> >>> On 19.02.2013 10:31, Claus Ibsen wrote: >>> >>>> >>>> Its been on the Camel 3.0 roadmap for a long time >>>> >>>> Though its heading caption may have been chosen a better wording than >>>> - More flexible routes at runtime >>>> http://camel.apache.org/camel-**30-ideas.html<http://camel.apache.org/camel-30-ideas.html> >>>> >>>> We had it as target for a long time, but as you said it safter to work >>>> on this in a major release than on the 2.x architecture. >>>> And hence why its not been done yet. >>>> >>>> And in term of the model, then we have missing pieces about the >>>> inteceptors/onExceptions and whatnot. This is also on the roadmap for >>>> Camel 3.0 >>>> - Add OnException, Interceptor, etc. to JAXB model for a >>>> CamelContextDefinition >>>> >>>> >>>> >>> -- >>> Christian Schneider >>> http://www.liquid-reality.de >>> >>> Open Source Architect >>> http://www.talend.com >>> >>> >> >> >>
