Upon cursory inspection I would suspect that the motivation behind the design of the Struts Form Bean is different from the motivation behind the Data Transfer Object.
The motivation behind the Data Transfer Object is to create a serializable data container that can help move data across JVM, process and network boundaries. It often carries more data than is required by the caller and is usually devoid of any behavior besides what is necessary to set and get its data members.
A Form Bean can add validation behavior. Being a Java bean means that it has an easily discoverable interface that is easy to configure (and load) declaratively through configuration files (rather than programmatically through program code). It's primary purpose seems to be an abstraction/container for form data, to serve as a parameter to an object modeled after the Command pattern (the Action). The Form Bean is serializable but I'm not sure how essential that is to the primary purpose of the Form Bean - I don't believe that the Action consuming the Form Bean is likely to be in a different JVM from the one where the Form Bean was created in the first place.
It would be incorrect to assume that designs and/or patterns that lead to similar looking implementations "are the same" when in fact the driving motivations are different. [ March 28, 2007: Message edited by: Peer Reynders ]
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus