RMI vs. JMS Clarification

Most developers and system designers may know what RMI is and what JMS is, but when they come to develop or design a real world application, they have trouble with which one to choose. So I thought it would be good to publish some thoughts on this.

Let's start with the regular descriptions.

RMI – Remote Method Invocation

1. Synchronous communication – Request initiator waits for the response. In order to archive this, the RMI service needs to be up at the time of communication.
2. Tightly coupled – Requesting system is coupled to the declared interface in RMI service.
3. Unreliable communication – If something happens in-between the communication you will lose the request and have to handle those in application level.

Advantages:
Easy to start by writing a simple interface and the implementation.

Disadvantages:
Can use only the Java-supported platforms.
Cannot use the code out of the scope of Java.
Security issues need to be monitored more closely.

Using RMI:
If you have a process with heavy computation and need more computation power to improve the performance, then you can go with RMI because it will give you the computation power on simple method calls.

JMS – Java Message Service

Topic – Publish and subscribe model

Queue – Load balancing model

1. Asynchronous communication – Request initiator is not going to wait for the response and it just sends the message out then close the connection. No need to have backing service up at the time of communication.
2. Loosely coupled – It is not tightly coupled with the service like RMI. You can use any kind of data format to communicate via message QUEUEs and TOPICs. e.g. XML, JSON
3. Reliable communication – This is not like RMI because this communication has a message broker in-between the systems, and the message broker has the capability of error handling and the persistence of the messages and hands them to the responsible party.

Advantages:
Due to asynchronous messaging, all the modules don’t need to be up for the application to function as a whole.

Disadvantages:
Extra overhead on setup and maintenance of the message broker

Using JMS:
If you have any process that will be getting a heavy request load and that can be run asynchronously, then go for JMS Queue implementations and run them separately and communicate via the queue. The next point is if you have a process that needs to send data to many downstream applications, then go for JMS Topic implementation.

By the way, remember this: There is no such a thing as bad technology, only bad choices.