In another question I was worried about using a web service that takes a five minutes to complete. I was thinking about using RMI instead of web services for this use case..
but at the end of the day, do both a web service and RMI use a TCP socket for the underlying connection? Is there any reason why a web service call taking 5 minutes is less stable than an RMI request taking the same time?
Note that in our case we are talking about internal apps communicating.
Update: This question stems from me worrying that we'd run into dropped connections or other issues with web services that take 3-5 minutes to complete. The worry maybe totally irrational - responders to my other question indicated you should be fine if you control both the client and the server. But I just wanted to understand in more detail why a dropped connection for a 5 minute call is no more likely using a web service implementation than an RMI implementation. If they both rely on socket connections than that might explain why there is no difference...
If a single remote call is taking 5 minutes to complete, then it's probably because the operation implementing that call is slow, not because the web service layer itself is slow. If you were to re-wrap the operation with RMI, it'll likely be just as slow.
The performance benefit of RMI over SOAP is only really going to be apparent when you have a large number of operations being called, rather than for the speed of any one operation, simply because RMI is more efficient than SOAP. But it won't magically make a slow operation go faster.
As for your question regarding sockets, yes, RMI and SOAP both use socket-level protocols when you go down far enough (IIOP or JRMP in the case of RMI, HTTP in the case of SOAP). That isn't really relevant to your problem, though.