RMI vs JMS Clarification

Most of the developers and system designers may know what is RMI and what is JMS but when they come to develop or design the real world application then they are in trouble with which one to choose. So I thought its better to publish some thoughts on this.

Lets start with the regular descriptions.

RMI – Remote Method Invocation

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

Advantages :
Easy to start by writing the 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 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 call.

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 send 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 tight to the service as RMI. You can use any kind of data format to communicate via message QUEUEs and TOPICs. ex/ XML, JSON
3. Reliable communication – This is not like RMI because this communication has message broker in-between the systems and message broker has capability of error handling and the persistent of the messages and handover 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 maintain the message broker

Using JMS :
If you have any process which will be getting heavy request load and that can be run asynchronously then go for JMS Queue implementation and run them separately and communicate via the queue. The next point is if you have a process that need to send the 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 choice.