General J2EE: RMI v/s JMS

  1. RMI v/s JMS (4 messages)

    What are the pros and cons of JMS over RMI and vice versa?
    And which technology is best suited for what kind of projects?


    Threaded Messages (4)

  2. RMI v/s JMS[ Go to top ]

    I think a hybrid approach is best. some situations more
    or less demand an RPC model, in which the caller blocks until a response is ready. in other cases, typically when the return value of the corresponding RMI call is void, it might be nice to have an asynchronous system.
    you can, of course, develop something like JMS using RMI. clients can
    add messages to a queue which is processed by some other thread. all sorts of things need to be considered, like how are error conditions signalled, how hard do you try to deliver messages in the face of network failures. etc. when you start worrying about those things,
    you start saying, "jeeze, why don't I just buy a JMS product?"

  3. RMI v/s JMS[ Go to top ]

    Frequently, JMS is implemented over RMI by the vendor. But basically the issue as he says is whether or not you want to block on a call or not.
  4. RMI v/s JMS[ Go to top ]

    Yup, the basic thing would be whether you want to block the call or not.
    Another consideration obviously is if you need to talk between systems other than java, some JMS vendors provide a way where c++ etc can talk to JMS.

  5. RMI v/s JMS[ Go to top ]

    I am new to Java and need to create a "Messenger" application for a project. I was trying to determine if RMI or JMS was the way to go. Can you explain to me what you mean by "blocking a call?"