This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I am new to JMS and learning now. I have some basic questions.
1. If JMS is been used in the application for the message interactions, tell me whether both of the side (Sender, Receiver) should be developed using JMS? If both or different, say for example in Receiver end is in JMS what could be in the Sender side for producing the Messages?
2. When we have to use JMS? Cant we do the same using JCA and Webservices?
Webservices tend to be synchronous (send / receive) , very flexible , easy to just publish an API an let your clients sort out how to talk to you (commonly used on the net), jack of all trades easy to write / implement but be concerned with performance.
JMS tends to be organisation internal, or between trusted organisations, (bulk possibly) asynchronous message passing type systems, you'd be expecting better through put than a web service.
Used for say feeds eg price feeds sent over MQ for reliability. A lot more restrictive in use cases than webservices usually I'm going to send you a lot of data regularly, reliably but I'm not looking for an instant response and puts more restrictions on the technologies used either end of the pipe.
JCA is used where you can't change the other side i.e. they want to talk a given protocol and can't change or won't i.e. legacy C++ server or client engine that wants to speak a given protocol, you need to be very generic with your message processing, you might have to support a socket API and that’s it deal with it. If its a known protocol you might be able to buy a JCA component but if not you have to write one and they tend not to be trivial comparatively.
JCA can make a C++ client think it’s talking to a C++ server while your Java programmers think they're responding to JMS messages.
"Eagles may soar but weasels don't get sucked into jet engines" SCJP 1.6, SCWCD 1.4, SCJD 1.5,SCBCD 5
For Sender and Recievier refer to QueueSender and QueueRecievier.
If you want something you never had do something which you had never done
Joined: Mar 17, 2009
Thansk for your points. I have one question here. In JMS, whether the receiver and sender ends should be developed in JMS or Receiver could be in JMS and producer could be in MQ series or other standard Messaging APIs? For my understanding there should be MOM sits between the ends to listen, receive and send the data from the queue to both side. Am i right?
If that is the case, in a project if we have decided to use JMS for the message communication, i hope no need to bother about what is in other end other than the Queue name and format..Please clarify.
Joined: Jan 30, 2009
I understood your problem (You are desperate to learn JMS)
JMS is an API . This API helps in connecting to the Queue(where your messages are stored).
Sender and Recievier should be developed using JMS API only(In this case it will be QueueSender and QueueReceivier)
There should be a MOM sitting /standing . in your Application .This can be a MQ from IBM or ActiveMQ fro Apache.
so a client(Servlet) needs to connect to the MOM so we need to use JMS API.
At the other end soeone should be listening to the messages in the Queue. (This will be generally a MDB)
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com