計(jì)算機(jī)科學(xué)與技術(shù) 畢業(yè)設(shè)計(jì) 外文英文文獻(xiàn) 翻譯 基于J2EE在分布式環(huán)境下的底層結(jié)構(gòu)的自動(dòng)動(dòng)態(tài)配置的應(yīng)用

《計(jì)算機(jī)科學(xué)與技術(shù) 畢業(yè)設(shè)計(jì) 外文英文文獻(xiàn) 翻譯 基于J2EE在分布式環(huán)境下的底層結(jié)構(gòu)的自動(dòng)動(dòng)態(tài)配置的應(yīng)用》由會(huì)員分享，可在線閱讀，更多相關(guān)《計(jì)算機(jī)科學(xué)與技術(shù) 畢業(yè)設(shè)計(jì) 外文英文文獻(xiàn) 翻譯 基于J2EE在分布式環(huán)境下的底層結(jié)構(gòu)的自動(dòng)動(dòng)態(tài)配置的應(yīng)用（18頁(yè)珍藏版）》請(qǐng)?jiān)谘b配圖網(wǎng)上搜索。

1、 黃河科技學(xué)院畢業(yè)設(shè)計(jì)(文獻(xiàn)翻譯) 基于J2EE在分布式環(huán)境下的底層結(jié)構(gòu)的自動(dòng)動(dòng)態(tài)配置的應(yīng)用 Anatoly Akkerman, Alexander Totok, and Vijay Karamcheti摘要：為了實(shí)現(xiàn)廣域網(wǎng)中符合工業(yè)標(biāo)準(zhǔn)基于組件的應(yīng)用程序中動(dòng)態(tài)的可適應(yīng)性，我們需要一種框架來(lái)在這樣的環(huán)境里自動(dòng)化地配置J2EE 應(yīng)用程序。這種需要對(duì)于哪怕在單一的應(yīng)用程序服務(wù)器上嘗試部署J2EE應(yīng)用的人來(lái)說(shuō)也顯而易見，這種任務(wù)設(shè)計(jì)到大量的系統(tǒng)服務(wù)和應(yīng)用組件的配置。關(guān)鍵詞：j2ee；動(dòng)態(tài)配置；分布式；組件；1 前言 近幾年，我們已經(jīng)看到基于組件的企業(yè)應(yīng)用開發(fā)的顯著增加。這種應(yīng)用程序通常被部署在公司的

2、內(nèi)部網(wǎng)或者是因特網(wǎng)上，以高事務(wù)容量，大量的用戶和覆蓋范圍廣的訪問為特征，它通常會(huì)被部署在中央?yún)^(qū)域，采用服務(wù)器集群來(lái)均衡負(fù)載從而支持用戶下載。但是這種平均負(fù)荷的方法被證明只對(duì)減少應(yīng)用轉(zhuǎn)發(fā)的用戶可以察覺的反應(yīng)時(shí)間有效，而對(duì)于減少網(wǎng)絡(luò)方面的延遲作用不大，垂直分割（例如運(yùn)行網(wǎng)絡(luò)層和事務(wù)層在不同的虛擬機(jī)）被用于錯(cuò)誤分離和均衡負(fù)荷，但是它是不符合實(shí)際的由于遠(yuǎn)程調(diào)運(yùn)的大量使用顯著地增加了運(yùn)行時(shí)時(shí)間。最近的著作已經(jīng)表明在廣域網(wǎng)中利用垂直負(fù)荷而不引起前面所述的超時(shí)問題的可行性。那非研究的主要結(jié)論可以概括如下：(1) 應(yīng)用合適的應(yīng)用程序，在廣域網(wǎng)中的垂直負(fù)荷可以察覺的延遲。(2) 廣域垂直層需要復(fù)制應(yīng)用層組件而且

3、需要維持和原組件間的一致性。(3) 新加的復(fù)制組件可以被動(dòng)態(tài)配置以滿足新的需要。(4) 事實(shí)上，不同的復(fù)制組件可能會(huì)根據(jù)應(yīng)用不同的方式實(shí)現(xiàn)相組件。(5) 新的請(qǐng)求路徑可以復(fù)用先前的組件配置路徑。應(yīng)用智能監(jiān)視和人工智能規(guī)劃方法再結(jié)合那個(gè)研究得出的結(jié)論，我們看到通過(guò)動(dòng)態(tài)布置基于動(dòng)態(tài)監(jiān)視的額外的應(yīng)用組件，在廣域網(wǎng)中符合工業(yè)標(biāo)準(zhǔn)基于組件的應(yīng)用程序中動(dòng)態(tài)的可適應(yīng)性是可以實(shí)現(xiàn)的。然而，為了實(shí)現(xiàn)這種動(dòng)態(tài)可適性，我們需要一種框架來(lái)在這樣的環(huán)境里自動(dòng)化地配置J2EE 應(yīng)用程序。這種需要對(duì)于哪怕在單一的應(yīng)用程序服務(wù)器上嘗試布置J2EE應(yīng)用的人來(lái)說(shuō)也顯而易見，這種任務(wù)設(shè)計(jì)到大量的系統(tǒng)服務(wù)和應(yīng)用組件的配置。例如你必須

