掌握 J2EE 是件令人生畏的事，因?yàn)樗募夹g(shù)和縮略語(yǔ)在不斷地增長(zhǎng)。Java 命名和目錄接口（Java Naming and Directory Interface，JNDI）從一開始就一直是 Java 2 平臺(tái)企業(yè)版（JEE）的核心，但是 J2EE 開發(fā)新手經(jīng)常用不好它。本文將消除 JNDI 在 J2EE 應(yīng)用程序中所扮演角色的神秘性，并展示它如何幫助應(yīng)用程序從部署細(xì)節(jié)中解脫出來(lái)。

雖然 J2EE 平臺(tái)提高了普通企業(yè)開發(fā)人員的生活水平，但是這種提高是以不得不學(xué)習(xí)許多規(guī)范和技術(shù)為代價(jià)的，這些規(guī)范和技術(shù)則是 J2EE 為了成為無(wú)所不包的分布式計(jì)算平臺(tái)而整合進(jìn)來(lái)的。Dolly Developer 是眾多開發(fā)人員中的一員，她已經(jīng)發(fā)現(xiàn)了一個(gè)特性，該特性有助于緩解隨企業(yè)級(jí)應(yīng)用程序部署而帶來(lái)的負(fù)擔(dān)，這個(gè)特性就是 JNDI，即 Java 命名與目錄接口（Java Naming and Directory Interface）。讓我們來(lái)看看 Dolly 在沒有 JNDI 的時(shí)候是怎么做的，以及她是如何正確地應(yīng)用 JNDI 來(lái)改善其狀況的。

所有人都非常熟悉的旅程

Dolly Developer 正在編寫使用 JDBC 數(shù)據(jù)源的 Web 應(yīng)用程序。她知道自己正在使用 MySQL，所以她將一個(gè)對(duì) MySQL JDBC 驅(qū)動(dòng)程序類的引用進(jìn)行了編碼，并通過使用適當(dāng)?shù)?JDBC URL 連接到其 Web 應(yīng)用程序中的數(shù)據(jù)庫(kù)。她認(rèn)識(shí)到數(shù)據(jù)庫(kù)連接池的重要性，所以她包含了一個(gè)連接池包，并把它配置成最多使用 64 個(gè)連接；她知道數(shù)據(jù)庫(kù)服務(wù)器已經(jīng)被設(shè)置成最多允許 128 臺(tái)客戶機(jī)進(jìn)行連接。

Dolly 在走向?yàn)?zāi)難

在開發(fā)階段，每件事都進(jìn)行得很順利。但是，在部署的時(shí)候，開始失控。Dolly 的網(wǎng)絡(luò)管理員告訴她，她不能從她的桌面機(jī)訪問生產(chǎn)服務(wù)器或登臺(tái)服務(wù)器（staging server），所以她不得不為每個(gè)部署階段開發(fā)不同的代碼版本。因?yàn)檫@種情況，她需要一個(gè)新的 JDBC URL，所以還要為測(cè)試、階段和生產(chǎn)進(jìn)行獨(dú)立的部署。（一聽到要在每個(gè)環(huán)境中建立單獨(dú)部署，熟悉配置管理的人會(huì)戰(zhàn)戰(zhàn)兢兢的，但是既然這是種非常普遍的情況，所以他們也只好硬著頭皮上了。）

就在 Dolly 認(rèn)為通過不同的 URL 建立彼此獨(dú)立的部署已經(jīng)解決了自己的配置問題時(shí)，她發(fā)現(xiàn)她的數(shù)據(jù)庫(kù)管理員不想在生產(chǎn)環(huán)境中運(yùn)行 MySQL 實(shí)例。他說(shuō)，MySQL 用作開發(fā)還可以，但是對(duì)于任務(wù)關(guān)鍵型數(shù)據(jù)而言，業(yè)務(wù)標(biāo)準(zhǔn)是 DB2®?，F(xiàn)在她的構(gòu)建不僅在數(shù)據(jù)庫(kù) URL 方面有所不同，而且還需要不同的驅(qū)動(dòng)程序。

