j2ee應(yīng)用的運(yùn)行重構(gòu)-外文翻譯

1、<p>　　J2EE應(yīng)用的運(yùn)行重構(gòu)</p><p>　　亞斯明卡 瑪特威斯卡-梅耶，薩沙 奧里格斯，威廉哈塞爾伯林</p><p>　　計(jì)算機(jī)科學(xué)系，軟件工程組，奧爾登堡大學(xué)，26121奧爾登堡，德國</p><p>　　matevska-meyer@informatik.uni-oldenburg.de,</p><p>　　ol

2、liges@informatik.uni-oldenburg.de,</p><p>　　hasselbring@informatik.uni-oldenburg.de</p><p>　　摘 要：改變運(yùn)行系統(tǒng)的運(yùn)行時重構(gòu)，不僅在安全和關(guān)鍵任務(wù)系統(tǒng)方面起著提供高可用性的一個重要角色，而且對商業(yè)網(wǎng)絡(luò)應(yīng)用提供專業(yè)服務(wù)。據(jù)此，主要的關(guān)切點(diǎn)是維持在由重構(gòu)時導(dǎo)致的在重新配置和最大限度地減少其停機(jī)期間

3、運(yùn)行系統(tǒng)的一致性。本文的重點(diǎn)是平臺獨(dú)立的，基于作為能夠使基于組件系統(tǒng)運(yùn)行重構(gòu)的執(zhí)行系統(tǒng)部署新的J2EE API 模塊的子系統(tǒng)。我們的“控制運(yùn)行時重新部署”包括以結(jié)構(gòu)調(diào)整為允許補(bǔ)充的延伸熱部署和動態(tài)刷新。</p><p>　　關(guān)鍵詞：基于組件的軟件工程，部署，動態(tài)/自主重構(gòu)/修改</p><p><b>　　1 簡介</b></p><p>　　

4、該軟件系統(tǒng)的要求就必須永久改變其演變。業(yè)務(wù)流程在設(shè)計(jì)意在系統(tǒng)的在設(shè)計(jì)，變異的管理辦法設(shè)計(jì)意在設(shè)計(jì)包括部署后的系統(tǒng)適應(yīng)變化的系統(tǒng)。作為運(yùn)行系統(tǒng)的必需的變化，運(yùn)行時重構(gòu)起著提供軟件系統(tǒng)的高可用性具有重要作用。主要的關(guān)切點(diǎn)是維持在由重構(gòu)時導(dǎo)致的在重新配置和最大限度地減少其停機(jī)期間運(yùn)行系統(tǒng)的一致性。因此，決定了系統(tǒng)的某些部分將在重構(gòu)停止和繼續(xù)運(yùn)行的技術(shù)是需要的，因此，該系統(tǒng)可繼續(xù)進(jìn)行重構(gòu)[1]執(zhí)行的部分。為了確定受影響的作為一個最小集合部分的組

5、件，我們需要一個系統(tǒng)的描述，它提供了其運(yùn)行時基本上是關(guān)于使用的組件的實(shí)例依賴關(guān)系[2]行為的一個信息。此外，我們必須能夠重新組合在系統(tǒng)其運(yùn)行期間。</p><p>　　我們有關(guān)所謂重新部署的運(yùn)行時重構(gòu)的方法提供了一個控制運(yùn)行時的熱部署和動態(tài)刷新概念延伸[3]。此外，我們也考慮[1]運(yùn)行系統(tǒng)的結(jié)構(gòu)上相一致的變化。</p><p>　　本文組織如下：首先，我們簡要地介紹了我們的做法以使基于組件

6、的系統(tǒng)在運(yùn)行時重構(gòu)（第3節(jié)），其次，我們提出一個系統(tǒng)架構(gòu)（圖2-1）。在2.1節(jié)我們提出了我們對J2EE部署的API [4]的執(zhí)行情況。最后，在第三節(jié)闡述我們進(jìn)一步的工作的結(jié)論。</p><p>　　2運(yùn)行時啟用基于組件的系統(tǒng)的重構(gòu)</p><p>　　我們關(guān)注作為一個運(yùn)行著的系統(tǒng)必須的變化的基于組件系統(tǒng)的重構(gòu)。我們通過重構(gòu)的結(jié)果：（1）功能，（2）非功能性，（3）結(jié)構(gòu)方面來區(qū)分三種不同的

