包曉安，張 娜，桂 寧，宋瑾鈺

（浙江理工大學(xué)信息學(xué)院 杭州310018）

1 引言

傳統(tǒng)實(shí)時(shí)系統(tǒng)，如過(guò)程控制系統(tǒng)，通常工作在封閉和高度可預(yù)知的環(huán)境。這些系統(tǒng)也只能提供預(yù)先定義的、固定不變的服務(wù)。只要滿足這些假設(shè)和條件，這種方法能夠高度保證硬實(shí)時(shí)需求得以滿足。然而，越來(lái)越多的系統(tǒng)被應(yīng)用于動(dòng)態(tài)的環(huán)境中，如在云計(jì)算系統(tǒng)中，服務(wù)器的配置不斷地發(fā)生改變。在這樣的動(dòng)態(tài)環(huán)境中，傳統(tǒng)的基于瀑布模型的實(shí)時(shí)應(yīng)用程序開(kāi)發(fā)模式不能有效工作[1]。提供有效的實(shí)時(shí)軟件的重配置支持，提供整個(gè)系統(tǒng)的生命周期中系統(tǒng)配置演變支持，已經(jīng)成為研究的熱點(diǎn)問(wèn)題。

這種開(kāi)放和不斷演變的執(zhí)行環(huán)境需要新的辦法來(lái)建立和管理實(shí)時(shí)應(yīng)用程序。但是，由于系統(tǒng)資源的缺乏，這些已安裝的應(yīng)用程序通常在一定程度上是互相依存的，不同的應(yīng)用程序會(huì)相互競(jìng)爭(zhēng)CPU、內(nèi)存、網(wǎng)絡(luò)或其他系統(tǒng)資源。這種依賴性可能會(huì)導(dǎo)致違背實(shí)時(shí)程序不能滿足亟需滿足的實(shí)時(shí)特性指標(biāo)[2]。

傳統(tǒng)的基于實(shí)時(shí)操作系統(tǒng)和實(shí)時(shí)調(diào)度的解決方案無(wú)法應(yīng)對(duì)這樣復(fù)雜的依賴性。系統(tǒng)作業(yè)調(diào)度器本身不可能理解這種高級(jí)別的應(yīng)用程序的相互依賴性。在某種意義上，實(shí)時(shí)操作系統(tǒng)離應(yīng)用程序級(jí)的問(wèn)題太“遙遠(yuǎn)”，因此無(wú)法正確決定自適應(yīng)策略，如選擇哪些組件、預(yù)留哪些資源。對(duì)于云計(jì)算來(lái)說(shuō)，這就意味著系統(tǒng)的調(diào)度程序無(wú)法很好地使用后臺(tái)的服務(wù)器資源。

由設(shè)計(jì)自適應(yīng)實(shí)時(shí)系統(tǒng)的經(jīng)驗(yàn)可知，為了支持動(dòng)態(tài)變化的實(shí)時(shí)應(yīng)用程序，任何一個(gè)有效的解決方案應(yīng)該有以下3個(gè)重要方面[3]。第一，跨應(yīng)用程序的資源需求管理。第二，組件依賴的依賴必須顯式化，包括顯式功能的依賴和由于爭(zhēng)奪有限的可用資源而產(chǎn)生的隱含功能的依賴。第三，系統(tǒng)高層模型應(yīng)該可以被用于驅(qū)動(dòng)相應(yīng)實(shí)時(shí)任務(wù)的較低級(jí)別的管理。

本文從不同的角度解決這些問(wèn)題，引入一種基于結(jié)構(gòu)的管理框架，即聲明實(shí)時(shí)組件的框架（DRCom框架），跨越安裝應(yīng)用程序域。通過(guò)從它的元數(shù)據(jù)及其組件管理接口引出每個(gè)實(shí)時(shí)組件的不同屬性，可以為當(dāng)前實(shí)時(shí)系統(tǒng)構(gòu)建一個(gè)準(zhǔn)確的總體結(jié)構(gòu)模型。為了保證實(shí)時(shí)應(yīng)用程序的某些性能，可根據(jù)不同的適應(yīng)策略對(duì)該模型進(jìn)行映射以調(diào)整低級(jí)實(shí)時(shí)任務(wù)的屬性和狀態(tài)。得益于面向服務(wù)的體系結(jié)構(gòu)，該框架易于用其他依賴解析策略進(jìn)行擴(kuò)展，以處理不同的系統(tǒng)需求。本文定性和定量地證明了本體系結(jié)構(gòu)的有效性，可以用于云計(jì)算的資源調(diào)度管理。

