精通J2EE應用程式開發之交叉分析J2EE

在不久前的一段時間內，Java 開發人員在準備一個新的企業 Java 開發項目時，事先就知道將要使用的工具。當時，一切都很簡單：J2EE 是新的，HTML 瀏覽器是公認的使用者介面標準，而複雜性（至少從推測的角度而言）已成為過去的事情。而如今，事情變得如此複雜。

“開發人員面對的選擇令人眼花繚亂。”

開發人員面對的選擇令人眼花繚亂，從“輕型容器”（如 Spring、NanoContainer 或 HiveMind）到“web 架構”（如 WebWork、Tapestry（一個基於 JSF 的 UI，類似於 Oracle 的新應用程式開發架構 (Oracle ADF)）或 Velocity）。這些選擇還增加了一系列新的 J2EE 規範，或者說是通過 JAXM、SAAJ、JAX-RPC 或 JAX 對“Web 服務”和相應的新技術術語“服務導向架構”賦予了新的價值（更不用提“WS-*”規範、工具和庫了），Java 開發人員可以完成所有工作，這真是一個奇蹟。

No Fluff Just Stuff 軟體論文系列的演講者 Ben Galbraith 將此現象稱作“Java 架構不確定性原則”：“您剛剛選擇了一個架構，某個其他架構的新版本便發布了，從而迫使您對選擇架構重新分析。”而且這種情況的複雜程度也無以複加了：只需將核心 J2EE 和 J2SE 類混合在一起使用。畢竟，我們被告知 EJB 是 J2EE 的“核心”，並且考慮一個沒有 EJB 的企業 Java 項目將是一個愚蠢的想法，這隻是昨天的事。究竟泛型如何改變您的 J2EE 編碼體驗？並且到底是誰讓所有 Java 管理擴充成了路障？

到底是怎麼了？最初明確專註於建立一個由單項優勢工具和庫構成的平台的行業何以在如此短的時間內變得如此零亂？我們何時需要在傳統的“J2EE”工具（如 EJB）與新型“Web 服務”（如 JAXRPC 和 WS-Security）工具之間進行選擇？更重要的是，我們現在如何做才能避免 Ben 的 Java 架構不確定性原則而又不違背 Java 首先應遵循的供應商無關原則？

此問題主要在於瞭解最能滿足需要的技術，而最好的方法是首先瞭解應用程式的需要。瞭解應用程式的需要後，即可清楚地界定應選用的相應技術。

本文將簡要概述最先進的 J2EE、與其相關的技術以及 Java 開發人員當今面臨的某些體繫結構挑戰。

我們如今要走向何處？

很多不同類型的 Java 程式在“企業 Java”的名義下趨於變得臃腫，在深入討論前，這也許有助於將它們與其他類型的 Java 應用程式區分開。如果我們從傳統的“3 層”方法開始（即將表示、商務邏輯和資料訪問劃分為三個一致的設計層次），則我們實際上可以確定五種“企業”Java 應用程式：煙囪、寶石、彙總器、整合器和公司專屬應用程式程式。

“我們實際上可以確定五種“企業”Java 應用程式：煙囪、寶石、彙總器、整合器和公司專屬應用程式程式”。

煙囪煙囪應用程式（也稱作“豎井”）可能是開發人員最容易接受的應用程式，這是因為它是一種我們一再開發的應用程式：它是傳統的“單資料庫、單 UI”應用程式，就絕對數量而言，它是當前構建最廣的一種 IT 應用程式。它通常是根據某個部門經理或副經理的需要（即尋找某個特定工具或應用程式來收集、操作和顯示某種當前未收集、操作和顯示的資料）而開始建立的，為此將組建一個團隊（規模通常不超過三到四個人，往往只有一個人）來收集需求、建立用例、構建資料庫、對商務邏輯進行編碼、將其部署到選擇作為此應用程式的生產伺服器的機器並不斷地監視它。

當然，此名稱得自您在白板上繪製的三個框（表示系統的邏輯層 — 展示層、商務邏輯層和資料訪問層）所形成的映像 — 它們構成了一條垂直線，不由使人想起將燃燒木頭的火爐中產生的煙排出到房間外面的舊式“煙囪”。（順便說一下，對於將該術語用作貶義術語的使用者而言，請記住，您在一生中將使用的許多最重要的系統（如 ATM 機、主要船運公司場地上的包裹定位器等）都是煙囪系統。

