Given: Node A(Client?) wants to say "hello" to Node B(Server?)
One Possibility might be: A =RMI//IIOP=> SLSB => CMP
The JMS aproach would be: A =TextMessage=> MDB => CMP
Whats the benefit of the JMS aproach? It seems similiar with additional overhead. Is it just to avoid timeouts when all SLSBs are busy? When its just a small Message being stored as CMP, the DB Storage might be fast enough to avoid such time issues. Also the Client might be able to call the SLSB method multithreaded, so the timeout might be no true reason or?.
Even though the functionality of JMS can, with some pain, be reproduced by other means (like slsb), JMS has unique features specific to its mission. Primarily, JMS guarantees message delivery, it will retry to deliver a message upon failure, nice handling of undeliverable message errors and other exceptions, etc. It also provides good interfaces for processing messages, queuing them, distributing/broadcasting them, and even if need be, persisting them. Granted, you can do all this using other methods, but they are not built around this purpose and will quickly show themselves ill fitted to perform it.
The fundamental purpose of any MOM is to have a loose communications and deployment coupling between message producers and message consumers, and typically with the expectation that the interactions are asynchronous. If neither of those two things are true for you, then there isn't much point to any MOM, JMS or otherwise.
When the sender sends a message to a receiver, the receiver does not have to be up and running. The sender's message will sit in the topic/queue and when the receiver is up and running, the message will be delivered to the reciever by the MOM.
asynchronous processing /better performance in certain applications
If you have a very high traffic system like an airline booking system a web client can book a ticket over the internet and does not have to wait for the confirmation. The confirmation will be sent later via email/phone call etc. The web module will shoot an asynchronous request (via XML message) to a booking service.
For example your web module might be in Java which needs to talk to a backend which is mainframe etc. You can shoot an XML message from your java web to MOM (Message Oriented Middleware like MQSeries), which will be delivered to the service in mainframe. similar to web services.
Joined: Feb 06, 2006
Many interstings concepts. Seems like i need to experiment with jms to see its benefits.
The Sender can send even when the Consumer is currently not available. Maybe a nice feature but im not even sure if this is a benefit or a problem in my case.
A => Server => B
Node A: update pls! Node B: here is my status and i update this status everytime something changed so maybe 10 times per minute. But the Server between them is currently gone
A Will produce update Messages. The user hits the button frustrated again and again and again. And it will produce new update request messages.
B Will send messages again and again and again.
Then the Server comes back again. There will be many requests from a and b and both get delivered. He will see 20 update requests from node a and all get delivered. And there are many undelivered updates from B. So for sure he will be able to process even the messages when he was gone away, but after the startup the server might be really busy because all concurrent users filled their queues.
And now the same szenario through slsb: A sees that he cant deliver his rmi call. An exception occours and he will give his users the apropriate feedback "server currently not available - pls wait".
B will see that he is unable to send the updated status. So he will transfer his whole status info only once when the server is back again.
Im not sure if i see a benefit for jms in this szenario.
Joined: Mar 24, 2005
Even with loose coupling and asynchronous processing, JMS still gives you the basics of messaging concepts like acknowledgments and error handling, which is more than enough to handle the nightmare you described.