4、在配置和部署應(yīng)用組件前先建立JDBC數(shù)據(jù)源，設(shè)立消息目的地和資源適配器。在需要跨越多個(gè)節(jié)點(diǎn)服務(wù)器的廣域網(wǎng)配置中，這將更加復(fù)雜，因?yàn)楦嗟谋憷麅?nèi)部節(jié)點(diǎn)通信的系統(tǒng)服務(wù)需要配置和啟動(dòng)，而且多種配置數(shù)據(jù)比如IP地址，端口號(hào)，JNDI名字和其他的數(shù)據(jù)在多個(gè)節(jié)點(diǎn)的配置文件中必須維持一致性。這種分布式配置框架必須滿足：(1) 聲明內(nèi)部組件一致性規(guī)范和定義它對(duì)組件配置部署的影響。(2) 聲明應(yīng)用程序組件對(duì)應(yīng)用服務(wù)器，以及它們的配置和部署的依賴性。(3) 提供簡(jiǎn)單但可表達(dá)的抽象方法去控制通過(guò)部署和拆卸組件獲得的適用性。(4) 能夠復(fù)用服務(wù)和組件從而高效的利用網(wǎng)路節(jié)點(diǎn)資源。(5) 提供上述便利而不會(huì)增加應(yīng)用程序員

5、的設(shè)計(jì)負(fù)擔(dān)。在本論文中，我們提出自動(dòng)動(dòng)態(tài)部署J2EE應(yīng)用程序的框架涉及了上面的所有問題，這種框架為組件定義了結(jié)構(gòu)描述語(yǔ)言，鏈接說(shuō)明和集合。這種組件說(shuō)明語(yǔ)言用來(lái)描述應(yīng)用程序組件和鏈接，它使得應(yīng)用組件與系統(tǒng)組件中清晰的分開。一種靈活的系統(tǒng)類型用來(lái)定義組件接口和端口的兼容性。一種為配置組件屬性而開發(fā)的定義和表述語(yǔ)言允許內(nèi)部組件間獨(dú)立的規(guī)范和組件間屬性的繼承。組件集合語(yǔ)言允許先前定義的復(fù)制的組件通過(guò)連接合適的端口集合到應(yīng)用路徑，連接時(shí)通過(guò)鏈接復(fù)制對(duì)象和具體把這些復(fù)制組件映射到目標(biāo)應(yīng)用服務(wù)器節(jié)點(diǎn)。組件配置過(guò)程評(píng)估了應(yīng)用程序路徑的正確性，確認(rèn)在系統(tǒng)組件上的應(yīng)用組件的獨(dú)立性和完成復(fù)制組件的部署。根據(jù)這些配置

6、使先前部署的復(fù)制組件在新的路徑中得以匹配和復(fù)用的努力正在做出。我們把這種架構(gòu)作為JBoss開源java應(yīng)用服務(wù)器的一部分加以實(shí)現(xiàn)，在幾個(gè)J2EE樣本程序比如Java PetStore,，RUB和 TPC_W_NYU中進(jìn)行測(cè)試。這種架構(gòu)實(shí)現(xiàn)利用了JBoss的可擴(kuò)展的微內(nèi)核結(jié)構(gòu)，基于JMX規(guī)范。JBoss的組件結(jié)構(gòu)允許根據(jù)部署應(yīng)用程序的需要增加服務(wù)配置。我們相信通過(guò)動(dòng)態(tài)部署和拆卸系統(tǒng)服務(wù)來(lái)重構(gòu)應(yīng)用服務(wù)器對(duì)構(gòu)建高效資源框架的動(dòng)態(tài)分布部署的J2EE應(yīng)用程序來(lái)說(shuō)是非常必要的。本文如下部分是這樣組織的。第2部分提供了必要的背景以理解和研究有關(guān)的J2EE組件技術(shù)規(guī)范。第3部分對(duì)這種架構(gòu)給出了一般性的描述。第

