J2EE 探索: 有狀態網絡的 J2EE 技術

選擇合適解決方案的最佳實踐

級別: 初級

Kyle Gabhart , 高級顧問, LearningPatterns

2003 年 5 月 12 日

J2EE 中的 Java servlet 和 Enterprise JavaBeans 組件都提供了有狀態服務器端處理。兩種技術各有千秋，每種技術都比其它技術更加適合于某些應用程序設置。為了幫助您為您的企業選擇合適的解決方案，LearningPatterns 的高級顧問 Kyle Gabhart 比較了這兩種技術，并評估了它們在一些常見的有狀態應用程序方案中的性能。

在 J2EE 探索 系列的 第一部分 中，我們首先研究了 J2EE 中狀態管理的最新技術。上個月，我們討論了 J2EE 中管理無狀態網絡的最佳選項；這個月我們將討論管理有狀態網絡的技術。

首先我將簡要介紹有狀態應用程序管理，然后談論不同的解決方案如何應用于 Web 層或業務層。接下來，我將比較 J2EE 中有狀態應用程序管理技術的優缺點。就象在前一部分中一樣，我們將通過研究每種技術最常用的一些實現，以及用于為您的企業選擇合適解決方案的一些最佳實踐來結束本文。

請注意，對于本文而言，JSP（Java ServerPages）文件被認為是專用類型的 servlet。

有狀態應用程序管理

您可能會回想起來，在上一篇文章中，Web 應用程序協議被分成兩大類別： 無狀態（stateless） 和 有狀態（stateful） ，協議的 狀態 指的是它“記憶”從一個傳輸到下一個傳輸的信息的能力。因為有狀態連通性是大多數企業應用程序的基本需求之一，并且因為 Web 應用程序依賴于 HTTP（內在的無狀態協議），所以聰明的開發人員已經找到了許多技巧來在 HTTP 上模擬有狀態連接。有狀態信息可以存儲在 HTML 表單字段中、附加到超鏈接或者存儲在客戶機端的 cookie 中。

客戶機和服務器之間的有狀態交互可以在 Web 層或業務層上進行管理。要在 Web 層上管理狀態，我們使用與 HTTPSession API 結合的 servlet。要在業務層上管理狀態，我們使用有狀態會話 EJB 組件。在接下來的章節里，我們將探究這兩種開發選項。

回頁首

Web 層

Servlet 體系結構的 HTTPSession API 允許應用程序開發人員管理跨網絡的客戶機/服務器交互（或 會話 ）的狀態。 HTTPSession 接口定義了 HTTPSession API 的核心功能。它為 J2EE 應用程序提供了一種方法，使它可以識別跨多個頁面請求的單個客戶機，以及將數據存儲在與那個客戶機相關聯的服務器上。通過該接口，servlet 容器創建和管理客戶機和服務器之間的會話。該會話由 HTTPSession 對象表示，它可以跨來自相同客戶機的多個連接和頁面請求持續存在一段特定的時間。Servlet 使用該接口來查看與處理有關會話的信息，如創建時間和上一次訪問會話的時間。該接口還允許 servlet 將對象綁定到會話，從而以一種跨多個連接（來自相同客戶機）持續存在的方式將該信息與特定的客戶機進行關聯。

Servlet 體系結構 Servlet 體系結構并沒有因為使用 HTTPSession API 而發生改變。就象在無狀態網絡中一樣，servlet 代表客戶機執行業務請求，并且充當控制器、視圖，或者二者同時兼任。Servlet 還可以有效地處理用戶交互，如內容格式化和顯示、基本請求處理和安全性請求及更多。就象在無狀態網絡中一樣，servlet 最好用于管理客戶機交互，那么通常可使用助手類（如 JavaBeans）來應付繁重的處理或者與后端組件相互操作（interface）。