7、重構(gòu)。所有類型的重組可以發(fā)生在不同的粒度級別（即，可滿足整個系統(tǒng)或單個子組件）。功能重構(gòu)包括對單個組件的功能變化，以及一個特定的子系統(tǒng)，甚至整個系統(tǒng)。非功能重構(gòu)與質(zhì)量有關(guān)的服務(wù)（QOS）的系統(tǒng)，可以影響單個組件（子系統(tǒng)）或架構(gòu)。同時考慮結(jié)構(gòu)重構(gòu)，改變單一組件接口和不斷變化的組件之間（一個系統(tǒng)的體系結(jié)構(gòu)更改的依賴）。</p><p>　　我們看到正在運(yùn)行的系統(tǒng)會在一個個特定的時間間隔內(nèi)接收重構(gòu)請求直到重組完成。在已

8、經(jīng)部署和運(yùn)行系統(tǒng)，我們用實(shí)體組成部分的依賴關(guān)系確定的時間限制，那種關(guān)系是由特定的結(jié)構(gòu)依賴關(guān)系和特定的信息或派生組件協(xié)議約束實(shí)例使用的依賴關(guān)系。知道了所有可能受影響的組件的當(dāng)前狀態(tài)，以及他們未來的行為，我們可以排除過去的依存關(guān)系和未來的。這使我們能夠建立一個最小的運(yùn)行時依賴關(guān)系圖匹配的特殊請求重構(gòu)[1]。</p><p><b>　　《實(shí)例》</b></p><p>　

9、　圖2-1.C3元模型</p><p>　　我們的元模型如圖2-1，]提出了一種綜合描述該系統(tǒng)的靜態(tài)結(jié)構(gòu)和運(yùn)行時的看法，從而使重組后的系統(tǒng)行為和其一致性檢查和組成層次分解。</p><p>　　對于這容器組件的重要延伸到建立該系統(tǒng)的部署和運(yùn)行性能模型。一個容器提供了活動的組件運(yùn)行環(huán)境。為了描述這種系統(tǒng)運(yùn)行行為，我們使用自動影響服務(wù)。對于確定的重構(gòu)的時間點(diǎn)，我們提出了一個重組的消息序列圖，所

10、謂生存序列圖，因?yàn)樗麄兛梢员磉_(dá)生機(jī)和時間終結(jié)。</p><p>　　最后，需要申請到已經(jīng)部署和運(yùn)行機(jī)制的變化通常會觸發(fā)一個系統(tǒng)配置的變化，意味著重構(gòu)后，系統(tǒng)會重建和重新部署，以取得一致。這里一個要解決主要的問題是組件運(yùn)行管理中的依賴關(guān)系。我們的控制下運(yùn)行時重新部署的概念提出了一種對熱署和動態(tài)刷新概念延伸[3]。另外相對于前面提到的，我們允許運(yùn)行系統(tǒng)的結(jié)構(gòu)變化和只允許一個應(yīng)用程序或單個組件在運(yùn)行時既簡單交換其他概念

11、的管理一致性問題。</p><p>　　2.1 J2EE部署API的實(shí)現(xiàn)</p><p>　　軟件的熱重新部署在J2EE（Java 2企業(yè)版的軟件組件）平臺由J2EE產(chǎn)品供應(yīng)商作為一個為組件開發(fā)者不斷在運(yùn)行環(huán)境中執(zhí)行測試的可選功能而實(shí)施。因此，熱重新部署和實(shí)際操作，可能是無效的現(xiàn)有用戶會話。松動會話狀態(tài)不是很關(guān)鍵在而調(diào)試和測試組件，對開發(fā)商沒有問題。在生產(chǎn)系統(tǒng)，揭露他們的服務(wù)真正的用戶，部