2 軟件架構(gòu)

為了支持動(dòng)態(tài)變化的實(shí)時(shí)應(yīng)用程序，本文提出了一種基于架構(gòu)的自適應(yīng)軟件設(shè)計(jì)模式，即聲明實(shí)時(shí)組件框架（DRCom框架），用以生成自適應(yīng)實(shí)時(shí)應(yīng)用程序。

2.1 架構(gòu)設(shè)計(jì)目標(biāo)

為了在提供實(shí)時(shí)支持的同時(shí)，應(yīng)對(duì)高度動(dòng)態(tài)的運(yùn)行環(huán)境，本文的軟件架構(gòu)提供了3種功能支持，即實(shí)時(shí)組件動(dòng)態(tài)支持、實(shí)時(shí)組件依賴性支持、可自定義的全局自適應(yīng)支持，實(shí)現(xiàn)了將系統(tǒng)生命周期的所有請(qǐng)求當(dāng)作一個(gè)整體進(jìn)行控制管理，能快速得到當(dāng)前系統(tǒng)配置，并能管理軟硬件各組件間兩種類型的依賴，即關(guān)于業(yè)務(wù)邏輯的功能性依賴和關(guān)于QoS需求的非功能性依賴。利用當(dāng)前系統(tǒng)配置以及組件間的功能性和非功能性依賴的相關(guān)描述定義自定義的適應(yīng)策略，并根據(jù)資源的動(dòng)態(tài)可用性和自適應(yīng)策略，采用不同的約束策略。

2.2 系統(tǒng)需求

本模型使用可擴(kuò)展的元數(shù)據(jù)文件中聲明DRCom的各個(gè)實(shí)時(shí)屬性。由于不同的實(shí)時(shí)應(yīng)用程序具有不同的特定的域和功能，不可能提出一個(gè)萬(wàn)能的自適應(yīng)邏輯，因此系統(tǒng)的體系結(jié)構(gòu)必須適應(yīng)不同的環(huán)境。

本框架的設(shè)計(jì)可以使用不同種類的描述語(yǔ)言和適應(yīng)邏輯。用3個(gè)關(guān)鍵模塊，即描述模塊、推理模塊和動(dòng)作模塊，滿足各種需求。描述模塊進(jìn)行依賴關(guān)系和配置說(shuō)明，推理模塊進(jìn)行推理說(shuō)明，動(dòng)作模塊進(jìn)行相應(yīng)的動(dòng)作描述。參考文獻(xiàn)[4]和現(xiàn)有的大多數(shù)研究，都是在運(yùn)行時(shí)靜態(tài)地集成這3個(gè)模塊，與此相反，本框架通過(guò)運(yùn)用面向服務(wù)的模型，將這3個(gè)模塊當(dāng)作服務(wù)提供者來(lái)執(zhí)行，各服務(wù)提供者通過(guò)服務(wù)接口松散耦合。這種設(shè)計(jì)使得未來(lái)復(fù)雜自適應(yīng)模塊可以容易地融入本框架中。

2.3 結(jié)構(gòu)框架

圖1所示為本文所述結(jié)構(gòu)框架的示意。該框架由3個(gè)主要部分組成，分別對(duì)應(yīng)于第2.2節(jié)所述的3個(gè)模塊，其他部分提供輔助性服務(wù)。

其中，資源依賴性表示機(jī)制（自定義語(yǔ)言解析服務(wù)，作為描述模塊）允許開(kāi)發(fā)人員用自定義的語(yǔ)言描述組件依賴性；自定義約束解析服務(wù)（作為推理模塊）允許用戶或管理員指定特定域系統(tǒng)的自適應(yīng)策略；描述性實(shí)時(shí)組件運(yùn)行時(shí)執(zhí)行環(huán)境DRCR（動(dòng)作模塊）是本框架的核心，它管理DRCom實(shí)例并執(zhí)行解析服務(wù)推理出的動(dòng)作，負(fù)責(zé)監(jiān)測(cè)由資源管理服務(wù)和OSGi系統(tǒng)發(fā)出的更改事件，并由DRCR維護(hù)的DRCom實(shí)例注冊(cè)表來(lái)保存已安裝的實(shí)時(shí)組件實(shí)例的信息。

