activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From RMMM <morelli...@comcast.net>
Subject Re: JMS the way to go?
Date Mon, 11 Aug 2008 17:47:26 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.
> 
> 

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.


Mime
View raw message