12、署是一個時間和錯誤敏感的過程。而方案的正確性，只有部分被部署過程的影響，在處理部署問題時，時間是一個重要因素。在大多數(shù)情況下，維持生產(chǎn)系統(tǒng)的停機(jī)時間被認(rèn)為是一個大問題，因?yàn)槠渌臉I(yè)務(wù)流程依賴著系統(tǒng)可用性。</p><p>　　部署API規(guī)范作為新的J2EE 1.4 [5]需要更進(jìn)一步重新部署的概念，以對用戶是透明從而允許它在生產(chǎn)系統(tǒng)中使用。在一個運(yùn)行的系統(tǒng)沒有使無效的會話情況下執(zhí)行配置變化的可能會明顯減少停機(jī)的時

13、間。</p><p><b>　　圖2-2 重構(gòu)管理</b></p><p>　　但是，沒有任何J2EE應(yīng)用服務(wù)器包括一個API規(guī)范的工作部署落實(shí)。我們的項(xiàng)目“部署的J2EE API實(shí)現(xiàn)”[4]開發(fā)了一個JBoss應(yīng)用服務(wù)器API實(shí)現(xiàn)的技術(shù)基礎(chǔ)。我們現(xiàn)在的工作在規(guī)格說明中標(biāo)注是可選的，就是實(shí)施重新部署的功能。這種API執(zhí)行的結(jié)果將會完整的集成到一個完整的系統(tǒng)使能在產(chǎn)品

14、系統(tǒng)建立配置、部署、重構(gòu)J2EE應(yīng)用程序。</p><p>　　我們將我們的系統(tǒng)取名為PIRMA（平臺獨(dú)立重構(gòu)經(jīng)理）,它是激活重構(gòu)的請求。它包括以下四個一流水平：重構(gòu)分析儀，依賴管理，一致性管理器和重構(gòu)組件。我們的部署在J2EE API實(shí)現(xiàn)覆蓋了重構(gòu)基本功能，并為一致性管理提供了一個接口。</p><p>　　2.1.1 執(zhí)行部署的基本原則</p><p>　　我們

15、的項(xiàng)目利用了JBoss的攔截器堆棧技術(shù)的潛力，以支持重新部署。在JBoss服務(wù)器中每個J2EE組件被部署在一個容器管理的組成部分。該容器配置了一系列處理配置系統(tǒng)級的EJB組件攔截對象，它們分別是：事務(wù)劃分，持久性，認(rèn)證，授權(quán)、遠(yuǎn)程通信以及實(shí)例池選擇鏈。其他的攔截器鏈的責(zé)任是調(diào)用這些路由，日志，并作為特別關(guān)心的問題是管理容器攔截關(guān)機(jī)操作。清潔關(guān)機(jī)攔截的責(zé)任是等待組件容器配置的完成，并拒絕再調(diào)用。我們計(jì)劃使用類似的機(jī)制，支持透明的重新部署行

16、動。新推出的攔截器可以讓任何開創(chuàng)了新的交易完成但新的同步調(diào)用等待一些障礙的杰出調(diào)用。在容器中調(diào)用完成后該組件將被新版本組件取代。不同的是清潔關(guān)機(jī)攔截?zé)o視該行動的事務(wù)屬性被調(diào)用，新的攔截器攔截了被配置為啟動新的交易業(yè)務(wù)。</p><p>　　因此，保證交易完成，沒有配置變化而進(jìn)行的交易運(yùn)行。不用說，有這樣的調(diào)動可以在配置更改一些限制。部署API規(guī)范指出，必須繼續(xù)運(yùn)行一個J2EE模塊同樣要成功地調(diào)動配置。但是，此限制

