I must say, I have programmed both with sockets and RMI/CORBA - both with the same objective in mind.
Sockets seem easier to control, where something like CORBA could take a lot of time to learn. RMI would limit you client to needing to be another Java application. In case you don't know, RMI is a Java only version of CORBA.
Sockets would limit your client applications to also being Java based if you choose to write objects across the stream (So in answer to your question, yes you can serialize and send objects across a network)
sockets could be client independent (c++,.NET, etc) if you choose to just write bytes across the network. However writing bytes you would need to make some sort of protocol for communications, this can be a lot of work, and if you get errors and need to debug problems by reading byte streams... your in for a tough time.
CORBA is good for business. It allows you to read and write objects, and call methods on remote objects, and its highly optimized, its a mature technology, having been around well over 10 years. It allows your Java application to communicate with ANY other client, c++, .NET, etc
My advice. If your programming games, chat programs, streaming media, file transfer use sockets and read/write bytes. You have tighter control over what is sent, you can optimize the streams, by buffering, or compressing date.
If you programming business applications which require remote method calls, use CORBA, (or if the client is definitly Java, you could use RMI). Corba however would be useless for lets say, file transfer, or any streaming type app.
Hope that helps
PLEASE WATCH THIS VIDEO: <a href="http://www.glumbert.com/media/dolphin" target="_blank" rel="nofollow">http://www.glumbert.com/media/dolphin</a><br /> <br /><-- that video is no joke. Spread the word... this cant go on!!!<br /> <br />SCJP 1.4, SCBCD 1.3, SCWCD 1.4, SCMAD 1.0
One benefit would be that RMI works in terms of objects and method calls, whereas socket communication works on the level of bytes sent and received (leaving aside serializing of Java objects for the moment). So socket-based apps need to put some infrastucture in place to get to the level where RMI is at.
(As an aside, RMI can be made to interoperate with Corba by using the IIOP protocol instead of the (Java-only) JRMP protocol.)
I'm not sure I'd agree with the advice to use Corba. Although it's used in many places, it doesn't seem to go anywhere, and has a steeper learning curve and much higher infrastructure requirements. I wouldn't recommend it for new projects, and neither would I recommend RMI, for that matter.
Instead, Web Services have been gaining attention because of their cross-platform interoperability, and easy deployability (a WS engine needn't be more than a web app).
Thanks so much. That was great information - exactly what I needed.
I very much understand Dean's promotion of CORBA where many apps need to communicate. It has been a lifesend in the auto manufacturing field where we are putting together a bunch of components from different platforms. I also appreciate Ulf's comment that a future direction is to go with Web Services where possible. I just don't see those CORBA components at Ford being wrapped up in a Web Service any time soon.
"RMI is just a Java version of CORBA." I'm sure that'd upset SOMEBODY on the RMI teams at Sun Microsystems.
subject: Why use RMI when Socket programming can do it all?