[转载]Geronimo renegade: OpenEJB 和 Apache Geronimo 的 EJB 实现
Geronimo renegade: OpenEJB 和 Apache Geronimo 的 EJB 實現(xiàn)
Enterprise JavaBeans (EJBs) 到底有什么了不起的，為什么對 Java? 2 Platform, Enterprise Edition (J2EE) 開發(fā)來說如此重要？在這一期的 Geronimo 叛逆者 專欄中，OpenEJB 的共同創(chuàng)始人 David Blevins 將介紹 EJB 可以為您做什么，并解釋 OpenEJB 如何被選擇作為 Apache Geronimo 的 EJB 實現(xiàn)。
簡介
說實在的，在我看來，EJB 并不好用。它們需要開發(fā)人員在應用程序中投入比他們想像的還要多的精力；它們引以為基礎的接口強制您實現(xiàn)許多您甚至根本不需要的功能；而且因為您需要在容器中運行它們，所以使用 JUnit 將它們與應用程序的其他部分一起測試是十分棘手的。
但是，它們也許恰恰正是 J2EE 開發(fā)的基石。
所以當 The Powers That Be 邀請我在這一期 Geronimo renegade 中選擇 OpenEJB 作為 Apache Geronimo 的 EJB 實現(xiàn)時，我的興趣被激發(fā)了。也許我能最終弄清楚它到底有什么了不起的。
|
OpenEJB 如何成為 Apache Geronimo 的一部分
我曾打電話給 David Blevins，他與 Richard Monson-Haefel 在六年前共同創(chuàng)建了 OpenEJB，他還創(chuàng)建了 Geronimo。我想知道 OpenEJB 為 Geronimo 提供了什么，以及 EJB 本身為開發(fā)人員提供了什么。
我首先問他 OpenEJB 是如何在 Geronimo 等比較大的項目中興起的。David 解釋說，他在 Geronimo 尚未正式發(fā)布、只是一個傳聞的時候就已經(jīng)支持 Geronimo 項目了。“所以我絕對是所謂的 Geronimo 陰謀的一部分” ，他開玩笑地說。
哈，又是陰謀。我問他為什么總是這樣形容 Geronimo 呢。“哦，Geronimo 真的非常 FUD（恐懼，不確定，懷疑），對于如此標榜我們的那些人來說。” 他解釋說，Geronimo 創(chuàng)始人的目標首先是將將合適的人聚集起來，然后才考慮合適的組件。“參與創(chuàng)建 Geronimo 的個人基本上都將自我和自己的代碼拋在一邊，而決定首先將自己投入項目中” ，David 告訴我。基本上，他們是從一張白板開始嘗試創(chuàng)建項目的。
那么 OpenEJB 是如何成為這張白板的一部分呢？“哦，我猜原因就是您所知道的那些”，David 說。但他并不十分嚴肅。事實上，一開始是最初的 Geronimo 創(chuàng)始人之一的 Dain Sundstrom 邀請他加入該項目的。Dain 實際上在一年前就曾試圖聘請 David 參與一個類似的開放源碼項目：“有一段時間，他參加了 Twin Cities Java Users Group (TCJUG) 的每一次社交聚會，并不斷就此事糾纏我。”
當他們確實走到一起時，真的是命中注定一樣。雖然他們兩個都來自 Minnesota，但組建 Geronimo 項目的時候，David 正在 San Francisco 任教。“我說，‘這樣吧，我現(xiàn)在在 San Francisco，所以您必須等到我返回 Minnesota。’ 當然他說，‘太好了，我也在 San Francisco’ ，他剛從一個會議返回來。所以那天我們正好在 San Francisco 聚到一起討論，他本來以為會繼續(xù)得到我一直給他的 no。但當重心從另一個項目轉到 Apache J2EE 實現(xiàn)時，答案立即變成 yes。”。
而且，作為 OpenEJB 的領導人（因為 Monson-Haefel 在幾年前已經(jīng)離開），David 決心圍繞 Geronimo 的工作重振該社區(qū)。“我們只知道這是應該做的事情”，他說。
不僅如此，OpenEJB 和 Geronimo 這兩個團體建立了大型項目中罕見的協(xié)作。OpenEJB 的 Alan Cabrera 編寫了 Geronimo 的安全系統(tǒng)。Aaron Mulder，一本有關 Geronimo 的可自由下載的書籍的作者，也鄭重其事地檢查了這個由 IBM? 捐獻的控制臺。Geronimo 的 Dain Sundstrom 和 David Jencks 為 OpenEJB 做了不計其數(shù)的工作，以使其遵循 EJB 2.1（Open EJB 原來只遵循 EJB 1.1）。Gianny D'Amour，Geronimo 的早期附加物，全力促進 David 稱為 “我所見過的最大的 Geronimo 或 OpenEJB 補丁，基本上完成了我們的 CMP（container-managed persistence，容器管理持久性）實現(xiàn)” 。Jacek Laskowski，一位 OpenEJB 的長期貢獻者，第一個開始了 Geronimo-Tomcat 集成工作，該工作由 Geronimo 的 Jeff Genender 驅動完成，Jeff Genender 最終也成為 OpenEJB 的貢獻者。
Apache 孵化器
事實上，當談到 OpenEJB 和 Geronimo 時，David 說，“它在很大程度上是一個社區(qū)”。這就是為什么當 Geronimo 邀請 OpenEJB 成為 Apache 的一部分時答案又一次是 yes 的原因之一。
OpenEJB 仍在獲取所有必要的文件，以成為 Apache 孵化期的一部分，任何第三方，比如持有任何一部分代碼版權的公司，需要以書面形式作出正式的授權和捐獻。之后，OpenEJB 代碼在孵化期的子版本中就有了自己的區(qū)段。郵件列表將位于孵化期領域之下，諸如此類的事項更方便了兩個項目涉及的工作。
孵化期曾被描述為密封過渡倉 (airlock) 一類的東西。因為項目曾被邀請成為 Apache 的一部分但還沒有正式被接受。為了保證從孵化期畢業(yè)，項目必須適應所謂的 Apache 做事方式。“有許多標準”，David 解釋說，“但基本上您必須展示一個健康的社區(qū)，您必須有干凈的 IP”。
項目目前正致力于這個過程中所謂的干凈 IP 方面，并正在獲取來自曾資助早期開發(fā)的公司（比如 Intalio）的退出。但一個健康的社區(qū)不成問題。項目已經(jīng)存在六年了，有許多熱忱的貢獻者。（這個隊伍階層已經(jīng)隨著 Geronimo 的加入而顯著膨脹。）這種多樣性對 Apache 來說至關緊要。David 解釋說，“多樣性是代碼和社區(qū)在人力資源撤退時存活下去的關鍵因素。” 換句話說，當社區(qū)的一部分人離開一段時間時（這在任何長期項目中都是必不可避免的），社區(qū)作為一個整體必須足夠強壯和多樣化才能生存。
同時，OpenEJB 必須至少使一個發(fā)行版成為孵化期過程的一部分。項目已經(jīng)因為參與 Geronimo 受到了極大的影響，尤其是在容器方面，需要投入大部分工作升級到 EJB 2.1。
|
OpenEJB 的兩端
OpenEJB 實際上包括兩個部分 —— 服務器和容器，團隊強調(diào)將二者分離。EJB 規(guī)范將容器和服務器合同描述為不同的兩部分，但從沒有實際定義這些部分。OpenEJB 定義了容器-服務器合同，最終 OpenEJB 的服務器部分幾乎原封不動地合并到 Geronimo 中，但容器部分在該項目中被完全重寫。“我們沒有全部使用 Jetty，而且沒有全部使用 OpenEJB，OpenEJB 在 Geronimo 存在之前已經(jīng)到處都是了”，David 說。“讓我們（Geronimo 社區(qū)成員）引以為豪的一件事是我們只是隨機地聚集起來一群人，并成就了弗蘭肯斯泰因般的結果。”
OpenEJB 的服務器端處理等式的分布式部分。在任何分布式系統(tǒng)中都需要兩樣東西：定位要使用的組件或服務器的能力，以及定位之后調(diào)用組件或服務的方式。定位組件或服 務通常需要類似注冊的操作。在 Web 服務中為 “統(tǒng)一描述、發(fā)現(xiàn)和集成” (Universal Description, Discovery and Integration, UDDI）。在 CORBA 中為 CosNaming。在 EJB 中為 “Java 命名和目錄接口” (Naming and Directory Interface, JNDI)。理想情況下，您應該能夠通過正常編程方式實現(xiàn)第二部分 —— 調(diào)用組件。換句話說，您應該能夠像調(diào)用本地對象一樣調(diào)用組件。
環(huán)境的服務器部分處理該調(diào)用過程，該部分確保調(diào)用到達實際遠程對象，并確保響應返回給客戶機。服務器還處理任務，比如 “通過調(diào)用通信事務處理安全狀態(tài)” ，David 說。
我必須承認，對于 Plain Old Java Objects (POJO) 來說這是相當棘手的事情。我已經(jīng)開始看到使用 EJB 的優(yōu)點。但我仍然是一個 Web 服務小子，所以遠程系統(tǒng)嚇不倒我。EJB 還能為我這個程序員做什么呢？基本上，它似乎主要以由容器執(zhí)行的函數(shù)為中心。
|
EJB 能為您做什么
有三種類型的 EJB —— 會話 bean（無狀態(tài)的和有狀態(tài)的）、消息驅動 bean (MDB) 和實體 bean。“我從來都不喜歡術語無狀態(tài) 或有狀態(tài)”， David 承認，“因為它們都保留狀態(tài)。只是它們對狀態(tài)具有不同的保證。我曾經(jīng)教過 EJB（課程），我總是告訴我的學生將它們看作專用實例和共享實例。專用實例是有狀態(tài)的會話 bean，共享實例是無狀態(tài)會話 bean。可以將共享組件看作從圖書館借來的書。如果在讀完之后歸還它，則可以再次簽出，但不能獲得物理相同的同一本書，即使其標題相同。有的人可能在里 面涂寫了，您在訪問這本書時必須將這些考慮在內(nèi)。”
專用或無狀態(tài)的 bean 沒有這個問題，因為一旦您請求一個這樣的 bean，它就是您的了。其他任何人都不能使用該組件實例，所以可以確保任何涂改都是您的。這里的挑戰(zhàn)在于，您現(xiàn)在冒著累積服務器上幾乎無數(shù)個這種私有狀 態(tài)的風險，所以需要一種方法來將那些目前不使用的狀態(tài)推到磁盤中。所有這些都由容器處理。
容器還管理 MDB，從而使您可以很容易地使用 Java Message Service (JMS) 來回傳遞消息。您可以通過 JMS 以事務處理方式調(diào)用（消息驅動），這是一個非常方便的特性”， David 解釋說。“您不必編寫許多代碼。您必須做的就是實現(xiàn)接口，而請求是從 JMS 到達您那里的。”在這種應用程序中，不必太多關注接收您消息的客戶機的形式。
還有實體 bean 的問題，它具有自己的優(yōu)點 —— 主要是持久性和高速緩存方面。例如，您可以從數(shù)據(jù)庫提取信息，并使用實體 bean 在事務處理期間高速緩存數(shù)據(jù)。“老實說，如果讓您親自編程，您會發(fā)現(xiàn)這種優(yōu)化是非常困難的”， David 說。
|
OpenEJB 容器
該功能全部都由容器負責。容器 “管理無狀態(tài) bean 池以及無狀態(tài) bean 和實體 bean 的高速緩存區(qū)”，David 告訴我，“當調(diào)用來臨時，它會進行必要的工作，將組件準備好以便調(diào)用。它在調(diào)用前準備好所有事務狀態(tài)或確保所有安全要求，然后一旦發(fā)生調(diào)用，它將處理任何 類型的故障，比如回滾事務處理等，然后將請求發(fā)送給要與客戶機通信的服務器。”
好了，容器要做的事情實在太多了。就容器而言，使用 bean 可能要比試圖親自管理一切要值得。但這并不是容器所做的全部事情。容器還可以管理每個組件的生命周期。
您可能說，“那這意味著什么呢？” 這意味著容器明確知道要發(fā)生在組件上的事情并能夠讓您知道。例如，您可能想知道它何時將調(diào)用一個組件，是當它在組件中啟動一個事務之前、在結束一個事務之 前，還是在銷毀一個組件之前，等等。您為什么想知道？因為您可以在那時實際執(zhí)行操作。例如，您可以實現(xiàn)回調(diào)，即在事務處理完成時或回調(diào)時發(fā)送消息。這使您 可以完全控制組件的生命周期。
能力的代價
但這種能力不會沒有代價。這個代價就是您必須實際實現(xiàn)所有這些回調(diào)，不管您是否使用它們。這對不需要 EJB 提供的全部功能的程序員來說是一個問題，因為實現(xiàn)每個回調(diào)的問題不在于 EJB 實現(xiàn)的選擇，而在于通過無格式舊 Java 接口實現(xiàn) EJB 這一事實的后果。“如果您有較低端的需求，那么使用這個 API 開發(fā)是相當麻煩的” ，David 說。
幸運的是，大多數(shù)復雜性將隨著 EJB 3.0 的到來而消失，這是 EJB 構造方式的主要變化。不需要實現(xiàn)這些接口和回調(diào)，只需要注釋無格式的舊 Java 類即可。“在 EJB 3.0 中，只能說 ‘乒，那是一個組件，我已經(jīng)將之標示為無狀態(tài)” ，David 解釋說。要實現(xiàn)回調(diào)，只需創(chuàng)建方法并適當?shù)貙⑵渥⑨尲纯伞！盀榱藴p少你這邊的工作，它需要實現(xiàn)很多，因此出現(xiàn)了這些反模式（人們?yōu)槭褂脮挾ㄎ黄鞯?EJB 找到的），還有類似的所有這類瘋狂的東西，他們能夠基本屏蔽了 EJB API，但是還可以用-- 所有這些東西現(xiàn)在還不是必需的。”
當然，這些留待將來解決，等到 OpenEJB 3 分支開始成為 Geronimo 一部分的時候（我猜想）。但即使現(xiàn)在也存在 OpenEJB 與應用服務器如此配合的必然原因。
挑選
您可能知道，Geronimo 基于 GBeans 的概念，它允許您作為管理員來確定到底想要激活哪個組件。所以您可以具有超流水線的版本或超工業(yè)強度的版本，但您應該選擇您希望支持的版本。 OpenEJB 十分符合這個概念，因為服務器和容器之間的徹底分離使得用戶可以非常靈活地確定要支持的工具。例如，盡管一些 EJB 系統(tǒng)要求您具有服務器要提供的 CORBA、Web 服務和任何其他工具，OpenEJB 允許您通過將每個工具包裝為 GBean 來挑選。這樣，您就可以具有兩個不同的 CORBA orb、任意數(shù)目的 Web 服務實現(xiàn)和其他任何您認為必要的工具。或者，您還可以一個也不支持且僅允許本地調(diào)用。此外，通過服務器的構造方式，您可以支持多個工具而不必具有應用服務 器甚至應用程序的多個副本。（作者注：David 指出，這種能力對于 Web 服務尤其有用，其目的在于完全的互操作性，但現(xiàn)實有時無法達到這種目標。）
|
前方的路
向前看，OpenEJB 有一些令人興奮的特性即將面市；一些是嶄新的，一些不太新。例如，David 對容器驅動測試的嵌入式可測試性的擬定回報感到非常興奮。這種能力使得用戶可以容易地使用 JUnit 測試 OpenEJB 組件。通常，這些組件沒有容器不能運行，并要求您在測試前和拆卸后執(zhí)行特殊設置。但嵌入式可測試性允許您創(chuàng)建一個環(huán)境，將容器包含在其中作為系統(tǒng)的嵌入式 部分，同樣地，您可以嵌入類似 IBM Cloudscape? 的數(shù)據(jù)庫。“這是 OpenEJB 1 中包含的東西，在 OpenEJB 2 中丟失了，我們將在 OpenEJB 3 中恢復”， David 解釋說。“所以如果您編寫 OpenEJB 組件，那么您可以毫不費力地用正常的 JUnit 測試運行它們。”
OpenEJB 3 還將著眼于支持 Java Persistence Architecture API (JPA)。David 介紹說，“OpenEJB 在過去偏向于使用其他組件實現(xiàn)其持久性。在 OpenEJB 1 中，我們使用了 Castor，在 2 中使用了 TranQL。在 3 中我們將使用 OpenJPA，該 API 目前是標準，所以 OpenEJB 3 將是可插拔的。所以如果 TranQL 或 Castor 或任何其他項目確實決定支持 JPA，我們將能夠支持它們中的任何一個，或者同時全部支持。”
OpenEJB 還將支持構造器注入，從而使得容器可以在運行時提供各種類和對象。EJB 3.0 規(guī)范談到了公共字段注入和 setter 注入，但構造器注入將使您可以避免為預期不會更改的值創(chuàng)建 setter。當然，它還能夠幫助避免使用公共字段實現(xiàn)相同功能的必要性。“我們在 1995 年基本停止了這種行為，大約在 Java 發(fā)明三天后”，David 聲明。
|
結束語
有了持久性、事務管理并認識到對該 API 的編程將不會始終如此痛苦，我可以看到深入調(diào)查 EJB 的價值所在，尤其是對于注定要在 Apache Geronimo 上運行的項目來說。它們在 Web 應用程序中是強大的力量，事實上，甚至在非 Web 應用程序中也是如此。請參閱本文 參考資料 一節(jié)中的鏈接，以幫助您繼續(xù)自己的調(diào)查。
來自 “ ITPUB博客 ” ，鏈接：http://blog.itpub.net/374079/viewspace-130285/，如需轉載，請注明出處，否則將追究法律責任。
轉載于:http://blog.itpub.net/374079/viewspace-130285/
總結
以上是生活随笔為你收集整理的[转载]Geronimo renegade: OpenEJB 和 Apache Geronimo 的 EJB 实现的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： XSS 扫描器成长记
- 下一篇： php 下载 迅雷下载地址,PHP 生成