用java:comp定位EJB

2019-11-18 12:38:10

字體：大中小

來源：轉載

供稿：網友

　　假如您把同一個 J2EE 應用程序部署到多個應用程序服務器上，而這些應用程序服務器共享一個 JNDI 名稱空間，那么，由于名稱空間中的 JNDI 名稱必須是唯一的，這樣做將會出現問題。部署到 WebSphere application Server 環境中的 J2EE 應用程序，應該使用 java:comp/env 環境命名上下文（environment naming context（ENC））來查找 EJB，而不是使用 JNDI 名稱來查找。有了這個命名上下文，就可以避免發生沖突，應用程序的可移植性也將好得多。
　　開發和部署按照 EJB 1.0 規范級別編寫的 EJB，困難之一是處理 EJB home 的 JNDI 名稱。例如，有很多代碼寫成像下面的代碼片段（取自會話 bean）那樣，試圖查找 com.ibm.wsc.Bean2 EJB 的 home：
　　
　　Context myInitCtx = new InitialContext();
　　Object result = myInitCtx.lookup("com/ibm/wsc/Bean2Home");
　　com.ibm.wsc.Bean2Home theBean2Home =(com.ibm.wsc.Bean2Home)
　　javax.rmi.PortableRemote.narrow(result,com.ibm.wsc.Bean2Home.class);
　　這一技術在Java開發環境（Java development tooling，JDT）中能工作得很好，在應用程序的部署階段似乎也不出什么問題。只要看一下上面的代碼，就可以確定在名稱空間中賦給Bean2Home的JNDI名稱，因為這個名稱就是EJB Home接口名稱。編碼約定就跟 EJB 類名被用來構造定位 home 的代碼那樣相當簡單。
　　當把“Bean2”部署到使用同一個（共享的） JNDI 名稱空間的兩個不同服務器中時，問題就冒出來了。
　　例如，有人可能有兩臺服務器，WSQASV 和 WSFXSV，它們共享同一個名稱空間（即 LDAP 或 CosNaming 服務器），并且他想把同一個 J2EE 應用程序（即 .ear 文件）部署到這兩臺服務器中。由于每臺服務器中的會話 bean 都必須查找／使用 Bean2Home 的正確實例，所以，這就出現了一個問題。要避免這個問題，必須做兩件事：
　　安裝在服務器 WSQASRV 中的 Bean2Home 的 JNDI 名稱必須與安裝在服務器 WSFXSV 中的 Bean2Home 的 JNDI 名稱不同。這兩個 JNDI 名稱必須不同，EJB home 的 lookup( ) 才能把引用（即 IOR）返回給安裝了該 EJB 的正確的服務器。
　　引用 Bean2Home 的客戶機（即會話 bean）必須根據部署了該應用程序的服務器顯式地指定 Bean2Home 的 JNDI 名稱。
　　EJB 的命名模式已經開發，以硬編碼的方式把 JNDI 名稱編寫到 java源代碼中是問題的真正起因。我們需要這樣一種能力，不必根據部署了 EJB 的服務器修改代碼就能夠提供特定于運行時的信息。結果是創建并實現一個模式，它利用 ResourceBundle 或 PRoperty 文件提供運行時信息，如以下代碼片段所示：
　　ResourceBundle myRB = ResourceBundle.getBundle("ServerProps");
　　String myBean2HomeJNDIName = myRB.getString("Bean2HomeName")
　　Context myInitCtx = new InitialContext();
　　Object result = myInitCtx.lookup(myBean2HomeJNDIName);
　　com.ibm.wsc.Bean2Home theBean2Home =(com.ibm.wsc.Bean2Home)
　　javax.rmi.PortableRemote.narrow(result,com.ibm.wsc.Bean2Home.class);
　　這一技術的全部要求就是為 WSQASV 服務器創建一個唯一的名為 ServerProps.properties 的 .properties 文件，WSQASV 服務器的這個文件包含有類似下面的內容：
　　Bean2HomeName=WSQASV/com/ibm/wsc/Bean2Home
　　WSFXSV 的 ServerProps.properties 文件包含有類似這樣的內容：
　　Bean2HomeName=WSFXSV/com/ibm/wsc/Bean2Home
　　現在，我們有了一個模式，不管將 J2EE 應用程序部署到兩臺服務器中的哪一臺，這個模式都不要求在部署之前對 java 代碼作絲毫更改，EJB home 的命名約定得到了一定程度的保護，但受服務器限定。這個“服務器名”限定使得在任一臺服務器中都可以正確定位 Bean2Home。在部署階段，部署者只需要知道 .properties 文件的內容，以將正確的 JNDI 名指定給 EJB。
　　采用這種技術，只有一個問題還留待部署者去解決：如何治理特定于服務器的 .properties 文件。讓人左右為難的是，.properties 文件既是特定于應用程序的（即應用程序中所包含的特定 EJB home 正在被查找），又是特定于服務器的（即 EJB home 的 JNDI 名稱取決于安裝了該應用程序的服務器）。問題是：ServerProps.properties 文件是在 J2EE 應用程序包（即 .ear 文件）中呢，還是在服務器的類路徑中？把 .properties 文件放到 .ear 文件意味著 .ear 文件在部署到上述兩臺服務器之前必須先作修改。人們不希望這樣做，原因與人們不希望修改 java 源代碼的原因如出一轍。不過，人們倒是很希望有一個各個部件的單個包，而不必為特定于應用程序的文件具體配置服務器。
　　EJB 1.1 解決方案
　　幸運的是，EJB 1.1 規范引入了 JNDI 增強功能，非凡是環境命名上下文（ENC）以及關于如何“找到” EJB、資源和特定于應用程序的環境變量的強烈推薦的做法。要了解具體信息，請參閱 EJB 1.1 規范的第 14 章和 J2EE 1.2 規范的第 5 章。以下代碼片段使用所推薦的 java:comp/env 構造來查找 Bean2Home：
　　Context myInitCtx = new InitialContext();
　　Object result = myInitCtx.lookup("java:comp/env/ejb/Bean2Home");
　　com.ibm.wsc.Bean2Home theBean2Home =(com.ibm.wsc.Bean2Home)
　　javax.rmi.PortableRemote.narrow(result,com.ibm.wsc.Bean2Home.class);
　　如何把“java:comp/env/ejb/Bean2Home”字符串和駐留在某臺特定服務器中的 Bean2Home 的 JNDI 名稱關聯起來，這項工作留給應用程序的裝配者和部署者去做。應用程序開發者既不知道也不關心 Bean2Home 的 JNDI 名稱。
　　非凡地，裝配者必須在引用 EJB 的 ejb-jar.xml 文件（或者是引用 servlet 的 web.xml 文件）中包含一條帶有以下內容的子句：
　　

