camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Chekan <>
Subject Re: camel spring xml restructure
Date Sat, 30 Aug 2008 18:55:36 GMT

I'm glad you see the problem. Arguably, difficulties with routing 
configurations is one of the the biggest obstacles on wider Camel 
adoption. There is nothing more frustrating than knowing exactly what 
you want in terms of EIP but spending many hours with so minor issue as 

Interesting enough, I was thinking about it yesterday too and my 
conclusion is such that it is very difficult to achieve smooth 
configuration using xml. It is not the tool for the job. I mean it can 
do it (it does it currently) and we can keep improving it but will we 
get the easiest possible way of configuring camel routes?
I'll skip large philosophical discussion but in my opinion xml sometimes 
becomes victim of its own success and programmers try to stretch its 
application beyond the reasons because "xml is so great, I would add it 
to my salad if I could" :)

Basically we are trying to define Abstract Syntax Tree in xml serialized 
form. People don't usually think in terms of AST.

We can give a whirl an idea of Domain Specific Language (DSL). I have 
some under my belt and it is not too difficult. The result would look 
like this (syntax can be any, but I'm trying to be java script alike):

routes {
   route {
     from 'queue:Incoming'
     process {
       bean '' 'MyFunction'
     if (header('myHeader') == 'value1') {
       to 'queue:Outgoing'
     } else {
       to 'queue:Alternative'

I thought about juel (or others evaluators).
I see a problem that those languagas will dictate syntax which may be 
not optimal for camel route definition domain.
Another and bigger problem is that external language will not detect 
camel invalid constructions. For example creating serializer but not 
assigning it data format would be invalid in camel but from Juel point 
of view it would be perfectly ok.
Having our own syntax parser will let us detect any syntax deviations 
and provide user with very clear and informative error messages for 
example " 'bean' or 'aggregator' are expected inside in 'process' ".

Another benefit we get is Backus-Naur Form (BNF) file which is human 
readable and is very easy to use in documentation. As opposite to xml 
schema which can be used for learning purposes but I would not risk 
claiming it a recommended way.

Here are fragments of BNF as I see it:
route :
	| from_list process_list to_list
process_list :
	/* can be empty*/
	| process
	| process process_list /* works as pipiline */
process :
	/* can be empty */
	| MULTICAST '{ process_list '}'
	| PIPELINE '{' process_list '}'
	| AGGREGATE expression
	| resequence

resequence :
	| BATCH RESEQUENCE expression
	| BATCH RESEQUENCE NUMBER NUMBER '(' expression_list ')'
	| STREAM RESEQUENCE resequence_options
	| STREAM RESEQUENCE resequence_options '(' expression ')'

to_list :
	| to to_list
to :
	| IF '(' bool_expression ')' THEN to
	| IF '(' bool_expression ')' THEN to ELSE to

If you guys think it worth a try I can mock up a prototype.
I think I would build an AST and then have another process which would 
traverse AST and invoke RouteBuilder to build the actual route.
This way we preserve backward compatibility with existing ways of 
building routes.

This route builder would be a separate plugin in order to be as little 
invasive as possible.

AST can be used in future to build graph representation of camel routes 
without building the actual routes. I recall James recent comment that 
building route for display purpose only (without running it) added some 

Let me know what do you think folks.

Claus Ibsen wrote:
> Hi
> I would suggest to restructure the camel spring xml format a bit.
> The overall goal is:
> ====================
> - ease of use
> Current situations:
> ===================
> - there are too many different types of xml tags possible that confuses end-users. 
> - most list types don't have a parent "holder" so they are mixed with all the others
> IDE auto completion
> ===================
> Using the IDE auto complete reveals many of these problems. For instance in the root
camelContext tag, you get datatypes, endpoint, spring remoting, and other stuff and of course
the routes etc is a bit of mixed content.
> I would suggest to restructure the xml so you have some parent holder tags to ease end-users.
> Motivation behind
> =================
> I would love the spring xml to be more firm and structured before letting loose my programming
team on the spring xml instead of java DSL. Having IDE completion with less mixed type of
elements would help a lot.
> Camel 1.5
> =========
> We are nearly there I think the daatatypes must be restructure so they don't appear in
the tag list from the root tag. Now you get articDS, xmlBeans, string, hl7, xstram and others.
I think they should be child tags of a parent holder tag named dataTypes. This will help a
> I thing this change can be done in camel 1.5 without breaking to much. After all we have
a bug in Camel so datatypes configured as camel tags isn't useable from the marshal and unmarshal
tags. So it doesn't work (CAMEL-871).
> Camel 2.0
> =========
> For Camel 2.0 we can consider having parent holders for
> - endpoints
> - routes
> - the spring remote stuff
> - jmx
> And I also think the <package> tag should have a parent holder that better describes
what it does. As now it's a bit of magic for new users reading the spring xml. Package doesn't
hint that is the route builder and that is it a very important tag. Also we should consider
making it possible to configure <package> as classnames or spring bean ids. So you better
can get the link from camel context to what java class is the actual route builder. 
> We could consider having a restructure for this and have it something on the way as:
> <routeBuilder>
>    <package>com.acme</package>
> </routeBuilder>
> Or even better I think:
> <routeBuilder>
>    <builder package="com.acme"/>
> </rouyteBuilder>
> <routeBuilder>
>    <builder class="com.acme.MyCheeseRoute"/>
>    <builder class="com.acme.MyBeerRoute"/>
> </rouyteBuilder>
> And the spring ref variation is also very great:
> <bean id="cheeseRoute" class="com.acme.MyCheeseRoute"/>
> <routeBuilder>
>    <builder ref="cheeseRoute/>
> </rouyteBuilder>
> Med venlig hilsen
> Claus Ibsen
> ......................................
> Silverbullet
> Skovsgårdsvænget 21
> 8362 Hørning
> Tlf. +45 2962 7576
> Web:

View raw message