摘要
JBoss是一個免費的開放的J2EE實作。它的架構是基于高标準的子產品化和插入式設計。JBoss使用工業标準的JMX來管理， JBoss元件和為EJB提供服務。基于我們以前的開發經驗，我們發現了不同的J2EE應用伺服器間的存在着巨大的性能和可擴充性差異。 我們相信架構的設計是決定類似于性能和可擴充性等品質名額的重要因素。 分析和展現JBoss架構模型有助于我們了解其内部行為并幫助我們建立一個精确的最終性能模型。 在這個項目中，我們分析JBoss應用伺服器架構的四個特殊部分，JBoss EJB 容器、JBossNS、JBossTX以及JBossCMP， 逆轉工程工具能使我們通過源代碼來分解元件/子系統。無論是三個JBoss子系統的概念模型或實際模型都将被我們用來讨論JBoss 架構子產品設計風格。
Table of Content
介紹
1.1 JBoss是什麼
1.2 動機
1.3 方法
1.4 組織
JBoss伺服器架構一覽
2.1 JMX - 層次
2.2 JBoss 主要子產品
2.3 它是如何工作的?
架構模型概念
3.1 容器的概念性架構模型 - 插入式
3.1.1 主要的元件和接口
3.1.2 依賴性
3. 2 JBoss 命名服務概念模型
3.2.1 主要JNDI API
3.2.2 主要元件和接口
3.2.3 依賴性
3. 3 JBossCMP概念模型
3.3.1 主要元件和接口
3.3.2 依賴性
3. 4 JBossTx概念模型
3.4.1 主要元件和接口
3.4.2 依賴性
實際架構模型
4.1 容器實際模型
4.1.1 獲得綜合實際模型的方法
4.1.2 非正規元件和依賴
4.1.3 實體Bean容器的示例和它的執行方法調用的插件
4.2 JBoss命名服務概念模型
4.2.1 特殊元件和互相關系
4.2.2 用戶端獲得EJB 本地對象的例子
4.3 JBossCMP概念模型
4.3.1 特殊元件和聯系
4.4 JBoss 交易管理實體模型
4.4.1 特殊元件和關聯
JBoss 架構的可擴充性
結論
參考
資料字典
附錄
圖示清單
- Figure 1-1 JBoss總體概念模型
- Figure 2-1 JMX層次模型
- Figure 3-1 容器概念架構模型
- Figure 3-2 攔截器調用'Pipe'
- Figure 3-3 JBoss命名服務概念模型 Services Conceptual Model
- Figure 3-4 JBoss CMP服務概念模型
- Figure 3-5 JBossTx概念架構模型
- Figure 4-1 容器互相依賴圖
- Figure 4-2 JBoss命名服務概念模型
- Figure 4-3 方法調用消息圖
- Figure 4-4 實體Bean容器概念架構模型
- Figure 4-5 用戶端和EJB容器的互動圖
- Figure 4-6 JBossCMP依賴與繼承圖and Inherency Diagram
- Figure 4-7 JBossCMP概念模型
- Figure 4-8 JBossTx依賴與繼承圖
- Figure Appendix-1 StatelessSessionContainer概念架構模型 Concrete Architectual Model
- Figure Appendix-2 StatefulSessionContainer概念架構模型 Concrete Architectual Model
- Figure Appendix-3 A COTS EJB容器概念架構模型 Conceptual Architecture Model
1. 介紹
1.1 JBoss是什麼?
JBoss是免費的，開放源代碼J2EE的實作，它通過LGPL許可證進行釋出。它提供了基本的EJB容器以及EJB(好像應該是J2EE)服務， 例如：資料庫通路JDBC、交易(JTA/JTS)、消息機制(JTS)、命名機制(JNDI)和管理支援(JMX)。目前的JBoss釋出版2.2.4實作了EJB 1.1和部分EJB 2.0的标準、JMS 1.0.1、Servlet 2.2、JSP 1.1、JMX 1.0、JNDI 1.0、JDBC 1.2和2.0擴充(支援連接配接池 (Connection Polling))、JavaMail/JAF、JTA 1.0和JAAS 1.0标準，JBoss是100%純Java實作能運作于任何平台。
1.2 動機
這個項目的動機是我們想分析一下中間件基礎系統的性能。基于我們以前的開發經驗， 我們知道不同J2EE應用伺服器在性能和可擴充性方面有着極大的差異，并且相信架構的設計是決定類似于性能和可擴充性等品質 名額的重要因素，我們想通過分析這個系統來了解架構設計究竟對于性能和可擴充性具有着怎樣的影響。無論概念性模型的局限性 或實際模型中對于系統運作期行為的Reflect(反射機制)應用，他們還是能提供給我們一個對于整個系統的全面架構的了解的視點 和符合基本境況的分析模型的建構的前提。
1.3 方法論
大型軟體系統的架構分析可以分為兩個層面：概念性架構和實際架構。概念性架構 通過将子系統的"捆綁式"分析和子系統間的分析描述了這個系統的架構。每一個子系統具有清晰的有意義的方法和他們包含了整個 系統的特殊的架構風格。實際架構和概念性架構比起來具有較少的層次關系。它表述了實際的程式設計規劃/模型的實際展現，它和想象 的概念性架構有很多不同。在這個項目中，我們将JBoss的概念性架構和實際架構進行了分割。想象的概念性架構模型通過參考 資料來分割和獲得，我們自己的經驗來自配置應用系統和JBoss的線上論壇。眼下，我們先關心一下每個元件在子產品層面上的 功能性，他們彼此不相關。實際架構模型是綜合的。我們使用逆轉工程工具Together 5.5以便于将源代碼翻轉成為類(class)圖和 序列(sequence)圖并使他們在一個子系統模型中綜合。Together 5.5支援應用設計，實施，配置和JBoss的逆轉工程。它可以 通過Java檔案和class檔案來獲得類圖。更深一層，我們通過使用Together選擇相應的特殊的方法來獲得序列圖。 有兩個工具可以幫助我們來了解元件行為，最終實際模型和概念性模型的比較。在實際模型中以外的子產品、元件和其它部分也 将被讨論。
1.4 組織
這份報告将按照以下次序進行組織：第二部分将介紹JBoss架構的整體設計和主要的元件。 第三部分讨論JBoss子系統的概念性模型，即：容器架構和它的插件。JBoss命名服務(JNDI)，JBoss容器持久性管理(CMP)和JBoss 交易服務。第四部分，我們将挖掘JBoss子系統的實際模型和被提及的元件間的相應穩固的關系。第五部分，我們來評價一下JBoss 的架構風格和在性能、可更改性、可擴充性等一系列品質名額上的表現。在第六部分我們将讨論我們将來的工作和提出我們報告的 最終結論。
2. 2. JBoss 伺服器架構概述
JBoss的構架和其他J2EE應用伺服器的構架有着巨大的不同。JBoss的子產品架構是建立在JMX底層上的， 下圖展現了JBoss主要元件和JMX的聯系。
Figure 1-1 Overall JBoss Conceptual Model
2.1 JMX -
層次
JMX是一個可複用架構，它為遠端(Remote)和本地(Local)管理工具擴充了應用。它的架構是層式架構。 他們是實作層(instrumentation layer)、代理層(agent layer)和釋出層(distribution layer)。其中， 釋出層還在等待未來的标準化。簡要的表述是，使用者使用管理Bean，MBean來提供獲得相應資源的實作方法。 實作層實作相關的特性資源并将它釋出于JMX相關應用中，它的代理層控制和釋出相應的注冊在MBeanServer代理上的管理資源。.
Figure 2-1 JMX層次模型
2.2 JBoss主要子產品
主要的JBoss子產品是在MeanServer上的可管理MBean。 [2]. 1.JBoss EJB容器是JBoss伺服器的核心實作。它有兩個特性，第一是在運作期産生EJB 對象的Stub和Skeleton類，第二是支援熱部署。
2.JBossNS是JBoss命名服務用來定位對象和資源。它實作了JNDI J2EE規範.
3.JBossTX 是由JTA/JTS支援的交易管理控制.
4.部署服務支援EJB(jar)、Web應用文檔(war)和企業級應用文檔(ears)的部署。它會時刻關心J2EE應用的URL情況，一旦它們被改變或出現的時候将自動部署。
5.JBossMQ使Java 消息規範(JMS)的實作。
6.JBossSX支援基于JAAS的或不支援JAAS機制的安全實作。
7.JBossCX實作了部分JCA的功能。JCA制訂了J2EE應用元件如何通路基于連接配接的資源。
8.Web伺服器支援Web容器和Servlet引擎。JBoss 2.4.x版本支援Tomcat 4.0.1，Tomcat 3.23和Jetty 3.x服務.
2.3 他們是如何工作的?
當JBoss被啟動，它的第一步是建立一個MBean伺服器的執行個體。一個基于管理機制的MBean元件通過在Mean Server中的注冊而被 插入JBoss中。JBoss實作了動态類裝載 M-Let 服務，它是代理服務，M-let允許MBean被注冊到MBean伺服器上。通過基于文本檔案 的配置檔案中的配置，相應MBean将被裝載。
JMX MBean伺服器實際上本身并沒有實作很多功能。它的工作類似于一個MBean中聯系的微核聚合元件，通過Mbeans取代JMX MBean 服務起來提供相應的功能，換而言之，真正起作用的是MBean。JBoss的整體架構并不是依循Garlan和Shaw檔案中的架構風格嚴格分 類的，代替它的是一個元件插入式的架構。MBean的接口是一個連接配接器。
在這封報告的餘下部分，我們選擇了JBoss架構中的JBoss EJB容器、JBossNS、JBossTX和JBossCMP子系統來加以學習。 雖然JBossCMP，實體Bean的容器管理持久層是容器架構的一部分，但我們還是将它分開讨論，因為他們有自己的構架。 我們隻在這個項目中介紹三個部分是因為它們是我們關心的JBoss應用伺服器的性能問題的關鍵點。 在這個項目中我們使用的方法學可以擴充到更多有用的子系統的學習中去。
3. 概念架構模型
3.1 容器的概念性架構模型 - 插入式
JBoss EJB容器是JBoss伺服器的核心實作。圖3-1展示了EJB容器的概念性模型。我們發現JBoss容器的架構并 不是一個嚴格意義上的層，決大多數的獨立件是雙向管理，容器依賴于更多的低層次元件。實際上，容器和它的插件、 執行個體池(instance pool)、執行個體緩存(instance cache)、攔截器、實體持久管理、有狀态會話持久管理，都是基于插入式架構來 為特定的EJB提供相應的EJB服務。
Figure 3-1 Container Conceptual Architecture Model
3.1.1 主要的元件和接口
用戶端不可以直接通路EJB執行個體而是要通過Home(EJBHome)和容器提供的遠端對象 (EJB Object) 接口。Container類是依循客戶 端的調用來提供Bean執行個體并實作操作。Container類的責任來實作插件的互動，為插件提供資訊來實作操作并管理Bean的生命周期。 Container類有四個子類(四種Bean的類型)，分别是：StatelessSessionContainer、 StatefulSessionContrainer、EntityContainer和MessageDrivenContainer。它們是由 ContainerFactory通過相應的Bean類型在部署期中被建立和初始化的。 ContainerFactory被用來建立EJB容器和在容器中部署相應的EJB。ContainerFactory 被作為一個MBean實作。這意味着JBoss服務 器啟動的時候其相應的服務也被啟動。它會對EJB-jar的XML定義檔案獲得相應的URL。ContainerFactory使用EJB-jar XML中的元數 據産生一個容器執行個體并使他們處于可被調用狀态，在部署期中，ContainerFactory的功能包括：
- 通過在部署描述檔案中的EJB類型來建立Container類的子類，即四個子類中的一個。
- 通過jboss.xml和standardjboss.html檔案建立容器屬性。
- 通過定義在standardjboss.html檔案中的内容建立和添加容器攔截器。
- 使用應用對象來聯系相應的容器。
ContainerInvoker 是一個Java RMI 伺服器對象。正如他名字所表述的，ContainerInvoker 通過用戶端的請求 (request)方法來調用相應的容器。可以看作用戶端請求和容器間的接口，它利用RMI來獲得自身的有效調用，無論這個調用來自 其他JVM上的遠端客戶或是來自同一JVM上同一EJB應用的其他Bean。ContainerInvoker工作在通訊層面上，通過特殊協定進行通訊。 如果想在JBoss伺服器上實作新的協定，第一是需要提供一個該協定的ContainerInvoker實作。JBoss 通訊層回複是通過Sun RMI的JRMP，ContainerInvoker的RMI版本是JRMContainerInvoker。一個ContainerInvoker在 EJB中實作分割相應的通訊協定，這種設計增加了系統的可更改性。JBoss EJB容器中所使用的協定可以在相應的伺服器配置檔案中定義。
EJB對象執行個體被放入InstancePool中以減少在運作期中建立它們的開銷。在Instance Pool中的執行個體不能和其他的EJB對象交流， 它們由Instance Pool來管理。
有狀态會話Bean和實體Bean執行個體将被緩存化，在生命周期中它們擁有相應的狀态。一個緩存執行個體通過執行個體池獲得， 他們和特殊的對象相關聯并具有相應的标示。其狀态由InstanceCache控制，例如在緩存中的執行個體狀态和第二方存儲媒體中的對象 的同步。
EntityPersistenceManager 對于實體Bean的持久性起作用。
StatefulSessionPersistenceManager 對于有狀态會話Bean的持久性起作用。
攔截器通過容器獲得相應的方法調用。在容器配置檔案 standardjboss.html中，被方法調用的攔截器必須被依次定義在 其中。圖3-2展示了通過攔截器的方法調用的邏輯執行順序。
圖3-2 通過攔截器管道的方法調用
這個設計遵循了David Garlan和Mary Shaw的"管道和過濾"("pipe and filter")架構定義，在此定義的過濾原型是一個元件， 其包括了資料流和類似于輸出總是發生在輸入流被完全讀取之後等方面的計算輸出的增強，攔截器是過濾器而方法調用是連續攔截 器中的連接配接器。攔截器是整個構架中的優勢部分：
- 它能夠知道每一個階段管道的行為。
- 它通過子產品來支援重用和擴充，不同攔截器之間具有明顯的一個功能性差別。添加一個新的攔截器，第一是需要實作攔截 器的接口并将他定義到相應的容器配置檔案中
- 支援同步.
- 具有快速的容錯語義表述.如果在攔截器進行中産生錯誤或違例,就會出現相應表述。
3.1.2 依賴性
本質上, InstancePool, InstanceCache, EntityPersistenceManager, StatefulSessionPersistenceManager, 都是容器插件的接口。 容器的插件是這些接口的實作對象的集合。JBoss容器并不做太多的複雜的工作，它隻是提供了一個聯系不同插件的架構。
- 容器向攔截器發出方法調用資訊。
- 攔截器依賴于InstancePool來通路會話Bean執行個體，或是依賴于InstanceCahce通路實體Bean執行個體
- 最好還是為了一個自由Bean時，InstanceCache會和InstancePool進行互動
- InstanceCache依賴于EntityPersistenceManager(或StatefulSessionPersistence Manager) 通過資料源進行執行個體狀态初始化。.
- 攔截器依賴于EntityPersistenceManager(或 StatefulSessionPersistenceManager)通過資料源進行執行個體狀态的 同步。
當執行用戶端請求時，容器的架構依賴于外部的其他的服務功能塊、命名服務、交易服務、安全服務和資源管理。舉個例子， 當用戶端請求一個交易資訊将更新資料庫内容，容器會通過命名服務獲得相應的資料源和資源管理提供的相應的資料源驅動。 整個交易過程在容器内進行，交易管理器和資料總管由交易服務進行控制。
不象傳統的分布式系統構架，EJB容器在部署描述檔案中聲明了外部屬性。雖然容器擔當的是和中繼資料資訊的通訊作用， 它在部署服務中顯示出的外在獨立性和其他的服務還是有點不同的。這意味着它的資訊在部署期時就被放入容器中了。
3. 2 JBoss命名服務的概念性模型
3.2.1 主要的JNDI API
JNDI提供了為數衆多的命名服務。主要的JNDI API是javax.naming.Name，javax.naming.Context以及 javax.namingInitialContext。根本上命名系統是一個對象的集合并且每個對象都有獨立的名字。Context是使用者端通路命名服務 的接口。InitalContext 實作了Context。JBoss 命名系統是JBoss JNDI的提供者。源代碼在org.jnp包中，就像我們在第二部分中 提到的一樣，JBoss 命名系統被實作成為MBean。圖3-2 展示了JBoss命名系統的概念性模型。
圖3-3 JBoss命名服務概念性模型
3.2.2 主要的元件和接口
Org.jnp.server包包含了命名服務的MBean，Main包裝了Main NamingServer并釋出它。NamingServer的工作是進行"命名-對象" 一對對的序列編排。
Org.inp.interface包繼承/實作了javax.naming.*接口，這是個J2EE規範。這個接口可以通過用戶端遠端通路。 它使得Main可以在Naming Server中和命名服務進行互動，NamingContext 實作了javax. naming.Context接口， 它是用戶端和JBoss命名服務之間的接口。
3.2.3 依賴
JBossNS沒有更多的外部依賴.
3.3 JBossCMP 概念性模型
3.3.1 主要元件和接口
JBossCMP通過擴充JAWS來支援記憶體中Java對象和關系型資料庫基本儲存之間的映射(是一個O/R Mapping的概念)。 JBossCMP包含了支援EJB 1.1容器持久性管理(CMP)模型的元件。在CMP的實體Bean模型中，EJB實體的持久性狀态的性能是由容器決定的。 容器通路資料庫是實體Bean的行為。圖3-4展示了JBoss CMP服務的概念性模型。
Figure 3-4 JBoss CMP Services Conceptual Model
EntityContainer 依賴EntityPersistenceManager接口為持久性管理的實體Bean。
CMPPersistenceManage實作了EntityPersistenceManager接口。就像我們前面提到的，容器管理了執行個體的狀态。EJB1.1CMP的語義有回調方法、 ejbLoad、ejbStore、ejbActivate、ejbPassivate、ejbRemove提供了執行個體狀态觀點的容器表述。實際上，正是CMPPesistenceManager在 做一項工作：底層的資料庫和緩存執行個體狀态的同步。舉個例子：當一個Bean的緩存資料被裝載，CMPPersistenceManager将會在Bean執行個體 中調用容器的回叫方法ejLoad。當緩存資料需要更新資料庫，ejbStore方法将被調用來準備相應的緩存資料，這樣CMPPersistenceManager 将關注于更新資料庫。
EntityPersistenceStore接口的實作關注的是具體的實體儲存細節。CMPPersistenceManager授權于EntityPersistenceStore進行實體 持久性内容的實際儲存。注意EntityPersistenceStore是一個接口，它留着持久層儲存實作的客戶化空間，e.g。基于檔案的儲存或數 據庫存儲。
3.3.2 依賴性
JBossCMP 并不是和JBossNS一樣被實作成為MBean服務。實際上， 它被包含在EJB容器包org.jboss.ejb中通過容器和其他的插件進行互動。表面上，JBossCMP是依賴于JbossNS來獲得相應的資料源 調用并在Bean執行個體中存放持久性資料。
3. 4 JBossTX 概念性模型
3.4.1 主要元件和接口
JBossTX 構架可以使用的是任何實作了JTA規範的交易管理。 在分布式交易中主要的參與者包括：:
| Figure 3-5 JBossTX 概念性架構模型 |
3.4.2 依賴
JBossTX架構被設計成為可以使用任何的實作了JTA javax.transaction. TransactionManager接口的交易管理， JBoss交易管理将被看作為一個MBean，并可通過RMI當作一個服務輸出其自身。
交易管理服務的基本需求是在JBoss伺服器服務管理啟動的時候通過JNDI命名目錄綁定它的實作。是以，JBossTX看上去是依賴于 JBossNS的。
4. 4.實際架構模型
實際架構模型是通過工程逆轉工具通過JBoss源代碼獲得的。我們選擇了TogetherSoft 公司的 Together 5.5。Together 5.5 是一個Case IDE工具，它可以通過源代碼或jar檔案來生成相應的類圖。它還支援跟蹤相應的類圖以建立 出相應的序列圖的方法，使用者可以選擇可視化界面。這裡是一個它如何工作的概述。
當開發者注意到在包中的一組檔案具有相同的功能性，我們發現源代碼包的層次性非常類似于概念性模型。我們将不同包中的源代碼依循 我們的概念性模型進行了相應的組重排，并将它們導入了Together 5.5。
實際架構模型和我們所期待對于概念模型的認識有着本質上的差別。一些元件和關聯的表現是相當特殊的，并且有一些不做任何表示。 這是因為實際模型和概念性模型比較起來更接近于運作期行為的實作觀念。在這個章節中，我們将讨論容器、命名服務、容器管理持久 性(CMP)服務和交易服務的實際模型。
4.1 容器實際模型
4.1.1 獲得綜合實際模型的方法
圖4-1 展示了容器和其插件的獨立的圖。我們從Together 5.5獲得的實際構架模型和我們腦中固有的對概念模型的認識有着很大的 差別，這是一個層構架模型，在頂層實作的是插入式實作元件，容器位于中間層，插入接口位于最底層。攔截器和持久性管理之間的 關系是不可見的，它是基于JBoss文檔的計算本能。我們找到它歸因于Together 5.5的關系型可視化的陷阱。在同一層面上的元件關聯 都被忽略，舉個例子，實體執行個體攔截器和實體實體。為了解決這個問題，我們使用下面的步驟：
-
1.重排容器的源代碼和它的插件接口，依據Bean類型來實作。将它們導入Together 5.5項目。
2.分析元件的依賴關系和固有聯系。
3.為關鍵元件的選擇關鍵方法，追蹤方法調用來生成消息視圖。
4.重複1，2，3步驟以合成容器架構的實際模型。
圖 4-1、4-2、4-3
| Figure 4-1 container dependecy diagram | Figure 4-2 container inherence diagram | Figure 4-3 method invocation message diagram |
4.1.2 非正規元件和依賴
在這裡我們隻讨論實體容器的構架模型。在附錄中我們展示了StatelessSessionContainer 和 StatefulSessionContainer 實際架構模型。
Figure 4-4 實體容器的實際構架模型
- 基于容器的動态代理設計
在EJB規範中，EJBHome實作了Bean的本地接口，EJBObject實作了Bean的 遠端接口。EJBObject 和EJB的客戶視圖進行互動。容器提供者的責任是産生javax.ejb.EJBHome和javax.ejb.EJBObject。JBoss EJB 容器的設計觀點是在這裡更本沒有EJBHome和 EJBObject的對象實作，這裡通過動态代理機制來獲得EJBHome和EJBObject的角色。 （JBoss是基于Dynamic Proxy機制而Auspic是基于自動代碼生成機制的。）動态代理機制是一個對象，它可以在運作期中實作特定的 一系列接口通過java反射機制來實作。
在部署期ContainerFactory建立和初始化相應的容器。Home對象是通過動态裝載機制使用JRMP ContainerInvoker來建立的，我們會在 下面的文章中讨論它。InvocationHandler被HomeProxy類所取代，現在他可以在部署描述檔案中定義并被作為一個特定的JNDI名稱綁定 在JNDI命名樹上。
代理器是可序列化的，這意味着它可以通過網絡被發送到遠端客戶那裡去。當一個用戶端通過JNDI尋找EJBHome，本地代理器執行個體被 序列化。在用戶端，本地代理器執行個體被反序列化。因為代理器實作了Bean的本地接口，它将可以被當作本地接口來捕獲和使用。
當用戶端利用本地對象引用reference來請求相應的EJBObject.EJBObject的動态代理會通過上面的代碼自動生成。InvocationHandler 會被某一個EJB對象代理器所取代，即，基于Bean的類型的StatefulSessionProxy，StatelessSessionProxy和EntityProxy來獲得。 本地代理的共同之處，EJB 對象代理也可以被序列化并通過網絡發送到遠端用戶端。
最後，用戶端獲得EJB對象的句柄，并使用它去調用在伺服器端部署的Bean的方法。本地和對象的動态代理通過用戶端的 InvocationHander調用。
- EJB 代理器
StatefulSessionProxy，StatelessSessionProxy和EntityProxy實作了 InvocationHandler接口。就像他們名稱所指出的一樣，在容器中他們的工作類似于一個代理器。他們首先着力處理用戶端請求的 方法。如果方法是由部署在伺服器端的遠端方法實作所調用的話，調用将被轉換為RemoteMethodInvocation對象，接着将其包裝成為 MarsharlledObject并通過RMI傳遞給JRMPContainerInvoker。
- JRMPContainerInvoker
回到3.1.1章節，ContainerInvoker是一個容器傳輸句柄, JRMPContainerInvoker實作了RMI/JRMP傳輸協定。它通過接受實作ContainerRemote接口的遠端方法的調用來輸出其自身， 實作ContainerRemote接口繼承了java.rmi.Remote.JRMPContainerInvoker，通過執行invoke()和invokeHome()兩個方法來獲得優化。 第一個使用MarshalledObject參數(值調用)和其他的使用方法反射類型的參數(Reference調用)，如果調用器來自于容器内的同一VM， 調用器會選擇Reference調用而忽視MarshalledObject序列化，否則，方法調用資訊會被MarshalledObject通過最初的EJB方法調用 (例如安全和交易内容)的屬性進行解包。接着，它被轉換成文MethodInvocation并通過容器傳遞。
- EntityContainer 和它的攔截器
在部署期中容器類型是通過Bean類型而被指定。 ContainerFactory建立并初始化它。此外，對于每一個Bean類型，standardjboss.xml都會定義使用這個容器和他們調用次序的 攔截器。攔截器都可以被建立和初始化，每一個容器維護着一組攔截器。它促使了針對于序列中第一個攔截器方法調用， 這是通過invoke()方法實作的。攔截器首先處理相應的調用并通過調用自身的invoke()方法來觸發下一個攔截器，最後的一個攔截器 是ContainerInterceptor，它的工作是将方法調用委托給Bean執行個體。
- 依賴性
我們重新排列了實際構架模型以便于更容易和概念性模型進行比較。象我們在3.1.1部分介紹 的InstancePool、InstanceCache、Intercptor和PersistenceManager都是繼承于ContainerPlugin的接口。在實際模型中，容器的插件 層被實際實作元件所替代。這些元件實作了插件的接口，是以EntityContainer在插件接口層面的控制流被目前委托到實際實作元件。 插件接口中的關系，比如InstanceCache和InstancePool在目前的實際實作元件中的控制流,，EntityInstance 和EntityInstancePool。
一個實體Bean的持久性管理有兩種類型，Bean管理持久性(BMP)和容器管理持久性(CMP)。作為BMP的程式員你需要非常關注Bean緩存狀态 和底層資料庫之間的同步。使用CMP，容器會産生相應的代碼來處理這種事情，這将使程式員變得輕松點。它們之間性能的影響不屬于 這篇文章讨論的内容，我們會在以後讨論JBossCMP的架構。
每一個攔截器都實作了攔截器接口，他們都是容器的插件。和實體Bean一樣， EntityInstanceInterceptor，EntityLockInterceptor 和EntitySynchronizationInterceptor使用BeanLockManager進行Bean執行個體的目前控制。
每一個ContainerPlugin的實作都和EntityContainer相關，它将知道哪個容器正在被setContainer()和getContainer()方法調用。
ContainerInvoker和Container交流是必需的，舉個例子一個會話Bean可以調用實體Bean的方法。ContainerInvoker是容器的一個接口， 它使用Containernvoker.JRMPContainerInvoker和ContainerInvokerContainer有相關性，ContainerInvokerContainer是實際上的 EntityContainer。
MethodInvocation通過網絡在所有的元件中通行。所有的元件都和它有關聯.。MethodInvocation依賴于EnterpriseContext， EnterpriseContext并且和生命期執行個體中的Bean執行個體相關聯。在實體Bean模型中，實體Bean是一個Java對象和底層資料庫的表現。 CacheKey是對于PrimaryKey元件的封裝，EntityEnterpriseContext依賴于CacheKey去獲得實體對象而EntityProxy通過CacheKey作為 一個實體容器的參數。
- 總結
和概念性模型相比，一些特殊的元件和它們之間的關系展示了JBoss EJB容器的特殊之處。 動态代理機制的設計和預編譯容器設計之間有着本質上的不同，預編譯技術使用在很多被測試過的EJB容器實作上 (例如：WebLogic等)。附錄-3展示了EJB容器測試裝置的概念性結構模型。JBoss文檔中宣稱，基于EJB容器的動态代理設計使容器 設計變得容易。它會對品質屬性有影響，例如不能在實際模型中直接觀測到的性能問題。它必須經過嚴格的品質測試，這将是我們 将來的工作。
EJB容器的插入式架構使得EJB容器變得靈活性和擴充性更好。如果需要改變隻需要寫一個特定結構的新的實作即可。
4.1.3 實體Bean容器的示例和它的執行方法調用的插件
圖4-5 展示了用戶端和EJB容器/伺服器互動 的情況.我們分析EJB容器的實際模型可以幫助我們了解容器的行為。
圖4-5 用戶端和EJB容器的互動示意
-
1.在部署期，EJB本地對象将被捆綁在JBoss命名服務的JNDI樹上，并被配置設定一個JNDI名稱。
2.用戶端第一次接觸JNDI命名服務以獲得EJB本地對象。
3.用戶端通過使用EJB 本地對象的Reference來向EJB對象送出請求。
4.EJB 本地對象建立(或尋找)一個EJB對象并将它的reference 傳回給用戶端。
5.用戶端獲得EJB 對象的reference，并在遠端接口中調用相應方法。
6.容器攔截下方法的調用并将其委派給Bean執行個體，相應的執行個體将通過遠端接口向用戶端傳回結果值。
7.LogInterceptor紀錄下調用的日志。
8.TxInterceptor通過XML部署描述，依循調用方法來決定如何進行管理交易。
9.SecuirtyInterceptor通過XML部署描述來驗證調用是否可以執行。
10.容器在他調用Bean的商務方法的時候必須有一個執行個體，EntityInstanceInterceptor通過給予一個主鍵來調用InstanceCache以此來獲得相應的實體Bean執行個體。
11.如果緩存中沒有和所提供的主鍵相一緻的執行個體，它會通知InstancePool獲得一個空閑的執行個體來和主鍵相關聯。
12.InstanceCache 現在要調用PersistenceManager，它通過調用ejbActivate()方法來獲得已被激活的執行個體。
13.EntitySynchronizationInterceptor被EntityInstanceInterceptor調用，用來處理 執行個體和資料庫的同步.它有幾個選項，每一個選項定義了一個攔截器，loadEntity()方法将在EntityPersistanceManager中 被調用。
14.ContainerInterceptor是在整個鍊中最後一個攔截器，它是通過容器本身添加的而不是容器工廠，業務方法的調用現在已經被委托給了EJB執行個體。
15.執行個體實作了一些工作并傳回了結果。
16.EntitySynchronizationInterceptor選擇了将目前的執行個體狀态儲存進資料庫，PersistenceManager的storeEntity()方法将被調用。
17.執行個體将被傳回入緩存。當交易在運作時被調用，執行個體會和這個交易鎖定以便于在這個交易期間沒有别的交易可以使用這個執行個體。
18.TxInteceptor依循交易設定處理相應的方法并針對目前的交易選擇送出或是復原。
19.容器激活傳回機制向用戶端傳回結果。
4.2 JBoss 命名服務實際模型
4.2.1 特殊元件和互相關系
圖 4-2 是JBoss命名服務實際架構模型。作為容器的實際模型， 這裡有着特殊元件群組件間的依賴關系，類似于NamingService MBean以及它和org.jnp子系統的關聯，在下面的部分， 我們會展示其中的細節。
圖4-2 JBoss 命名服務實際模型
Org.jboss.naming.NamingService被作為一個MBean實作。它提供了JNDI命名服務，這個NamingService建立了Main MBean并且 管理他們的狀态。當一個NamingService啟動，它将初始化并啟動Main MBean。NamingService将相應的功能都為委托給了Main MBean。 複制MBean符合我們的概念性模型，可是，在表象後面的是JBoss中的JNDI命名服務被實作成了一個獨立的應用。NamingService MBean 通過建立一個新的執行個體插入Main MBean。這種設計的好處是如果JNDI VM 和JBoss Server VM一緻的話，JNDI操作将會通過socket連接配接 以減少相應的開銷。
4.2.2 用戶端獲得EJB 本地對象的例子
為了更好的了解JBoss命名服務架構，我們給出了一個例子并追蹤整個調用過程。舉個例子，當一個用戶端想去調用一個Bean的方法， 它不得不先定位Bean Home，因為它是為用戶端需求而建立Bean執行個體的句柄。本地對象的JNDI名字是在部署期中被定義在部署描述檔案 中的。用戶端在運作期中通過使用JNDI名字通路相應的命名服務來獲得對象。
-
1.當JBoss伺服器啟動，NamingService MBean将被注冊并等候調用。
2.NamingService初始化Main MBean并使得命名服務通過偵聽相應的Socket端口準備被調用。
3.一個用戶端提供命名服務的環境配置。
4.一個用戶端建立一個新的IntialContext，它是NamingContextFactory用來建立新的NamingContext的促發器。
5.一個用戶端通過提供JNDI名字并在JNDI命名服務中定位相應的本地對象。NamingContext連接配接相應的命名伺服器來進行相應的定位。
4.3 JBossCMP 實際模型
| 圖4-6展示了我們通過Together 5.5 獲得得JBossCMP的關聯和固有的内容。JBossCMP實際模型非常類似我們的概念性模型. 這個特殊的子系統是JWAS。 | 圖 4-6 JBossCMP依賴和關聯圖 |
4.3.1 特殊元件和聯系
Org.jboss.ejb.plugin.jwas 包包括了 JBoss中CMP實體Bean O/R Mapping工具的預設實作。它使用JDBC資料 庫作為它的持久層存儲。
EntityPersistenceStore的預設實作是JAWSPersistenceManager。
CMP實體Bean持久層存儲的客戶化實作了EntityPersistenceStore的接口方法。JAWSPersistenceManage通過調用它的子類中的 execute()方法來實作，舉個例子，JDBCActivateEntityCommand通過它的JMPActivateEntityCommand的接口方法， JAWSPersistenceManager基于資料庫的存儲.如果有其他的存儲媒體，它需要提供一個實作了JMPXXXCommand接口的包。
圖4-7 JBossCMP 實際模型
表 4-1 顯示了EntityPersistenceStore的接口方法，在org.jboss.ejb.plugin.jwas包中的接口被實作了實作了 EntityPersistenceStore的JAWSPersistenceManager使用，以及在那些接口中是比較低層次的實作。
| EntityPersistenceStore中的方法 | 接口名稱 | 實作名稱 | 方法 |
| createEntity | JMPCreateEntityCommand | JDBCCreateEntityCommand | 當實體建立的時候調用 |
| findEntity | JMPFindEntityCommand | JDBCFindEntityCommand | 當單個實體被發現時調用 |
| findEntities | JMPFindEntitiesCommand | JDBCFindEntitiesCommand | 當實體集合被發現時調用 |
| activateEntity | JMPActivateEntityCommand | JDBCActivateEntityCommand | 當實體被激活時調用 |
| loadEntity | JMPLoadEntityCommand | JDBCLaodEntityCommand | 當實體被底層存儲裝載時調用 |
| loadEntities | JMPLoadEntitesCommand | JDBCLoadEntitesCommand | 當一組實體被底層存儲預裝載時調用 |
| storeEntity | JMPStoreEntityCommand | JDBCStoreEntityCommand | 當實體需要被寫入底層存儲時調用 |
| passivateEntity | JMPPassivateEntityCommand | JDBCPassivateEntityCommand | 當實體被鈍化時被調用 |
| removeEntity | JMPRemoveEntityCommand | JDBCRemoveEntityCommand | 當實體從底層存儲中被移去時調用 |
4.4 JBoss 交易管理實體模型
| 圖4-8 展示了我們從Together 5.5 中獲得的JBossTx的關聯和固有資訊圖。到目前為止，我們并沒有從UML圖中驚奇的發現 一些特殊的元件和關聯，我們再次排列關鍵元件和關系的關聯以及集合以便我們從中得出綜合的實際模型。 | Figure 4-8 JBossTx dependency and inherency diagram |
4.4.1 特殊元件和關聯
我們關注JBossTx的概念性模型，JBossTx被實作成為MBean通過RMI被釋出。 通過 RMI/JRMP的交易内容傳播被設計成為兩個接口，TransactionPropagationContextImpoter接口，它的實作被用來向交易管理 期導入交易傳播内容，TransactionPropagationContext Factory接口，它的實作被用來從用戶端獲得交易傳播内容。當交易管理 器被啟動，它的第一個工作是在熟悉的JNDI位置上綁定TransactionManager， TransactionPropagationContext Impoter和 TransactionPropagationContextFactory。
TxManager實作了javax.transaction.TransactionManager和其上層的兩個接口。它由 TransactionManagerService進行管理。 TxManager依靠TransactionImpl來實作交易操作，類似于聲明交易的開始、送出、復原方法。有趣的是，TransactionImpl隻是一個 輕量級的前置TxCapsule。TxCapsule是通過TransactionImp的方法調用而被控制的。TxCapsule 控制着關于一個交易的所有資訊。 在這個類中實作了回調和同步，它通過XidImpl來分辨不同交易。
在會話Bean中通過管理JTA交易Bean調用概念性模型。在這個模型中，javax.transaction.UserTransaction是必需的。 JBossTx由一個子系統實作了UserTransaction 接口，位于org. jboss.tm.usertx包中。Usertx 被分割成為兩個子系統， 用戶端和伺服器端，他們通過接口進行互動。
這是一個非常純的層構架。ClientUserTransaction是用戶端UserTransaction的實作。 它将通過UserTransactionSession接口委托所有的UserTransaction去調用相應的伺服器。UserTransactionSessionImpl在伺服器端 實作了UserTransactionSession接口。這是以便作為不在同一個地點的交易管理的VM的遠端用戶端。當用戶端執行的是在同一伺服器上 的VM，ServerVMClientUserTransaction是一個用戶端的Usertransaction實作，它将所有的UserTransaction調用委托給了伺服器端 的TransactionManager。和JBoss中的大多數服務一樣，UserTransaction的被作為一個MBean來實作和管理。它通過JNDI名稱 UserTranaction被綁定在JNDI的相應位置上。
圖4-9 JBossTx 實際模型
5.JBoss 架構的可擴充性
通過上面對于JBoss架構的讨論，我們可以看出在JBoss架構設計中的兩個重要的特性， 第一是使用JMX作為一個軟體總線垂直的貫穿其所有的服務，通過将新的服務元件遵循JMX規範挂接上"總線"，使得系統擴充現有的服務 變得容易。可插入式架構被廣泛的運用于服務的實作。開發者可以選擇他們需要的服務并編寫他們所需要的相應實作，通過定義在 部署描述檔案中，讓JBoss伺服器知道。另一個是容器被設計成為動态代理機制，這樣使容器的實作變得簡單和使開發者避免費勁的 将jar檔案進行預編譯以獲得stub和skeleton代碼。但是這樣做潛在的問題是性能和可測性，因為我們知道java反射機制會引起性能 的損失。JBoss中存在着相應的優化方案并且在将來的研究中我們會論述該優化方法在什麼時候工作并且是如何工作的。
6. 結論
在這篇文章中，我們讨論了JBoss概念性架構模型和實際架構模型。我們通過使用逆工程工具和人工追蹤源代碼的方法建立了一個綜合 的實際模型，我們發現實際模型和基于文檔的概念性模型有着較大的差異。這就是為什麼實際模型是處于實作層面的東西它更接近于 "真實的故事"。實際模型展示了JBoss應用伺服器的獨特的、特殊的設計。我們嘗試着将這個方法提供給J2EE産品的檢測中去。不幸的 是，源代碼并不都是有效的而且逆工程結果也不完全有效的，這将導緻誤導，我們隻能做到JBoss架構模型和概念性模型的比較。
雖然，在這篇文章中我們分析JBoss架構的方法非常的令人興奮，但這種接觸是有限的。我們依然沒有獲得一些架構對于品質因素影響 的結論，比如說性能，因為這取決于運作期内元件和子系統的多樣性。從實際模型中我們獲得的是靜态分析，一個具有可能性的解決 方案是分析相應的源代碼并在運作期中跟蹤其元件并測試它的性能。在這裡，概念性架構模型将和軟體實作模型相映射，相應的節點 将表現軟體的功能元件，相應的流程将表現控制流。實際架構模型将被映射成為系統執行模型，它将展現出類似于網絡隊列的關鍵計算 機資源。是以，這是一個基于架構分析的可行的JBoss性能測試方法。我們的工作是分析JBoss架構以使我們更了解系統。接下來要做的 是，通過這次分析來獲得JBoss應用的初步的解析性模型，分析代碼是可行的測試方法并可測試它的性能。
7. 參考資料
1.JBoss Home Page http://www.jboss.org/
2.JBoss Documentation http://www.jboss.org/doco.jsp
3.JBoss Quick Techincal Overview http://www.ejbean.com/resources/free-open/jboss. html
4.Prof. Richard C. Holt's Home Page http://plg.uwaterloo.ca/~holt/
5.Ivan T. Bowman, Richard C. Holt and Neil V. Brewster, Linux as a Case Study: Its Extracted Software Architecture, ICSE 99, Los Angeles, May 99.
6.How do I deploy Enterprise JavaBean to JBoss http://otn.oracle.com/products/jdev/ howtos/appservers/deploy_to_jboss.html
7.The art of EJB deployment http://www.javaworld.com/javaworld/jw-08-2001/jw- 0803-ejb_p.html
8.Superior app management with JMX http://www.javaworld.com/javaworld/jw-06- 2001/jw-0608-jmx_p.html
9.DynaServer: System Support for Dynamic Content Web Servers http://www.cs.rice. edu/CS/Systems/DynaServer/
10.MTE Project http://www.cmis.csiro.au/adsat/mte.htm
11.TogetherSoft Home Page http://www.togethersoft.de/downloads/down_index.html
12.David Garlan and Mary Shaw, An Introduction to Software Architecture, CMU Software Engineering Institute Technical Report, 1994
13.Loyd G. Williams, Connie U. Smith, Performance Evaluation of Software Architecture, WOSP 98, Santa Fe.N.M
14.Felix Bachman, Len Bass, Charles Buhman, Santiago Comella-Dorda, Fred Long, John Robert, Robert Seacord, Kurt Wallnau,Technical Concepts of Component-based Software Engineering, Technical Report, CMU/SEI-2000-TR-008 ESC-TR-2000-007
8. 資料字典
[J2EE] Java 2 Enterprise Edition from Sun MicroSystem. It is a web operationg system
[JMX] the Java Management eXtension (TM) to offer standard interfaces to the management of its components as well as the applications deployed on it.
[JAWS] Just Another Web Storage
[JCA] The J2EE Connector Architecture
[JNDI] Java Naming and Directory Interface
[RMI] Remote Method Invocation. It is Sun's object request broker(ORB).
[JRMP] Java Remote Method Protocal.
[JTA] Java Transaction API.
Appendix-1
Figure Appendix-1 StatelessSessionContainer Concrete Architectual Model
Appendix-2
Figure Appendix-2 StatefulSessionContainer Concrete Architectual Model
Appendix-3
Figure Appendix-3 A COTS EJB Container Conceptual Architecture Model
![QQ空間及郵箱驗證碼登入的校驗方式及自動登入的解決方案[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)