activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From RMMM <>
Subject Re: JMS the way to go?
Date Sat, 16 Aug 2008 06:02:20 GMT

James.Strachan wrote:
> I'd be tempted to hide the middleware from your application code; then
> use something like Camel's bean integration to integrate the
> 'messaging' into your business logic in a kinda invisible way - then
> you don't have to spend a while figuring out how to use the JMS APIs
> properly etc.
> Then you can easily switch between different middleware technologies
> to suit your exact needs...

Well, I've given Camel a try, but I'm not so enthusiastic about it anymore.
I was
able to get off the ground with it by poking around. But sadly, the project 
shows a surprising lack of professionalism. For instance, whatever 
documentation there is, is scattered and incomplete. In one place it's
that the user take out several hours to manually create a map of links to
scattered documentation pages. I'm not really sure what to make of that. The 
programmers seem to have decided that instead of taking the modicum of a few 
hours time to organize the site themselves, every single user of the library
create some sloppy makeshift site map for themselves. It's such a bizarre
concept, it 
almost defies comment.

As I'm sure most of us agree, a programmer who is too busy to document his
is generally not the kind of programmer you want around.

Who knows whether Apache Camel will continue development or whether the
will roll out of bed one day distracted by a new whim and abandon Camel for
another sloppy 
unprofessional project. Who knows what kind of kooky design decisions are
taking place in the 
labyrinths of undocumented code. Etc.

So, my question comes full circle. Assuming I want to restrict myself to
maintained by competent professionals, what technology makes sense for my 

View this message in context:
Sent from the ActiveMQ - User mailing list archive at

View raw message