17、可能會在一定程度上削弱。它應(yīng)該是可能的支持結(jié)構(gòu)的變化，以模塊部分符合一定的要求。該組件的類型決定的標(biāo)準(zhǔn)組件來滿足，因此組件著扮演是否是安全的結(jié)構(gòu)性改變或不區(qū)分關(guān)鍵作用。</p><p>　　會話bean類型EJB組件是由創(chuàng)建它們的客戶端定義擴(kuò)展。 EJB規(guī)范定義了兩種這樣的組件類型。一個有狀態(tài)會話bean實(shí)例包含必須在方法和交易的保留的會話狀態(tài)。會話bean容器有時需要轉(zhuǎn)變beans的性能原因二級存儲狀態(tài)。這種轉(zhuǎn)

18、移稱為鈍化。作者把beans復(fù)活操作稱為激活。為了支持這項(xiàng)工作，由會話Bean類型實(shí)現(xiàn)的該接口包含容器調(diào)用告知其鈍化或激活一個組成部分的回調(diào)方法。它的實(shí)例有責(zé)任保證從一個使返回鈍化方法的領(lǐng)域?qū)崿F(xiàn)Java序列化存儲。由于序列化的序列化類型的結(jié)構(gòu)，有狀態(tài)會話bean的依賴是不可靠的結(jié)構(gòu)變化。無狀態(tài)會話Bean組件類型不包含方法調(diào)用之間的對話狀態(tài)。因此這種類型的bean實(shí)例是可互換的。由于在切換組件的版本時沒有需要保存的狀態(tài)信息，就不會有重新

19、部署問題。另一方面，作為會話bean的客戶端擴(kuò)展，其結(jié)構(gòu)是納入自己的客戶，因此一個無狀態(tài)會話bean只能被由（不變）遠(yuǎn)程客戶端引用的bean部署。這始終是本地EJB組件處理的情況（見第6.5章的EJB規(guī)范）。</p><p>　　一個實(shí)體bean類型EJB組件是信息實(shí)體的面向?qū)ο蟮挠^點(diǎn)，就像一個人或一個賬戶，存儲在數(shù)據(jù)庫或現(xiàn)有企業(yè)應(yīng)用程序。由于一個實(shí)體bean是一個位于其他地方的數(shù)據(jù)視圖，它不包含任何狀態(tài)。根據(jù)容

20、器的配置也可能被緩存在應(yīng)用服務(wù)器中，但在任何情形，這是保證該實(shí)體在當(dāng)前交易完成提交后的修改寫入到數(shù)據(jù)存儲系統(tǒng)。在實(shí)體bean組件處理部署是發(fā)生的真正的問題是，當(dāng)其結(jié)構(gòu)的變化，在相關(guān)的持久性存儲數(shù)據(jù)結(jié)構(gòu)的時候也需要改變的。雖然這肯定是可能的，但這樣的操作可能是一個長期運(yùn)行而對用戶透明系統(tǒng)在調(diào)動時不可接受的任務(wù)。一種可能的解決方案是備用數(shù)據(jù)存儲與第一個數(shù)據(jù)庫存儲。備用數(shù)據(jù)存儲，然后可用于持久性的實(shí)體的新版本。該數(shù)據(jù)存儲交換機(jī)通過為實(shí)體的新版

21、本配置完成新的資源管理器。如果EJB組件是由（不變）遠(yuǎn)程客戶端引用，這又是不可能改變的EJB組件結(jié)構(gòu)。</p><p>　　消息驅(qū)動bean類型的組件有沒有客戶端可見的身份。一個消息驅(qū)動bean中沒有會話狀態(tài)的特定客戶，但他們當(dāng)然可能包含說明的客戶端郵件處理有效的實(shí)例變量。然而，EJB規(guī)范指出，一個消息驅(qū)動Bean的所有實(shí)例，相當(dāng)于一個消息因而可能會被發(fā)送到任何實(shí)例。作為一個消息驅(qū)動Bean是一個異步消息接收器，

