把您从麻烦中解脱的JNDI在J2EE中的角色

核心提示：把握 J2EE 是件令人生畏的事，因为它包含的技术和缩略语在不断地增长，把您从麻烦中解脱的JNDI在J2EE中的角色，java 命名和目录接口（Java Naming and Directory Interface，JNDI）从一开始就一直是 Java 2 平台企业版（JEE）的核心，参见清单 1，我们可以看出，但是

　　把握 J2EE 是件令人生畏的事，因为它包含的技术和缩略语在不断地增长。java 命名和目录接口（Java Naming and Directory Interface，JNDI）从一开始就一直是 Java 2 平台企业版（JEE）的核心，但是 J2EE 开发新手经常用不好它。本文将消除 JNDI 在 J2EE 应用程序中所扮演角色的神秘性，并展示它如何帮助应用程序从部署细节中解脱出来。
　　
　　虽然 J2EE 平台提高了普通企业开发人员的生活水平，但是这种提高是以不得不学习许多规范和技术为代价的，这些规范和技术则是 J2EE 为了成为无所不包的分布式计算平台而整合进来的。Dolly Developer 是众多开发人员中的一员，她已经发现了一个特性，该特性有助于缓解随企业级应用程序部署而带来的负担，这个特性就是 JNDI，即 Java 命名与目录接口（Java Naming and Directory Interface）。让我们来看看 Dolly 在没有 JNDI 的时候是怎么做的，以及她是如何正确地应用 JNDI 来改善其状况的。
　　
　　所有人都非常熟悉的旅程
　　Dolly Developer 正在编写使用 JDBC 数据源的 Web 应用程序。她知道自己正在使用 MySQL，所以她将一个对 MySQL JDBC 驱动程序类的引用进行了编码，并通过使用适当的 JDBC URL 连接到其 Web 应用程序中的数据库。她熟悉到数据库连接池的重要性，所以她包含了一个连接池包，并把它配置成最多使用 64 个连接；她知道数据库服务器已经被设置成最多答应 128 台客户机进行连接。
　　
　　Dolly 在走向灾难
　　在开发阶段，每件事都进行得很顺利。但是，在部署的时候，开始失控。Dolly 的网络治理员告诉她，她不能从她的桌面机访问生产服务器或登台服务器（staging server），所以她不得不为每个部署阶段开发不同的代码版本。因为这种情况，她需要一个新的 JDBC URL，所以还要为测试、阶段和生产进行独立的部署。（一听到要在每个环境中建立单独部署，熟悉配置治理的人会战战兢兢的，但是既然这是种非常普遍的情况，所以他们也只好硬着头皮上了。）
　　
　　就在 Dolly 认为通过不同的 URL 建立彼此独立的部署已经解决了自己的配置问题时，她发现她的数据库治理员不想在生产环境中运行 MySQL 实例。他说，MySQL 用作开发还可以，但是对于任务要害型数据而言，业务标准是 DB2?。现在她的构建不仅在数据库 URL 方面有所不同，而且还需要不同的驱动程序。
　　
　　事情越变越糟。她的应用程序非常有用，并且变得非常要害，以致于它从应用服务器那里得到了故障恢复的能力，并被复制到 4 个服务器集群。但是数据库治理员提出了抗议，因为她的应用程序的每个实例都要使用 64 个连接，而数据库服务器总共只有 200 个可用连接 —— 全部都被 Dolly 的应用程序占用了。更麻烦的是，DBA 已经确定 Dolly 的应用程序只需要 32 个连接，而且天天只有一个小时在使用。
　　
　　随着她的应用程序规模扩大，应用程序碰到了数据库级的争用问题，而她的惟一选择就是改变集群的连接数量，而且还要做好预备，在集群数量增长或者应用程序复制到另一个集群时再重复一次这样的操作。看来她已经决定了如何配置应用程序，应用程序的配置最好是留给系统治理员和数据库治理员来做。
　　
　　J2EE 的角色
　　假如 Dolly 在开发应用程序时了解 J2EE 所扮演的角色，那么她就可能避免遭遇这种困境。J2EE 规范把职责委托给多个开发角色：组件提供者（Component PRovider）、应用程序组装者（application Assembler）、部署人员（Deployer）和系统治理员（System Administrator）。（在许多公司中，组件提供者和组件组装者的角色是融合在一起的，部署人员和系统治理员的角色是融合在一起的。）在真正了解 J2EE 中的 JNDI 角色之前，把握 J2EE 角色的作用非常重要。
　　
　　组件提供者
　　这个角色负责创建 J2EE 组件，J2EE 组件可以是 Web 应用程序、企业级 JavaBean（EJB）组件，或者是应用程序客户机（例如基于 Swing 的 GUI 客户机应用程序）。组件提供者包括：Html 设计师、文档编程人员以及其他开发人员角色。大多数 J2EE 开发人员在组件提供者这一角色上耗费了相当多的时间。
　　
　　应用程序组装者
　　这个角色将多个 J2EE 模块捆绑成一个彼此结合的、可以部署的整体：企业归档（EAR）文件。应用程序组装者要选择组件，分清它们之间的交互方式，配置它们的安全性和事务属性，并把应用程序打包到 EAR 文件中。许多 IDE，例如 WebSphere? Studio、IDEA、JBuilder、WebLogic Workshop 和其他 IDE，都可以帮助应用程序组装者以交互方式配置 EAR 文件。
　　
　　部署人员（Deployer）
　　这个角色负责部署，这意味着将 EAR 安装到 J2EE 容器（应用服务器）中，然后配置资源（例如数据库连接池），把应用程序需要的资源绑定到应用服务器中的特定资源上，并启动应用程序。
　　
　　系统治理员（System Administrator）
　　
　　这个角色负责保证容器需要的资源可用于容器。
　　
　　角色实战
　　假设有一个企业应用程序，该应用程序包含一个 Web 应用程序，还有一个负责业务逻辑和持久性的 EJB 组件。开发这个应用程序的组件供给商可能有许多，但是在许多情况下，可以由一个人来承担全部职责。组件可以包含数据传输对象（一个 JAR 文件）、EJB 接口（另一个 JAR 文件）、EJB 实现本身（另一个 JAR 文件），以及用户界面组件 —— servlet、jsp、HTML 页面和其他静态 Web 内容。用户界面组件被进一步打包成 Web 应用程序，其中包含 servlet 类、JSP 文件、静态内容，以及其他必需组件的 JAR（包括 EJB 接口）。
　　
　　这听起来似乎用到的组件太多了，几乎超出了人的想像范围，尤其是在考虑构建一个典型的 Web 应用程序需要使用多少个 JAR 文件的时候。但是，重要的是熟悉到在这里必须小心地治理依靠性。接口和传输对象是 Web 应用程序和 EJB 实现可以依靠的对象，但是依靠性的方向应该是相同的；还要避免产生循环依靠。J2EE 组件（例如 WAR 文件和 EJB JAR 文件）必须在它们的部署单元之外声明它们在资源上的依靠性。
　　
　　应用程序组装者负责把 Web 应用程序中的依靠内容包含进来，并把它们整体打包成单个企业应用程序。工具在这里帮助很大。IDE 可以协助创建反映模块和 JAR 依靠性的项目结构，还答应您随意指定包含或排除的模块。
　　
　　部署人员负责确保部署环境中存在组件所需的资源，并将组件绑定到平台的可用资源上。例如，Web 应用程序中的外部 EJB 引用（部署描述符中的 ejb-ref）就是在此时被绑定到实际部署的 EJB 组件 —— 而且是立即绑定。
　　
　　外部资源的后绑定
　　任何不平凡（nontrivial）的 J2EE 应用程序都需要访问描述它期望使用环境的信息。这意味着开发和测试组件时，为了临时测试代码，开发人员要承担一些部署方面的职责。重要的是要理解：这么做的时候，您就走出了开发人员的领域。否则，可以试着依靠 JDBC 驱动程序，或 URL、JMS 队列名称，或者其他具有无意识的、偶然可能是灾难性暗示的机器资源。
　　
　　JNDI 前来援助
　　Dolly 的问题的解决方案是从她的应用程序中清除所有对数据存储的直接引用。没有对 JDBC 驱动程序的引用，没有服务器名称，没有用户名称或口令 —— 甚至没有数据库池或连接治理。Dolly 需要编写代码来忽略将要访问的特定外部资源，只需要知道其他人会提供使用这些外部资源所需的链接即可。这答应部署人员（任何处在这个角色的人）把数据库连接分配给 Dolly 的应用程序。Dolly 没有必要参与其中。（从数据库安全性到遵守 Sarbanes-Oxley 法案，她都没有参与进来，她这样做也有充足的业务理由。）
　　
　　许多开发人员知道：代码和外部资源之间的紧密耦合是潜在的问题，但是在实践中却经常忘记角色的划分。在小型开发工作中（指的是团队规模或部署规模），即使忽视角色划分也能获得成功。（究竟，假如应用程序只是个人的应用程序，而且您不预备依靠它，那么把应用程序锁定在特定的 PostgreSQL 实例上也挺好的。）
　　
　　J2EE 规范要求所有 J2EE 容器都要提供 JNDI 规范的实现。JNDI 在 J2EE 中的角色就是“交换机” —— J2EE 组件在运行时间接地查找其他组件、资源或服务的通用机制。在多数情况下，提供 JNDI 供给者的容器可以充当有限的数据存储，这样治理员就可以设置应用程序的执行属性，并让其他应用程序引用这些属性（Java 治理扩展（Java Management Extensions，JMX）也可以用作这个目的）。
　　
　　JNDI 在 J2EE 应用程序中的主要角色就是提供间接层，这样组件就可以发现所需要的资源，而不用了解这些间接性。
　　
　　Dolly 的情况更糟了
　　现在我们重新来看一下 Dolly 的情况。在其简单的 Web 应用程序中，她直接从应用程序代码中使用了一个 JDBC 连接。参见清单 1，我们可以看出，Dolly 显式地把 JDBC 驱动程序、数据库 URL 以及她的用户名和口令编码到了 servlet 中：
　　
　　清单 1. 典型（但是不好）的 JDBC 用法:
　　
　　Connection conn=null;
　　try {
　　　Class.forName("com.mysql.jdbc.Driver",
　　　　　　　　　　true, Thread.currentThread().getContextClassLoader());
　　　conn=DriverManager.getConnection("jdbc:mysql://dbserver?user=dolly&passWord=dagger");
　　　/* use the connection here */
　　　c.close();
　　}
　　catch(Exception e) {
　　　e.printStackTrace();
　　}
　　finally {
　　　if(conn!=null) {
　　　　try {
　　　　　conn.close();
　　　　} catch(SQLException e) {}
　　　}
　　}
　　假如不用这种方式指定配置信息，Dolly（以及她的同伴们）使用 JNDI 来查找 J