事情越變?cè)皆恪Ｋ膽?yīng)用程序非常有用，并且變得非常關(guān)鍵，以致于它從應(yīng)用服務(wù)器那里得到了故障恢復(fù)的能力，并被復(fù)制到 4 個(gè)服務(wù)器集群。但是數(shù)據(jù)庫(kù)管理員提出了抗議，因?yàn)樗膽?yīng)用程序的每個(gè)實(shí)例都要使用 64 個(gè)連接，而數(shù)據(jù)庫(kù)服務(wù)器總共只有 200 個(gè)可用連接 —— 全部都被 Dolly 的應(yīng)用程序占用了。更麻煩的是，DBA 已經(jīng)確定 Dolly 的應(yīng)用程序只需要 32 個(gè)連接，而且每天只有一個(gè)小時(shí)在使用。隨著她的應(yīng)用程序規(guī)模擴(kuò)大，應(yīng)用程序遇到了數(shù)據(jù)庫(kù)級(jí)的爭(zhēng)用問題，而她的惟一選擇就是改變集群的連接數(shù)量，而且還要做好準(zhǔn)備，在集群數(shù)量增長(zhǎng)或者應(yīng)用程序復(fù)制到另一個(gè)集群時(shí)再重復(fù)一次這樣的操作?？磥?lái)她已經(jīng)決定了如何配置應(yīng)用程序，應(yīng)用程序的配置最好是留給系統(tǒng)管理員和數(shù)據(jù)庫(kù)管理員來(lái)做。

回頁(yè)首

J2EE 的角色

如果 Dolly 在開發(fā)應(yīng)用程序時(shí)了解 J2EE 所扮演的角色，那么她就可能避免遭遇這種困境。J2EE 規(guī)范把職責(zé)委托給多個(gè)開發(fā)角色：組件提供者（Component Provider）、應(yīng)用程序組裝者（Application Assembler）、部署人員（Deployer）和系統(tǒng)管理員（System Administrator）。（在許多公司中，組件提供者和組件組裝者的角色是融合在一起的，部署人員和系統(tǒng)管理員的角色是融合在一起的。）在真正了解 J2EE 中的 JNDI 角色之前，掌握 J2EE 角色的作用非常重要。

組件提供者

這個(gè)角色負(fù)責(zé)創(chuàng)建 J2EE 組件，J2EE 組件可以是 Web 應(yīng)用程序、企業(yè)級(jí) JavaBean（EJB）組件，或者是應(yīng)用程序客戶機(jī)（例如基于 Swing 的 GUI 客戶機(jī)應(yīng)用程序）。組件提供者包括：HTML 設(shè)計(jì)師、文檔編程人員以及其他開發(fā)人員角色。大多數(shù) J2EE 開發(fā)人員在組件提供者這一角色上耗費(fèi)了相當(dāng)多的時(shí)間。

應(yīng)用程序組裝者

這個(gè)角色將多個(gè) J2EE 模塊捆綁成一個(gè)彼此結(jié)合的、可以部署的整體：企業(yè)歸檔（EAR）文件。應(yīng)用程序組裝者要選擇組件，分清它們之間的交互方式，配置它們的安全性和事務(wù)屬性，并把應(yīng)用程序打包到 EAR 文件中。許多 IDE，例如 WebSphere® Studio、IDEA、JBuilder、WebLogic Workshop 和其他 IDE，都可以幫助應(yīng)用程序組裝者以交互方式配置 EAR 文件。

部署人員（Deployer）

這個(gè)角色負(fù)責(zé)部署，這意味著將 EAR 安裝到 J2EE 容器（應(yīng)用服務(wù)器）中，然后配置資源（例如數(shù)據(jù)庫(kù)連接池），把應(yīng)用程序需要的資源綁定到應(yīng)用服務(wù)器中的特定資源上，并啟動(dòng)應(yīng)用程序。

系統(tǒng)管理員（System Administrator）