本框架設(shè)計(jì)了一個(gè)完整的組件生命周期模型和一個(gè)相應(yīng)的實(shí)時(shí)組件管理界面。根據(jù)自定義約束解析服務(wù)做出的決策，DRCR完全控制組件的生命周期。自適應(yīng)過(guò)程由組件狀態(tài)更改和外部事件源的通知（如資源管理器或簡(jiǎn)單的周期時(shí)間）觸發(fā)。

3 架構(gòu)組件

實(shí)時(shí)組件說(shuō)明在元數(shù)據(jù)文件中定義，該文件描述了特定實(shí)時(shí)組件的主要特性。此外，本文使用支持復(fù)雜描述語(yǔ)言的混合實(shí)時(shí)組件模型[5]。

在DRCom實(shí)現(xiàn)中，實(shí)時(shí)組件配置表示組件實(shí)例的功能需求和非功能需求。如上所述，框架應(yīng)能夠支持不同的描述語(yǔ)言。但從實(shí)現(xiàn)的角度看，純粹分離的方法意味著事先不了解組件元數(shù)據(jù)格式，這將導(dǎo)致相當(dāng)大的實(shí)現(xiàn)復(fù)雜性和不必要的性能開(kāi)銷。與復(fù)雜的非功能需求相比，組件的功能需求部分有較好的結(jié)構(gòu)和穩(wěn)定性。為了在性能和復(fù)雜度之間達(dá)到一個(gè)平衡點(diǎn)，使用兩相模式描述和處理組件的功能性和非功能性依賴。其中，功能部分由XML（extensible markup language，可擴(kuò)展標(biāo)記語(yǔ)言）定義，由DRCR解析；非功能部分的組件資源的先決條件描述，由外部的自定義解析服務(wù)進(jìn)行解析，并對(duì)已解析的數(shù)據(jù)進(jìn)行處理，然后將結(jié)果發(fā)送到DRCR。

圖2所示為元數(shù)據(jù)文件的一個(gè)片段，其中包含了一個(gè)能夠根據(jù)需要返回用戶感興趣的區(qū)域（一幀圖像數(shù)據(jù)的子集）的智能相機(jī)組件的功能和非功能需求。

其中，name：被用作組件調(diào)用名，因此必須是全局唯一的；enabled：控制組件是否啟用，其默認(rèn)值為真。組件的implementation元素定義組件實(shí)現(xiàn)類的名稱，DRCR通過(guò)引用此屬性創(chuàng)建組件實(shí)例，因此是組件必不可少的元素。組件的inport和outport元素定義通信方法，通過(guò)它們可進(jìn)行組件間數(shù)據(jù)共享。組件可能有0個(gè)或多個(gè)輸入、輸出端口。outport指定實(shí)時(shí)組件所需輸出的內(nèi)容，它包含一個(gè)用作通信調(diào)用的名稱屬性。而除了名稱屬性外，輸入端口還具有以下屬性。interface：通信接口，它可以是共享內(nèi)存、實(shí)時(shí)FIFO導(dǎo)管或郵箱。type：傳輸?shù)牡臄?shù)據(jù)類型，可以是整型或字節(jié)。size：數(shù)據(jù)類型的基數(shù)。與outport相比，inport有一個(gè)額外屬性，即optional屬性，該屬性顯示此端口依賴性是否是組件執(zhí)行所必需的。此外，組件描述也可以有許多屬性，可以通過(guò)管理接口來(lái)利用這些屬性元素配置實(shí)時(shí)組件實(shí)例。

4 約束關(guān)系解析

本文實(shí)時(shí)組件框架的一個(gè)關(guān)鍵過(guò)程是約束關(guān)系解析，它負(fù)責(zé)識(shí)別實(shí)時(shí)組件之間以及資源之間的關(guān)系，并根據(jù)當(dāng)前系統(tǒng)環(huán)境推斷出系統(tǒng)可能的反應(yīng)。

當(dāng)系統(tǒng)配置更改時(shí)，例如，有新的實(shí)時(shí)組件的出現(xiàn)或者資源管理服務(wù)組件提示有明顯的資源變化，DRCR將被激活。首先它將檢查已有的 DRCom約束和依賴；如果功能部分成功通過(guò)檢查并滿足要求，DRCR將判定是否能在不危害其他組件實(shí)時(shí)合同的有效性的條件下滿足組件的非功能需求，如果能夠滿足，這一新組件將被激活。