22、重新部署行動可能會暫時禁用郵件路由和交換相關(guān)的bean的定義。</p><p>　　上述意見現(xiàn)在可以概括：是否有一個EJB組件是安全的結(jié)構(gòu)性變化（即界面改性的區(qū)別），是否能夠歸結(jié)到（不變）遠(yuǎn)程客戶持有，是否是含有引用會話狀態(tài)。要檢測一個組件是安全的配置改變（甚至取消），再一次攔截是可取的，這次截獲的組成部分主接口是用來創(chuàng)建（EJBHome），查找和刪除處理（存根）到EJB對象。</p><p&

23、gt;　　2.1.2 相關(guān)研究</p><p>　　JBoss的開源項(xiàng)目本身就以研究部署API實(shí)現(xiàn)開始。作為一個新的項(xiàng)目，目前的資源是不完整和不包括任何調(diào)動的支持。無論如何，該項(xiàng)目是更新非常頻繁，一定會產(chǎn)生一些有趣的發(fā)展。</p><p>　　另一個開源項(xiàng)目叫Ishmael，該工程研究Jonas J2EE服務(wù)器[OBJ 04]的執(zhí)行情況。雖然該項(xiàng)目是在ObjectWeb的注冊網(wǎng)站追溯到20

24、02年10月，但仍然認(rèn)為是alpha版本，不支持當(dāng)前的服務(wù)器版本。看來這個項(xiàng)目的發(fā)展幾乎停止。無論如何，在我們項(xiàng)目的J2EE部署API實(shí)現(xiàn)'[4]追溯到2003年夏天段，有些設(shè)計(jì)決定是受Ishmael的源代碼的影響。</p><p><b>　　3 小結(jié)</b></p><p>　　一個實(shí)現(xiàn)了在運(yùn)行時允許在組件之間的依賴關(guān)系基于組件的系統(tǒng)重構(gòu)的方法被提出了。我

25、們使用一個元模型，描述了系統(tǒng)提供的運(yùn)行時行為，也是我們高水平架構(gòu)的重構(gòu)管理器。圖2-2，作為一個J2EE技術(shù)實(shí)現(xiàn)平臺是就業(yè)。目前，我們的工作是為J2EE系統(tǒng)執(zhí)行J2EE應(yīng)用的運(yùn)行時重構(gòu)。這份文件的特殊重點(diǎn)介紹我們在實(shí)施一個使部署和重新部署的基于J2EE部署API的J2EE模塊的子系統(tǒng)，。預(yù)測未來的工作包括在重構(gòu)為一個特定的時間請求重構(gòu)的最佳點(diǎn)的模擬方法的考慮。</p><p><b>　　4 參考文獻(xiàn)&

26、lt;/b></p><p>　　[1] MATEVSKA - j的邁耶，哈塞爾伯林W.和REUSSNER“開發(fā)加快基于構(gòu)件的運(yùn)行時重構(gòu)系統(tǒng)協(xié)議信息?！?，在法律程序上的車間面向構(gòu)件編程WCOP 2003年，德國達(dá)姆施塔特2003年7月。達(dá)姆施塔特技術(shù)大學(xué)。</p><p>　　[2] MATEVSKA - j的邁耶，哈塞爾伯林W.和REUSSNER，“軟件體系結(jié)構(gòu)描述支持部門的部署和

27、系統(tǒng)運(yùn)行時重構(gòu)”，在法律程序上的車間面向構(gòu)件編程WCOP 2004年，奧斯陸，挪威， 2004年6月。奧斯陸大學(xué)。</p><p>　　[3] IBM公司，http://www-3.ibm.com/software/webservers/appserv/doc/v40，WebSphere應(yīng)用服務(wù)器文檔，2003年6月。</p><p>　　[4] OLLIGES南，部署的J2EE API實(shí)

28、現(xiàn)，學(xué)生項(xiàng)目，奧爾登堡大學(xué)，德國，計(jì)算科學(xué)系，軟件工程組，2004年1月。</p><p>　　[5] Sun微系統(tǒng)，http://java.sun.com/j2ee/，Java 2平臺企業(yè)版規(guī)范，版本1.4，2003。 </p><p>　　Runtime Reconfiguration of J2EE Applications</p><p>　　Jasmink

