I read this great article about best-practice for EJB-JNDI mapping :
http://www.ibm.com/developerworks/websphere/library/bestpractices/increase_app_portability.html
The notion of ejb-link isn’t clear for me.
For example, let’s say we have an ejb-jar.xml containing this :
<ejb-ref>
<ejb-ref-name>ejb/Bean2Home</ejb-ref-name>
<ejb-ref-type>Entity</ejb-ref-type>
<home>com.ibm.wsc.Bean2Home</home>
<remote>com.ibm.wsc.Bean2</remote>
<ejb-link>Bean2</ejb-link>
</ejb-ref>
Thus, it is precised that the targeted EJB component is Bean2 and this simple notation means that Bean2 must be find on this J2EE application package or .ear file.
So, if ejb-link markup is enough determinant to indicate the right way to link to the good EJB component, what is the need for assembler to create a JNDI name for this ejb-ref ?
Is it really useful?
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.