7、4部分更深入的描述了有關(guān)這種架構(gòu)特別重要的和有趣的內(nèi)部機(jī)制。第五部分描述了如何實(shí)現(xiàn)這種架構(gòu)，相關(guān)聯(lián)的工作將在第六部分介紹。2 J2EE背景知識(shí)2.1 介紹組件框架。組件框架是一種中間件系統(tǒng)，它支持遵守一定標(biāo)準(zhǔn)的有不同組件構(gòu)成的應(yīng)用程序。應(yīng)用組件被塞入這種確立它們運(yùn)行環(huán)境和規(guī)定它們交互的框架中。這通常是通過(guò)容器，組件持有者來(lái)實(shí)現(xiàn)的。這種容器也提供通常需要的功能以實(shí)現(xiàn)命名，安全性，事務(wù)，和持久性！組件框架為組件的執(zhí)行提供了一個(gè)集成的環(huán)境，因此顯著的減少了在設(shè)計(jì)，實(shí)現(xiàn)，部署和維護(hù)應(yīng)用程序時(shí)工作?，F(xiàn)在工業(yè)上的組件框架標(biāo)準(zhǔn)以對(duì)象管理組的CORBA組件模型， SUN 公司的JAVA 2 Platform

8、J企業(yè)版J2EE和微軟公司的.NET標(biāo)準(zhǔn)，其中在企業(yè)里應(yīng)用最為廣泛的組件框架是2EEE。J2EE. J2EE是開發(fā)多層企業(yè)應(yīng)用JAVA程序的綜合性的標(biāo)準(zhǔn)。J2EE規(guī)范定義如下：(1) 組件編程模型。(2) 組件和主服務(wù)器的鏈接。(3) 服務(wù)器提供給組件的服務(wù)。(4) 各種各樣的人物角色。(5) 兼容性檢驗(yàn)裝置和編譯測(cè)試程序。在眾多的服務(wù)列表中，消息通信，事務(wù)處理，命名機(jī)制和其它應(yīng)用組件用到的服務(wù)是應(yīng)用服務(wù)器必須提供的。用J2EE進(jìn)行應(yīng)用開發(fā)必須遵守經(jīng)典的3層結(jié)構(gòu)表現(xiàn)層，業(yè)務(wù)層和企業(yè)信息系統(tǒng)層。屬于各層的J2EE組件在開發(fā)時(shí)遵守具體的J2EE標(biāo)準(zhǔn)。1、表現(xiàn)層或者網(wǎng)絡(luò)層這一層實(shí)際上又被分為客戶端和

