Howdy --
Java's an OO language, so it's a more natural fit to SEND whole objects (over a network, for example), and to SAVE whole objects when you need persistence. I used to write games, and before Serialization (which didn't appear until Java 1.1), saving the state of a game and its characters was AWFUL -- you had to have your classes implement a 'Saveable" interface (just made that up), and then implement the saveYourself() method in each class. That saveYourself() method had to look at the state of all the important variables and then write them out to the file and then -- OH GOD you had to be absolutely certain you knew what you were doing when you tried to 'restore' the objects later using that data. You had to keep track of exactly in which order you wrote the variables out to, and obviously all classes were different, and... I get the chills just thinking about how many Bad Things Happened.
So that's the Saving part of Serialization, which is cool all by itself. But then there's the Shipping part of Serialization, where you pass a whole object over the wire instead of the object's individual values which you use to later build a similar object on the other side. Serialization is really great for this purpose because it allows RMI, and RMI lets you call a method on an object running in some other JVM (probably on some other physical machine on the network) almost as simply as calling a method on an object in the same JVM heap.
Serialization comes in to play in several ways, but most importantly in passing arguments and return values. Without Serialization, you couldn't have the ease of RMI (where all the sockets/streams/protocol issues are handled for you behind the scenes!) because you'd have to split apart the object's data, agree on a protocol, send it over the wire in a stream, and then figure out how to parse and use the info on the other side.
With RMI, the client just calls a method... getBalance(aCustomer) passing in a local reference to an object, just like you always do with a method call, and the object on the other side (the remote object with the getBalance(Customer aCustomer) method) just treats the aCustomer parameter like any other object reference. As far as the remote object getting the call is concerned, it's just a plain old local object. But in reality, whatever object was originally referenced on the client by aCustomer was actually serialized, shipped over, deserialized, and then the new reference was passed to the remote object with the method.
Serialization is just fantastic!! Every OO language needs a way to 'flatten' or 'persist' objects, and Serialization is Java's way. Saving, passing, writing objects through Serialization is the more OO way to save, pass, and write the data that makes up an object's state. It's just better OO.
(in many cases, anyway).
cheers,
Kathy Sierra