一：EJB與spring的全面比較

        Rod Johnson將Indeed.com(一個求職網站)職位列表中對EJB和Spring兩種技能的需求數量進行了對比，並通過分析這一統計資料得出了一些關於EJB的發展過程及其未來的結論。他圍繞著會話Bean和訊息Bean對EJB展開了討論，並承認JPA做為獨立的規範是有價值的，JPA“是基於現代技術並已開始體現其價值”。首先，Johnson闡述了職位要求所體現的趨勢的重要性：

        職位列表是技術真正被採納的良好指示器。它們表明公司是否把錢花在了“刀刃”上;它們為開發人員指明獲取、增強相關技能的重要性(這是技術延續的一個重要因素);它們還為公司穩妥地採用特定技術提供了良好的指導。

        隨後，Johnson介紹了下面這個EJB和Spring圖表。該圖表顯示，截止到2007年11月，Java職位列表對Spring技能的需求已經超越了EJB。他認為倘若現在基於EJB的應用數量仍相當可觀的話，那是很令人驚詫的。

              

        Johnson評論這些趨勢的時候有些洋洋自得，因為他2003年以來就預言EJB會因他在J2EE without EJB一書中描述的那些缺點而失去其實用性。甚至在他看來，EJB3.0新的改進也不足以遏制這種趨勢：


        EJB 3.0改進了一些事情，但還是太少、太遲：依賴注入(DI)的能力不足以滿足實際需要;攔截API認識到了需要有一個對橫切關注點的解決方案，但我們看到的還是一個最差、最笨重、最容易出錯的解決方案(我一直想在部落格上釋出的一些東西);由於要相容那些現在已不相關的舊有技術，把它拖累了;沉重的EJB契約(它比“簡化的程式設計模型”多出數百頁)需要一個相當複雜的執行時環境，而且開銷很大;儘管有語法糖(syntax sugar)，但它還是不能掩蓋EJB的大量缺陷，例如啟動行為、單例、以及廢棄的執行緒模型。最後，每次改變基礎環境的時候，它都要有效地繫結到一個應用伺服器環境中去。

        接下來，他解釋了對整個行業及開發人員個體來說，EJB的衰落意味著什麼：

        這不是反對標準——而僅僅是有選擇性地反對那些無實際意義的標準。正如我長期以來一直指出的那樣，Java EE不只是EJB，任何關心這個平臺的人都應該真誠地對待其各部分的質量和關聯性。

        隨著越來越先進的技術，業務物件變成了POJOs，對特殊元件模型的依賴在減少，標記也變得不那麼重要了。

        拋棄EJB後會有更好的架構靈活性來應對需求的變化。隨著SOA和其它力量的興起，公司也越來越多地選擇輕量級的部署平臺。

        Johnson總結到：“由於其絕對數量仍然相當多，EJB不會很快消失。但是趨勢曲線清楚地表明它正在逐漸成為過去”。EJB懷疑論者Rick Hightower也相信EJB仍然會存在一段時間。同時，他還表現出對這種對比方式的關注：


         然而，EJB被廢棄還是比較遙遠的事情，難道不是嗎?把Spring這樣的通用架構(比如Spring MVC、Spring WebFlow、Spring XXX)和EJB這樣有側重點的框架放在一起做比較真的公平嗎?正如從Seam，EJB和Spring的比較圖中看到的一樣，對現有的開發人員來說，這種相對比較的方式是很不公平的。

             

        對於象Seam這樣的技術顯然有一些疏漏，但Seam結合了EJB 3.0，它也彌補了很多EJB模型原有的缺點，也提供了許多與Spring一樣的優點(使用POJOs和IOC等)。依我愚見，它要比Spring更好一些(比如說，它幾乎完全基於註釋，而不是XML)。我不是想打擊Spring，我只是想說結合了Seam和其它技術(像JSF)的EJB3提供了一個非常可行的Spring的替代方法。


        假如基於EJB的那些應用中有相當一部分內容是依賴於應用伺服器的，而應用伺服器恰恰是採用EJB規範專有的實現，那麼在一些為它們的核心 Java企業元件模型權衡開源框架的公司中，這些趨勢會增加他們的信心。這些對比在表明Spring框架正在走向勝利的同時，不也恰恰表明EJB模型即將開始失去其實用性了嗎?檢視英文原文：Spring Overtakes EJB as a Skills Requirement?