這個(gè)角色負(fù)責(zé)保證容器需要的資源可用于容器。

角色實(shí)戰(zhàn)

假設(shè)有一個(gè)企業(yè)應(yīng)用程序，該應(yīng)用程序包含一個(gè) Web 應(yīng)用程序，還有一個(gè)負(fù)責(zé)業(yè)務(wù)邏輯和持久性的 EJB 組件。開發(fā)這個(gè)應(yīng)用程序的組件供應(yīng)商可能有許多，但是在許多情況下，可以由一個(gè)人來(lái)承擔(dān)全部職責(zé)。組件可以包含數(shù)據(jù)傳輸對(duì)象（一個(gè) JAR 文件）、EJB 接口（另一個(gè) JAR 文件）、EJB 實(shí)現(xiàn)本身（另一個(gè) JAR 文件），以及用戶界面組件 —— servlet、JSP、HTML 頁(yè)面和其他靜態(tài) Web 內(nèi)容。用戶界面組件被進(jìn)一步打包成 Web 應(yīng)用程序，其中包含 servlet 類、JSP 文件、靜態(tài)內(nèi)容，以及其他必需組件的 JAR（包括 EJB 接口）。

這聽起來(lái)好像用到的組件太多了，幾乎超出了人的想像范圍，尤其是在考慮構(gòu)建一個(gè)典型的 Web 應(yīng)用程序需要使用多少個(gè) JAR 文件的時(shí)候。但是，重要的是認(rèn)識(shí)到在這里必須小心地管理依賴性。接口和傳輸對(duì)象是 Web 應(yīng)用程序和 EJB 實(shí)現(xiàn)可以依賴的對(duì)象，但是依賴性的方向應(yīng)該是相同的；還要避免產(chǎn)生循環(huán)依賴。J2EE 組件（例如 WAR 文件和 EJB JAR 文件）必須在它們的部署單元之外聲明它們?cè)谫Y源上的依賴性。

應(yīng)用程序組裝者負(fù)責(zé)把 Web 應(yīng)用程序中的依賴內(nèi)容包含進(jìn)來(lái)，并把它們整體打包成單個(gè)企業(yè)應(yīng)用程序。工具在這里幫助很大。IDE 可以協(xié)助創(chuàng)建反映模塊和 JAR 依賴性的項(xiàng)目結(jié)構(gòu)，還允許您隨意指定包含或排除的模塊。

部署人員負(fù)責(zé)確保部署環(huán)境中存在組件所需的資源，并將組件綁定到平臺(tái)的可用資源上。例如，Web 應(yīng)用程序中的外部 EJB 引用（部署描述符中的 ejb-ref）就是在此時(shí)被綁定到實(shí)際部署的 EJB 組件 —— 而且是立即綁定。

外部資源的后綁定

任何不平凡（nontrivial）的 J2EE 應(yīng)用程序都需要訪問描述它期望使用環(huán)境的信息。這意味著開發(fā)和測(cè)試組件時(shí)，為了臨時(shí)測(cè)試代碼，開發(fā)人員要承擔(dān)一些部署方面的職責(zé)。重要的是要理解：這么做的時(shí)候，您就走出了開發(fā)人員的領(lǐng)域。否則，可以試著依靠 JDBC 驅(qū)動(dòng)程序，或 URL、JMS 隊(duì)列名稱，或者其他具有無(wú)意識(shí)的、偶爾可能是災(zāi)難性暗示的機(jī)器資源。

回頁(yè)首

JNDI 前來(lái)援助

Dolly 的問題的解決方案是從她的應(yīng)用程序中清除所有對(duì)數(shù)據(jù)存儲(chǔ)的直接引用。沒有對(duì) JDBC 驅(qū)動(dòng)程序的引用，沒有服務(wù)器名稱，沒有用戶名稱或口令 —— 甚至沒有數(shù)據(jù)庫(kù)池或連接管理。Dolly 需要編寫代碼來(lái)忽略將要訪問的特定外部資源，只需要知道其他人會(huì)提供使用這些外部資源所需的鏈接即可。這允許部署人員（任何處在這個(gè)角色的人）把數(shù)據(jù)庫(kù)連接分配給 Dolly 的應(yīng)用程序。Dolly 沒有必要參與其中。（從數(shù)據(jù)庫(kù)安全性到遵守 Sarbanes-Oxley 法案，她都沒有參與進(jìn)來(lái)，她這樣做也有充足的業(yè)務(wù)理由。）