因此， HTTPSession 接口允許 servlet 容器創建和管理客戶機會話，并且使 servlet 能訪問與會話相關的信息、將對象綁定到會話以及訪問先前綁定的對象。到現在為止，一直都還不錯。但是 servlet 容器如何跟蹤通過無狀態協議（如 HTTP）通信的客戶機呢？為了實現這一點，為每個 HTTPSession 對象都提供一個唯一的標識，以確保每個客戶機會話和與會話相關的數據可以被唯一標識。考慮到 HTTP 內在的無狀態本質，在每次請求時，該會話標識必須被客戶機傳遞給服務器，以便于 servlet 容器將客戶機與正確的會話相關聯。會話標識可以用三種方式中一種進行傳遞：作為 HTML 表單中的參數（通常是隱藏字段）；作為附加在查詢字符串后的參數；或者作為 cookie 的屬性。不管會話標識如何傳遞，servlet 容器都將攔截它，檢查它，并找到與之關聯的 HTTPSession 對象。

Servlet 性能

由 Servlet 體系結構創建的輕量級線程模型決不會因為 servlet 或 JSP 文件創建、讀取或修改 HTTPSession 對象而受到破壞。該對象只是將對象引用存儲為簡單鍵-值對的散列表或類似的集合。同樣， HTTPSession 內存空間的實現本身也是輕量級的，只需要存儲（或許序列化）會話對象和相應的會話標識。簡而言之，servlet 可以支持與 HTTP 客戶機的有狀態交互，而且對應用程序設計或容器資源產生最小的影響。

回頁首

業務層

J2EE 為在業務層上處理狀態提供了內置的支持。與無狀態會話 bean 一樣，有狀態會話 bean 也被映射到業務過程。兩者之間的關鍵區別是：無狀態 bean 及其數據在單個客戶機請求的生命周期內存活，而有狀態 bean 卻維護與客戶機的對話并且它們的數據跨多個請求持續存在。與 servlet 不同，有狀態會話 bean 不需要任何特殊的對象，也不需要使用額外的接口來創建有狀態連接。EJB 容器提供了所有有狀態會話 bean 管理。對于 bean 而言，所有必要的工作就是在其部署描述符中將其聲明為 stateful 。

EJB 體系結構 從體系結構的觀點看，有狀態會話 bean 與其無狀態的同類沒有任何差別。兩種類型的 bean 都可以很好地充當視圖、控制器或模型；二者通常都可以實現虛包（Facade）模式或業務委派（Business Delegate）模式；二者都可以與多個客戶機類型一起使用。有狀態會話 bean 可以通過 servlet（或 JSP 文件）、幫助 servlet（或 JSP 文件）的 JavaBean 和另一個企業 bean 訪問，或者直接通過 applet、Swing 應用程序或其它 Java 應用程序，或者甚至是使用 IIOP 協議的非 Java 客戶機訪問。

管理有狀態 bean

正如以前闡述的，會話 bean 是最輕量級類型的企業 bean 類型。特別地，無狀態會話 bean 可以方便地被容器合用，因為它們只需要維護每個請求的狀態。

相反，有狀態會話 bean 與容器資源并不那樣友好。有狀態會話 bean 的池不能象無狀態 EJB 組件的池那樣用來容納任何客戶機請求。有狀態 bean 只能處理來自一個客戶機的請求，直到該客戶機釋放其對那個特殊 bean 實例的控制。有狀態會話 bean 消耗了容器的大量時間和內存。為了保存客戶機調用之間的 bean 狀態，容器必須將 bean 實例保存在活動內存中，或者臨時將狀態寫到持久性存儲（如文件系統或數據庫）中。將狀態分配到持久性存儲中就是所謂的 鈍化（passivation） 。當以前鈍化的企業 bean 被再次請求時，容器通過從池中檢索 bean，并且利用鈍化前 bean 的持久性狀態對它進行初始化，來激活它。下圖闡明了有狀態會話 bean 的鈍化和激活：

