First off, there are very few if any rules set in stone about these, so everything I am about to say is subject to interpretation and riddled with exceptions in practice.
That said... ValueObjects are usually only getters/setters. They strictly contain no business logic and are used as transport mechanisms on a J2EE environment such as transporting between the client to the server or the server to the database. Any serializable class can be a value object, although putting business logic in them is generally considered bad design. Finally, each getter/setter corresponds with a single object/primitive value.
JavaBeans, on the other hand, are specifically for client side/jsp management. You wouldn't pass a JavaBean to a database server for example (although you could since your ValueObjects and JavaBeans may be the same class). While they should contain getters/setters they often contain over-ridden methods for getting and setting complex types.
For example, a user may enter a date and a time as two separate boxes on an HTML form. There would be two setters that set two distinct values, but there may be only one getter that converts the date plus the time strings into a single java.util.Date object. Therefore, there is no required direct correspondence between getters/setters and the objects/primitives they represent.
All classes can be JavaBeans but only ones with getter/setters can be used directly by a JSP. Finally, JSP's contain corresponding JavaBeans entries in XML that convert the bean data into runtime objects to be used by the JSP. I tend to put a ton of conversion code in JavaBeans such as converting strings to integers and setting them to blank (or flagging an error) if they are not valid numbers. Keep in mind, the JavaBean can store such boolean flags that represent there was a problem during the use of a setter or getter. [ December 22, 2005: Message edited by: Scott Selikoff ]
For me a ValueObject is a kind of JavaBeans. It's just a matter of Design pattern : the pattern "Value Object" which define a way to encapsulate data (in VO) in order to transfer them between different layers. We use the term of Value Object to refer to the Design patterns but in the fact it's just a JavaBean.
Yes they are really just terms. kind of like the difference between a POJO (Plain Old Java Object), a JavaBean, a ValueObject, and a DTO (Data Transfer Object).
A JavaBean, ValueObject and DTO are all POJOs, but a POJO isn't necessarily a JavaBean, VO or DTO, it could be a class like the Math class, where there isn't any getters and setters.
In the JavaBean case, it is just a basic contract that states all instance variables are private, and have getters and setters to access them.
a ValueObject and DTO are the exact same, they are an Object that holds data for us, so that when calling accross a network we can have just one network call that returns a VO/DTO and we get all our data in that one call that we need.
Not to everyone. DTO fits well with what we've been talking about, but Value Object is defined by some OO folks like this: value objects are things like numbers, dates, monies and strings. Usually, they are small objects which are used quite widely. Their identity is based on their state rather than on their object identity. This way, you can have multiple copies of the same conceptual value object.
Stick with the DTO term for moving data between architectural layers.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi