Java 理論與實踐：讓 J2EE 脫離容器

2019-11-18 12:29:11

字體：大中小

來源：轉載

供稿：網友

　　大多數項目不是屬于 J2EE 應用程序就是屬于 J2SE 應用程序。不過，有一些 J2EE 技術可以存在于 J2EE 容器之外，并且有些 J2SE 應用程序可以對它們加以利用。本月，Brian Goetz 分析如何在 J2SE 應用程序中使用某些 J2EE 服務。請在附帶的討論論壇上與作者和其他讀者分享您關于本文的心得。（您也可以單擊文章頂部或底部的討論來訪問論壇。）
　　
　　在大多數情況下，java 應用程序要么是 J2EE 應用程序、要么是 J2SE 應用程序，并且在這一點上是涇渭分明的。J2EE 應用程序需要 J2EE 容器的服務，容器要實現一長串的 J2EE API，包括 EnterPRise JavaBean (EJB)、JTA、JNDI、JMS、JCA 和 JMX。J2EE API 設計為協同工作；究竟，J2EE 設計是從多年來數百人開發企業應用程序的經驗中提取出的公共需求。像所有框架一樣，J2EE API 的主要目的是“不重新發明輪子”。
　　
　　有一些 API 屬于 J2EE 規范的一部分，但是可以很輕易地在 J2SE 應用程序中使用，如 JDBC、jsp 和 servlet，但是對于大多數 J2EE API，J2EE 是一個要么是要么不是的命題——大多數 J2EE API 需要全功能的 J2EE 容器。不過，有一些服務器應用程序開發為 J2SE 應用程序而非 J2EE 應用程序，這通常都有很好的理由。為什么這些應用程序的開發人員必須重新發明輪子呢？J2EE 中是否有部分內容可以輕易地被 J2SE 應用程序借用來提供同樣的優點呢？什么組件可以同時用于 J2EE 和 J2SE 應用程序的組件呢?
　　
　　松散耦合
　　J2EE 的一個主要設計原理是 J2EE 應用程序可以松散地耦合——用組件組裝，在組裝或者部署應用程序時而不是在組件開發時定義或者改變這些組件的相互連接。J2EE 組件使用 JNDI 相互查找和查找所需要的資源，如 JDBC 和 JMS 連接。JMS 這樣的技術鼓勵松散耦合，答應靈活地為工作流程建模、輕易分配處理任務、可伸縮性和容錯性。很多 J2SE 服務器應用程序也可以從這些技術和原理中受益。
　　
　　像 JDBC、JMS 和 JNDI 這樣的 API 基本上是“中間件”——它們作為應用程序與不同的服務提供者之間的統一接口。幾乎每一個數據庫服務器都有 JDBC 驅動程序，有大量的免費數據庫服務器，所以幾乎每一個希望利用數據庫的 Java 應用程序都可以輕易地做到這一點。不過，對于 JMS 就不是這樣了。消息隊列服務器遠沒有數據庫這樣常見，非凡是在小型商店中。但是有大量的應用程序可以通過使用消息隊列而極大地受益。
　　
　　Somnifugi JMS
　　消息隊列是一個功能強大的范例，它用于構建健壯的、靈活的、松散耦合的、可伸縮的應用程序。有一些商業消息隊列產品，如 WebSphere MQ、Sonic、Fiorano、JBossMQ 和 SpiritWave。就像 JDBC 對于數據庫一樣，JMS 是消息的中間件——它使得應用程序可以通過統一的接口訪問不同的消息隊列產品，這個接口提供了像 Connection、Topic 和Message 這樣的抽象。
　　
　　許多 J2SE 應用程序使用某種形式的消息隊列，但是不使用 JMS——而是使用線程池、工作隊列、任務治理器等。AWT 和 Swing 框架使用消息（事件）在模型與視圖層之間通信，JavaBean 組件利用監聽器支持一種基于主題的消息。消息隊列提供了很多結構上的優點——它固有的松散耦合有利于采用靈活的、基于組件的方法，并提供了有助于簡化設計和減少互連的天然抽象邊界。一個附帶的好處是，MQ 范例使得分布式的、可伸縮的和容錯的設計變得更輕易了，因為消息生產者和使用者不一定需要運行在同一 JVM 中，大多數生產者/使用者任務的本性是答應并發處理的。
　　
　　J2SE 服務器應用程序的開發人員經常開發他們自己的消息層，或者從零開始，或者以 util.concurrent 這樣的庫為基礎構建。通常這么做的理由是：
　　
　　MQ 服務器是昂貴的和重量級的，并且由于我們不需要像持久性、分布式、事務和驗證這樣更重量級的功能，構建自己內存中的消息層，只提供所需要的功能會更輕易。
　　
　　雖然這在一般情況下是正確的，但是應用程序需求通常會隨著時間而增加，在開始時不需要的一些消息功能在以后可能會變得更重要了。
　　
　　面向消息的應用程序的開發人員在開發過程的初期就必須做出選擇——選擇一個商業消息產品，或者構建自己的更便宜的、更輕量級的解決方案。Somnifugi JMS 包結合了這兩種方式——一個基于高性能的 util.concurrent 庫的非持久內存中消息隊列服務，和一個符合 JMS API 的接口。與傳統 JMS 提供者相比較，Somnifugi 是相當輕量級的，不管是功能上還是性能上。它只限于在一個 JVM 中使用（盡管可以取消這種限制），并缺少持久性、事務和驗證功能。另一方面，它非凡快——它比傳統 JMS 實現快得多，以至于可以在因性能原因可能無法使用消息的地方使用它。為了表明 Somnifugi 到底有多輕量級，在它的分發中包含了幾個用 JMS 主題取代 Swing/JavaBean 事件框架的例子。
　　
　　增加的靈活性
　　Somnifugi 還提供了另一項重要的優點：現在可以開發使用 JMS 接口的組件，然后在部署應用程序時決定是使用更快的、內存中的 Somnifugi 提供者還是更重量級的、但是更可靠的提供者，如 WebSphere MQ?？梢詫⑦@種選擇推遲到部署時的好處非常巨大——非凡是因為需求可能會在項目的開發過程中變化時——并提供了代碼重用的機會，對于自已開發的消息層來說這是不太可能做到的。
　　
　　在 J2SE 中使用 JNDI
　　像 JDBC 和 JMS 一樣，JNDI 是一種中間件。像 JMS 一樣，在 J2SE 應用程序中使用 JNDI 不像使用 JDBC 那么輕易。JDBC 提供者無處不在——有數十種兼容 JDBC 的商業和開放源代碼數據庫服務器。雖然所有 J2EE 容器都必須包括一個 JNDI 提供者，但是對于不屬于 J2EE 容器的 JNDI，數量相對就少了。這不僅使在 J2SE 應用程序中使用 JNDI 更困難了，而且還意味著 J2SE 開發人員不太可能接觸到 JNDI 并熟悉它的優勢。
　　
　　根據所使用的 JNDI 提供者和應用程序配置，JNDI 可能在 JNDI 名稱空間中存儲任意的 Java 對象（有一些限制：有些 JNDI 提供者限制存儲的對象是可序列化的）。一般用 JNDI 存儲靜態配置數據（整型和字符串型）、JDBC DataSource 對象、JMS Connection 和 Topic 對象，以及無狀態的對象（包括工廠對象）。完整地存儲已配置對象，比如 JDBC DataSource 對象，而不只是配置數據，比如 JDBC URL，還可以增強應用程序的安全性，因為像授權憑證這樣的敏感信息不能被應用程序直接使用。
　　
　　J2EE 應用程序使用 JNDI 作為連接松散耦合組件之間的“開關板”——J2EE 組件使用 JNDI 尋找其他想要使用的組件，如 EJB 組件，并尋找 JDBC 和 JMS 連接這樣的資源。J2EE 組件之間的互連是在組件的部署描述符中聲明式地定義的，容器自動將對象綁定到名稱空間中的特定位置，并保證在部署組件之前組件之間的所有資源依靠關系都得到滿足。
　　
　　J2SE 應用程序可以以類似于 J2EE 應用程序的方式使用 JNDI，只是它們必須多做一些填充名稱空間的工作。但是好處是相同的——應用程序可以更松散地耦合，組件在運行時彼此發現。
　　
　　免費 JNDI 提供者
　　雖然 JNDI 參考實現不包括一般性的 JDNI 提供者，但是可以下載 Sun 網站提供的 File System （FSContext）。這是一個示例 JNDI 提供者，它是以源代碼的方式提供的，它訪問并存儲文件中的可序列化對象，還使名稱空間的內容可以保證跨程序調用的一致性。雖然 FSContext JNDI 提供者主要是做為編寫 JNDI 提供者的一個示例，但是簡單的應用程序也可以使用它作為序列化對象的持久性數據存儲，或者是作為“存根” JNDI 提供者，對從 JNDI 獲得其配置的組件進行單元測試。
　　
　　JBoss 開放源代碼 J2EE 容器還包括一個更一般性的 JNDI 提供者 JNPServer，它可以輕易地作為單獨的 JNDI 提供者運行，不需要 JBoss 容器。可以通過 RMI 從遠程 JVM 訪問 JNP，而在本地 JVM 中不會產生 RMI 開銷。它在內部將對象存儲到內存中的一個 HashMap 中。
　　
　　在 JBoss 發行版的 jnpserver.jar JAR 文件中可以找到 JNP JNDI 服務器，它還依靠于 log4j 日志引擎。要使用它，必須配置 log4j，創建相應的 jndi.properties 文件（參見清單 1），并安排通過調用同一 JVM 或者另一個 JVM 中的 org.jnp.server.Main 的主入口點來啟動服務器。訪問 JNDI 名稱空間的類文件在 JBoss 發行版的 jnpclient.jar JAR 文件中。
　　
　　清單 1. JNPServer 的 jndi.properties
　　
　　java.naming.factory.initial=org.jnp.interfaces.NamingContextFactory
　　java.naming.factory.url.pkgs=org.jboss.naming:org.jnp.interfaces
　　# Uncomment this line only if the JNDI server is to run in another JVM;
　　# otherwise, local JNDI requests will go over RMI
　　#java.naming.provider.url=localhost
　　
　　Java 治理擴展（JMX）
　　Java 治理擴展（Java Management Extensions，JMX）是一種治理組件和服務的生命周期的機制。JBoss 大量使用 JMX——JBoss 中的幾乎所有組件都作為 JMX 服務提供。結果就是很輕易配置一個只包括所需服務的應用程序。對于每一個組件服務，創建一個名為 MBean （托管的 bean）對象，它包含生命周期方法（start() 和 stop()）和公開屬性的 getter 和 setter。清單 2 顯示了描述一個簡單 Web 容器服務的 MBean 接口：
　　
　　清單 2. 簡單 Web 容器服務的 MBean 接口
　　
　　public interface WebServerMBean {
　　　 // Lifecycle methods
　　　 void create() throws Exception;
　　　 void start() throws Exception;
　　　 void stop();
　　　 void destroy();
　　
　　　 // Getter and setter for listener-port property
　　　 int getPort();

上一篇：J2EE 探險者：持久數據管理

下一篇：如何開發會話Bean（有狀態會話Bean）