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.
The ejb-ref elements in the standard ejb-jar.xml are used to specify logical references to another EJB the one being described is going to use. It's basically a promise/requirement saying "the application deployer must map this reference to a real JNDI name upon deployment". For example, you have an EJB called CustomerBean that needs to use the AccountBean. You could just lookup the AccountBean from CustomerBean using the JNDI name that was used to deploy AccountBean with. This approach does have its sore points however. What happens if the application deployer finds out that the JNDI name the bean developer had assumed cannot be used in the production environment for some reason? The solution would be to abstract the real JNDI name from the CustomerBean by using ejb-ref. The ejb-jar.xml of CustomerBean would define an ejb-ref so that CustomerBean code can use "java:comp/env/XXX" to lookup the AccountBean where "XXX" is anything the deployer wills. It is then the application deployer's job to specify the link between ejb-ref and the real JNDI name. With WebLogic, for example, this is done using weblogic-ejb-jar.xml (i.e. using the vendor-specific deployment descriptor).