命名和目录接口 JNDI-The Java Naming and Directory Interface

JNDI (The Java Naming and Directory Interface)为应用程序提供命名和目录功能。

JNDI体系结构由API和SPI组成。Java应用程序使用JNDI API来访问各种命名和目录服务。SPI允许透明地插入各种命名和目录服务，这样是用来JNDI API的应用程序才能访问JNDI服务。

SPI: Service Provider Interface，服务提供者接口

通俗地讲，你可以通过JNDI给某个对象命名，然后通过这个命名你可以获取到这个对象。就好像DOTA这款经典对战游戏中一位我们熟悉的英雄叫做斯奎、斯布林和斯布恩，这是一个由三个小地精组成的炸弹小分队，玩家们对于这个名字气急败坏，实在记不住，于是命名为炸弹人，然后我们通过炸弹人也能顺利找到这个英雄，当然你只能在DOTA游戏中找到炸弹人，后面会讲到，DOTA游戏就是所谓的Context上下文。最后，希望这个例子不要误导了大家对JNDI的认识，它绝对不是一个为了起绰号、假名alias而存在的标准。

这种命名和目录服务有什么用处？
先说目录服务，有了目录，你就可以在运行时，间接地去查找其他组件、资源或服务，JNDI为这些功能指定了一个通用机制。命名就是组件目录的过程。JNDI主要运用在J2EE中，承担了“交换机”的角色，是J2EE规范中较为重要的规范之一。

JNDI

JNDI本身不是服务，它和JDBC一样，是一组接口，允许应用程序使用标准化API访问许多不同的目录服务提供者。
例如硬件上的Micro接口、TypeC接口或者是USB接口，这些硬件接口只是一种标准和协议，华为、小米各类手机厂商都实现了Micro或者TypeC接口，各类电脑主板厂商例如华硕、华擎、技嘉都在其主板上实现了USB接口。我们真正使用的并不是上述硬件接口协议，而是各个厂家提供的产品，软件领域中，我们称为接口的实现。
正如Spring cache在早期的版本中默认了一个ehcache的实现一样，JDK中也包含了一些自带的目录服务提供程序。

JDK中包含了JNDI，如果要使用JNDI，必须具有一个JNDI的类和对应的服务提供者。
JDK中已经包含的命名/目录服务的提供者有：

Lightweight Directory Access Protocol (LDAP,轻量级目录访问协议)
Common Object Request Broker Architecture (CORBA,公共对象请求代理体系结构) Common Object Services (COS,公共对象服务) name service
Java Remote Method Invocation (RMI,Java远程方法调用) Registry
Domain Name Service (DNS,域名服务)

JDK中JNDI相关的package

javax.naming
javax.naming.directory
javax.naming.ldap
javax.naming.event
javax.naming.spi

javax.naming

javax.naming包含了进入命名服务的类和接口。
可以参考 JDK的API。
其中比较核心的类是Context和InitialContext。

Context接口是查找，绑定/解除绑定，重命名对象以及创建和销毁子上下文的核心接口。

在JNDI中，所有命名和目录操作都是相对于上下文执行的。没有绝对的根源。因此，JNDI定义了一个InitialContext，它为命名和目录操作提供了一个起点。获得初始上下文后，可以使用它来查找其他上下文和对象。

Context

lookup

lookup()是最常用的操作。传入要查找的对象的名称，返回绑定到该名称的对象。

listBindings

listBinding()返回名称到对象(name-to-object)绑定的枚举。这个枚举包含了绑定对象的名称，对象类的名称和对象本身。

list

list()与listBinding()类似，只是不返回对象本身，是一个更轻量地方法。

Name

interface Name是一个表示0或多个有序序列组件的通用名称的接口。命名系统使用此接口来定义遵循其约定的名称。

References

对象以各种方式存储在命名和目录服务中。一般情况下我们不会存储对象本身，而是存入对象的引用。
JNDI定义Reference类来表示引用。引用包含有关如何构造对象副本的信息。 JNDI从目录中查找到引用，然后转换为它们所指向的Java对象，以便JNDI客户端从目录中获取到的内容是Java对象。

javax.naming.spi

其他的包可以参考JDK API文档中具体的描述，或者在Oracle的官网上获取信息，点击查看。

javax.naming.spi包为不同命名/目录服务供应商的开发人员提供了可以开发和连接其实现的方法，以便使用JNDI的应用程序可以访问相应的服务。

Plug-In Architecture
- javax.naming.spi包允许动态插入不同的实现。这些实现包括初始上下文和可以从初始上下文到达的上下文的实现。
支持Java对象
- javax.naming.spi包提供了lookup和相关方法的实现，以返回Java对象。例如，如果从目录中查找打印机名称，那么您可能希望找回要在其上运行的打印机对象。这种支持以对象工厂的形式提供。该软件包还支持反向操作。也就是说，Context.bind()和相关方法的实现可以接收Java对象并以底层命名/目录服务可接受的格式存储对象。这种支持以StateFactory的形式提供(下面引用了JDK API中的描述)。
StateFactory接口表示一个工厂，该工厂用来获得用于绑定的对象状态。
JNDI 框架允许通过对象工厂动态加载对象实现。例如，当查找绑定在名称空间中的打印机时，如果打印服务将打印机的名称绑定到 Reference，则可以使用该打印机 Reference 创建一个打印机对象，从而查找的调用者可以在查找后直接在该打印机对象上操作。
ObjectFactory 负责创建特定类型的对象。在上述示例中，可以有一个用来创建 Printer 对象的 PrinterObjectFactory。
对于相反过程，当将对象绑定到名称空间中时，JNDI 将提供状态工厂。继续打印机的示例，假设打印机对象被更新和重新绑定：
ctx.rebind("inky", printer);
用于 ctx 的服务提供者使用一个状态工厂来获得绑定到其名称空间的 printer 的状态。用于 Printer 类型对象的状态工厂可能返回一个用来存储在命名系统中的更紧凑的对象。
状态工厂必须实现 StateFactory 接口。此外，工厂类必须是公共的，必须有一个不接受任何参数的公共构造方法。
可以使用不同的参数多次调用状态工厂的 getStateToBind() 方法。该实现是线程安全的。
StateFactory 与只实现 Context 接口的服务提供者一起使用。DirStateFactory 与实现 DirContext 接口的服务提供者一起使用。
Multiple Naming Systems (Federation)
- JNDI操作允许应用程序提供跨多个命名系统的名称。在完成操作的过程中，一个服务提供者可能需要与另一个服务提供者交互，例如传递要在下一个命名系统中继续的操作。该软件包支持不同的提供商合作完成JNDI操作。

其他文章

之后会更新该文章的译文

J2EE or J2SE? JNDI works with both

本文参考文献：
Java API
https://docs.oracle.com/javase/tutorial/jndi/overview/index.html