二、JavaBean與EJB的不同：

        您現在可能已在使用 JavaBean，但還不瞭解它。如果有支援 Java 的瀏覽器，那麼，在桌面上使用 JavaBean 就沒有限制。使用的 Web 頁面可以將 bean 作為小應用程式的一部分。您很快就會和作為瀏覽器可視部分的 JavaBean 互動，然後，那些 JavaBean 將與伺服器上的 EJB 介面。這種能力也可以擴充套件到因特網和內部網。

        JavaBean 和 Server Bean（通常稱為 Enterprise JavaBean (EJB)）有一些基本相同之處。它們都是用一組特性建立，以執行其特定任務的物件或元件。它們還有從當前所駐留伺服器上的容器獲得其它特性的能力。這使得 bean 的行為根據特定任務和所在環境的不同而有所不同。

        這開闢了巨大商機。因為 JavaBean 是與平臺無關的，所以對於將來的解決方案，供應商可以輕易向不同使用者推出其客戶機方的 JavaBean，而不必建立或維護不同的版本。這些 JavaBean 可以與執行商業功能（例如訂購、信用卡處理、電子匯款、存貨分配、運輸等）的 EJB 配合使用。這裡有巨大潛力，而這正是元件代理（WebSphere Application Server 企業版）設計提供的那種潛力。

         JavaBean 是一種元件，它在內部有介面或有與其相關的屬性，以便不同人在不同時間開發的 bean 可以詢問和整合。可以構建一個 bean，而在以後構造時將其與其它 bean 繫結。這種過程提供了先構建，然後重複使用的方法，這就是元件的概念。可以將這種單一應用程式部署成獨立程式、ActiveX 元件或在瀏覽器中。

        JavaBean 因其外部介面（即屬性介面）而與純物件不同。這種介面允許工具讀取元件要執行的功能，將其與其它 bean 掛鉤，以及將其插入其它環境。JavaBean 設計成對單一程序而言是本地的，它們在執行時通常可視。這種可視元件可能是按鈕、列表框、圖形或圖表 - 但這不是必需的。


        可執行元件
        Server Bean 或 EJB 是部署在伺服器上的可執行元件或商業物件。有一個協議允許對其進行遠端訪問或在特定伺服器上安裝或部署它們。有一系列機制允許它們將服務安全性、事務行為、併發性（由多個客戶機同時訪問的能力）和永續性（其狀態可以儲存多久）的主要方面授權給 EJB 伺服器上其所在的容器。當安裝在容器中時，它們獲得各自的行為，該行為提供不同質量的服務，因此，選擇正確的 EJB 伺服器至關重要。這正是 IBM WebSphere 企業版的優勢所在。

        EJB 是設計成執行在伺服器上，並由客戶機呼叫的非可視遠端物件。可通過多個非可視 JavaBean 構建 EJB。它們有一個部署描述符，其目的與 JavaBean 屬性相同：它是以後可由工具讀取的 bean 的描述。EJB 還獨立於平臺，一旦編寫好，還可以在任何支援 Java 的平臺（包括客戶機和伺服器）上使用。

        因為 EJB 由諸如 IBM VisualAge for Java 這樣的工具集生成，所以，它是基於伺服器的物件，並用於遠端呼叫。它們安裝在 EJB 伺服器上，並象呼叫其它 CORBA 遠端物件那樣獲得進行呼叫的遠端介面。

         ActiveX 物件
        可以將 JavaBean 部署成 ActiveX 物件，雖然 EJB 的代理也可以這樣做，但是，因為 ActiveX 執行在桌面上，所以，EJB 本身不能成為 ActiveX 物件。要在與平臺相關的、僅 Windows 平臺上做到這一點，開發人員可以將 JavaBean 變換成 ActiveX 元件。

        好處
        EJB 的主要好處在於：構建 bean時，bean開發人員可以規定需要什麼型別的行為，而不必規定如何去做。開發分為兩部分：程式設計師開發 bean，然後驗證：它可與構建工具一起工作，幷包括標識所需服務質量行為種類的部署描述符。下一步，另一個程式設計師可以採用這個 bean，並使用讀取 EJB 部署描述符的部署工具，然後將該 bean 安裝到 Enterprise java Server 上的容器中。在第二步中，部署工具採取一些操作 - 這可能意味著生成如狀態儲存程式碼，放入事務掛鉤，或執行安全性檢查這樣的程式碼。所有這些操作由部署工具生成，bean 開發人員和部署人員可以是不同的人。


        可以通過使用部署工具，將任何獨立於平臺的 JavaBean 改寫成具有可靠服務質量、特定於平臺的 EJB，以滿足現有商業系統和應用程式的特定需求。這就是 EJB 伺服器對整合系統、網路和體系結構如此重要的原因所在。

       EJB 與 IBM WebSphere 企業版

        在 IBM WebSphere 企業版中使用時，可以將 EJB 配置成被管理的商業物件。接受它們授權服務的容器是其安裝到的容器。將 EJB 的永續性部分對映在資料或狀態物件中。EJB 伺服器為 EJB 提供不同的服務質量，選擇正確的 EJB 伺服器可能對滿足完整的商業需求至關重要。“元件代理”功能極其健壯，該功能提供如負載均衡和支援伺服器組中多臺機器的高階功能。它還有大大超出 Enterprise Java Server (EJS) 規範所倡導的系統管理功能。因此，按照基本標準編寫的 JavaBean 或 EJB 可以執行在使用“元件代理”功能的 WebSphere 企業版上，並獲得那些所有的附加功能。

        EJB 伺服器還提供獨特的特性和服務質量，而且不完全相同。IBM“元件代理”有一些強大特性 - 例如，可伸縮性，它允許開發人員將 EJB 部署到從小型系統到大型網路的不同型別伺服器。開發人員可以從小處入手，例如，在一個部門中，首先在 LAN 的 Java 伺服器上部署，一旦準備好，就知道可以將在那裡建立的 JavaBean 和 EJB 部署到全球網路。然後，開發人員可以測試並熟悉這些 bean，試執行，製作樣本等等。滿意之後，開發人員可以通過將其移至高效能伺服器，來大幅度擴大其規模。JavaBean 和 EJB 不受任何計算機體系結構邊界的限制。它們用 Java 編寫，可以執行在任何具有 Java 虛擬機器的系統上，並可以使用任何 Enterprise Java Server (EJS) 來部署物件。因此，開發人員現在可以在方便的系統上構建，以後在方便的系統上部署，而不必是同一臺或同樣型別的機器。

        IBM WebSphere 企業版支援將商業物件部署到多臺伺服器。EJB 作為商業物件整合到“元件代理”功能，並作為任何其它商業物件處理。因此，EJB 可以連線到所選的後端系統，並執行任何所需操作，以滿足其商業需求。這就成為“元件代理”為 EJB 提供的基礎設施。通過將“元件代理”用作 EJB 伺服器，開發人員將能夠繼續使用當前舊有系統，並將其與電子商務介面一起提供。

        為使 EJB 能在 WebSphere“元件代理”環境中工作，可以使用“元件代理”部署工具將其安裝在一臺或多臺伺服器上，然後將其新增到命名伺服器，以便可以全域性查詢到它。任何可以訪問公共命名伺服器的人都可以找到它，找到其宿主，並可以在宿主上執行方法，同時建立 EJB。這就是“代理元件”要做的事。

示例

        讓我們舉一個在 Web 購物站點上可以看到的電子購物車的例子。使用者的購物車是一個 JavaBean。使用者將貨架上的商品放入購物車，這些商品本身是 JavaBean。它們全部可視，並且面向使用者。結帳時，將使用者購物車中的商品傳送到伺服器上的 EJB，該 EJB 執行一些必要的操作，如檢查信用卡授權和可用額度，生成封條，或生成給發貨部門的有關提什麼貨和發貨地點的特殊指示 - 這就是商業程式已在進行的活動。


結束語

        Bean 的全部意義不只是其現有能力，更在於其可以為商業提供的有競爭力的潛在能力。IT 設計師和應用開發人員現在可以將精力完全集中在商業邏輯，而將如事務、永續性和安全性的底層工作留給伺服器。WebSphere 的“元件代理”功能將提供所有這些（還有後端訪問）和物件事務管理器。