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. > > http://activemq.apache.org/camel/bean-integration.html > > Then you can easily switch between different middleware technologies > to suit your exact needs... > http://activemq.apache.org/camel/components.html > >
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 suggested that the user take out several hours to manually create a map of links to the 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 should 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 work is generally not the kind of programmer you want around. Who knows whether Apache Camel will continue development or whether the programmers 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 projects maintained by competent professionals, what technology makes sense for my project? -- View this message in context: http://www.nabble.com/JMS-the-way-to-go--tp18920123p19009022.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