29、a Matevska-Meyer, Sascha Olliges, Wilhelm Hasselbring</p><p>　　Department of Computing Science, Software Engineering Group, University of Oldenburg, 26121 Oldenburg, Germany </p><p>　　matevska-m

30、eyer@informatik.uni-oldenburg.de,</p><p>　　olliges@informatik.uni-oldenburg.de,</p><p>　　hasselbring@informatik.uni-oldenburg.de</p><p>　　ABSTRACT: Runtime reconfiguration considere

31、d as “applying required changes to a running system” plays an important role for providing high availability not only of safety- and mission-critical systems, but also for commercial web-applications offering professiona

32、l services. Hereby, the main concerns are maintaining the consistency of the running system during reconfiguration and minimizing its down-time caused by the reconfiguration. This paper focuses on the platform independen

33、t subsystem that </p><p>　　KEY-WORDS: component-based software engineering, deployment, dynamic/autonomic reconfiguration/adaptation</p><p>　　1 Introduction</p><p>　　The permanent c

34、hange of requirements on software systems necessitates their evolution. Reengineering approaches aim at a reasonable re-design of the system and variability management approaches concentrate on designing systems which in

35、clude variation points for post-deployment system adaptation. Runtime reconfiguration as applying required changes to a running system plays an important role for providing high availability of software systems. Main iss

36、ues are maintaining the consistency of the sy</p><p>　　Our approach to runtime reconfiguration concerning the deployment called controlled runtime redeployment presents an extension of the concepts of hot de

37、ployment and dynamic reloading [IBM 03]. Additionally, we consider consistent structural changes of the running system [MAT 03:2]. </p><p>　　This paper is organised as follows. First, we briefly present our

38、 approach to enabling reconfiguration of component-based systems at runtime (Section 3); next, we propose a system architecture (Figure 1). In Section 2.1 we present our implementation of the J2EE Deployment API [OLL 04]

39、. Finally, we conclude and indicate further work in Section 3.</p><p>　　2 Enabling Reconfiguration of Component-Based Systems at Runtime</p><p>　　We aim at reconfiguration of component-based sys

40、tems at runtime as applying required changes to a running system. We distinguish between three different types of reconfiguration according to their reconfiguration effort: (1) functional, (2) nonfunctional, and (3) stru

41、ctural. All types of reconfiguration can occur on different levels of granularity (i.e., can address the entire system or a single sub-component). Functional reconfigurations include changes to the functionality of a sin

42、gle componen</p><p>　　We observe a running system at a particular time interval from receiving a reconfiguration request until reconfiguration completion. In an already deployed and running system we determi

43、ne time-constrained use dependencies among instances of components, which are constrained by specified structural dependencies and specified or derived component protocol information. Knowing the current state of all pos

44、sibly affected components, and their future behaviour, we can exclude past dependencies and lat</p><p>　　Figure 1. C3-Meta Model</p><p>　　Our meta-model in Figure 1, described in [MAT 03:3] pres

45、ents a Composite [GAM 95] structural static and runtime view of the system, thus enabling hierarchical decomposition of the system behaviour and its consistency check and composition after reconfiguration.</p>&l

46、t;p>　　For this paper container components are the essential extension to establish modelling of deployment and runtime properties of the system. A container provides the runtime environment for the live components [OM

47、G 03, SUN 03] To describe the runtime behaviour of the system we use service effect automata (as specified in [REU 03]). For determining the reconfiguration point in time we propose a special extension of message sequenc

48、e charts called live sequence charts [DAM 01] because they can expres</p><p>　　Finally, applying required changes to an already deployed and running system usually triggers changes in a system configuration

49、and implies its reconstruction and redeployment to obtain a consistent system after reconfiguration. A major problem to be solved here is managing runtime dependencies among the components. Our concept of controlled runt

