In the context of "Business Object", think of entity beans and/or DAOs are the gateways to persistence storage. The idea is to present the client with an object a.k.a
a bag of data and still maintain the flexibility to change the underlying implementation. Although creating composite(coarse-grained) entity beans is a step in the right direction, I think the Business Object pattern is all about abstraction of data representation. It is not about how the data is populated or who populates it( the
J2EE pattern description tends to hint in the wrong direction), but it is about the "client view" of the data. A sort of composite transfer object if you will.
In the past I have implemented my coarse-grained transfer objects as busines objects. They implement an interface and the clients know only about the interface, but not about the implementation. This allows you to implement different flavors of the business object eg., data carried in a hashmap, data carried around as one big concatenated
string 
(although not recommended) and so on, while still conforming to the declared interface.
Cheers,
