Java 开发：JNDI   

在 J2EE 中的角色

 

掌握 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 的角色