RMI vs JMS vs Web services

There is always a debate among Developers, Architects when we choose a middleware technology for communicating between two java programs. One says choose RMI, other JMS and few say let us choose the Web services which is the latest trend in communicating in web world today. 

Though this can be a simple selection for most of the Architects/Designers, the ideology behind choosing this has to be showered to low level developers also. In my experience, I have seen many developers are clueless about the middleware selection and write programs without understanding the internal details of how distributed computing happens.

Please note that my main focus here is to point out the differences between using RMI, JMS & Webservices when developing java applications.

First let us understand some definitions of RPC, Middleware, Sync/Async communication.

What is RPC ?

As per Wiki, In computer science, a remote procedure call (RPC) is an inter-process communication that allows a computer program to cause a subroutine or procedure to execute in another address space (commonly on another computer on a shared network) without the programmer explicitly coding the details for this remote interaction.

Why do you need Middleware ?

As per Wiki, Middleware in the context of distributed applications is software that provides services beyond those provided by the operating system to enable the various components of a distributed system to communicate and manage data. Middleware supports and simplifies complex distributed applications. It includes web servers, application servers, messaging and similar tools that support application development and delivery. Middleware is especially integral to modern information technology based on XML, SOAP, Web services, and service-oriented architecture.

ASYNC: In asynchronous communication, the requester of a service does not wait for a response from the service, it can continue processing once it sends the request (message).Asynchronous communication deals better with increase number of requests and traffic than synchronous communication, because of no waiting for response feature. Moreover, messages in asynchronous communication are not lost rather delayed in case of intensive traffic.
SYNC: Whereas the requester in synchronous communication must wait for a response from the service, the requester is blocked till an acknowledgment is received. In synchronous communication, both parties must be active, otherwise the transaction won't be completed.

So now, we have two java applications running in same/different computers and we make them communicate over wire. Of course, my comparison to RMI and JMS is invalid as these are two different things to compare, as RMI is a RPC form where as  JMS is MOM (Message Oriented Middleware)

JMS has got the following:

• Asynchronous
• Loosely coupled
• Reliable communication

RMI has got the following:

• Synchronous
• Tightly coupled
• Unreliable communication

The reason why I have compared JMS with RMI is, JMS also has support for request/reply model in a synchronous way. Sync/Async communication entirely depends on the application design. And don’t worry about the TRANSPORT protocol for these communications. RMI shall use JRMP or IIOP, mostly JRMP is default choice, it is a wire level protocol running at the level under RMI and over TCP/IP. Coming to JMS, it uses TCP as Default, of course you can configure other protocol also based on your need, in your Message Broker configuration file.

Now coming to Web services, it has got the following:

• Interoperability
• Synchronous
• Loosely coupled

They can connect to different systems using Transport & Network protocols and make HTTP requests. There is also a comparison done by many SOAP over HTTP and SOAP over JMS.

Selecting an option is completely based on the application requirement. One has to choose what is needed for the application architecture and design, whether we need synchronous or asynchronous communication, etc..  Also, there can be a mix of these- For eg: Using web service, you get a data processed and form a message and send it to other components or application using a Message Broker.