JMS - Use question
Hey Folks,
Just reading a book on JMS for the first time and i just have a few philosophical questions on the use of it. In the book it gives me an example of setting up a JMS queue and then using a MDB to receive a message and then does a credit check on a customer!!
So after one has gone through all the hassle of configuring your factories,setting up your queue, creating your MDB and then configuring it your are finally ready to write code to do your business requirements!!
Now my first thought were, why would i do all that work just to do a credit check on a customer asynchronously, if i was using plain old POJO磗 , why wouldnt i just spin off a thread to do this for me in the backround instead of having to do all the above? So what am i missing here?
Next point that i need some clarity on is more related to a production setup. Say i have 10 nodes, does one just create one JMS channel that all 10 nodes use or do they each have a channel for every node? If they have a channel for every node then why would i use JMS? Ok loose coupling, great but i can get that if i create my own observer pattern, what extra will it give me than a normal observer pattern? I assume in the above scenario that you have no external applications listening, so everything that needs to listen for the message is in your JVM!! I understand if you have SAP or any other external applications listening
Last but not least, is it fair to make a comparison JMS to tibco messaging bus? If so why, if not why? ;)
Thanks for any help on the matter, like i said im just reading up on it now and need a few thoughts cleared up!!
Cheers,
LL
# 1
I wouldn't use JMS or spin off a thread if I were you. Maybe a stateless EJB would be appropriate but I would only expose such a service to JMS if I had a production chain consisting of several components and the proverbial credit check was just a single step in that chain. JMS works well in situations like chained components because any component can be brought down without bringing down the whole chain.
JMS can work in human interfaces as well though. It typically requires a bit more of a complicated GUI. What I have seen work is the user submits a job and they have a job status page where they can check where their job are.
Just because there is a code sample in a book doesn't mean that the sample makes sense in the real world.
Dwayne
# 2
Maybe a stateless EJB would be appropriate but I would only expose such a service to JMS if I had a production chain consisting of several components and the proverbial credit check was just a single step in that chain.
Call is asynchronous in this scenario, ejb model is single threaded, so would have to spin off a thread for the ejb call to make asynch. Anyways that off topic.....
JMS works well in situations like chained components because any component can be brought down without bringing down the whole chain.
So when you say chained, i take it you can set the order in which you want your beans to be called first(assuming in a topic scenario where you have several listeners)? is that possible with JMS? if so how?
What I have seen work is the user submits a job and they have a job status page where they can check where their job are.
Yeh i can see how it would work in this scenario but you still have other options to solve this problem without the need of JMS!!
i suppose im looking for a scenario where i would say to myself, yes thats a job for JMS!! And in this scenario exclude the need to talk to external applications!!
Just because there is a code sample in a book doesn't mean that the sample makes sense in the real world.
How true........
thanks for comments Dwayne....
# 3
> So when you say chained, i take it you can set the
> order in which you want your beans to be called
> first(assuming in a topic scenario where you have
> several listeners)? is that possible with JMS? if
> so how?
We've written a custom Process Manager that receives messages and uses XPath and XSL to coordinate several JMS applications (all of our messages are XML). We typically don't use topics because we don't want multiple applications getting the same message. Each application does its work in turn, not at the same time.
> Yeh i can see how it would work in this scenario but
> you still have other options to solve this problem
> without the need of JMS!!
There's always more than one way to solve a problem.
> i suppose im looking for a scenario where i would say
> to myself, yes thats a job for JMS!! And in this
> scenario exclude the need to talk to external
> applications!!
I wouldn't want to design a large system with multiple teams working on multiple applications, each with its own processing needs without JMS. Tuning is pretty easy. Adding more horsepower at any point in the chain is pretty easy.
But it may be that I just reach for the tools that I am most familiar with.
Dwayne
# 4
Just to answer some of my own questions about this,maybe of use to someone else latter on down the line
why wouldnt i just spin off a thread to do this for me in the backround instead of having to do all the above?
You shouldnt do this, what if the thread you spin off end up deadlocked or blocked, could result in bringing down the whole server!!
i suppose im looking for a scenario where i would say to myself, yes thats a job for JMS!! And in this scenario exclude the need to talk to external applications!!
In this case it would have to be a use case that can be done asynchronous, an example in a real world scenario would be your online banking site. You want to do a money transfer from account a to account b, these kind of transfers dont happen immediately, they can be queued and processed later.(obviously depends on bank set up but assume bank system cant do it automatically!!)
anyways im more clearer in my head now for when to use it!!
Cheers Dwayne for the comments!!
