The main reason is we want to encourage the writing of portable applications. Access of
resources/dependencies via the component environment is one of the key aspects of the
Java EE programming model. Components access dependencies using a level of indirection
so that both the code and standard deployment descriptors do not have hardcoded values
that are specific to a particular deployment environment or application server. This is important
when accessing any kind of depenendencies from your components, not just local EJB references.
It's important to note that the issue is not whether a particular resource has an associated
global JNDI name. Just because Remote EJB components happen to typically be assigned
a global JNDI name does not mean they should always be looked up directly via that global JNDI name. The global JNDI name is used to map a dependency from a calling Java EE component to the target physical resource. Application code running outside of a Java EE
environment might need to use a global JNDI name directly, but such code does not have
the same portability guarantees. Of course that doesn't apply to local EJB references
since they are only accessible to Java EE web/EJB components.
In the case of local EJB references, there is no need to define a global JNDI name because
an @EJB or ejb-local-ref can always be fully resolved to the target local EJB using purely
standard metadata in the form of beanName() or ejb-link, which uses the target ejb-name and
optionally the target ejb-jar within the application.
We have a presentation that goes into further detail about the component environment
architecture here :
https://glassfish.dev.java.net/javaee5/ejb/compdependencies_xmlforum_nov15.pdf
--ken
[Message sent by forum member 'ksak' (ksak)]
http://forums.java.net/jive/thread.jspa?messageID=218589