What is the difference between Java RMI and JMS?

java jakarta-ee jms rmi distributed-system
Jonas picture Jonas · Apr 5, 2010 · Viewed 18.6k times · Source

When designing an distributed application in Java there seem to be a few technologies that address the same kind of problem. I have briefly read about Java Remote Method Invocation and Java Message Service, but it is hard to really see the difference. Java RMI seems to be more tightly coupled than JMS because JMS uses asynchronous communication, but otherwise I don't see any big differences.

  • What is the difference between them?
  • Is one of them newer than the other one?
  • Which one is more common/popular in enterprises?
  • What advantages do they have over each other?
  • When is one preferred over the other?
  • Do they differ much in how difficult they are to implement?

I also think that Web Services and CORBA address the same problem.

Answer

John picture John · Apr 5, 2010

You already know about method calls. What if the object that you want to invoke the method on is on a different computer? You use RMI to send the call from one computer (client) to the other (server). The client will wait (or "block") until the result comes back from the server. This is called synchronous operation.

JMS is different: it lets one computer send a message to another - like email. The first one doesn't have to wait for a response: it can keep doing whatever work it wants. There may not even be a response. The two computer systems don't necessarily work exactly in step, so this is called asynchronous.

Another way of thinking about the difference: RMI is like making a phone call, and JMS is like sending a text message.

RMI is a little older than JMS, but that's not really relevant. The two concepts are much much older than java.

There's not much difference in the complexity. I think that you should try doing a tutorial on each one. RMI and JMS

If you're starting a project from scratch, and you're not sure which one to use, then probably the synchronous/asynchronous issue is the best decision factor. If you're working on an existing system, it's probably best not to introduce too many new technologies. So if they're already using one, then I'd suggest it's probably best to stick with that one.

Related questions

Why is my JNDI lookup for a QueueConnectionFactory returning null?

I am trying to look up a QueueConnectionFactory and Queue via Geronimo's JNDI. The Queue gets returned fine, but the QueueConnectionFactory lookup always returns null. It doesn't throw a NamingException, which is what I'd expect if the JNDI name was …

Read More
Accessing MQ with JMS

i am using MQ7 and trying to access a queue with JMS api's. Getting this error. Has anyone seen it before? How do i resolve this? TIA Exception in thread "main" com.ibm.msg.client.jms.DetailedJMSException: JMSFMQ6312: An exception …

Read More
Is it a good practice to use JMS Temporary Queue for synchronous use?

If we use JMS request/reply mechanism using "Temporary Queue", will that code be scalable? As of now, we don't know if we will supporting 100 requests per second, or 1000s of requests per second. The code below is what I …

Read More