如果您把同一个 J2EE 应用程序部署到多个应用程序服务器上，而这些应用程序服务器共享一个 JNDI 名称空间，那么，由于名称空间中的 JNDI 名称必须是唯一的，这样做将会出现问题。部署到 WebSphere Application Server 环境中的 J2EE 应用程序，应该使用 java:comp/env 环境命名上下文（environment naming context（ENC））来查找 EJB，而不是使用 JNDI 名称来查找。有了这个命名上下文，就可以避免发生冲突，应用程序的可移植性也将好得多。 　　开发和部署按照 EJB 1.0 规范级别编写的 EJB，困难之一是处理 EJB home 的 JNDI 名称。例如，有很多代码写成像下面的代码片段（取自会话 bean）那样，试图查找 com.ibm.wsc.Bean2 EJB 的 home： 　　 　　Context myInitCtx = new InitialContext(); 　　Object result = myInitCtx.lookup("com/ibm/wsc/Bean2Home"); 　　com.ibm.wsc.Bean2Home theBean2Home =(com.ibm.wsc.Bean2Home) 　　javax.rmi.PortableRemote.narrow(result,com.ibm.wsc.Bean2Home.class); 　　这一技术在Java开发环境（Java development tooling，JDT）中能工作得很好，在应用程序的部署阶段似乎也不出什么问题。只要看一下上面的代码，就可以确定在名称空间中赋给Bean2Home的JNDI名称，因为这个名称就是EJB Home接口名称。编码约定就跟 EJB 类名被用来构造定位 home 的代码那样相当简单。 　　当把“Bean2”部署到使用同一个（共享的） JNDI 名称空间的两个不同服务器中时，问题就冒出来了。 　　例如，有人可能有两台服务器，WSQASV 和 WSFXSV，它们共享同一个名称空间（即 LDAP 或 CosNaming 服务器），并且他想把同一个 J2EE 应用程序（即 .ear 文件）部署到这两台服务器中。由于每台服务器中的会话 bean 都必须查找／使用 Bean2Home 的正确实例，所以，这就出现了一个问题。要避免这个问题，必须做两件事： 　　安装在服务器 WSQASRV 中的 Bean2Home 的 JNDI 名称必须与安装在服务器 WSFXSV 中的 Bean2Home 的 JNDI 名称不同。这两个 JNDI 名称必须不同，EJB home 的 lookup( ) 才能把引用（即 IOR）返回给安装了该 EJB 的正确的服务器。 　　引用 Bean2Home 的客户机（即会话 bean）必须根据部署了该应用程序的服务器显式地指定 Bean2Home 的 JNDI 名称。 　　EJB 的命名模式已经开发，以硬编码的方式把 JNDI 名称编写到 java源代码中是问题的真正起因。我们需要这样一种能力，不必根据部署了 EJB 的服务器修改代码就能够提供特定于运行时的信息。结果是创建并实现一个模式，它利用 ResourceBundle 或 Property 文件提供运行时信息，如以下代码片段所示： 　　ResourceBundle myRB = ResourceBundle.getBundle("ServerProps"); 　　String myBean2HomeJNDIName = myRB.getString("Bean2HomeName") 　　Context myInitCtx = new InitialContext(); 　　Object result = myInitCtx.lookup(myBean2HomeJNDIName); 　　com.ibm.wsc.Bean2Home theBean2Home =(com.ibm.wsc.Bean2Home) 　　javax.rmi.PortableRemote.narrow(result,com.ibm.wsc.Bean2Home.class); 　　这一技术的全部要求就是为 WSQASV 服务器创建一个唯一的名为 ServerProps.properties 的 .properties 文件，WSQASV 服务器的这个文件包含有类似下面的内容： 　　Bean2HomeName=WSQASV/com/ibm/wsc/Bean2Home 　　WSFXSV 的 ServerProps.properties 文件包含有类似这样的内容： 　　Bean2HomeName=WSFXSV/com/ibm/wsc/Bean2Home 　　现在，我们有了一个模式，不管将 J2EE 应用程序部署到两台服务器中的哪一台，这个模式都不要求在部署之前对 java 代码作丝毫更改，EJB home 的命名约定得到了一定程度的保护，但受服务器限定。这个“服务器名”限定使得在任一台服务器中都可以正确定位 Bean2Home。在部署阶段，部署者只需要知道 .properties 文件的内容，以将正确的 JNDI 名指定给 EJB。 　　采用这种技术，只有一个问题还留待部署者去解决：如何管理特定于服务器的 .properties 文件。让人左右为难的是，.properties 文件既是特定于应用程序的（即应用程序中所包含的特定 EJB home 正在被查找），又是特定于服务器的（即 EJB home 的 JNDI 名称取决于安装了该应用程序的服务器）。问题是：ServerProps.properties 文件是在 J2EE 应用程序包（即 .ear 文件）中呢，还是在服务器的类路径中？把 .properties 文件放到 .ear 文件意味着 .ear 文件在部署到上述两台服务器之前必须先作修改。人们不希望这样做，原因与人们不希望修改 java 源代码的原因如出一辙。不过，人们倒是很希望有一个各个部件的单个包，而不必为特定于应用程序的文件具体配置服务器。 　　EJB 1.1 解决方案 　　幸运的是，EJB 1.1 规范引入了 JNDI 增强功能，特别是环境命名上下文（ENC）以及关于如何“找到” EJB、资源和特定于应用程序的环境变量的强烈推荐的做法。要了解详细信息，请参阅 EJB 1.1 规范的第 14 章和 J2EE 1.2 规范的第 5 章。以下代码片段使用所推荐的 java:comp/env 构造来查找 Bean2Home： 　　Context myInitCtx = new InitialContext(); 　　Object result = myInitCtx.lookup("java:comp/env/ejb/Bean2Home"); 　　com.ibm.wsc.Bean2Home theBean2Home =(com.ibm.wsc.Bean2Home) 　　javax.rmi.PortableRemote.narrow(result,com.ibm.wsc.Bean2Home.class); 　　如何把“java:comp/env/ejb/Bean2Home”字符串和驻留在某台特定服务器中的 Bean2Home 的 JNDI 名称关联起来，这项工作留给应用程序的装配者和部署者去做。应用程序开发者既不知道也不关心 Bean2Home 的 JNDI 名称。 　　特别地，装配者必须在引用 EJB 的 ejb-jar.xml 文件（或者是引用 servlet 的 web.xml 文件）中包含一条带有以下内容的子句： 　　 　　ejb/Bean2Home 　　Entity 　　com.ibm.wsc.Bean2Hom [1] [2] 下一页