為了與兩相DRCom配置一致，運(yùn)用兩相約束解析。一個(gè)是功能依賴解析相，用于在發(fā)生系統(tǒng)更改時(shí)檢查各個(gè)實(shí)時(shí)組件功能依賴；另一個(gè)是自定義約束關(guān)系解析相，由于本框架使用OSGi面向服務(wù)的模型，因此系統(tǒng)管理員可以通過(guò)注冊(cè)自定義的解析服務(wù)改變系統(tǒng)解析行為，以適應(yīng)特定的系統(tǒng)配置。

4.1 功能依賴解析

功能依賴解析主要包括以下的兩個(gè)步驟。

（1）循環(huán)檢測(cè)

應(yīng)用程序中由實(shí)時(shí)組件構(gòu)成，通?？梢越橐粋€(gè)組件聯(lián)通圖，該圖通常是有向無(wú)環(huán)圖。在任務(wù)路徑上，組件上的任務(wù)具有一組輸出，這組輸出是該路徑上下一組件上的任務(wù)的一組輸入。一組組件描述可創(chuàng)建一個(gè)循環(huán)依賴，此時(shí)至少有一個(gè)組件的配置不能得到滿足，當(dāng)DRCR試圖滿足組件配置時(shí)，它將檢測(cè)循環(huán)引用。這時(shí)，DRCR運(yùn)行時(shí)將記錄一條錯(cuò)誤消息，且不激活任何可能創(chuàng)建循環(huán)依賴的組件配置。

（2）端口兼容性檢測(cè)

為了滿足功能性依賴，所有已啟用和激活的組件輸入端口應(yīng)有相應(yīng)的輸出端口。這意味著它們的端口名稱、接口類型、數(shù)據(jù)類型和數(shù)據(jù)大小應(yīng)完全匹配。圖2中的智能相機(jī)端口需要一個(gè)“windowsposition”輸入端口。為了滿足端口的兼容性檢查，名稱為“ua.pats.trajectory.windows”的已激活的組件實(shí)例和按如下定義的輸出端口必須已經(jīng)在注冊(cè)表中部署和啟用。

4.2 自定義解析過(guò)程

在實(shí)際環(huán)境中，根據(jù)資源的動(dòng)態(tài)可用性和系統(tǒng)特定需求，需要不同的資源描述方法。因此將自定義解析服務(wù)設(shè)計(jì)為面向服務(wù)的模型，以提供可自定義的支持。

通過(guò)使用不同的自定義解析服務(wù)提供者，系統(tǒng)行為可以在不更改應(yīng)用程序主要功能邏輯的情況下輕易地改變，這緩解了重新編譯和加載整個(gè)應(yīng)用程序的需要。一個(gè)基本的解析策略是，必須在激活組件配置之前滿足所有基本的資源需求。不管怎樣，運(yùn)用特定的上下文或依賴性知識(shí)，可以進(jìn)行更加靈活、復(fù)雜的解析，例如，通過(guò)停止低優(yōu)先級(jí)任務(wù)或具有可選端口需求的任務(wù)，給高優(yōu)先級(jí)實(shí)時(shí)組件釋放更多資源。此外，某些規(guī)則引擎，如Jess[6]，也可以集成到解析服務(wù)中。

多個(gè)自定義解析服務(wù)提供商可以共存于本系統(tǒng)中，DRCR會(huì)選擇一個(gè)與當(dāng)前系統(tǒng)環(huán)境相匹配的候選服務(wù)提供者。在當(dāng)前實(shí)現(xiàn)中，系統(tǒng)上下文是一個(gè)由管理員管理的全局屬性，下面筆者利用上下文推理策略，獲取更準(zhǔn)確、靈活的上下文信息，以便使用更適當(dāng)?shù)淖远x解析服務(wù)。

4.3 自適應(yīng)配置時(shí)序圖

