This week's book giveaway is in the OCAJP forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide 1Z0-808 and have Jeanne Boyarsky & Scott Selikoff on-line! See this thread for details.
I find the following two paragraphs illuminating. They are from "Sun Certified Enterprise Architect for J2EE, Study Guide" by Paul Allen and Joseph Bambara.
J2EE Best Practices � Session Bean Fa�ade
The session bean fa�ade (SBF), shown in Figure 4-13, provides a simple, single point of entry to shared entity beans. It shields the client from complex entity bean relationships. The most obvious rationale for using session beans to abstract entity beans is that the approach also abstracts the structure of your data stores. The presumption is that you do not want to expose the inner workings of your application�s data store (such as the database tables and columns), or even the specifics of how that data is stored. In other words, letting users (potential hackers) know your database schema is not a good idea. Problems can arise when you allow direct access to the entity bean layer.
The methods in entity beans typically map directly to underlying fields in the data schema. This will become more important as service-based computing increases. Instead of providing complete applications, the J2EE specification (or Web Services: UDDI, SOAP) indicates that organizations are focusing more on components than on complete applications. Interchanging data components from enterprise A�s application with presentation components from enterprise B�s application is becoming the standard. As a result, it is unsafe to assume that only your enterprise will be accessing your business layer and EJBs. For these reasons, a sound design of the business layer can save trouble when beans you worked on must be accessible by a new business partner.
William Butler Yeats: All life is a preparation for something that probably will never happen. Unless you make it happen.
James J Xu
Joined: Jul 07, 2004
Dan, Thanks for reply.
James J Xu
Joined: Jul 07, 2004
If session facade talks with only one single entity bean, like AccountManagerSF used to manage CustomerEJB, should we just use a regular session bean like AccountManagerSLSB is enough? From best practice, it seems SF is used in managing the interaction between different beans.
Originally posted by James J Xu: If session facade talks with only one single entity bean, like AccountManagerSF used to manage CustomerEJB, should we just use a regular session bean like AccountManagerSLSB is enough? From best practice, it seems SF is used in managing the interaction between different beans.
Session Facades are generally used to abstract sub systems, complex entity relationships and inter dependencies between various entities in the system. The basic idea is that the web tier should never have access to the entity beans in the system. As the entity beans reflect the data model, its considered a bad practice to expose the interfaces of the entity beans to the web tier. It affects performance, maintainability and is also seen as a security risk to expose your database schema/model to the web tier. Hence, you generally abstract the entity beans behind session beans. If you have multiple entity beans and complex inter-relationship between them, then its best to abstract them with session facade. Session facades are used to manage workflow or "processes". If you have only one entity bean, then its best to either use a stateless or stateful session bean, as per the requirements of the system.