許多開發(fā)人員知道：代碼和外部資源之間的緊密耦合是潛在的問題，但是在實(shí)踐中卻經(jīng)常忘記角色的劃分。在小型開發(fā)工作中（指的是團(tuán)隊(duì)規(guī)?；虿渴鹨?guī)模），即使忽視角色劃分也能獲得成功。（畢竟，如果應(yīng)用程序只是個(gè)人的應(yīng)用程序，而且您不準(zhǔn)備依靠它，那么把應(yīng)用程序鎖定在特定的 PostgreSQL 實(shí)例上也挺好的。）

J2EE 規(guī)范要求所有 J2EE 容器都要提供 JNDI 規(guī)范的實(shí)現(xiàn)。JNDI 在 J2EE 中的角色就是“交換機(jī)” —— J2EE 組件在運(yùn)行時(shí)間接地查找其他組件、資源或服務(wù)的通用機(jī)制。在多數(shù)情況下，提供 JNDI 供應(yīng)者的容器可以充當(dāng)有限的數(shù)據(jù)存儲(chǔ)，這樣管理員就可以設(shè)置應(yīng)用程序的執(zhí)行屬性，并讓其他應(yīng)用程序引用這些屬性（Java 管理擴(kuò)展（Java Management Extensions，JMX）也可以用作這個(gè)目的）。JNDI 在 J2EE 應(yīng)用程序中的主要角色就是提供間接層，這樣組件就可以發(fā)現(xiàn)所需要的資源，而不用了解這些間接性。

Dolly 的情況更糟了

現(xiàn)在我們重新來(lái)看一下 Dolly 的情況。在其簡(jiǎn)單的 Web 應(yīng)用程序中，她直接從應(yīng)用程序代碼中使用了一個(gè) JDBC 連接。參見清單 1，我們可以看出，Dolly 顯式地把 JDBC 驅(qū)動(dòng)程序、數(shù)據(jù)庫(kù) URL 以及她的用戶名和口令編碼到了 servlet 中：

            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 來(lái)查找 JDBC DataSource 會(huì)更好一些，如清單 2 所示：

            Connection conn=null;
            try {
            Context ctx=new InitialContext();
            Object datasourceRef=ctx.lookup("java:comp/env/jdbc/mydatasource");
            DataSource ds=(Datasource)datasourceRef;
            Connection c=ds.getConnection();
            /* use the connection */
            c.close();
            }
            catch(Exception e) {
            e.printStackTrace();
            }
            finally {
            if(conn!=null) {
            try {
            conn.close();
            } catch(SQLException e) { }
            }
            }
            

為了能夠得到 JDBC 連接，首先要執(zhí)行一些小的部署配置，這樣我們才可以在本地組件的 JNDI 下文中查找 DataSource。這可能有點(diǎn)煩瑣，但是很容易學(xué)。不幸的是，這意味著即使是為了測(cè)試組件，開發(fā)人員也必須涉足部署人員的領(lǐng)地，并且還要準(zhǔn)備配置應(yīng)用服務(wù)器。

配置 JNDI 引用

為了讓 JNDI 解析 java:comp/env/jdbc/mydatasource 引用，部署人員必須把 <resource-ref> 標(biāo)簽插入 web.xml 文件（Web 應(yīng)用程序的部署描述符）。 <resource-ref> 標(biāo)簽的意思就是“這個(gè)組件依賴于外部資源”。清單 3 顯示了一個(gè)示例：

            <resource-ref>
            <description>Dollys DataSource</description>
            <res-ref-name>jdbc/mydatasource</res-ref-name>
            <res-ref-type>javax.sql.DataSource</res-ref-type>
            <res-auth>Container</res-auth>
            </resource-ref>
            

