Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 4.0

...

The proposal is to shift towards an iterative model, by redesigning the logic of Camel routing. The suggested model is defined by these pillars:

  • A single class, or a limited set of them, contain the routing logic of Camel. Package name: org.apache.camel.core.routing. Central (abstract) class: RoutingCore. Concrete realisations could be: PipeliningRoutingCore, MulticastRoutingCore, depending on the fundamental routing pattern.
  • The RoutingCore iteratively calls the routing steps, one after another. The routing steps return their result to the RoutingCore, who is in charge of calling the next element subsequently. OUT and IN are bridged if necessary (PipeliningRoutingCore).
  • The Processor interface is crumbled up into its many specialisations, each of which represents a distinct concept of the Camel framework: RoutingDecider (EIPs should only take decisions about the routing, but not perform the routing itself, e.g. choice, filter, loop, throttle, etc.; see examples in subsection below.), Actions, ErrorHandler (already exists), Interceptor, etc.
  • The RoutingCore is responsible of all the "magic" now disseminated across a number of processors. Assisted by Helper classes.

The goal of this idea isn't to zap off recursion altogether, just to consolidate the routing logic into a handful of cornerstone classes.

...

Converting some EIPs from "performers" to mere "deciders"

  • choice() => evaluates the predicates and returns the List of Processors or Endpoints to invoke.
  • filter() => same as choice(), but returning null if the filter doesn't match, to continue to the next routing step.
  • loop() => evaluates whether the looping control predicate still stands. If yes, it returns the processors to invoke, where the last is itself (to trigger the looping logic again); else, it returns null to continue to the next routing step.
  • throttle() => pauses accordingly and then returns the endpoint/processors to invoke.
  • ...

Clearer Architecture of Camel Core

...

We should consider removing

  • camel-bam
  • camel-msv
  • org.apache.camel.view from came-core
  • dot maven generator
  • ... (there could be other stuff to remove)

The BAM has not changed in 5 years, and very seldom used by end users. And neither has the functionality you need. There is much better solutions outside ASF Camel for a BAM solution.
The DOT generator is not up to date and maintained. Also it requires binary generator to generate a route diagram; we never managed to find a good java library for that.

...