決定將 bean 保存在內存中還是對它進行鈍化，然后再激活它，這取決于各個供應商。盡管在釋放容器資源方面鈍化機制非常有幫助，但是在防止服務器崩潰以避免丟失有狀態會話 bean 的活動狀態方面卻無能為力。盡管一些供應商提供了會話恢復功能以解決這個問題，但它不是標準的，因此依賴該功能會降低應用程序的可移植性。但是，別擔心！EJB 規范確實定義了一個接口（ javax.ejb.SessionSynchronization ），它可以向企業 bean 警報事務的狀態，包括由于服務器崩潰而失敗的事務（假定不是拔了服務器的插頭）。實現 SessionSynchronization 接口的企業 bean 必須定義三個已聲明的方法特征符： afterBegin() 、 beforeCompletion() 和 afterCompletion(boolean) 。這些方法使 bean 可以從容器接收三個額外的回調，以允許正確處理 bean 中的事務狀態。

EJB 組件性能

從性能的角度看，servlet 和無狀態會話 bean 是相當具有競爭力的技術。它們都可以使用實例池為來自客戶機的請求提供服務。但是，當您添加了應用程序狀態管理時，巨大的性能差異就將顯現。與可用作 Servlet 體系結構一部分的輕量級 HTTPSession 機制不同，有狀態會話 bean 需要一個更加重量級的針對狀態管理（如上面概述的鈍化／激活方案）的解決方案。這個針對有狀態會話 bean 的常用解決方案需要花費服務器時間和資源來鈍化 bean 狀態、回收 bean 實例和激活 bean 狀態。上述的每個過程都需要幾次容器調用，以及需要直接對 bean 執行回調方法，以確保正確處理 bean 的狀態。總而言之，有狀態會話 EJB 組件為管理應用程序狀態提供了一種重量級機制。

回頁首

選擇合適的技術

與無狀態的 J2EE 體系結構不同，J2EE 應用程序不提供典型的配置來充當指南或藍圖。管理狀態時，合適的體系結構取決于下列因素：

• 客戶機是基于 Web（HTTP）的嗎？
• 對話狀態需要包含到 GUI 中嗎？
• 服務器將處于哪種負載條件下呢？
• 有狀態組件需要能夠在服務器崩潰后仍然有效嗎？
• 該組件需要哪種事務上下文呢？
• 有狀態數據有多重要？

盡管上述一些問題似乎明顯地傾向于其中一種技術，但是許多有狀態方案實際上既需要使用 servlet 又需要使用 EJB 組件。至關重要的決定就是確定是在 Web 層還是在業務層上管理狀態，或者同時在兩個層上管理狀態。在下一節中，我們將研究一些可能的企業應用程序方案，及其最適宜的解決方案。

應用程序客戶機

標準的應用程序客戶機是與另一個系統或組件相互操作的客戶機。我們將研究三種典型的應用程序客戶機方案，并且討論每個客戶機最適合的有狀態解決方案：

• 如果客戶機是基于 Java 的，并且與服務器處于相同的防火墻之后，那么您首先應該決定有狀態交互模型是否是必需的。管理有狀態會話 bean 是資源密集型的，因此您應該考慮更輕量級的備用方案。最佳解決方案就是使用 RMI 直接與應用程序服務器中的 無狀態 會話 bean 對話。如果 有狀態 解決方案是必需的，則請考慮使用帶有簡單事務層的無狀態會話 bean，或者在業務層上創建瘦 servlet 層。任何一種解決方案花費部分成本即可提供有狀態體驗。最后，如果您的客戶機必須與跨多個請求的業務過程的狀態進行緊耦合，并且不能接受添加 Web 層，那么有狀態會話 bean 是顯而易見的選擇。
  
