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. > >
Thanks for the suggestion. I appreciate the explanations and all the links. I've browsed some of the materials at the Camel site and it does look like a compelling option. Let me just reiterate my question about complexity and overhead though. >From what I gathered in a quick look, using Camel to manage the messaging looks pretty easy. Camel seems to hide a lot of the details. In fact, even using JMS/ActiveMQ directly doesn't seem all that complicated ... at least, at first glance. So my question is, is there going to be a big burden of complexity that I may not be seeing yet (over writing a simple asynchronous messaging/ event system from scratch)? Also, is there going to be a major memory/cpu hit, considering the light use I'm expecting from this system? We don't have a server farm with state of the art hardware. The hope is that the software can run on cheap, low end PCs that the stores already own from years back. Finally, just to be clear, I'm using plain Java. I've judged that going all the way to Java EE and an application server would open a lot of unnecessary complication. (Does that sound reasonable?) -- View this message in context: http://www.nabble.com/JMS-the-way-to-go--tp18920123p18930417.html Sent from the ActiveMQ - User mailing list archive at Nabble.com.
