j2ee應用的運行重構-外文翻譯

1、<p>　　J2EE應用的運行重構</p><p>　　亞斯明卡 瑪特威斯卡-梅耶，薩沙 奧里格斯，威廉哈塞爾伯林</p><p>　　計算機科學系，軟件工程組，奧爾登堡大學，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>　　摘 要：改變運行系統(tǒng)的運行時重構，不僅在安全和關鍵任務系統(tǒng)方面起著提供高可用性的一個重要角色，而且對商業(yè)網(wǎng)絡應用提供專業(yè)服務。據(jù)此，主要的關切點是維持在由重構時導致的在重新配置和最大限度地減少其停機期間

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

28、現(xiàn)，學生項目，奧爾登堡大學，德國，計算科學系，軟件工程組，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