9、服務(wù)器端。客戶端包括瀏覽器，applets，Java應(yīng)用程序等和負(fù)責(zé)和服務(wù)器端的表現(xiàn)層或者業(yè)務(wù)層進(jìn)行交互。服務(wù)器端包括servlet、jsp和靜態(tài)網(wǎng)頁(yè)內(nèi)容。這些組件負(fù)責(zé)把業(yè)務(wù)數(shù)據(jù)傳遞給終端用戶。數(shù)據(jù)本身通常從業(yè)務(wù)層獲得有時(shí)也從企業(yè)信息系統(tǒng)層直接獲得。表現(xiàn)層的服務(wù)器端通常通過(guò)Http協(xié)議來(lái)進(jìn)行訪問。2、 業(yè)務(wù)層或者EJB層這一層包含EJB，即企業(yè)應(yīng)用的事務(wù)邏輯模型。這些組件提供了持久化機(jī)制和事務(wù)支持。EJB中的組件通過(guò)RMI被調(diào)用。在Java虛擬機(jī)調(diào)用或者異步的消息傳遞，取決與EJB組件的類型。EJB規(guī)范定義了很多種組件。它們?cè)谡{(diào)用風(fēng)格（同步和異步，本地和遠(yuǎn)程）與狀態(tài)（完全狀態(tài)，不可持久狀態(tài)，可

10、持久）方面不同。同步調(diào)用的EJB組件通過(guò)特定的工廠代理對(duì)象來(lái)表現(xiàn)自己。這種工廠代理對(duì)象通常被EJB部署者綁定在JNDI中。EJB對(duì)象允許或者本地EJB對(duì)象是特定EJB實(shí)例的代理。3、企業(yè)信息系統(tǒng)或者數(shù)據(jù)層這一層指的就是企業(yè)信息系統(tǒng)，比如關(guān)系數(shù)據(jù)庫(kù)，ERP系統(tǒng)，消息系統(tǒng)等。業(yè)務(wù)層和持久層在資源適配器的幫助下與該層進(jìn)行通信。資源適配器在Java連結(jié)結(jié)構(gòu)中被定義。J2EE編程模型一直被認(rèn)為是分布式的編程模型，在該模型中應(yīng)用組件在J2EE服務(wù)器上運(yùn)行并且彼此可以相互交互。經(jīng)過(guò)初始化說(shuō)明和第一個(gè)服務(wù)實(shí)現(xiàn)后，該技術(shù)，更顯著的說(shuō)EJB技術(shù)，已經(jīng)明顯地從純粹的分布式計(jì)算模型轉(zhuǎn)向了本地交互。轉(zhuǎn)變的背后有合理的性

11、能有關(guān)的原因，然而分布式的特征現(xiàn)在還存在。J2EE規(guī)范已經(jīng)經(jīng)過(guò)了好幾次修訂，現(xiàn)在最穩(wěn)定的版本是1.3，1.4版本正處于重審階段。我們應(yīng)該把注意力放在1.3版本上，而實(shí)際上是在學(xué)習(xí)后者。適用與商業(yè)的J2EE實(shí)現(xiàn)可以大量的從BEA系統(tǒng)，IBM，Oracle等贊助商得到。包括JBoss和JOnAS在內(nèi)的開源實(shí)現(xiàn)據(jù)稱兼容性也不錯(cuò)。最近名單上有多出了新的Apache project Geronimo。2.2 J2EE組件編程模型在我們基本的J2EE組件前，先讓我們強(qiáng)調(diào)一下什么是組件。軟件組件是有一系列的具體的接口和明確的上下文環(huán)境構(gòu)成。它可以被獨(dú)立的部署而且易于被第三方重構(gòu)。根據(jù)以上的定義，如下的組成J

12、2EE應(yīng)用程序的實(shí)體可以看作是軟件組件：(1) EJBS（會(huì)話，實(shí)體，消息驅(qū)動(dòng)）。(2) Web組件（Servlet、JSP）。.(3) 消息目的。(4) 數(shù)據(jù)源。EJB和Web組件被部署在由應(yīng)用服務(wù)贊助商提供的容器中.它們有定義良好的容器規(guī)則來(lái)管理生命周期，線程，持久化和其他問題。EJB和Web組件都利用JNDI目錄機(jī)制去尋找資源和它們想要交互的其EJB組件。目錄被執(zhí)行的JNDI環(huán)境被獨(dú)立的由容器的每個(gè)組件加以維護(hù)。該種環(huán)境下的綁定機(jī)制通常由組件部署的解釋者加以配置。消息目的地，像對(duì)話和隊(duì)列，是由消息服務(wù)執(zhí)行所提供的資源。數(shù)據(jù)源是提供給應(yīng)用服務(wù)器的為事務(wù)組件進(jìn)入到企業(yè)信息服務(wù)層提供數(shù)據(jù)接口，

13、通常由被應(yīng)用服務(wù)器管理的JDBC連接池實(shí)例化。一個(gè)J2EE編程者明確編寫的項(xiàng)目只有EJB和Web組件。這些用戶編寫的組件彼此交互而且系統(tǒng)服務(wù)可以是明顯的也可以是隱含的。例如，EJB開發(fā)者可以選擇明確的事務(wù)區(qū)分方式，這種方式意味著開發(fā)者假設(shè)通過(guò)定義良好接口的事務(wù)經(jīng)理服務(wù)平臺(tái)來(lái)書寫明確的程序交互?；蛘撸_發(fā)者也可選擇容器管理事務(wù)區(qū)分的方式。這樣由于組件的事務(wù)行為通過(guò)他的描述者來(lái)定義而且全部用EJB容器來(lái)處理，因此作為一個(gè)隱式獨(dú)立的EJB提供潛在的事務(wù)管理服務(wù)。2.3 組件間的鏈接2.3.1 遠(yuǎn)程交互J2EE僅定義了三種可以在不同應(yīng)用服務(wù)器間傳遞的基本組件間連接類型。在這三種情況下，通信通過(guò)特定的J

14、ava對(duì)象來(lái)完成。(1) 遠(yuǎn)程EJB調(diào)用：同步的EJB調(diào)用通過(guò)主EJB對(duì)象和EJB對(duì)象接口來(lái)實(shí)現(xiàn)。(2) Java連結(jié)器的外部連接：同步消息接收，同步和異步消息發(fā)送，用連接工廠和連接接口進(jìn)行數(shù)據(jù)庫(kù)查詢。(3) Java連接器的內(nèi)部連接：異步消息傳遞進(jìn)入消息驅(qū)動(dòng)Bean只能使用Activation Spec 對(duì)象。在前兩個(gè)實(shí)例中，應(yīng)用組件的開發(fā)者不僅書寫執(zhí)行在組件的運(yùn)行時(shí)JNDI環(huán)境中的對(duì)象目錄代碼，而且書寫發(fā)布方法調(diào)用，與遠(yuǎn)程的組件相互發(fā)送和接受消息。組件的運(yùn)行時(shí)JNDI環(huán)境為每一個(gè)組件部署所創(chuàng)建。環(huán)境中的綁定在組件部署時(shí)由部署者進(jìn)行初始化。這些綁定被假設(shè)為是靜態(tài)的，因?yàn)橐?guī)格中沒有提供任何的容

