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
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???
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.