<resource-ref> 入口告訴 servlet 容器，部署人員要在 組件命名上下文（component naming context） 中設(shè)置一個(gè)叫做 jdbc/mydatasource 的資源。組件命名上下文由前綴 java:comp/env/ 表示，所以完全限定的本地資源名稱是： java:comp/env/jdbc/mydatasource.

這只定義了到外部資源的本地引用，還沒有創(chuàng)建引用指向的實(shí)際資源。（在 Java 語(yǔ)言中，類似的情況可能是： <resource-ref> 聲明了一個(gè)引用，比如 Object foo，但是沒有把 foo 設(shè)置成實(shí)際引用任何 Object。）

部署人員的工作就是創(chuàng)建 DataSource（或者是創(chuàng)建一個(gè) Object 對(duì)象，讓 foo 指向它，在我們的 Java 語(yǔ)言示例中就是這樣）。每個(gè)容器都有自己設(shè)置數(shù)據(jù)源的機(jī)制。例如，在 JBoss 中，是利用服務(wù)來(lái)定義數(shù)據(jù)源（請(qǐng)參閱 $JBOSS/server/default/deploy/hsqldb-ds.xml，把它作為示例），它指定自己是 DataSource 的全局 JNDI 名稱（默認(rèn)情況下是 DefaultDS）。在創(chuàng)建資源之后，第三步仍然很關(guān)鍵：把資源連接或者綁定到應(yīng)用程序組件使用的本地名稱。在使用 Web 應(yīng)用程序的情況下，是使用特定于供應(yīng)商的部署描述符擴(kuò)展來(lái)指定這個(gè)綁定，清單 4 中顯示了一個(gè)這樣的例子。（JBoss 用稱為 jboss-Web.xml 的文件作為特定于供應(yīng)商的 Web 應(yīng)用程序部署描述符。）

            <resource-ref>
            <res-ref-name>jdbc/mydatasource</res-ref-name>
            <jndi-name>java:DefaultDS</jndi-name>
            </resource-ref>
            

這表明應(yīng)該將本地資源引用名稱（ jdbc/mydatasource）映射到名為 java:DefaultDS 的全局資源。如果全局資源名稱出于某種原因發(fā)生了變化，而應(yīng)用程序的代碼無(wú)需變化，那么只需修改這個(gè)映射即可。在這里，有兩個(gè)級(jí)別的間接尋址：一個(gè)定義并命名資源（ java:DefaultDS），另一個(gè)把特定于本地組件的名稱（ jdbc/mydatasource）綁定到命名的資源。（實(shí)際上，當(dāng)您在 EAR 級(jí)別上映射資源時(shí)，可能還存在第三級(jí)別的間接尋址。）

回頁(yè)首

超越數(shù)據(jù)源

當(dāng)然，J2EE 中的資源并不局限于 JDBC 數(shù)據(jù)源。引用的類型有很多，其中包括資源引用（已經(jīng)討論過）、環(huán)境實(shí)體和 EJB 引用。特別是 EJB 引用，它暴露了 JNDI 在 J2EE 中的另外一項(xiàng)關(guān)鍵角色：查找其他應(yīng)用程序組件。

試想一下這種情況：當(dāng)一家公司從 Order Ontology Processing Services（OOPS）購(gòu)買了一個(gè)可部署的 EJB 組件來(lái)處理客戶訂單時(shí)，會(huì)發(fā)生什么。為了便于舉例說(shuō)明，我們把它叫做 ProcessOrders V1.0。ProcessOrders 1.0 有兩部分：一組接口和支持類（home 和 remote 接口，以及支持的傳輸類）；實(shí)際 EJB 組件自身。選擇 OOPS 是因?yàn)樗谶@個(gè)領(lǐng)域的專業(yè)性。

