JMS the way to go?

[RMMM <mo...@comcast.net>]

I'm new to this kind of technology and trying to get some perspective.
I'm writing a software system for a business with about a half dozen
store locations. It's a system that will only be used internally and
(for the foreseeable future) have very low volume.  It will just perform
a few basic services involving db access.

I decided to use an asynchronous client server approach. I could just
write that from scatch, but I'm thinking, why reinvent the wheel? That's
what JMS is for and it has all the functionality that I'll probably ever
need.

So my intention is to use JMS with, say, Apache ActiveMQ. (I'm using
plain old Java SE). My only worry is that it my be overkill and add
more complexity or overhead than necessary. 

Am I getting into more than I realize trying to use JMS?

Is ActiveMQ a good choice? (as opposed to JBoss, Spring, ...)

So should I write a simple system from scratch, or go to the other extreme
and use JMS?

Any advice/comments very much appreciated.


-- 
View this message in context: http://www.nabble.com/JMS-the-way-to-go--tp18920123p18920123.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: JMS the way to go?

[James Strachan <ja...@gmail.com>]

2008/8/11 RMMM <mo...@comcast.net>:
>
>
> 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
weaknesses.

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

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!
http://activemq.apache.org/camel/writing-components.html


> 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
xstream/jaxb

-- 
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://open.iona.com

Re: JMS the way to go?

[RMMM <mo...@comcast.net>]

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.

Re: JMS the way to go?

[RMMM <mo...@comcast.net>]

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.

Re: JMS the way to go?

[James Strachan <ja...@gmail.com>]

2008/8/11 RMMM <mo...@comcast.net>:
> I'm new to this kind of technology and trying to get some perspective.
> I'm writing a software system for a business with about a half dozen
> store locations. It's a system that will only be used internally and
> (for the foreseeable future) have very low volume.  It will just perform
> a few basic services involving db access.
>
> I decided to use an asynchronous client server approach. I could just
> write that from scatch, but I'm thinking, why reinvent the wheel? That's
> what JMS is for and it has all the functionality that I'll probably ever
> need.
>
> So my intention is to use JMS with, say, Apache ActiveMQ. (I'm using
> plain old Java SE). My only worry is that it my be overkill and add
> more complexity or overhead than necessary.
>
> Am I getting into more than I realize trying to use JMS?
>
> Is ActiveMQ a good choice? (as opposed to JBoss, Spring, ...)

ActiveMQ does seem to be the most popular and powerful open source
message broker. FWIW Spring is a framework, not a messaging provider


> So should I write a simple system from scratch, or go to the other extreme
> and use JMS?
>
> Any advice/comments very much appreciated.

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

e.g. you can start with in-JVM messaging (SEDA)...
http://activemq.apache.org/camel/seda.html

then use ActiveMQ or JMS
http://activemq.apache.org/camel/activemq.html
http://activemq.apache.org/camel/jms.html

then use hibernate/JPA using a database table / entity bean as a queue...
http://activemq.apache.org/camel/hibernate.html
http://activemq.apache.org/camel/jpa.html


FWIW I've started hacking a little wiki page together describing this
technique of hiding middleware APIs from your business logic...
http://cwiki.apache.org/CAMEL/hiding-middleware.html

-- 
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://open.iona.com