圖3所示為自適應(yīng)軟件框架的動(dòng)態(tài)調(diào)整時(shí)序。本方案中，組件B需要用組件A的輸出滿足其功能約束。由于組件A配置已經(jīng)存在實(shí)例（ComAInstance），因此DRCR將成功解析B的功能約束。然后訪問(wèn)內(nèi)部解析服務(wù)和外部自定義服務(wù)，如果兩個(gè)服務(wù)均返回積極結(jié)果，DRCR將根據(jù)組件B的配置創(chuàng)建并激活它的實(shí)例 （ComBInstance）。如果ComAInstance被停止，DRCR將得到通知，并再次請(qǐng)求其內(nèi)部和外部自定義服務(wù)以檢測(cè)新的滿足或不滿足條件的組件實(shí)例，當(dāng)DRCR發(fā)現(xiàn)ComBInstance目前尚未滿足，那么ComBInstance將被禁用。

5 系統(tǒng)仿真

本文使用基于場(chǎng)景的仿真，測(cè)試基于框架的自適應(yīng)軟件的動(dòng)態(tài)調(diào)整模式，并定性和定量地驗(yàn)證所提的框架的特性。

5.1 系統(tǒng)實(shí)現(xiàn)

系統(tǒng)使用OSGi[7]框架作為實(shí)現(xiàn)平臺(tái)。OSGi技術(shù)一個(gè)是通用中間件平臺(tái)，其開(kāi)放標(biāo)準(zhǔn)簡(jiǎn)化了新功能和服務(wù)的引入。筆者的基本開(kāi)發(fā)平臺(tái)是Equinox，它是Eclipse組織開(kāi)發(fā)的免費(fèi)開(kāi)放源OSGi平臺(tái)。組件實(shí)現(xiàn)中，使用DRCom模型，該模型最初是為動(dòng)態(tài)可配置的反射實(shí)時(shí)系統(tǒng)的建模而設(shè)計(jì)的，它有一個(gè)基本的管理界面，能夠統(tǒng)一管理組件的生命周期和屬性，每個(gè)組件都與一個(gè)記錄其抽象概念（如通信接口、屬性以及引用約束）的元數(shù)據(jù)文件相關(guān)聯(lián)。這種方法提供了一種元數(shù)據(jù)級(jí)的反射和自檢，每個(gè)組件都標(biāo)記了任務(wù)相關(guān)的配置和驗(yàn)證信息。

5.2 模擬配置

由一個(gè)仿真的機(jī)頂盒系統(tǒng)進(jìn)行模擬。該機(jī)頂盒系統(tǒng)運(yùn)行2個(gè)應(yīng)用軟件，一個(gè)是電視應(yīng)用程序，一個(gè)是視頻文件轉(zhuǎn)換工具。各個(gè)軟件的核心模塊（解碼器和轉(zhuǎn)碼器）的執(zhí)行組件都是以周期任務(wù)的形式執(zhí)行。電視應(yīng)用程序的解碼組件由一個(gè)周期為33.37 ms的實(shí)時(shí)任務(wù)實(shí)現(xiàn)，其優(yōu)先級(jí)為2、執(zhí)行時(shí)間約8 ms、截止時(shí)間為12 ms；轉(zhuǎn)碼器組件由一個(gè)周期為50 ms的實(shí)時(shí)任務(wù)實(shí)現(xiàn)，其優(yōu)先級(jí)為1、執(zhí)行時(shí)間約1 ms、截止時(shí)間為30 ms。其中，RTAI系統(tǒng)使用的計(jì)劃策略是FIFO。為了顯示這兩個(gè)組件之間的相互作用，其他組件只占用少量的CPU時(shí)間進(jìn)行實(shí)現(xiàn)。此外，傳輸方法是異步的（共享內(nèi)存），這樣就能夠重點(diǎn)研究?jī)蓚€(gè)編碼模塊的性能。

由于視頻解碼執(zhí)行時(shí)間會(huì)隨著視頻流內(nèi)容的變化而改變，為了更加清晰地表明不同應(yīng)用程序之間的相互影響，用一個(gè)在每輪計(jì)算中使用了同等恒定CPU時(shí)間的計(jì)算函數(shù)代替解碼函數(shù)。

5.3 仿真結(jié)果

對(duì)電視應(yīng)用程序中解碼組件的執(zhí)行時(shí)間進(jìn)行5 000次觀測(cè)，表1顯示了有和沒(méi)有自適應(yīng)框架支持時(shí)組件的執(zhí)行時(shí)間。為了消除冷啟動(dòng)和自適應(yīng)過(guò)程帶來(lái)的影響，在系統(tǒng)啟動(dòng)并能穩(wěn)定執(zhí)行后，才開(kāi)始記錄測(cè)量數(shù)據(jù)。執(zhí)行時(shí)間用微秒（μs）表示。

