General J2EE: design question about socket programming vs RMI
I need to communicate from a process in one partition of a application server to another process in a different partition. What is the most appropriate way to do this communcation.
- Posted by: Kishore Dandu
- Posted on: June 18 2004 18:18 EDT
Is socket programming better compared to RMI-IIOP.
Your inputs are appreciated.
If the communication is asynchronous, you can use JMS. JMS is a part of the J2EE spec, so very Application Server has to support it.
What is the form of communication? Will there be a lot of it?
Personally, I find RMI better unless things are very simple. You do have some extra things to worry about with RMI (RMI-Compiler, serialization versions), but it does abstract away most low-level details, and it can be quite powerful. Performance has never been a big problem for me with RMI. The increased level of abstraction makes up for any performance hit (the main issue is that RMI from Sun (JRMP) uses TCP, when UDP is a much more suitable protocol for RPC calls, though I know many individuals/companies have rectified this by writing their own RMI implementations that use UDP).
Do you need to worry about transactions? I.e. if the remote call executes or not, if the remote process in another parition has died or the listener is not active? RMI implements at most once semantics, so a remote invocation is guaranteed to be executed no more than once which means that it may not be executed at all in the event of an error.
The communication needs to be synchronous. So JMS is ruledout.
There is no need for transactional security because there is no need for rollback etc in case of failure on the serverside.
I have a question.
You said the follow: "Performance has never been a big problem for me with RMI."
Many time ago, about 8 years, I read an article about this, where spoke that Socket is better (performance) than RMI.
I believe that serialization, object transfer
What happens with RMI during this time? Optimization?