Are the notions mentionned in the question title synonymous to a certain degree? Where do the main differences lie (context, structure, …) and can one be considered a subset of another? Here’s some brief definitions taken from Wikipedia.
POJO (Plain Old Java Object)
Wikipedia
In computing software, POJO is an
acronym for Plain Old Java Object. The
name is used to emphasize that a given
object is an ordinary Java Object, not
a special object, and in particular
not an Enterprise JavaBean. The term
was coined by Martin Fowler, Rebecca
Parsons and Josh MacKenzie in
September 2000:"We wondered why people were so against using regular objects in their systems and concluded that it was because simple objects lacked a fancy name. So we gave them one, and it's caught on very nicely."
Java Bean Wikipedia
JavaBeans are reusable software
components for Java that can be
manipulated visually in a builder
tool. Practically, they are classes
written in the Java programming
language conforming to a particular
convention. They are used to
encapsulate many objects into a single
object (the bean), so that they can be
passed around as a single bean object
instead of as multiple individual
objects. A JavaBean is a Java Object
that is serializable, has a nullary
constructor, and allows access to
properties using getter and setter
methods.
Value Object Wikipedia
Data transfer object (DTO), formerly
known as value objects or VO, is a
design pattern used to transfer data
between software application
subsystems. DTOs are often used in
conjunction with data access objects
to retrieve data from a database.
Business Object Wikipedia
A business object is a type of an
intelligible entity being an actor
inside the business layer in a
n-layered object-oriented computer
program.
Related:
Difference between DTO, VO, POJO, JavaBeans?
What is the difference between a JavaBean and a POJO?
DDD: what's the use of the difference between entities and value objects?
Not all of these classifications are related. Here’s my understanding:
POJO is what its name suggests – a plain old Java object. There’s nothing special about it. And this is exactly what we want to convey when we say that an object is a POJO. Today most applications are using some kinds of underlying frameworks, and with the frameworks come requirements on the objects that will integrate with the framework – the object must implement an interface or extend a class. When we say an object is a POJO, we mean to say it is just an ordinary object and has no dependencies on any framework.
A JavaBean is a java class that follows certain conventions as described in your question. Such objects are often mandated by certain frameworks which use reflection to find out the properties (accessible through getters/setters) of the object and manipulate them e.g. beans exposed to JSPs, Spring beans etc. The good thing about JavaBeans is that they are still POJOs. Although they follow certain conventions, the conventions are not defined by any particular framework but are rather defined by Sun Javabean standard and the classes are still plain Java classes with no ties to any third party framework’s classes or interfaces.
Business Objects refer to objects that represent your business domain entities. These usually reside in your business layer – the layer where all the business logic is. These objects usually map to persistence store entities e.g. tables. These objects could be POJOs, JavaBeans, EJBs etc.
Value objects are a type of design pattern. In some small web applications, you have the option of using your business objects in the web layer as well. However, in larger applications or J2EE applications, you define value objects to move information from the business layer to the web layer. That’s why they are also called Data Transfer Objects (DTOs). These objects usually have only the attributes that are needed in the web layer and leave the attributes of business objects that were meant for business layer consumption behind. They may also have “computed” attributes that are generated in the business layer. Using this patterns helps decouple the business and web layers.