This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Is it advisable to always wrap Entity EJBs in Session EJBs? Say for example I had to update or add information for a single Customer. What would be the major arguments for or against having a servlet directly work with an Entity bean rather than have the servlet interact with a Session bean that wraps the Entity bean? Thanks in advance
Usually a EJB that executes only this kind of work shouldn�t be build as an entity ejb, there�s some best design rules that you may follow to optimize the application that�s why you allwas see this kind of instruction about accessin entity ejb�s. If you wanna understand this better there�s a free downloadable book from sun at: http://java.sun.com/j2ee/blueprints/aboutthebook.html it�s a worth time reading.
The process of wrapping your entity Beans into a Session Bean is called the Session Facade Pattern. If you have your clients / servlets access the Entity Bean directly you have the following drawbacks: - It doesn't scale well under serious load. This is because you have lots of network I/O. You have to find the bean(s) you want and then execute methods on it. Think of how many requests this will make when you are running bean specific methods on each entty and they ALSO are passing info to the Session bean that handles the workflow between your entities. I'll use an example I read about on http://www.theserverside.com. If you have a bank application where you are transferring information from one account to another you need to loookup the User, Account1 and Account2. This requires 3 lookups and then multiple method executions (I.E. I/O) to withdraw from Account1 and Deposit to Account2. - Client tied to server. If you change the logic in the entity bean the client is directly tied to it. - Transactions. If your client is located far from the server, or even behind firewalls. Your transactions could last a very long time as the server waits for the client to respond. Having your Session bean handle all the entity bean calls addresses the previous problems in the following way. - Network IO: Although you are now calling through the Session Bean layer and not directly to the Entity, you only have to make one call. (I.E. someSessionBean.transferfunds( User, originalAccount, destinationAccount ). This method can do all the lookup for you and handle all the remote calls to each entity bean. You make one method call and get one result to handle. - Client is not tied to server. Now if we change some of the logic with the Entity beans you (or I) just have to change the Session bean's facade. Also, multiple diffrent types of clients can access our Session easily as they all use a common interface that translaite their protocol specific needs into a generic one. It's easier to have some kind of session controller translate a HttpRequest or a WapRequest into a hashmap and send it to the Session bean. - Transactions: All transactions are carried out by the server container inside the session bean. We don't have to 'manually' handle the multiple bean method calls. There are plenty of great resources on the net explaining this a bit further. The one I used for my above exmaple was at the following link: http://www.theserverside.com/resources/patterns_review.jsp I hope this helped.
------------------ SOURCE CODE should be SURROUNDED by "code" tags. Click here for an example [This message has been edited by John Bateman (edited August 24, 2001).]