15、器和組件間協(xié)議去提示綁定發(fā)生了變化。在 Java連接器的內(nèi)部通信情景下，Activation Spec 對(duì)象查詢以及所有的相應(yīng)的M容器隱式的完成。雖然查詢的協(xié)議還沒有被標(biāo)準(zhǔn)化，但是假設(shè)一個(gè)基于JMX或者JNDI的查詢是合理的。 假設(shè)潛在的應(yīng)用服務(wù)器提供了所有的設(shè)備去控制部署過(guò)程的每一步，那么在兩個(gè)J2EE組件間確立一個(gè)連接需要涉及：(1) 部署目標(biāo)組件類。(2) 創(chuàng)建一個(gè)特定的Java對(duì)象用作目標(biāo)組件代理。(3) 用組件的命名服務(wù)去綁定目標(biāo)。(4) 啟動(dòng)目標(biāo)組件。(5) 部署指定的組件類。(6) 在主機(jī)的命名服務(wù)中，創(chuàng)建和進(jìn)行指定組件的運(yùn)行環(huán)境。(7) 啟動(dòng)指定的組件。然而，沒有一個(gè)現(xiàn)代的應(yīng)用

16、服務(wù)器允許詳細(xì)的控制所有組件類型的部署過(guò)程除了在它們的部署解釋器中的有限的選擇。因此我們的架構(gòu)將使用簡(jiǎn)化的途徑，它所依賴的特征在現(xiàn)在的大多數(shù)的應(yīng)用服務(wù)器上都可以得到。(1) 動(dòng)態(tài)部署消息目的和數(shù)據(jù)源的能力。(2) 創(chuàng)建和綁定特定的JNDI目標(biāo)去訪問消息目的和數(shù)據(jù)源的能力。(3) 把初始綁定的EJB對(duì)象到EJB部署組件的能力。(4) 用在參考組件運(yùn)行環(huán)境中的JNDI指引去指出綁定的參考EJB的能力。在只有相同的應(yīng)用服務(wù)器的架構(gòu)中，上面的功能對(duì)通過(guò)簡(jiǎn)單的部署控制解釋器方式來(lái)控件間的連接已經(jīng)足夠了。然而，在不同應(yīng)用服務(wù)器的環(huán)境下，由于跨服務(wù)器的類下載問題，這種簡(jiǎn)單的控制解釋器的方式是不夠的。2.3.

17、2 本地交互一些組件間的交互可以發(fā)生在同一地點(diǎn)的相同應(yīng)用服務(wù)器虛擬機(jī)的組件間，有時(shí)候甚至可以發(fā)生在只有相同容器的組件間。在Web層，這種交互的例子是 servlet到 servlet的請(qǐng)求轉(zhuǎn)發(fā)。在EJB層，這種交互的例子是CMP實(shí)體關(guān)系和通過(guò)EJB本地接口的調(diào)用。這種本地部署所關(guān)心的不是在分布式架構(gòu)中去表現(xiàn)而是去增強(qiáng)一致性。因此，這種架構(gòu)把所有的本地的組件請(qǐng)求當(dāng)作一個(gè)單一的組件加以對(duì)待。2.4 部署J2EE應(yīng)用程序和系統(tǒng)服務(wù)2.4.1 部署應(yīng)用程序組件部署和拆卸標(biāo)準(zhǔn)的J2EE組件還沒有統(tǒng)一的標(biāo)準(zhǔn)，因此每個(gè)應(yīng)用服務(wù)的提供商對(duì)組件的部署和拆卸提供了單獨(dú)的功能于J2EE規(guī)范中沒有定義標(biāo)準(zhǔn)組件的包，包

18、的格式和包內(nèi)的基于xml部署解釋器的位置，因此這種包對(duì)于沒有所屬權(quán)變化的應(yīng)用服務(wù)器不需要部署。具體變化的例子有：(1) 支持或者取代標(biāo)準(zhǔn)所有者解釋器的新的所有者解釋器的產(chǎn)生。(2) 具體服務(wù)應(yīng)用程序類的代碼的更替。為了著手構(gòu)建一個(gè)能夠部署不可網(wǎng)絡(luò)的動(dòng)態(tài)的分布式的架構(gòu)，我們提出了一種普遍的部署單元即一個(gè)簡(jiǎn)單的基于xml部署的解釋器或者是一組類似的綁定到文檔中的解釋器。文檔可能包含用于執(zhí)行組件的Java類或者任何其它的所需組件。相應(yīng)地，部署解釋器也可以簡(jiǎn)單地用URL來(lái)索引代碼。我們假設(shè)這種動(dòng)態(tài)的部署和拆卸服務(wù)存在于所有的兼容的J2EE服務(wù)器上而且在不理解類重載相關(guān)問題時(shí)一個(gè)健壯的類重載結(jié)結(jié)構(gòu)的應(yīng)用

