Feedback on my Camel talk at the IJTC conference

Thanks to John for the great feedback on my Camel talk (and other talks too). I started to write a huge reply and figured I'd post it here instead then link to it as its easier to reply to different parts.

Camel itself is not an ESB per-se, it is a component of an ESB

Agreed. The idea is Camel does the routing and Enterprise Integration Patterns - you can then use it inside a web service stack like Apache CXF, a message broker like Apache ActiveMQ or an ESB like Apache ServiceMix

1. One of the key messages that came out of the session was how Java-centric the Camel solution is - Strachan went so far as to articulate the view that coding in XML was a fundamentally bad idea.

Maybe being the author of Jelly and hating writing XSLT has made me a bit too sensitive to the idea of programming by XML. Quite a few customers I talk with report frustration of too much XML hacking with Spring (which is being addressed in Guice and Spring 2.5). But heck if you like programming in XML be my guest :)

He went on to cast aspersions on graphical tools also. His clear preference was that integration logic should be written in Java. Given that I have worked with highly skilled Java developers for many years now I was not too surprised to hear this - many good developers shy away from tooling, seeing it as compromising their style or the power of the underlying framework - hence the longevity of vi and emacs I suppose.

I didn't mean to cast aspersions on graphical tools; more that pretty much all developers understand Java these days, its pretty universal - whereas most complex graphical tools require a fair amount of learning to get used to them.

Personally I totally prefer writing in Java rather than XML or using visual tooling but one of the main requirements of Camel is that you can configure and specify routes in any way you like - via a graphical IDE (e.g. Cimero) or via XML or Java or Groovy or Ruby or one day hopefully a real DSL. Using XML is quite useful as you can just drop your routing rules inside a spring XML file such as inside the Apache ActiveMQ.

So we're working hard to allow folks to specify routing rules however they like - despite what I prefer :). Irrespective of how you write your routing rules, we can visualise them so anyone can easily understand them.

However it is important to note that all developers are not middleware experts and have no wish to be. Indeed the enterprises they work for want their developers to spend as little time and effort as possible on middleware plumbing. They need and demand tools which will enable them to get at least 80% of patterns done without having to understand the middleware architecture, it's threading model,

Thats one of the main things we're trying to attempt with Camel - letting folks who are not middleware experts easily use the Enterprise Integration Patterns using a single line of Java code - using any transport or component with minimal configuration required.

it's support for configurable expression languages etc.

I find it hard to understand how any tool can be usable by folks without some kind of expression language that they understand - whether its Java or SQL or XPath/XQuery or whatnot. Even a visual query definer is a language that users need to know.

Most people express their requirements in a declarative way- I have data at A that needs to get to B, on it's way I need to perform transformation, validation, logging etc. (indeed the EIP book itself does this) . However Camel has taken a very Java centric approach and I think this increases it's complexity unnecessarily.

We are actually trying to be as declarative as possible - don't let the fact that you can use Java as the DSL confuse you. e.g. here's what you just described in Camel using a single line of Java code...

from(a).
to("xsd:org/cheese/something.xsd").
to("xslt:com/acme/mytransform.xsl").
to("log:com.acme.MyLogger").
to(b);

Its hard to be more concise than that in Java code. But sure - you could use some other language or XML or UI tool etc

2. Camel presents transports as nice-simple looking endpoint URIs in Java. However configuration of these transports may not be as simple as it seems. There appears to me to be a potential disconnection between the Camel processors and the Camel Components in terms of configuration.

You can always configure anything in Camel via Java or Spring; a component, endpoint, processor etc. The URI is just a shorthand notation for configurating things; which tends to work well with endpoints as usually all the smart configuration is in the component.

In the presentation processors use endpoints which can be configured using Spring within Camel. However it would appear that many of the component implementations are inherited from ServiceMix and these properties will need to be set presumably within the ServiceMix container configuration?

Not so - all the components are configured in Spring via Camel. If you want to talk to ServiceMix components and endpoints you can use the NMR and the JBI endpoint.

When you have multiple XML configurations to use a transport then the pretty looking URI is hiding a lot of complexity under the hood.

I hear you. We've tried very hard to make things as easy as is possible with minimal configuration; for example most configuration tends to be on the Component rather than the Endpoint. But you can configure things however you like in Java code or Guice or Spring.

3. Some of the pattern implementations look a little short on credibility - take the aggregator pattern for example the "aggregator" pattern does not seem to have the concept of a store - so in essence one must have access to all of the messages which require aggregation or must hold aggregations in memory for the configurable timeout period. This will clearly not work in a scalable way. Likewise as regards clustering - if you are looking to aggregate 2 messages and they turn up on different servers you gotta problem.

You're right I purposely missed out some of the detail on a few slides (such as specifying some kind of persistence store or strategy for aggregator or for idempotent consumer) but that is easily done via a pluggable strategies Spring beans. However just because I missed out some detail on some slides (its kinda hard in an hour to present all the detail in all the patterns as well as the rest of Camel) please don't think that somehow Camel isn't short on capabilities.

To summarise Camel is clearly a worthy set of widgets and they will work for very simple applications without Enterprise requirements.

Ouch :). We've actually lots of customers using Camel today in production with very Enterprise requirements. Apache ActiveMQ 5.0 actually ships fully integrated with Camel so we've tons of users in production using Camel today.

I hope I've managed to straighten out some misunderstandings on Camel; its definitely a great fit for enterprise requirements. Thanks for your great feedback - I'll definitely take it on board on future presentations and try and avoid confusing other folks :).