Wake up and smell the java

Session Facade
Consider two Entity Beans and a client for ex: Employee and Paycheck. So you find the Employee, create a new Paycheck, populate some of the employee details or based on some values in Employee, you set some values on Paycheck. So you have all this business logic noise all over the client and the overhead of managing the entity beans. Enter Session Facade: You have a Session bean, that has a single method called managePaycheck, all the client has to do is call this method and all the noise moves to the Session bean.

Value Object/Data Transfer Object
Value objects are used to transfer bulk data between tiers. So if you have a remote object (entity bean) and you are calling a multitude of get methods on that object. It makes sense to create a single ValueObject containing all the data needed. So now you are just calling getValueObject on that Entity bean (provided ofcourse the entity bean populates all the fields in the ValueObject first).

Use of dirty flags in the EntityBean
Use dirty flags in ejbStore, basically init this as false in ejbLoad and set it to true in the setter. In ejbStore check this flag and only go ahead if it is true.

More to come…

• More detail here
• You have your EJB server, container, EJBs and clients.
• Entity Beans (think persistence), Session Beans (stateful/stateless), Mesage Driven Beans (needs no interface)

EJBs have:

• Home Interface: provides methods for locating, creating, and removing instances of EJB classes, home object is implementation
• Remote Interface: is the client facing interface, it has all the business methods.
• Enterprise Java Bean: Is in the container result of deploying home and remote interface.
• Create home interface by extending EJBHome
• Create Remote interface by extending EJBObject
• Define primary key object.
• Create your Entity Bean implementing EntityBean

Typical lifecycle:

• Locate home object, create or find remote object from home object, apply business methods on remote object