19、服務(wù)器就能夠重復(fù)的部署生命周期。大多數(shù)現(xiàn)代的應(yīng)用服務(wù)器都提供這樣的功能。2.4.2 部署系統(tǒng)組件對(duì)應(yīng)用組件來(lái)說(shuō)，J2EE規(guī)范只是少了在部署和拆卸時(shí)的明確定義，而對(duì)系統(tǒng)服務(wù)來(lái)說(shuō)，在這方面做的更糟。對(duì)系統(tǒng)服務(wù)來(lái)說(shuō)不僅沒有具體的定義一個(gè)標(biāo)準(zhǔn)化的部署，實(shí)際上，這個(gè)規(guī)格甚至連沒有強(qiáng)調(diào)在生命周期屬性方面的要求，更不用手強(qiáng)調(diào)依賴也潛在的系統(tǒng)服務(wù)的應(yīng)用組件的明確規(guī)范了取而代之的是它定義了部署者的角色，這個(gè)角色負(fù)責(zé)確保像組件的本性和系統(tǒng)的解釋器所暗示的那樣，所需的服務(wù)是基于應(yīng)用組件對(duì)系統(tǒng)服務(wù)依賴性的基礎(chǔ)之上。例如，假如有一個(gè)事務(wù)容器要至少用一種方法去開始一個(gè)新的事務(wù)，那么一個(gè)帶有這樣的事務(wù)容器的EJB就需要在應(yīng)

20、用層表示事務(wù)管理服務(wù)。與之相似的是，一個(gè)消息驅(qū)動(dòng)的bean，也隱式需要一種運(yùn)行在網(wǎng)絡(luò)上消息服務(wù)實(shí)例。它為MDB管理消息目的以及基于查詢的Java連接器通過(guò)它的管理服務(wù)層去提供這種消息服務(wù)。考慮到應(yīng)用層可能通常只用到了應(yīng)用服務(wù)器所提供的服務(wù)的一個(gè)子集，根據(jù)應(yīng)用層的需要允許遞增的配置服務(wù)的組件應(yīng)用服務(wù)器允許更高效的利用多種資源。包括，開源的應(yīng)用服務(wù)器，JBoss和OnAS在內(nèi)，已經(jīng)有多種J2EE應(yīng)用服務(wù)器已經(jīng)全部或者部分的實(shí)現(xiàn)了組件化。我們感覺到通過(guò)動(dòng)態(tài)的部署和拆卸系統(tǒng)服務(wù)，動(dòng)態(tài)的配置應(yīng)用服務(wù)器對(duì)動(dòng)態(tài)分布的部署J2EE應(yīng)用程序是一種十分重要的構(gòu)建資源有效型框架的方法。因此我們提倡并將把用JBoss

21、應(yīng)用服務(wù)器設(shè)計(jì)的微內(nèi)核的應(yīng)用服務(wù)器用作一個(gè)模型。在該模型中，一個(gè)微型的服務(wù)包括了系統(tǒng)調(diào)用總線，一個(gè)穩(wěn)健的類下載子系統(tǒng)，一些命名子系統(tǒng)和一個(gè)動(dòng)態(tài)配置子系統(tǒng)。所有其它的服務(wù)是熱部署并且通過(guò)一個(gè)普通的調(diào)用總線來(lái)進(jìn)行通信。例如，JBoss利用Java管理擴(kuò)展服務(wù)器來(lái)實(shí)現(xiàn)基本的命名和調(diào)用功能。除此之外，JBoss實(shí)現(xiàn)了一個(gè)先進(jìn)的類下載子系統(tǒng)和部署服務(wù)。所有其它的JBoss是動(dòng)態(tài)配置的，并外在的表現(xiàn)為具有良好機(jī)制和生命周期的JMX MBeans.這樣的一種應(yīng)用服務(wù)器根據(jù)系統(tǒng)服務(wù)外在利用應(yīng)用組件去設(shè)計(jì)相關(guān)功能，并且只有需要的系統(tǒng)服務(wù)才會(huì)得到合理配置和部署！ 參考文獻(xiàn)1 Matt Bishop. Comput

22、er Security: Art and Science. New York, 20022 Matt Bishop. Vulnerabilities Analysis. Proceedings of the Second International Symposium on Recent Advances in Intrusion Detection. Los Angeles 20063 Balasubra maniyan. Architecture for Intrusion Detection using Autonomous AgentsM. Department of Computer

23、 Sciences, Purdue University, 1998.Infrastructure for Automatic Dynamic DeploymentOf J2EE Application in Distributed EnvironmentsAnatoly Akkerman, Alexander Totok, and Vijay KaramchetiAbstract: in order to achieve such dynamic adaptation, we need an infrastructure for automating J2EE application dep

