ejb-ref,ejb-local-ref 是用于ejb调ejb的情况。ejb-local-ref用来做本地调用,ejb-ref用来做远程调用。
JNDI的位置可能由于各种情况会有所改变,这样可能使已经对应好JNDI的代码也跟着改,显然不利于编码,于是引入一别名ref,这个名字不一定要对应于事际的JNDI的位置,是一个reference.由系统实现一种引用和实际位置的关联。
个人理解,欢迎指正。
说到ejb-ref,就应提到JNDI命名冲突的问题。
当把同一个 J2EE 应用程序部署到多个应用程序服务器上,而这些应用程序服务器共享一个 JNDI 命名空间,那么,由于命名空间中的 JNDI 名称必须是唯一的,这样做将会出现冲突。所以我们使用 java:comp/env 环境命名上下文来查找 EJB,而不是使用 JNDI 名称来查找。有了这个命名上下文,就可以避免发生冲突,移植性也好。
当把一个bean或jar文件部署到使用同一个JNDI 名称空间的两个不同服务器中时, 如果按常规的方式 Lookup("beanJndiName"),就会出现命名冲突。我们可以通过改两个不同服务器上的EJB的JNDI名称,然后改它们各自的lookup语句。这是一种硬编码,正如上个贴子说的不利于编码。
我们也可以用软编码的方式,在不同的服务器上使用同一个配置文件,在配置文件中修改不同的JNDI名,然后在代码中读取这个配置文件但是是把这个配置文件放在哪里昵?放在jar文件中,这样只对这个特定的EJB应用用效,跟改源代码差不多,就是省了编议的步骤,放在App的clasapath下,当部署在服务器上的EJB越来越多的时候,阅读起来不直观,管理起来也不方便。于是就有了使用 java:comp/env 环境命名上下文来查找 EJB的方式,
我们可以用
|
这里在ejb-jar.xml文件中,有一个ejb-ref的引用,如何把“java:comp/env/ejb/myHome”字符串和驻留在某台特定服务器中的 BeanHome 的 JNDI 名称关联起来,这项工作留给底层去做。我们不必关心。当我们完成这些工作后,发布BeanHome在一台服务器上,相应的JNDI也会得到一个引用,这是一个EJB实际位置的引用,系统自然会把ejb的reference与这个EJB实际位置的引用对应起来,我们就可以不必理会JNDI名称冲突问题,sessionBean也可以通过以上代码定位到相应的JNDI服务(并没有使用BeanHome的JNDI名),并且在发布EJB的时候,deployer可以清楚的知道test这个EJB要调用Bean这个EJB。直观明了。
另外,如果我不配置ejb-ref,ejb-local-ref标签,是否可以通过lookup(JNDI名称)实现本地调用呢?
不是,这里的Bean是一个实现了EjbObject的Remote对象
> 另外,如果我不配置ejb-ref,ejb-local-ref标签,是否可以?> 过lookup(JNDI名称)实现本地调用呢?
如果没有名称冲突的话,是没问题的,你可以自已试一下。
|
使用 ejb-link,这就使用本机中的要引用EJB的JNDI 名称。如果没有,那么 ejb-ref 就有可能引用别的机子上的同一个EJB的JNDI 名称,这样也就可能会调别的机子上的EJB了,你也在ejb-link中引用不同jar 文件中的Ejb-name. 不过我没试过ejb-link是否可以引用远程的不同jar文件。