該公司遵照 J2EE 規(guī)范，編寫使用 EJB 引用的 Web 應(yīng)用程序。公司的部署人員把 ProcessOrders 1.0 綁定到 JNDI 樹中，將它用作 ejb/ProcessOrders/1.0，并解析 Web 應(yīng)用程序的資源名稱，以指向這個(gè)全局 JNDI 名稱。目前為止，這些都是 EJB 組件非常普通的用法。但是，當(dāng)我們考慮公司的開發(fā)周期與公司供應(yīng)商之間的交互時(shí)，事情就變得復(fù)雜起來(lái)。在這里，JNDI 也能幫助我們。

我們假設(shè) OOPS 發(fā)布了一個(gè)新版本，即 ProcessOrders V1.1。這個(gè)新版本有一些新功能，公司內(nèi)部的一個(gè)新應(yīng)用程序需要這些新功能，而且很自然地?cái)U(kuò)展了 EJB 組件的業(yè)務(wù)接口。

在這里，公司有以下幾個(gè)選擇：可以更新所有應(yīng)用程序來(lái)使用新版本，也可以編寫自己的版本，或者使用 JNDI 的引用解析，允許每個(gè)應(yīng)用程序在不影響其他應(yīng)用程序的情況下使用自己的 EJB 組件版本。立刻更新所有應(yīng)用程序?qū)S護(hù)來(lái)說(shuō)是一場(chǎng)噩夢(mèng)，它要求對(duì)所有組件都進(jìn)行完整的回歸測(cè)試，這通常是一項(xiàng)艱巨的任務(wù)，而且如果發(fā)生任何功能測(cè)試失敗的話，那么還要進(jìn)行另一輪調(diào)試。

編寫內(nèi)部（in-house）組件常常是沒有必要的重復(fù)工作。如果組件是由在這個(gè)業(yè)務(wù)領(lǐng)域內(nèi)具有專業(yè)知識(shí)的公司編寫的，那么給定的 IT 商店不可能像專業(yè)的組件供應(yīng)商那樣精通業(yè)務(wù)功能。

正如您可能已經(jīng)猜到的那樣，最好的解決方案是用 JNDI 解析。EJB 的 JNDI 引用非常類似于 JDBC 資源的引用。對(duì)于每個(gè)引用，部署人員都需要把新組件按特定的名稱（比如說(shuō) ejb/ProcessOrders/1.1）綁定到全局樹中，對(duì)于需要 EJB 組件的其他每個(gè)組件，還要為組件在部署描述符中解析 EJB 引用。依賴于 V1.0 以前的應(yīng)用程序不需要進(jìn)行任何修改，也不需要重新測(cè)試，這縮短了實(shí)現(xiàn)的時(shí)間、降低了成本并減少了復(fù)雜性。在服務(wù)趨于轉(zhuǎn)換的環(huán)境中，這是一種很有效的方法?？梢詫?duì)應(yīng)用程序架構(gòu)中所得到的所有組件進(jìn)行這類配置管理，從 EJB 組件到 JMS 隊(duì)列和主題，再到簡(jiǎn)單配置字符串或其他對(duì)象，這可以降低隨時(shí)間的推移服務(wù)變更所產(chǎn)生的維護(hù)成本，同時(shí)還可以簡(jiǎn)化部署，減少集成工作。

回頁(yè)首

結(jié)束語(yǔ)

有一個(gè)古老的計(jì)算機(jī)科學(xué)笑話：每個(gè)編程問題都可以僅僅用一個(gè)抽象層（或間接的）來(lái)解決。在 J2EE 中，JNDI 是把 J2EE 應(yīng)用程序合在一起的粘合劑，但還沒有緊到無(wú)法讓人很容易地把它們分開并重新裝配。JNDI 提供的間接尋址允許跨企業(yè)交付可伸縮的、功能強(qiáng)大且很靈活的應(yīng)用程序。這是 J2EE 的承諾，而且經(jīng)過一些計(jì)劃和預(yù)先考慮，這個(gè)承諾是完全可以實(shí)現(xiàn)的。實(shí)際上，它要比許多人想像的容易得多。