有一點可能比較令人吃驚的是，J2EE 軟體套件並不能完全滿足構建簡單煙囪系統的開發人員的需要。當只需要一個展示層，且只有一個資源用於儲存和檢索資料時，J2EE 套件（尤其是 EJB）就顯得“礙事”了。更誘人的方法是考慮輕型架構，因為它們並不那麼專註於部署描述符，並且就 JNDI、JMS 之類而言也沒什麼不便的。它只是通過 網頁瀏覽器進行的基本請求/響應通訊，通常構建在類似 Struts 或相似的 MVC 樣式 web 架構中，並與一組核心的傳統 Java 對象（有時與單個機器上啟動並執行展示層和商務邏輯層（而非資料庫本身））進行通訊。（您可能奇怪此處為什麼沒有使用術語“資料庫”。原因很簡單，雖然大多數項目使用資料庫（而且還是關聯式資料庫）儲存資料，但資料存放區通常是原有系統、商業軟體程式包或形如 CICS 大型主機、SAP 或 BizTalk 的“中介”技術。使用更一般的術語“資源”有助於強調這樣一個看法：後端實現確實與本討論無關。）

煙囪應用程式的另一個優勢是它們通常是“獨立的” — 也就是說不涉及其他應用程式。幾乎不需要遵守任何已建立的安全、可靠性或管理標準，這是因為此應用程式所確立的所有內容都將成為標準（至少對此應用程式而言是這樣，這正是此範圍的關鍵所在）。開發人員經常利用此事實來構建正好適合於此應用程式的基礎架構，從而消除了通常針對企業 Java 應用程式的指責：它們太複雜了，以至於無法使用和維護。

儘管人們希望如此，但 J2EE 的設計並非是針對煙囪應用程式的 — 當然，一個基於 J2EE 的應用程式可以構建此類應用程式（並且有上千個樣本可以作為此事實的證據），事實上有點像用牛刀殺雞。基於 J2EE 的應用程式實施了一定程度的層劃分，但有時這種劃分對於解決手頭的問題顯得有些矯枉過正，如傳統的“10 使用者”煙囪系統。當然，問題是 10 使用者煙囪系統通常有一種另人不悅的趨勢，即轉變為其他四個版本中的某個版本，這樣將使事情變得很糟。就像某位哲學家說的那樣“沒有哪個人是孤立的”，我們也可以很輕鬆和準確地說“沒有哪個系統是孤立的”。至少在短期內是這樣。（當然，如果系統無法完成其預期的目標，那它就無法與任何其他系統整合，並且可能停產，但我們將假設那不是預期的目標。）

珠寶 我們並不是說這是 IT 環境的成功和驕傲或五種應用程式樣式中“最好”的一個，但珠寶樣式的應用程式是結合了多個展示層的應用程式（因此，它的名稱--“珠寶”表示有很多面可供查看）。但請注意，給定展示層可能根本不是供使用者查看的；公司當前經常探討的一個層是其基於 Web 服務的應用程式前端，它並非為人使用而設。儘管如此，該 Web 服務仍表示一個展示層，這是因為它從根本上執行同一操作：擷取輸入並從其下面的核心商務邏輯層中提供輸出。

由於一度曾存在的某些假設突然間不複存在了，珠寶應用程式對傳統編程模型進行了一些有趣的轉變。例如，當考慮一個 Web 服務前端時，突然必須以某種平台和語言無關的方式（對此，XML 模式是當前可以選擇的工具）定義類型，而理想情況下，“一次且僅此一次”規則（也稱作“不重複自身”原則）將允許我們直接通過基於 HTML 的展示層用來與商務邏輯層通訊的同一類型構建此類型。這就是某些 JAX* 規範的用武之地--例如，Java API for XML Binding 有助於定義一個以非常模糊的方式進行“對象到 XML 以及 XML 到對象”轉換的標準方法，而 Java API for XML RPC (JAX-RPC) 定義一種使用 WSDL、SOAP 和 XML 構建可互操作的要求-回應遠程通訊層的方法。