24、loyment in such an environment. This need is quite evident to anyone who has ever tried deploying a J2EE application even on a single application server, which is a task that involves a great deal of configuration of both the system services and application components.Key words: j2ee; component; Dis

25、tributed; Dynamic Deployment; 1 IntroductionIn recent years, we have seen a significant growth in component-based enterprise application development. These applications are typically deployed on company Intranets or on the Internet and are characterized by high transaction volume, large numbers of u

26、sers and wide area access. Traditionally they are deployed in a central location, using server clustering with load balancing (horizontal partitioning) to sustain user load. However, horizontal partitioning has been shown very efficient only in reducing application-related overheads of user-perceive

27、d response times, without having much effect on network-induced latencies. Vertical partitioning (e.g., running web tier and business tier in separate VMs) has been used for fault isolation and load balancing but it is sometimes impractical due to significant run-time overheads (even if one would ke

28、ep the tiers on a fast local-area network) related to heavy use of remote invocations. Recent work 14 in the context of J2EE component based applications has shown viability of vertical partitioning in wide-area networks without incurring the aforementioned overheads. The key conclusions from that s

29、tudy can be summarized as follows: Using properly designed applications, vertical distribution across wide-area networks improves user-perceived latencies. Wide-area vertical layering requires replication of application components and maintaining consistency between replicas. Additional replicas may

30、 be deployed dynamically to handle new requests. Different replicas may, in fact, be different implementations of the same component based on usage (read-only, read-write). New request paths may reuse components from previously deployed paths. Applying intelligent monitoring 6 and AI planning 2, 12

31、techniques in conjunction with the conclusions of that study, we see a potential for dynamic adaptation in industry-standard J2EE component-based applications in wide area networksThrough deployment of additional application components dynamically based on active monitoring. However, in order to ach

32、ieve such dynamic adaptation, we need an infrastructure for automating J2EE application deployment in such an environment. This need is quite evident to anyone who has ever tried deploying a J2EE application even on a single application server, which is a task that involves a great deal of configura

33、tion of both the system services and application components. For example one has to set up JDBC data sources, messaging destinations and other resource adapters before application components can be configured and deployed. In a wide area deployment that spans multiple server nodes, this proves even

34、more complex, since more system services that facilitate inter-node communications need to be configured and started and a variety of configuration data, like IP addresses, port numbers, JNDI names and others have to be consistently maintained in various configuration files on multiple nodes.This di

35、stributed deployment infrastructure must be able to: address inter-component connectivity specification and define its effects on component configuration and deployment, address application component dependencies on application server services, their configuration and deployment, provide simple but

36、expressive abstractions to control adaptation through dynamic deployment and undeployment of components, enable reuse of services and components to maintain efficient use of network nodes resources, provide these facilities without incurring significant additional design effort on behalf of applicat

37、ion programmers.In this paper we propose the infrastructure for automatic dynamic deployment of J2EE applications, which addresses all of the aforementioned issues. The infrastructure defines architecture description languages (ADL) for component and link description and assembly. The Component Desc

38、ription Language is used to describe application components and links. It provides clear separation of application components from system components. A flexible type system is used to define compatibility of component ports and links. A declaration and expression language for configurable component

39、properties allows for specification of inter-component dependencies and propagation of properties between components. The Component (Replica) Assembly Language allows for assembly of replicas of previously defined components into application paths byConnecting appropriate ports via link replicas and

40、 specifying the mapping of these component replicas onto target application server nodes. The Component Configuration Process evaluates an application paths correctness, identifies the dependenciesof application components on system components, and configures component replicas for deployment. An at

41、tempt is made to match and reuse any previously deployed replicas in the new path based on their configurations. We implement the infrastructure as a part of the JBoss open source Java application server 11 and test it on severalSample J2EE applications Java Pets tore 23, Rubies 20 and TPC-W-NYU 32.

42、 The infrastructure implementation utilizes the JBosss extendable micro-kernel architecture, based on the JMX 27 specification. Componentized architecture of JBoss allows incremental service deployments depending on the needs of deployed applications. We believe that dynamic reconfiguration of appli

43、cation servers through dynamic deployment and undeployment of system services is essential to building a resource-efficient framework for dynamic distributed deployment of J2EE applications. The rest of the paper is organized as follows. Section 2 provides necessary background for understanding the

44、specifics of the J2EE component technology which are relevant to this study. Section 3 gives a general description of the infrastructure architecture, while section 4 goes deeper in describing particularly important and interesting internal mechanisms of the infrastructure. Section 5 describes the i

45、mplementation of the framework, and related work is discussed in section 6.2 J2EE Background2.1 IntroductionComponent frameworks. A component framework is a middleware system that supports applications consisting of components conforming to certain standards. Application components are “plugged” int

