Entity beans are nice, but there are disadvantages to using EntityBeansAsDomainObjects. So another approach is not not use them as domain objects. Domain objects can be plain vanilla objects just like your mother made them. A separate persistence layer then works with the database, just as in pre EJB days. You can buy a persistence framework to make this easier.
You can use a session bean to coordinate the transaction (keeping track of changed objects etc) and communicate with a client. The session bean uses FacadesAsDistributedComponents
The entity beans now sit in the infrastructure layer of the FourLayerArchitecture. The infrastructure layer is responsible for storing and saving domain objects, but the domain objects don't know about the infrastructure layer and the entity beans.
The advantages of this approach are that we now don't have remote business objects. We don't have to catch and throw remote exceptions all over the place. There is no danger of FineGrainedDistributedObjects.
We also can replace entity beans in the infrastructure layer with direct calls to the database should we wish to. In the face of immature EJB containers this could be important, especially if we want to control the database accesses to improve performance. Indeed we could eliminate Entity Beans entirely if we were unhappy with them, or use a mix of Entity Beans and SQL for our data access.
However this requires extra coding. The transaction management has to be written, mapping code back and forth to the EJBs has to be written.
Save-Load Responsibilities
There is variation in this approach as to which objects should actually do the save and load of the domain objects.
The simplest route is to let the entity beans do this. Another option, which KyleBrown has used successfully, is to have separate factory objects which use the entity beans as data sources. Although this adds an extra layer of objects, it means that the entity beans can be entirely generated. This is good as it separates machine-generated and hand-written code.