50、ime redeployment presents an extension of the concepts of hot deployment and dynamical reloading [IBM 03]. We additionally allow structural changes of t</p><p>　　2.1 Implementation of the J2EE Deployment API

51、</p><p>　　Hot redeployment of software components in the J2EE (Java 2 Enterprise Edition) platform is implemented by the J2EE product providers as an optional feature for component developers who continuousl

52、y need to execute tests in a running environment. As a consequence, hot redeployment was and actually is an operation that potentially invalidates existing user sessions. This is no problem for developers, as loosing the

53、 session state is not critical while debugging and testing components. In productiv</p><p>　　The Deployment API specification [SEA 03] introduced as a part of the new J2EE 1.4 specification [SUN 03] takes th

54、e concept of redeployment one step further by specifying redeployment to be transparent to users thus allowing it to be used in productive systems. The possibility to perform configuration changes in a running system wit

55、hout invalidating running sessions will significantly reduce its downtime.</p><p>　　Figure 2. Reconfiguration Manager</p><p>　　However, no J2EE application server includes a working implementati

56、on of the Deployment API specification yet. Our project “J2EE Deployment API Implementation” [OLL 04] developed the technical basis for an API implementation for the JBoss Application Server. We now work on implementing

57、the redeployment functionality which is marked optional in the specification. The resulting API implementation will then be integrated into a complete system enabling configuration, reconfiguration, deployment and</p&

58、gt;<p>　　We name our system PIRMA (Platform Independent Reconfiguration Manager). It is activated on reconfiguration requests. It consists of the following four top-level components [MAT 03]: Reconfiguration Analy

59、ser, Dependency Manager, Consistency Manager and Reconfigurator. Our implementation of the J2EE Deployment API covers the fundamental functionality of the reconfigurator and provides an interface to the consistency manag

60、er.</p><p>　　2.1.1 Basic concepts of the Redeployment Implementation</p><p>　　Our project exploits the potentials of the JBoss interceptor stack technology [STA 02] to support redeployment. In J

61、Boss server each J2EE component is deployed inside a manageable container component. That container is configured with a chain of interceptor objects that handle the configurable system-level aspects of an EJB component

62、which are: transaction demarcation, persistence, authentication, authorization and remote communication as well as instance pooling and optionally clustering. Other</p><p>　　Session bean type EJB components

63、are by definition extensions of the client that created them. The EJB specification [SUN 03:2] defines two types of such components. A stateful session bean instance contains conversational state that must be retained ac

64、ross methods and transactions. The session bean container sometimes needs to transfer the state of the hosted beans to secondary storage for performance reasons. This transfer is called passivation. The operation of brin

65、ging beans back to life is </p><p>　　An entity bean type EJB component is an object-oriented view of information entities, like a person or an account for example, that are stored in a database or an existin

66、g enterprise application. As an entity bean is a view on data located elsewhere, it contains no state. Depending on the container's configuration it may be cached in the application server, but under any circumstance

67、s it is guaranteed that modifications to the entity are written to the data store when the current transaction is </p><p>　　Message driven bean type components have no client-visible identity. A message driv

68、en bean contains no conversational state specific to a client, but they of course may contain instance variables that constitute state valid across the handling of client messages. However, the EJB specification [SUN 03:

69、2] states that all instances of a message driven bean are equivalent and therefore a message may be send to any instance. As a message driven bean is by definition an asynchronous message receiver,</p><p>　　

70、The above observations now can be summarized: The distinction of whether an EJB component is safe to structural change (i.e. interface modification) or not can be boiled down to the question whether (unchanged) remote cl

71、ients hold references to it or not and if it contains conversational state or not. To detect if a component is safe to configuration change (or even removal) another interceptor may be introduced, this time intercepting

72、invocations of the components home interface (EJBHome) which</p><p>　　2.1.2 Related Work</p><p>　　The JBoss open source project itself started to work on an implementation of the Deployment API

73、. Being a new project, the current sources are incomplete and do not (yet) include any support for redeployment. Anyway, the project is updated quite frequently and will surely yield some interesting developments.</p&

