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.
If I had both the client and the EJB in the same container, do I have to use only local client interfaces, or can I implement remote interfaces?
That is can I use remote even though client is presently local? The scenario is if the application were to expand and if there is a chance that in future the client might become remote, I shouldn't have to change the client code to catch remote exceptions & do narrowing, etc.. right?
Does writing remote interfaces for local clients reduce performance?
I was thinking of what I would answer but your question already contains answer.
First of all, it is perfectly legal to define both local and remote interfaces for your beans. The only thing is you must NEVER mix them (ie do not make a remote home interface create method returning a local component interface, or anything like that).
But what you say is good, using local interface should be reserved to scenarios where you are 100% sure you will NEVER have clients and beans on different VM. This is quite hard to be so sure. For scalability needs it's still good to use remote interfaces even locally, so that the day you change, your app does NOT need any modification.
Of course, remote interface add overhead to your processings. It's up to you to decide wether your app architecture is worth the overhead.