Here are some scenarios that hopefully clarify why <ejb-link/> (or @EJB(beanName="...")) and EJB ref bindings are both useful and complementary:    An application can itself be logically broken up into components, and the developer chooses to use EJBs to implement those components. In this case, the application developer knows the target EJB component that the client wants to use. If there are multiple components implementing the same interface, then some disambiguation is required, and <ejb-link/> can be used.    An application has a dependency on an external service. In this case, the application knows it has a dependency on an external service, so <ejb-link/> cannot be used since the service implementation does not exist in the same application.    An application has a dependency on an external service, but a minimal implementation is provided in the same application. In this case, the developer might use an <ejb-link/> as in #1, but the deployer has the flexibility to override that choice as in #2.

    public static final Set<String> knownResourceEnvTypes = new TreeSet<String>(Arrays.asList(        "javax.ejb.EJBContext",        "javax.ejb.SessionContext",        "javax.ejb.EntityContext",        "javax.ejb.MessageDrivenContext",        "javax.transaction.UserTransaction",        "javax.jms.Queue",        "javax.jms.Topic",        "javax.xml.ws.WebServiceContext",        "javax.ejb.TimerService",        "javax.enterprise.inject.spi.BeanManager",        "javax.validation.Validator",        "javax.validation.ValidatorFactory"    ));

Good question (and one you should know for the exam)resource-ref is for "resource manager connection factory" objects that can give you connections to a resource manager. The typical example is for javax.sql.DataSource from which you can get JDBC connections (javax.sql.Connection).The resource-ref is so that you can have a ‘logical name‘ used in code -- that the deployer then binds to the *actual* resource factory configured into the server. So when you think of resource-ref, think of "Programmer‘s made-up/fake name for the datasource." Since the programmer may not know, at the time of coding, what the *real* name is going to be (and since the component model demands that the name of these things is something that can be configured at deploy-time without changing code.)So... what‘s the deal with resource-env-ref?1) It is new to EJB 2.02) It was added because of message-driven beans/JMS3) It has the WORST name, designed, I‘m certain, just to confuse you.For example, a resource manager connection factory is certainly an entry in the bean‘s environment -- so it would be perfectly logical to assume that resource-env-ref is an appropriate name for what is actually resource-ref.But...you have to memorize it differently.A resource-env-ref is for "administered objects associated with resources", and the most obvious example (and the reason it was added) was for JMS destinations. The idea is the same as resource-ref (or security-role-ref) in that it stands for "programmer‘s made-up/fake name", only instead of a name for a resource factory, it is a name for a ‘resource‘.The main difference:resource-ref:things that give you CONNECTIONS (including URL connection - JavaMail connection factory, JDBC connection -- DataSource, and -- for the really confusing one -- QueueConnectionFactory for obtaining JMS connections.)resource-env-ref:things that give you access to a resource, but which are NOT factories that give you connections. In other words, with resource-ref you are getting something that you then can use to GET to a resource, but with resource-env-ref, you get right to the resource without going through a factory.The way I think of it, for the purposes of the exam is:resource-ref: "Programmer‘s made-up name for the database driver"[just a way to remember, not the exact technically correct way to say it]resource-env-ref: "Programmer‘s made-up name for the JMS destination"From what I‘ve heard, the resource-env-ref really should have just been called JMS-resource-ref, but that would have been more limiting. Much clearer, though.The only resource example used in the spec is for JMS destination, and although I‘m sure there may be other examples, I have no idea what they might be.

@EJB(name="ejb/EmplRecord", beanInterface=EmployeeRecordHome.class)@Stateless public class EmployeeServiceBean implements EmployeeService {    public void changePhoneNumber(...) {        ...        // Obtain the default initial JNDI context.        Context initCtx = new InitialContext();        // Look up the home interface of the EmployeeRecord        // enterprise bean in the environment.        Object result = initCtx.lookup(        "java:comp/env/ejb/EmplRecord");        // Convert the result to the proper type.        EmployeeRecordHome emplRecordHome = (EmployeeRecordHome)        javax.rmi.PortableRemoteObject.narrow(result,        EmployeeRecordHome.class);        ...    }}