• 如果您正在使用非 Java 的客戶機或者使用與服務器不在同一個防火墻之后的客戶機，那么狀態管理問題略有不同。在這種方案中，您首先應該確定狀態管理的目標。如果目標是通過某種 GUI 為用戶提供流暢的體驗，那么您可以在 Web 層上管理狀態。如果目標是將跨多個請求的復雜業務過程聯系在一起，那么狀態管理應該在業務層上進行。再次強調，您應當始終探索其它選項，如使用帶有事務層的無狀態會話 bean。
• 一些應用程序服務器供應商以一種諸如接受本機 IIOP 調用的方式公開 EJB 容器，從而允許 CORBA 客戶機將 EJB 組件當成本機 CORBA 應用程序。這允許非 Java 客戶機使用 IIOP 協議與無狀態會話 bean 進行通信。在該設置中，客戶機繞過了 Web 層，并使用 IIOP 協議直接與業務層（會話 bean）進行通信。這時，體系結構分析與位于防火墻后的基于 Java 的應用程序分析是相同的。請參考第一種方案，以理解業務層上的狀態管理問題。

電子商務隨需應變環境

正如我們 上個月 討論的，無狀態會話 bean 是為電子商務隨需應變（e-business on demand）應用程序精心設計的。它們是非常輕量級的，可以輕松地匯聚為池，以確保卓越的可伸縮性。相反，有狀態會話 bean 并不是為這類應用程序而精心設計的。電子商務隨需應變應用程序中通常需要狀態管理，但是最好由專用的機制或通過 J2EE 事務進行處理。另一種可能性是調用 EJB 組件，就好象它是 CORBA 組件一樣。當一個或多個被集成的應用程序是 CORBA 組件時，該選項特別有用。

“富”GUI 客戶機

有三種基本的“富”GUI（不是 HTML，也不是命令行）客戶機類型：Java applet、獨立應用程序和 Java Web Start。下列解決方案適用于這三種“富”GUI 組件類型中的任何一種：

• 如果您的客戶機和服務器被防火墻分隔，您應該讓客戶機通過 HTTP 與 servlet 直接通信。該 servlet 層可以使用助手類應付簡單的業務處理。如果您的應用程序有更復雜的需求，或者對企業資源有更高的請求頻率，您應該使用會話 bean 來處理業務過程。這里再強調一次，您應當將有狀態交互模型的必要性作為決策過程的一部分進行考慮。
• 如果您的客戶機和服務器位于同一個防火墻之后，直接的 RMI 調用可能是您的最佳選擇。在這種情形下，servlet 只會帶來額外的開銷和不必要的體系結構復雜性。在 applet 或 Java Web Start 情形中，通過提供帶有 applet 或 Java Web Start 應用程序鏈接的首個 HTML 文檔，servlet 可以啟動事務。然后，最好使客戶機與一個或多個會話 bean 建立直接的 RMI 連接。該方案的設置與典型的應用程序客戶機方案（與服務器不在同一個防火墻之后）的設置相同。

如果您正在使用本機 GUI 客戶機，并且需要管理復雜的事務或事務系列，那么您應該再次考慮調用 EJB 組件，就象它是 CORBA 組件一樣。如果不能那樣做，您可以始終讓客戶機通過 HTTP 與 servlet 通信，并且相應地管理會話。

Web 應用程序

在標準的、基于 Web 的應用程序情形中，客戶機位于防火墻的哪一側并不重要；使用 servlet 是必需的。因為您將使用 HTTP 作為傳輸協議，所以將在 Web 層上工作。唯一實際的決定 ― 是否在幕后使用 EJB 組件 ― 將取決于對 EJB 容器服務的相關需求。首先，您將選擇通用的組件類型（如 servlet 和會話 bean）。接下來，您將選擇一些匹配應用程序的用戶界面顯示和業務請求處理需求的更特定類型（如 JSP 頁面和有狀態會話 bean）。就所關心的狀態管理而言，Web 應用程序中存在著和其它客戶機類型中類似的問題。一些標準問題（和答案）將有助于您為您的 Web 應用程序確定合適的狀態管理解決方案：

• 有狀態體驗需要直接與用戶界面聯系嗎？ 如果是，那么必須使用 servlet 和 HTTPSession API 管理狀態。
  