正常情況下，解碼器的執(zhí)行時(shí)間大多為8 ms左右，有自定義解析服務(wù)（它會(huì)禁用轉(zhuǎn)碼模塊）時(shí)最大執(zhí)行時(shí)間約8.13 ms；沒(méi)有自定義解析服務(wù)時(shí)，系統(tǒng)會(huì)同時(shí)運(yùn)行這兩個(gè)應(yīng)用程序，解碼器任務(wù)執(zhí)行時(shí)間的抖動(dòng)很大，其平均偏差是3 563.2 μs，遠(yuǎn)遠(yuǎn)大于有框架解析機(jī)制時(shí)的 5.23 μs，這最終可能導(dǎo)致視頻解碼任務(wù)的瞬態(tài)時(shí)間問(wèn)題，包括幀缺失、數(shù)據(jù)溢出等。

表1 執(zhí)行時(shí)間的比較

6 結(jié)論和進(jìn)一步工作

本文描述了一種支持運(yùn)行時(shí)自適應(yīng)的軟件設(shè)計(jì)模式，以應(yīng)對(duì)復(fù)雜的實(shí)時(shí)系統(tǒng)的動(dòng)態(tài)演變和連續(xù)調(diào)度問(wèn)題。其中，實(shí)時(shí)合同由組件元數(shù)據(jù)指定，組件實(shí)例由依賴解析服務(wù)和實(shí)時(shí)合同系統(tǒng)管理，DRCR服務(wù)對(duì)當(dāng)前系統(tǒng)配置進(jìn)行全局管理。這種系統(tǒng)能夠推理出系統(tǒng)配置更改的原因，能在遵守指定的實(shí)時(shí)組件實(shí)時(shí)合同的前提下執(zhí)行某些操作，并使得各實(shí)時(shí)組件不必監(jiān)視系統(tǒng)狀態(tài)，就能調(diào)用其他可用的動(dòng)態(tài)實(shí)時(shí)組件。雖然本文所述框架是基于OSGi中間件的，但研究結(jié)果將會(huì)普遍運(yùn)用于其他基于結(jié)構(gòu)的管理系統(tǒng)。

雖然本文描述了一個(gè)為基于組件的應(yīng)用程序提供實(shí)時(shí)屬性的完整方法，但仍有許多地方需要進(jìn)一步研究。其中之一就是如何使用元數(shù)據(jù)來(lái)描述那些組件特有的自適應(yīng)接口和功能，進(jìn)而使系統(tǒng)具有更靈活、更強(qiáng)大的自適應(yīng)能力。

1 Hassan Gomaa,Koji Hashimoto,Minseong Kim,et al.Software adaptation patterns for service-oriented architectures.Proceedings of ACM Symposium on Applied Computing (SAC),Sierre,Switzerland,2010:462～469

2 Gui Ning,Florio V D,Sun Hong,et al.A framework for adaptive real-time applications:the declarative real-time OSGi component model.Proceedings of the 7th Workshop on Adaptive and Reflective Middleware(ARM),Leuven,Belgium,2008:35～40

3 Gui Ning,Florio V D,Sun Hong,et al.A hybrid real-time component model for reconfigurable embedded systems.Proceedings of the 2008 ACM Symposium on Applied Computing,Fortaleza,Brazil,2008:1509～1596

4 Santambrogio M D,Rana V,Beretta I,et al.Operating system runtime managementofpartially dynamically reconfigurable embedded systems.Proceedings of the 8th IEEE Workshop on Embedded Systems for Real-Time Multimedia,Scottsdale,AZ,United states,2010:1～10

5 Colmenares J A,Kim K H,Zhang Z,et al.Real-time-component based software architecture for QoS-adaptive networked multimedia applications. Proceedings of the 13th IEEE International Symposium on Object,Component,and Service-Oriented Real-Time Distributed Computing (ISORC),Carmona,Seville,Spain,2010:133～142

6 Jess:the rule engine for the Java platform.http://www.jessrules.com/jess/index.shtml

7 OSGi service platform core specification.http://www.osgi.org,2011