camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <>
Subject Re: Architecture of camel
Date Mon, 21 Jan 2008 00:31:36 GMT
Hello again,

sorry for the start of my mail. It looks a bit confused and I should 
have started with an explanation what I try to do ;-)

First I am a big fan of camel. The java DSL is really a charm to work 
with and shows that java can be used for a decent DSL what I doubted 
before. In my work I need integration processes at many places and camel 
is a great tool for this. So when we started to use camel more intensive 
I tried to learn a bit more about camel. When I tried to understand the 
big picture of the architecture I found no clues on the website. So I 
started with an architecture tool and eclipse and tried to understand 
what each package means and how the packages depend on each other. When 
I visualized the architecture I found that there are many cycles what 
made it difficult to know where to start.  So after some time digging in 
the code and the visualization I thought there were some places where 
refactorings like moving a class would help make things much clearer. So 
I started to post some small pataches as jira issues.

When looking into the architecture of other frameworks almost all have 
many cycles in the package structure with one exception: The Spring 
Framework. I think the clear layering is one of the key success 
criterias of Spring. While at the start of a framework cycles are not 
that important, they slow down further development when the framework 
grows in size. At the same time when your number of developers grows you 
need some basic blueprint of how the architecture should look like, so 
everyone has a clue where to put new classes and what depencies to 
avoid. Juergen Hoeller held a very interesting talk about the 
architecture of Spring and how they manage the architecture over time. 
Here is an excerpt of it:

So I had the idea to help document the architecture of camel and help to 
fix some issues where possible.
That much about my motivation.

Below are some guesses I have about the architecture:

- camel and model are the base packages. Most other packages need them. 
camel has only two references to model so I guess model should be above 
- converter is a uitilty package that is referenced by most other 
packages but does not reference other packages (except camel for the 
interface Converter). So it is almost at the bottom.
- spi contains extension points for camel. It references camel and model 
quite heavily so it probably is above those two.
- impl is intended for the implementation details so it probably is on 
top of at least camel, model and spi.

Am I about right with these guesses?

Best regards



Christian Schneider

View raw message