74、gt;<p>　　Another open source project called Ishmael [ISH 04] works on an implementation for the JOnAS J2EE Server [OBJ 04]. Though the project was registered at the ObjectWeb website back in October 2002, it is st

75、ill considered an alpha release and does not support the current server version. It seems the project’s development has nearly stopped. Anyway, in the early development phases of our project ‘J2EE Deployment API Implemen

76、tation’ [OLL 04] back in summer 2003, some design decisions were influenced </p><p><b>　　3 Summary</b></p><p>　　An approach to enabling reconfiguration of component-based systems at

77、runtime allowing changes of the dependencies among components is presented. We use a meta model which provides description of the system runtime behaviour and a highlevel architecture of our reconfiguration manager (Figu

78、re 2). As an implementation platform J2EE Technology [SUN 03] is employed. Currently, we work on an implementation of a J2EE system for runtime reconfiguration of J2EE applications. A special focus of this pape</p>

79、<p>　　4 Bibliography</p><p>　　[DAM 01] DAMM W. and HAREL D. LSCs: “Breathing life into message sequence charts.” Formal Methods in System Design, 19(1):45–80, 2001.</p><p>　　[GAM 95] GAMM

80、A, HELM, JOHNSON, and VLISSIDES, Design Patterns Elements of Reusable Object-Oriented Software, Object-Oriented Technology, Addison-Wesley, Massachusetts, 1995.</p><p>　　[IBM 03] IBM, http://www-3.ibm.com/so

81、ftware/webservers/appserv/doc/v40, WebSphere Application Server Documentation, June 2003.</p><p>　　[ISH 04] ISHMAEL project website, http://forge.objectweb.org/projects/ishmael, retrieved 31 August 2004.<

82、/p><p>　　[MAT 03] MATEVSKA-MEYER J. and HASSELBRING W., “Enabling reconfiguration of component-based systems at runtime.”, in J. B. J. van Gurp, editor, Proceedings of Workshop on Software Variability Managemen

83、t, pages 123–125, Groningen, The Netherlands, Feb. 2003. University of Groningen.</p><p>　　[MAT 03:2] MATEVSKA-MEYER J., HASSELBRING W., and REUSSNER R.“Exploiting protocol information for speeding up runtim

84、e reconfiguration of componentbased systems.”, in Proceedings of Workshop on Component-Oriented Programming WCOP 2003, Darmstadt, Germany, July 2003. Technical University of Darmstadt.</p><p>　　[MAT 03:3] MA

85、TEVSKA-MEYER J., HASSELBRING W., and REUSSNER R., “Software architecture description supporting component deployment and system runtime reconfiguration”, in Proceedings of Workshop on Component-Oriented Programming WCOP

86、2004, Oslo, Norway, June 2004. University of Oslo.</p><p>　　[OBJ 04] ObjectWeb, Java Open Application Server, http://jonas.objectweb.org, retrieved 31 August 2004.</p><p>　　[OLL 04] OLLIGES S.,

87、J2EE Deployment API Implementation, Student Project, University of Oldenburg, Germany, Department of Computing Science, Software Engineering Group, Jan 2004.</p><p>　　[OMG 03] Object Management Group OMG, CO

88、RBA Component Model, V3.0, 2003, http://www.omg.org/technology/documents/formal/components.htm.</p><p>　　[REU 03] REUSSNER R. H., “Automatic component protocol adaptation with the coconut tool suite”, Future

89、 Generation Computer Systems, 19(5):627–639, 2003.</p><p>　　[SEA 03] SEARLS R., J2EE Deployment API Specification, Version 1.1, Sun Microsystems, http://java.sun.com/j2ee/tools/deployment/, Nov. 2003. Retrie

90、ved 2004-03-30.</p><p>　　[STA 02] STARK S, JBoss Administration and Development, JBoss Group, July 2002.</p><p>　　[SUN 03] Sun Microsystems, http://java.sun.com/j2ee/, Java 2 Platform, Enterpris