This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
1. To enable stub objects injected into interfaces for unit/integration testing. That being said, EJB 3.1 introduces no-interface local beans. 2. To enforce loose-coupling between clients and implementation code. This is especially true for remote clients. I can't think of a single technology, Java or otherwise, that allows direct access to implementation objects for remote clients.
Independent Consultant — Author, EJB 3 in Action — Expert Group Member, Java EE 6 and EJB 3.1
One more reason which I could see here . Enterprise Beans are not remote objects. Client and Enterprise beans do not share same heap and hence clients can not communicate directly to enterprise beans. So we have remote and home interfaces to safe guard enterpise beans from any direct interaction. As per Head First EJB, remote interface is like a body guard to enterprise bean and every communication should go only through him. If at all anything can communicate to enterprise bean it can be only container.
Thanks & Regards, SK
SCJP 5.0, DB2 - 800, DB2 - 803, SCDJWS (On the way)