ejb/Bean2Home

Entity

　　com.ibm.wsc.Bean2Home
　　com.ibm.wsc.Bean2
　　

Bean2

　　.xml 文件的內容通常由開發工具（即 WebSphere Studio Application Developer）或裝配工具（即應用程序裝配工具（Application Assembly tool（AAT）））構建和驗證，不要求手工構造。請注重，沒有給出 JNDI 名稱，只有一條聲明，表明這個 EJB（或 servlet）將查找一個給定類型的 EJB home，并且該 EJB home 駐留在這個 J2EE 應用程序包即 .ear 文件中。（假如省略了 ejb-link 描述符，servlet 或 EJB 就可以查找并使用駐留在 JNDI 名稱空間中具有這一 bean 類型的任何服務器中所駐留的 Bean2Home。）實際上，應用程序裝配者并不知道也不關心 Bean2Home 的 JNDI 名稱。JNDI 名稱留給部署者指定，其限制條件是，不論 J2EE 應用程序被部署到什么服務器中，Bean2Home 都必須駐留在該 J2EE 應用程序中。
　　在把應用程序安裝／部署到某一特定服務器（例如，在我們的示例中，是 WSQAEV 或 WSFXSV 服務器）中時，部署者必須做兩件事：
　　為 Bean2Home 創建一個 JNDI 名稱，它指向被安裝到“這臺”服務器的 Bean2Home。JNDI 名稱在名稱空間中必須是唯一的，這樣才能夠定位到駐留在“這臺”服務器中的所期望的Bean2Home，而不至于無意中使用了駐留在別的服務器中的 Bean2Home。
　　把 EJB 引用解析為正確的 Bean2Home JNDI 名稱。使用 ejb-link 描述符，這就迫使引用被解析為“這臺”服務器中的 Bean2Home JNDI 名稱。請注重，假如省略了 ejb-link，那么 ejb-ref 就有可能被解析為別的服務器中的另一個 Bean2Home 部署的 JNDI 名稱。
　　要點是：應用程序（連帶應用程序開發者）不需要知道在公共名稱空間中注冊的這臺或任何其它服務器中所駐留的任何組件的實際 JNDI 名稱。
　　應用程序可能不需要使用副文件就可以使用 EJB 的正確的 JNDI 名稱，這取決部署組件的服務器。
　　不需要修改 J2EE 包（即 .ear 文件）中的文件或部署描述符。一個 .ear文件不經修改、不加調整就可以部署到任何服務器中。
　　這一技術大大增強了 EJB 的可移植性。很輕易就可以部署應用程序，而不必為實際的 JNDI 名稱勞心費神。可以從一個 J2EE 應用程序抽取出 EJB，然后很輕易就可以將它集成到另一個 J2EE 應用程序中。
　　剩下的問題是：部署者應選擇什么樣的 JNDI 名稱？要求是：
　　在部署 J2EE 應用程序的服務器的名稱空間中，組件的 JNDI 名稱應是唯一的。
　　命名模式假如不是自治理的，那就應該是易于治理的。
　　用于 WebSphere for z/OS 的 Systems Management Administration 工具答應部署者指定特選的 JNDI 名稱，假如部署者選擇這樣做，或者應用程序要求這樣做的話。當不使用 java:comp/env 技術進行 lookup( ) 的時候就會出現這種情況。更為重要的是，該治理工具答應部署者指定一個系統生成的名稱，這樣生成的名稱必定是唯一的。名稱的格式如下：
　　///// 　　
　　因此，假如 Bean2 駐留在 EntityBeans.jar 文件中，并且所有的 J2EE 組件都被打包到 BeanSalad.ear 中，.ear 文件將被部署到 WSFXSV 服務器中，這臺服務器又在與 WSCPLEX sysplex 相關聯的 WebSphere 節點／群集上，那么，所生成的名稱將是：
　　WSCPLEX/WSFXSV/BeanSalad/EntityBeans/Bean2/com.ibm.wsc.Bean2Home.class
　　這個名稱唯一地標識了駐留在位于節點 WSCPLEX 的 WSFXSV 服務器中的 Bean2Home，對比于駐留在位于這個節點的 WSQASV 服務器中的 Bean2Home。
　　通過使用這一技術，我們實現了自治理的 JNDI 名稱唯一性，這不為應用程序所知，并且應用程序的可移植性達

上一篇：在JBoss下開發、部署EJB

下一篇：Enterprise JavaBeans組件慨述之二