• 您的業務過程需要跨越來自客戶機的多個調用嗎？ 如果是，您有三種選項：
  1. 使用有狀態會話 bean 來提供有狀態業務過程。
  2. 使用無狀態會話 bean，并且讓持久數據高速緩存在服務器上。接著對高速緩存的引用可以存儲在客戶機的 HTTPSession 對象中。
     
  3. 通過調用 bean 上的方法使 JavaBean 充當業務委派（請參閱 參考資料 ），從而使 bean 批處理所有來自客戶機的數據，并且僅在客戶機準備提交業務過程時才聯系無狀態會話 EJB 組件。再次使用了 HTTPSession API 來持久化 JavaBean 實例。
• 您的有狀態業務過程需要故障保護嗎？ 如果是，您有三種選項：
  1. 使用應用程序服務器，該服務器為有狀態會話 bean 的狀態恢復提供自動支持。
  2. SessionSycnhronization 接口允許無狀態或有狀態會話 bean 對事務故障做出響應。這將允許您回滾事務、持久化數據或執行您可能需要的任何其它清除功能。通常，服務器故障將不會阻礙容器調用由接口聲明的回調方法。
     
  3. 許多 Web 服務器都提供了故障保護 HTTPSession 實現。如果您的服務器可以這樣做，那么您可以使用 JavaBean 作為業務委派。

多客戶機類型

最后的情形需要客戶機類型的組合，例如基于 Web 的瀏覽器和標準的“富”GUI 桌面。在這種情形下，有狀態選項同無狀態選項沒有區別。請參考 本系列的第一篇文章 以獲取詳細信息。

回頁首

結束語

在本部分（ J2EE Pathfinder 系列的第二部分）中，我們探討了使用 Java servlet 和有狀態會話 bean 來執行客戶機請求和提供有狀態體驗的相對優缺點。本文討論的方案并未包含所有情形，但是它們代表了有狀態通信環境中的 servlet 和會話 EJB 組件的一些最常見用法。

在下一部分中，我們將開始有關持久數據管理的兩部分探討，首先將比較實體 bean 和 JDBC。愿我們到時“探索”愉快！

回頁首

參考資料

• 您可以參閱本文在 developerWorks 全球站點上的 英文原文 .
  
  
• 參與有關本文的 論壇 。（您也可以單擊文章頂部或底部的 討論 來訪問論壇。）
  
  
• 請參閱由 Kyle Gabhart 撰寫的完整 developerWorks J2EE pathfinder 系列 。
  
  
  
• 如果您還是 EJB 技術的新手，那么您可能應該查閱本系列的第一篇文章“ The ABCs of EJBs ”中的側欄。
  
  
  
• 如果您希望學習更多有關 Java 2 平臺，企業版和相關技術的知識，可以從 J2EE 主頁 開始。
  
  
  
• Brett McLaughlin 的 EJB 最佳實踐 系列 （ developerWorks ）介紹了與 Enterprise JavaBeans 組件相關的一些基本模式和用法。
  
  
  
• 了解本文提及的有關虛包（Facade）、業務委派（Business Delegate）和工廠（Factory）模式的更多知識。請參閱 Sun Microsystems 的 Java BluePrints 。
  
  
  
• Paul Monday 的優秀“ Java design patterns 201 ”教程（ developerWorks ，2002 年 4 月）更理論上的討論了 Java 編程中設計模式的使用。
  
  
  
• 在 developerWorks Java 技術專區 可以找到數百篇有關 Java 編程各個方面的文章。
  
  
  
• 還請參閱 developerWorks Java 技術教程頁面 以獲取有關 Java 技術的免費教程的完整清單。
  

關于作者

		Kyle Gabhart 是 LearningPatterns 的高級顧問，該公司是為全世界客戶提供世界一流的顧問和培訓的動態知識公司。Kyle 是很受歡迎的公眾講演者，他以其對新興技術的熱情、精辟分析以及演講而聞名。要獲取他最近以及即將進行的演講或發表的業內出版物的信息，請訪問 Gabhart.com 。可以通過 kyle@learningpatterns.com 與 Kyle 聯系。