WebLogic Server JNDI 服务提供程序接口（Service Provider Interface，简称 SPI）提供一个允许远程 Java 客户端连接到 WebLogic Server 的 InitialContext 实现。客户端可以指定标识特定 WebLogic Server 部署的标准 JNDI 环境属性，以及用于登录 WebLogic Server 的相关连接属性。
要与 WebLogic Server 交互，Java 客户端必须能够获取某个远程对象的对象引用，并能够调用对该对象的操作。要完成此操作，客户端应用程序代码必须执行下列步骤：
下列部分讨论连接到特定 WebLogic Server 的 JNDI 客户端操作。有关在 WebLogic Server 群集中使用 JNDI 的详细信息，请参阅在群集环境中使用客户端的 WebLogic JNDI。
必须将 WebLogic Server 环境的对象下载到 WebLogic Server JNDI 树中，才能使用 JNDI 访问该对象。
| 注意： | 下列操作不受支持，而且在启动时会导致出现故障：绑定使用 WebLogic Server 6.1 类生成的对象，以及将其部署到 WebLogic Server 7.0 或更高版本。 |
任何 Java 客户端应用程序必须执行的第一项任务是创建环境属性。InitialContext 工厂使用多种属性自定义特定环境的 InitialContext。可以使用散列表或 WebLogic 环境对象的 set() 方法来设置这些属性。这些指定为名值对形式的属性确定 WLInitialContextFactory 如何创建上下文。
Context.PROVIDER_URL- 指定提供命名服务的 WebLogic Server 的 URL。默认为t3://localhost:7001。Context.SECURITY_PRINCIPAL- 指定用于身份验证的用户（即在 WebLogic Server 安全领域中所定义的用户）标识。该属性默认为guest用户，除非线程已与 WebLogic Server 用户关联。有关详细信息，请参阅将 WebLogic 用户与安全上下文关联。Context.SECURITY_CREDENTIALS- 指定Context.SECURITY_PRINCIPAL属性中定义的用户密码，或指定使用已定义的Context.SECURITY_CREDENTIALS属性来实现weblogic.security.acl.UserInfo接口的对象。如果在此属性中传递 UserInfo 对象，则忽略Context.PROVIDER_URL属性。该属性默认为guest用户，除非线程已与某个用户关联。有关详细信息，请参阅将 WebLogic 用户与安全上下文关联。
可以在客户端或服务器使用相同属性。如果在服务器端对象定义属性，则使用本地上下文。如果在客户端或另一台 WebLogic Server 上定义属性，则上下文委托在 Context.PROVIDER_URL 属性所指定的 WebLogic Server 上运行的远程上下文。绑定到服务器的远程对象不能接受 peerGone 提供的服务，且在客户端失败时不可访问。
创建上下文后，有些属性就不可再更改。这些属性包括提供程序 url、用户凭据和工厂。创建上下文后，AddToEnvironment 可用于更改其他属性。
清单 3-1 说明如何使用 Context.INITIAL_CONTEXT_FACTORY 属性和 Context.PROVIDER_URL 属性获取上下文。
Context ctx = null;
Hashtable ht = new Hashtable();
ht.put(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFactory");
ht.put(Context.PROVIDER_URL,
"t3://localhost:7001");
try {
ctx = new InitialContext(ht);
// 使用程序中的上下文
}
catch (NamingException e) {
// 发生故障
}
finally {
try {ctx.close();}
catch (Exception e) {
// 发生故障
}
}
其他 WebLogic 特定的属性也可以用于控制如何将对象绑定到群集范围的 JNDI 树。是否跨群集中每个服务器的 JNDI 树复制绑定，取决于设置这些属性的方法。诸如这些属性由 weblogic.jndi.WLContext 类的常量来标识。有关 JNDI 相关的群集问题的详细信息，请参阅在群集环境中使用客户端的 WebLogic JNDI。
可以使用指定设置 InitialContext 的 JNDI 环境属性中所述属性的散列表创建上下文。
为此，将散列表传递到 InitialContext 的构造方法。属性 java.naming.factory.initial 用于指定如何创建 InitialContext。要使用 WebLogic JNDI，您必须一直将 java.naming.factory.initial 属性设置为 weblogic.jndi.WLInitialContextFactory。此设置可确定真正创建上下文的工厂。
也可以使用 weblogic.jndi.environment 实现的 WebLogic 环境对象创建上下文。虽然环境对象是 WebLogic 特定的，但它具有下列优势：
如果希望用这些默认设置创建 InitialContext，请编写下列代码：
Environment env = new Environment();
Context ctx = env.getInitialContext();
如果希望只将 WebLogic Server 设置为用于访问客户端群集的分布式命名服务（Distributed Name Service，简称 DNS），请编写下列代码：
Environment env = new Environment();
env.setProviderURL("t3://myweblogiccluster.com:7001");
Context ctx = env.getInitialContext();
| 注意： | 每次新建 JNDI 环境对象的同时，也在创建新的安全范围。使用 context.close() 方法结束该安全范围。 |
| 注意： | 如果使用 IIOP 协议，则 environment.getInitialContext() 方法不能正常工作。 |
清单 3-2 演示了使用 JNDI 环境对象创建安全上下文。
weblogic.jndi.Environment environment = new weblogic.jndi.Environment();
environment.setInitialContextFactory(
weblogic.jndi.Environment.DEFAULT_INITIAL_CONTEXT_FACTORY);
environment.setProviderURL("t3://bross:4441");
environment.setSecurityPrincipal("guest");
environment.setSecurityCrendentials("guest");
InitialContext ctx = environment.getInitialContext();
也可能需要从在 WebLogic Server 的 Java 虚拟机（Java Virtual Machine，简称 JVM）上实例化的对象（Enterprise JavaBean (EJB) 或远程方法调用（Remote Method Invocation，简称 RMI）对象）创建上下文。使用服务器端对象时，不需要指定 Context.PROVIDER_URL 属性。只有要以特定用户登录时，才需要用户名和密码。
要从服务器端对象创建上下文，首先必须新建一个 InitialContext，如下所示：
Context ctx = new InitialContext();
不需要指定工厂或提供程序 URL。默认情况下，上下文创建为 Context 并连接到本地命名服务。
请参阅 JNDI 上下文和线程。
创建具有用户名和密码的 JNDI 上下文时，即将用户和线程关联起来。创建上下文后，用户被上推到与线程关联的上下文堆栈。在启动线程上新的上下文之前，必须关闭第一个上下文，以使第一个用户不再与线程关联。否则，每次新上下文创建后，用户都会被下推到堆栈。这不仅不能高效使用资源，还可能导致 ctx.lookup() 调用返回错误的用户。下列步骤演示了上述情况：
为user1创建一个名为ctx1的上下文（具有用户名和凭据）。在创建上下文的过程中，user1与线程关联，并被上推到与线程关联的堆栈。现在当前用户是user1。为user2创建另一个名为ctx2的上下文（具有用户名和凭据）。此时，线程使某个用户的堆栈与之关联。User2位于堆栈顶部，而user1位于其后，因此user2作为当前用户使用。如果调用ctx1.lookup("abc")，则作为标识使用的是user2，而不是user1，因为user2位于堆栈顶部。要获得预期结果，即调用ctx1.lookup("abc")作为user1，则需要调用ctx2.close()。ctx2.close()调用会从与线程关联的堆栈中删除user2，这样，现在ctx1.lookup("abc")调用可以按预期使用user1。注意： 当启用 weblogic.jndi.enableDefaultUser 标志时，会有两种情况因为 close()调用并未从堆栈中删除当前用户而导致出现 JNDI 上下文问题。有关如何避免出现 JNDI 上下文问题的详细信息，请参阅如何避免潜在的 JNDI 上下文问题。
通常是调用 close()，如 JNDI 上下文和线程中所述。不过，在启用 weblogic.jndi.enableDefaultUser 标志后，也会发生非预期行为，如下面的异常：
使用 IIOP 时，当有一个上下文位于堆栈中，而由 close() 来删除该上下文，会发生非预期行为的异常。从堆栈中删除的上一个上下文标识确定当前用户的标识。下列步骤介绍了上述情况：
对上下文使用的 lookup() 方法用于获取已命名对象。被传递到 lookup() 方法的参数是一个包含所需对象名称的字符串。清单 3-3 说明检索名为 ServiceBean 的 EJB 的方法。
try {
ServiceBean bean = (ServiceBean)ctx.lookup("ejb.serviceBean");
}catch (NameNotFoundException e) {
// 绑定不存在
}catch (NamingException e) {
// 发生故障
}
EJB 客户端应用程序从 EJB Home 中获取对 EJB 远程对象的对象引用。RMI 客户端应用程序从初始命名对象中获取对其他 RMI 对象的对象引用。WebLogic Server 将这两个初始命名对象识别为工厂。工厂是任何可以将引用返回到 WebLogic 名称空间中另一个对象的对象。
客户端应用程序对工厂调用方法，以获取对特定类的远程对象的引用。然后客户端应用程序对远程对象调用方法，传递所有需要的参数。
清单 3-4 包含获取远程对象、而后对该对象调用方法的代码片段。
ServiceBean bean = ServiceBean.Home.create("ejb.ServiceBean")
Servicebean.additem(66);
BEA 系统建议客户端使用上下文完成工作后，应当关闭上下文，以释放资源和避免内存泄漏。BEA 建议使用 finally{} 块并包装 try{} 块中的 close() 方法。如果尝试关闭一个因错误而从未实例化的上下文，则 Java 客户端应用程序会引发异常。
在清单 3-5 中，客户端将关闭上下文，并释放正在使用的资源。
try {
ctx.close();
} catch () {
//发生故障
}
WebLogic JNDI 的目的在于向 J2EE 服务提供命名服务，特别是 EJB、RMI 和 Java 消息服务（Java Messaging Service，简称 JMS）。因此，了解将对象绑定到群集环境中 JNDI 树的含义是很重要的。
下列部分讨论在群集环境中如何实现 WebLogic JNDI，并提供了一些可以使自己的对象在 JNDI 客户端可用的方法。
WebLogic RMI 是允许 JVM 客户端从另一个 JVM 客户端访问 EJB 和 JMS 服务的可行性技术。RMI 存根控件将客户端传入的调用编组到 RMI 对象。为将 J2EE 服务提供给客户端，WebLogic 将特定服务的 RMI 存根控件绑定到其 JNDI 树的特定名称下。在将实例部署到群集中的其他服务器时，会更新 RMI 存根控件及 RMI 对象的其他实例位置。如果群集中的某个服务器出现故障，则其他服务器的 JNDI 树中的 RMI 存根控件将更新，以反映此服务器故障。
客户端连接群集时，实际上是连接到群集中的一个 WebLogic Server。由于此 WebLogic Server 的 JNDI 树包含群集中其他 WebLogic Server 提供的所有服务（除了其自身服务）的 RMI 存根控件，因此群集对客户端显示为承载所有群集范围服务的 WebLogic Server。当有新的 WebLogic Server 加入群集时，群集中已有的每个 WebLogic Server 负责将有关自己服务的信息与新的 WebLogic Server 共享。通过从群集中的其他服务器收集到的信息，新服务器会创建自己的群集范围 JNDI 树的副本。
RMI 存根控件对在群集环境下实现 WebLogic JNDI 有着显著的影响：
将自定义对象（非 RMI 对象）绑定到 WebLogic Server 群集中的 JNDI 树时，群集中的所有服务器都将复制该对象。但是，如果主机服务器发生故障，则从群集的 JNDI 树上删除自定义对象。除非再次绑定自定义对象，否则不复制该自定义对象。每次传播对自定义对象所做的更改时，需要先对自定义对象取消绑定，然后再重新绑定。因此，WebLogic JNDI 不能用作分布式对象缓存。可以结合使用第三方解决方案和 WebLogic Server 来提供分布式缓存。
假设自定义对象需要只允许仅在一个 WebLogic Server 中部署的 EJB 对其进行访问。很明显，不需要跨群集中的所有 WebLogic Server 复制此自定义对象。事实上，应当避免复制自定义对象，以免因进行不必要的服务器对服务器通信导致性能下降。要创建不跨群集中的 WebLogic Server 复制的绑定，在创建将自定义对象绑定到名称空间的上下文时必须指定 REPLICATE_BINDINGS 属性。清单 3-6 说明 REPLICATE_BINDINGS 属性的用法。
Hashtable ht = new Hashtable();
//关闭绑定的复制
ht.put(WLContext.REPLICATE_BINDINGS, "false");
try {
Context ctx = new InitialContext(ht);
//绑定对象
ctx.bind("my_object", MyObect);
} catch (NamingException ne) {
//发生故障
}
使用此技巧以及需要使用自定义对象时，必须明确获取 WebLogic Server 的 InitialContext。如果连接到群集中的任意其他 WebLogic Server 时，JNDI 树将不显示绑定。
如果需要从群集中的任何一台 WebLogic Server 都能访问某个自定义对象，请将自定义对象部署到群集的每个 WebLogic Server 而不是复制 JNDI 绑定。
使用 WebLogic JNDI 复制绑定时，被绑定对象将被作为主机 WebLogic Server 拥有的对象来处理。如果主机 WebLogic Server 失败，则会从群集中所有 WebLogic Server 的 JNDI 树上删除自定义对象。此行为不利于使用自定义对象。
Web 应用程序的常用任务是缓存多个对象在一段时间内使用的数据，以避免产生与数据计算或与连接另一个服务有关的开销。
假设已设计了在单个 WebLogic Server 上执行良好的自定义数据缓存对象，并要在 WebLogic 群集中使用此对象。如果将数据缓存对象绑定到其中一个 WebLogic Server 的 JNDI 树上，默认情况下，WebLogic JNDI 会将此对象复制到群集中的任何其他一台 WebLogic Server 上。很重要的一点是，因为这不是 RMI 对象，但绑定到 JNDI 树（以及复制到其他 WebLogic Server）的是对象本身，而不是其中一台 WebLogic Server 所承载的单个对象实例的存根控件。不能根据 WebLogic Server 会在服务器之间复制自定义对象，从而假定自定义对象可用作分布式缓存。请记住，如果自定义对象所绑定到的 WebLogic Server 失败，则将从群集中删除该对象，并且，除非先取消绑定该对象，然后将其重新绑定到 JNDI 树，否则不会在群集中传播对该自定义对象所做的更改。
从性能和可用性方面来考虑，通常需要避免使用 WebLogic JNDI 的绑定复制将可用性要求较高的大型自定义对象复制到群集中的所有 WebLogic Server。因此，可以将自定义对象的单个实例部署到群集中的每台 WebLogic Server。将对象绑定到每台 WebLogic Server 中的 JNDI 树时，必须确保关闭绑定复制，如使自定义对象对 WebLogic Server 群集可用中所述。在此设计模式中，每台 WebLogic Server 都有自定义对象的副本，但要避免将大量的数据从一台服务器复制到另一台服务器。
不管使用何种方法，每个对象实例必须维护自己的逻辑，这样，不需要依赖群集中的其他数据缓存对象，便可更新其缓存。例如，假设客户端访问 WebLogic Server 中的数据缓存。这是缓存对象第一次被访问，所以它会计算或获取信息，并且保存信息副本以备将来的请求使用。现在假定另一个客户端连接群集以执行与第一个客户端相同的任务，不同之处只是连接到群集中的另一台 WebLogic Server。如果此特定的数据缓存对象是第一次被访问，则它需要计算信息，而不管群集中的其他数据缓存对象是否已经缓存该信息。当然，考虑到将来的请求，该数据缓存对象的实例应该能够查阅已保存的信息。
有些情况下，要求具有在群集中只出现一次的服务。通过只在一台计算机上部署服务，可以达到此目的。对于 RMI 对象，可以使用 WebLogic JNDI 的默认行为来复制绑定（RMI 存根控件）以及可从群集中的所有 WebLogic Server 进行访问的单个对象实例。这称作固定服务。对于非 RMI 对象，确保将对象绑定到名称空间时使用的是 REPLICATE_BINDINGS 属性。这种情况下，需要显式连接到主机 WebLogic Server 才能访问对象。也可以创建部署在相同主机 WebLogic Server （充当非 RMI 对象的代理）上的 RMI 对象。可以复制（使用默认的 WebLogic JNDI 行为）代理的存根控件，这允许连接到群集中的任何 WebLogic Server 的客户端都可以通过 RMI 代理来访问非 RMI 对象。
对于要求高可用性的服务，可以将 RMI 对象的自动迁移配置到另一个服务器上。有关自动迁移的详细信息，请参阅“使用 WebLogic Server 群集”中的服务器迁移。
对象的 JNDI 绑定可以出现在群集中其中一台 WebLogic Server 的 JNDI 树上，也可以被复制到群集中的所有 WebLogic Server 中。如果关注的对象只绑定在一台 WebLogic Server 上，则创建初始上下文时，必须通过将 Context.PROVIDER_URL 属性设置为主机 WebLogic Server 的 URL 来显式连接主机 WebLogic Server，如使用 WebLogic JNDI 将 Java 客户端连接到单个服务器中所述。
然而，大多数情况下，关注的对象是群集服务或固定服务。因此，服务的存根控件显示在群集中每个 WebLogic Server 的 JNDI 树中。这种情况下，客户端不需要命名特定的 WebLogic Server 才能提供其命名服务。实际上，客户端最好只请求 WebLogic 群集提供命名服务，这样，WebLogic Server 中的上下文工厂可以从群集中选择最适合客户端的 WebLogic Server。
现在，可以使用由“群集地址”特性定义的群集的 DNS 名从 WebLogic 中选择命名服务提供程序。此特性定义客户端用于连接到群集的地址。此地址可以是映射到多个 IP 地址的 DNS 主机名，也可以是以逗号分隔的单个地址主机名或 IP 地址的列表。如果配置了网络通道，则可以为每个通道设置群集地址。请参阅使用 WebLogic Server 群集。
通常，将返回到群集服务客户端的上下文作为故障转移存根控件来实现。当选定 WebLogic Server 发生故障（如通信失败）时，该存根控件可以以透明方式更改命名服务提供程序。
清单 3-7 说明客户端如何使用群集命名服务。
Hashtable ht = new Hashtable();
ht.put(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFactory");
ht.put(Context.PROVIDER_URL, "t3://acmeCluster:7001");
try {
Context ctx = new InitialContext(ht);
// 做客户端的工作
}
catch (NamingException ne) {
// 发生故障
}
finally {
try {ctx.close();}
catch (Exception e) {
// 发生故障
}
}
指定作为提供程序 URL 一部分的 hostname 是指 ClusterAddress setting in a Cluster stanza of the config.xml file 定义的群集的 DNS 名。ClusterAddress 映射到此群集中提供的命名服务的主机列表。有关详细信息,请参阅“使用 WebLogic Server 群集”中的了解群集配置和应用程序部署。
在清单 3-7 中，群集名 acmeCluster 用于连接群集中的任意一台 WebLogic Server。复制结果上下文，以透明地故障转移到群集中的任意一台 WebLogic Server。
指定与 WebLogic 群集的初始联系点另一个方法是提供以逗号分隔的 DNS 服务器名列表或 IP 地址列表。
使用映射到多个服务器的 DNS 名时，WebLogic Server 取决于负载平衡的 DNS。
使用以逗号分隔的 WebLogic Server 节点的 DNS 名列表时，通过循环法方法完成故障转移，并将请求转到随机选择的服务器，如果该服务器响应失败，则该请求会转到列表上的下一个服务器。如果每台失败的服务器，此操作都会。
一旦客户端获取上下文，除非出现故障，否则不会发生其他负载平衡。这种情况下，WebLogic Server 将故障转移到群集的另一个节点。
远程客户端将从第一台可用服务器中获取上下文。群集中某台服务器的本地客户端永远不会转到远程服务器进行 JNDI 操作。
查找存根控件时，存根控件的第一个调用通常将转到获得上下文的服务器。如果存根控件是可群集的，则后续的调用会根据用户定义的负载平衡策略进行负载平衡。
有关 JNDI 和群集的详细信息，请参阅了解 WebLogic Server 群集。
虽然 J2EE 组件可能可以直接使用全局环境，但最好是使用组件环境。J2EE 应用程序中的每个 J2EE 组件都有自己的组件环境，该环境是根据组件的部署描述符中包含的信息进行设置的。
Context ctx = new InitailContext();
Context comp_env = (Context)ctx.lookup("java:comp/env");
由于是在 J2EE 组件中工作，所以不需要设置散列表或环境对象来定义连接信息。
使用此上下文的方法与使用全局环境的方法相同，但是，所使用的名称是在组件的部署描述符中定义的名称。例如，部署描述符中有如下的 ejb-ref：
<ejb-ref-name>ejb1</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
则可以查找使用 <ejb-ref-name> 设置所定义的名称，本例中为“ejb1”。
使用组件环境比使用全局环境来设置 JNDI 名称更具优势，因为在部署过程将解析所涉及的名称。这意味着，不必重新编写代码，就可以解决命名冲突。
有关设置和使用组件环境的详细信息，请参阅位于 http://java.sun.com/j2ee/j2ee-1_3-fr-spec.pdf 的“J2EE Specification”。
外部 JNDI 是一个无需直接连接到远程树即可访问远程 JNDI 树上的对象的 API。
通过它，可以链接至另一台服务器上或提供程序（包括但不限于 WebLogic Server）上的 JNDI 树或者 java 程序中的 JNDI 树。一旦配置外部 JNDI 后，就可以使用位于其他位置的对象，这与使用绑定在 WebLogic server 实例的对象同样方便。
要配置外部 JNDI，请使用希望使用其对象的远程 JNDI 提供程序的地址创建 ForeignJNDIProvider，并创建用户名和密码访问这些对象。然后创建 ForeignJNDILinks 和 ForeignJNDIObjects，以设置本地 JNDI 树的名称和远程树的对象之间的关系。
有关如何配置外部 JNDI 的详细信息，请参阅“管理控制台联机帮助”中的创建外部 JNDI 提供程序。
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