46、o the component framework, which establishes their environmental conditions and regulates the interactions between them. This is usually done through containers, component holders, which also provide commonly required support for naming, security, transactions, and persistence. Component frameworks

47、provide an integrated environment for component execution, as a result significantly reduce the effort .it takes to design, implement, deploy, and maintain applications. Current day industry component framework standards are represented by Object Management Groups CORBA Component Model 18, Sun Micro

48、systems Java 2 Platform Enterprise Edition (J2EE) 25 and Microsofts .NET 17, with J2EE being currently the most popular and widely used component framework in the enterprise arena.J2EE. Java 2 Platform Enterprise Edition (J2EE) 25 is a comprehensive standard for developing multi-tier enterprise Java

49、 applications. The J2EE specification among other things defines the following: Component programming model, Component contracts with the hosting server, Services that the platform provides to these components, Various human roles, Compatibility test suites and compliance testing procedures.Among th

50、e list of services that a compliant application server must provide are messaging, transactions, naming and others that can be used by the application components. Application developed using J2EE adhere to the classical 3-Tier architectures Presentation Tier, Business Tier, and Enterprise Informatio

51、n System (EIS) Tier (see Fig. 1). J2EE components belonging to each tier are developed adhering to theSpecific J2EE standards.1. Presentation or Web tier.This tier is actually subdivided into client and server sides. The client side hosts a web browser, applets and Java applications that communicate

52、 with the server side of presentation tier or the business tier. The server side hosts Java Servlet components 30, Java Server Pages (JSPs) 29 and static web content. These components are responsible for presenting business data to the end users. The data itself is typically acquired from the busine

53、ss tier and sometimes directly from the Enterprise Information System tier. The server side of the presentation tier is typically accessed through HTTP(S) protocol.2. Business or EJB tier.This tier consists of Enterprise Java Beans (EJBs) 24 that model the business logic of the enterprise applicatio

54、n. These components provide persistence mechanisms and transactional support. The components in the EJB tier are invoked through remote invocations (RMI), in-JVM invocations or asynchronous message delivery, depending on the type of EJB component. The EJB specification defines several types of compo

55、nents. They differ in invocation style (synchronous vs. asynchronous, local vs. remote) and statefulness: completely stateless (e.g., Message-Driven Bean), stateful non-persistent(e.g., Stateful Session Bean), stateful persistent (e.g., Entity Bean). Synchronously invocable EJB components expose the

56、mselves through a special factory proxy object (an EJB Home object, which is specific to a given EJB), which is typically bound in JNDI by the deployer of the EJB. The EJB Home object allows creation or location of an EJBObject, which is a proxy to a particular instance of an EJB 1.3. Enterprise Inf

57、ormation System (EIS) or Data tier.This tier refers to the enterprise information systems, like relational databases, ERP systems, messaging systems and the like. Business and presentation tier component communicate with this tier with the help of resource adapters as defined by the Java Connector A

58、rchitecture 26.The J2EE programming model has been conceived as a distributed programming model where application components would run in J2EE servers and communicate with each other. After the initial introduction and first server implementations, the technology, most notably, the EJB technology ha

59、s seen some a significant shift away from purely distributed computing model towards local interactions 2. There were very legitimate performance-related reasons behind this shift, however theDistributed features are still available. The J2EE specification has seen several revisions, the latest stab

60、le being version 1.3, while version 1.4 is going through last review phases 3. We shall focus our attention on the former, while actually learning from the latter. Compliant commercial J2EE implementations are widely available from BEA Systems 4, IBM 9, Oracle 21 and other vendors. Several open sour

61、ce implementations, including JBoss 11 and JOnAS 19 claim compatibility as well. ARecent addition to the list is a new Apache project Geronimo 1.2.2 J2EE Component Programming ModelBefore we describe basic J2EE components, lets first address the issue of defining what a component is a software compo

62、nent is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties 31.According to this definition the following entities which make up a typical J2EE applicat

63、ion would be considered application components (some exceptions given below): EJBs (session, entity, message-driven), Web components (servlets, JSPs), messaging destinations, Data sources,EJB and Web components are deployed into their corresponding containers provided by the application server vendo

64、r. They have well-defined contracts with their containers that govern lifecycle, threading, persistence and other concerns. Both Web and EJB components use JNDI lookups to locate resources or other EJB components they want to communicate with. The JNDI context in which these lookups are performed is

65、 maintained separately for each component by its container. Bindings messaging destinations, such as topics and queues, are resources provided by a messaging service implementation. Data sources are resources provided by the application server for data access by business components into the enterprise information services (data) tier, and most commonly are exemplified by JDBC connection pools managed by the applicationServer