camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: Architecture of camel
Date Mon, 21 Jan 2008 10:03:53 GMT
On 21/01/2008, Christian Schneider <> wrote:
> 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.

I hear you. Camel has grown organically over time and I'm sure we can
reorganise things to be a little bit better layered. For example the
model package was a relatively new change, trying to use a common AST
model underneath the XML, Java DSL and other DSLs (such as
Groovy/Ruby). There's still some cruft we could remove from the
camel.builder package for example.

> 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
> camel.
> - 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?

Yes. The impl package probably requires all of the code in camel-core
to be honest; other packages have pretty well defined scopes.

The camel package is intended to be the core API folks use (defining
the CamelContext, Exchange, Message, Component, Endpoint etc).

The SPI is a set of strategies folks can plugin to customize things
(like type conversion, Registry and the like).

model is the AST of the routing DSL which is common to both the Java
DSL and the XML languages.

If folks can figure out cleaner ways to organise the code to improve
the layering lets do it.

I guess its worth mentioning that there's another aspect to the
layering, that of the various modules. So camel-spring for example
reuses pretty much all of camel-core and adds Spring support.
camel-jms reuses camel-core, camel-spring and adds JMS etc.


Open Source Integration

View raw message