*
The moose likes EJB and other Java EE Technologies and the fly likes JMS - benefits? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "JMS - benefits?" Watch "JMS - benefits?" New topic
Author

JMS - benefits?

Bernhard Neuhauser
Greenhorn

Joined: Feb 06, 2006
Posts: 21
Whats the benefit of using JMS?

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

thx for your ideas
Bernhard Neuhauser
Emanuel Kadziela
Ranch Hand

Joined: Mar 24, 2005
Posts: 186
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.
Reid M. Pinchback
Ranch Hand

Joined: Jan 25, 2002
Posts: 775
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.


Reid - SCJP2 (April 2002)
ak pillai
author
Ranch Hand

Joined: Feb 11, 2006
Posts: 288
mainly

  • loose coupling
  • asynchronous processing
  • better performance in certain applications


  • Loose coupling

    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.


    java j2ee job interview questions with answers | Learn the core concepts and the key areas
    ak pillai
    author
    Ranch Hand

    Joined: Feb 11, 2006
    Posts: 288
    Forgot to mention another point:

    [*]Disparate systems can talk to each other.

    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.
    Bernhard Neuhauser
    Greenhorn

    Joined: Feb 06, 2006
    Posts: 21
    Hmm

    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.

    Bernhard
    Emanuel Kadziela
    Ranch Hand

    Joined: Mar 24, 2005
    Posts: 186
    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.
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: JMS - benefits?