aspose file tools*
The moose likes Java in General and the fly likes RMI v/s JMS Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "RMI v/s JMS" Watch "RMI v/s JMS" New topic
Author

RMI v/s JMS

Nitin Narayan
Greenhorn

Joined: May 03, 2001
Posts: 15
Dear friends,
What are the pros and cons of JMS over RMI and vice versa?
Regards,
Nitin
Sean MacLean
author
Ranch Hand

Joined: Nov 07, 2000
Posts: 621
Pehaps I'm wrong here, but they have rather different uses and can't really be compared (unless you intend to use RMI as a messaging service, in which case I'd suggest using a messaging service). How are you intending to apply these technologies?
Sean
Nitin Narayan
Greenhorn

Joined: May 03, 2001
Posts: 15
Originally posted by Sean MacLean:
Pehaps I'm wrong here, but they have rather different uses and can't really be compared (unless you intend to use RMI as a messaging service, in which case I'd suggest using a messaging service). How are you intending to apply these technologies?
Sean


Well Sean basically what I have to do is send some data which is retrieved by querying a database acros from one server to another. So am just wondering whether to use RMI or JMS. I read an article which suggest JMS to be more robust that RMI, also RMI has some limitations with respect to the amount of data that it can send from one point to another and the server which receives the data is a J2EE complaint app server.
So am just thinking whether to use JMS or not???
Nitin Narayan
Greenhorn

Joined: May 03, 2001
Posts: 15
Also I would like to mention i dont intend using the pub/sub approach to JMs rather the p2p approach.
Regards,
Nitin
Mark Herschberg
Sheriff

Joined: Dec 04, 2000
Posts: 6037
I have to disagree with you Sean, fundamentally JMS and RMI are similar. Both involve data transfer to an external system for the purpose of processing, e.g. system A send data to system B and asks it to perform a calculation, system B does this, and returns the result to system A.
I'm going to talk about these at a high level. Obviously, the implementation and usage details are very different.
The main difference between the two is the RMI is synchronous whereas JMS is asynchronous. When a client makes an RMI call, that thread of execution in the client is suspended until the RMI calls returns (or is timed out). With an asynchronous scheme like JMS, the client sends off a message, and continues to do work until a reply is received.
At my last company, we had a framework for a client-server system and used RMI. RMI is fairly standard for typical client-server systems on LANs. The programming model is straight forward. The developer simply makes a method call, not really worrying bout the fact that the object on which the method is being invoked exists on another machine (more or less, there is some extra work that needs to be done).
My current company has a wireless client-server framework. Compared to JMS, RMI requires more bandwidth. Given un unstable, lossy network (typical of most if not all wireless systems worldwide), we felt a messaging solutionwas more appropriate. If the network failed, we can queue messages to be sent off later. The programming model is a little more complex. For example, task A does some works sends off a message. That's all we can do for now, so we moe on to task B. In the middle of task B, we get a reply to message A. Maybe it's important, so we need to deal with it immediately, menaing we need ot handle it in the background or suspend task B. You need to have more hooks in your code for these call-back like events, and there are more situations you need to worry about.
Generally, messaging solutions are much more scalable. Most high transaciton systems use messaging, because it can handle failure better. That's because messaging systems are used ot handling multiple tasks, which may each be at different stages (as in the example above). If the netowrk dies, it can queue messages, an move on to the next task; whent he network returns, the messages get sent off. The application doesn't necessarily know or care that the network died, the JMS "layer" took care of all that.
I was at a talk recently by company that makes JMS products. They found and architect claimed he sees no need to RMI, and that JMS should be able to do everything you need (I think there's an a synchronous JMS scheme, these days). That sounds a bit extreme, but in theory he may be right.

Summary:
On a stable network with a limite dnumber of clients, use RMI; it's easier to use, from a design standpoint (not necessarily implementation standpoint), i.e. the programmatic model is easier. If the network is unstable or you need high throughput, use JMS.

--Mark
hershey@vaultus.com
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: RMI v/s JMS