activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: JMS the way to go?
Date Mon, 11 Aug 2008 19:08:28 GMT
2008/8/11 RMMM <>:
> 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

>From your application code no; though there are things to learn about
all middleware; whether its some home grown stuff, in JVM SEDA, JMS or
some database etc. Each have their own particular strengths and

If you don't care about concurrency (e.g. you've mostly just 1 single
consumer thread) and you've a very low volume, using a database / JPA
/ hibernate is fine. If you want to implement a big compute grid with
loads of JVMs and/or loads of threads per JVM reliably processing
requests in parallel - then JMS is awesome. Databases are much slower
and don't do load balancing of consumers at all really - but they are
simpler to use if you're already using a database.

The biggest costs of middleware is usually, learning the APIs and
using them properly - and the admin/operational cost. Clearly Camel
makes the first issue a non-issue; making it super trivial to switch
from any middleware technology to any other as your requirements
change (particularly around concurrency, load balancing and

The only real downside with JMS/ActiveMQ is there is some learning to
do about how it behaves (e.g. how the load balancer works in relation
to lots of threads if you use concurrent consumption) and how to
manage an ActiveMQ broker etc.

But its always good to delay decisions until you absolutely have to
make them - so you could start today with in-JVM messaging (which is
non-persistent, so if the JVM dies you loose all in-transit messages)
- then upgrade to JPA/Hibernate/iBatis if you need persistence with
low volume and no load balancing of consumers - then move to JMS as
and when your requirements match the sweet spots of JMS (e.g.
concurrent consumers & high performance).

> (over writing a simple asynchronous messaging/
> event system from scratch)?

I'd definitely not recommend doing that :)  Given the zillions of
messaging systems that are ready to use and are already heavily
tested, I don't see much value in writing a new one from scratch -
unless you've some truly wacky requirements :). Though feel free to
hack a new Camel component if ever that becomes an issue - its really
easy to do!

> 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.

Camel, ActiveMQ and hibernate/mysql can all run on modest cheap hardware.

> 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?)

Definitely. Lightweight is where its at. Maybe Tomcat - Spring and
Camel/ActiveMQ is pretty much all you need these days - maybe a web
framework here or there too and some XML/JSON binding stuff like


Open Source Integration

View raw message