移動(dòng)云環(huán)境中基于節(jié)點(diǎn)自適應(yīng)配置的可靠服務(wù)架構(gòu)

，

(國(guó)網(wǎng)天津市電力公司 信息通信公司，天津 300010)

0 引言

移動(dòng)云計(jì)算是一種在移動(dòng)節(jié)點(diǎn)之外進(jìn)行數(shù)據(jù)存儲(chǔ)和處理的基礎(chǔ)架構(gòu)，即利用附近移動(dòng)節(jié)點(diǎn)提供的分布式資源來使用獲得的服務(wù)[1]。這種系統(tǒng)在教育和旅游等應(yīng)用領(lǐng)域有很大的應(yīng)用前景。然而，這些系統(tǒng)通常基于動(dòng)態(tài)網(wǎng)絡(luò)拓?fù)?，其中鏈路斷開和網(wǎng)絡(luò)分區(qū)可能頻繁發(fā)生，因此服務(wù)的可靠性通常會(huì)受到影響?，F(xiàn)有的移動(dòng)云計(jì)算服務(wù)模式主要分為三種[2-4]：傳統(tǒng)的客戶端-服務(wù)器模式，在對(duì)移動(dòng)節(jié)點(diǎn)的處理上，是通過網(wǎng)絡(luò)連接方式將其部分或者全部操作委托給云端處理，自身充當(dāng)云端的常規(guī)客戶端角色。第二種為基于局域移動(dòng)云服務(wù)模式，主要是憑借本地網(wǎng)絡(luò)節(jié)點(diǎn)之間的分布式結(jié)構(gòu)，可以達(dá)到執(zhí)行數(shù)據(jù)的存儲(chǔ)和數(shù)據(jù)處理的目的。但是在缺乏穩(wěn)定性的網(wǎng)絡(luò)連接區(qū)域，會(huì)存在無法與外部云信息交流的問題，此時(shí)軟件架構(gòu)的成功建立就顯得尤其重要。最后一種是混合服務(wù)模式，其中移動(dòng)系統(tǒng)的節(jié)點(diǎn)由本地移動(dòng)云組成，同時(shí)外部云也提供支持。

云計(jì)算中面向服務(wù)的體系結(jié)構(gòu)(Service Oriented Architecture, SOA)[5]與軟件即服務(wù)(Software as a Service, SaaS)的聯(lián)系非常緊密，這是因?yàn)镾OA是軟件系統(tǒng)設(shè)計(jì)和開發(fā)的模型，云計(jì)算和SaaS分別負(fù)責(zé)軟件的實(shí)現(xiàn)和交付。

由于現(xiàn)有的移動(dòng)云計(jì)算服務(wù)模式會(huì)存在電池限制、有限的帶寬、傳輸錯(cuò)誤以及路由開銷等問題，使得系統(tǒng)數(shù)據(jù)的可靠性、安全性、完整性受到不利影響，并且使維護(hù)的成本越來越高[6]。甚至，網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)的動(dòng)態(tài)性還會(huì)影響到網(wǎng)絡(luò)節(jié)點(diǎn)的斷開或關(guān)閉，導(dǎo)致出現(xiàn)鏈路故障，路由更改等。

基于此，本文提出了一種基于節(jié)點(diǎn)自適應(yīng)配置的軟件體系架構(gòu)，旨在提供一個(gè)高效適應(yīng)性的解決方案來支持移動(dòng)云服務(wù)的可靠性。該方案是基于服務(wù)復(fù)制技術(shù)和上下文感知機(jī)制，通過自適應(yīng)配置方法來激活/休眠服務(wù)副本。通過網(wǎng)絡(luò)模擬實(shí)驗(yàn)，驗(yàn)證了所設(shè)計(jì)的軟件架構(gòu)的可行性，提高了網(wǎng)絡(luò)的運(yùn)行效率。另外，通過創(chuàng)建節(jié)點(diǎn)組，使得相鄰節(jié)點(diǎn)可以共享同一個(gè)服務(wù)副本，這樣為提高集群系統(tǒng)的可伸縮性提供了可能。

1 云計(jì)算

云計(jì)算作為一種新出現(xiàn)的商業(yè)計(jì)算模式，從發(fā)展歷程來看，它是繼分布式、并行處理、網(wǎng)格計(jì)算之后誕生的一種全新發(fā)展模式。云計(jì)算的主要服務(wù)形式有軟件即服務(wù)(SaaS)，平臺(tái)即服務(wù)(PaaS)以及基礎(chǔ)設(shè)施服務(wù)(IaaS)[7]。

SaaS即企業(yè)將開發(fā)的應(yīng)用軟件統(tǒng)一部署在自己的服務(wù)器上向用戶提供服務(wù)，主要根據(jù)客戶所定制的軟件服務(wù)時(shí)間長(zhǎng)短和耗費(fèi)資源多少等因素收費(fèi)。優(yōu)勢(shì)是用戶不再需要像以前那樣在資源使用和維護(hù)上花費(fèi)大量資金和人力，只需通過互聯(lián)網(wǎng)即可享受到相應(yīng)的硬件和軟件服務(wù)。PaaS即把開發(fā)環(huán)境作為一種服務(wù)來提供。企業(yè)提供開發(fā)環(huán)境、服務(wù)器平臺(tái)、硬件資源等作為服務(wù)給客戶，客戶可以自主定制專屬的應(yīng)用程序并通過其服務(wù)器和互聯(lián)網(wǎng)傳遞給其他用戶。IaaS即企業(yè)提供云計(jì)算服務(wù)將內(nèi)存、I/O設(shè)備、存儲(chǔ)和計(jì)算能力整合成一個(gè)虛擬的資源池提供給客戶，客戶可以享受到資源的存儲(chǔ)和計(jì)算以及虛擬化服務(wù)器等優(yōu)勢(shì)服務(wù)。從本質(zhì)上講，這是一種托管型硬件方式，而用戶需付費(fèi)才能使用企業(yè)的硬件設(shè)施。

2 提出的移動(dòng)云可靠服務(wù)架構(gòu)

本文提出了一種基于服務(wù)副本管理和節(jié)點(diǎn)自適應(yīng)配置的移動(dòng)云服務(wù)軟件架構(gòu)。該架構(gòu)主要由四部分組成：通信中間件、監(jiān)測(cè)系統(tǒng)、上下文管理器以及副本管理器，如圖1所示。這些組成部分將配置到網(wǎng)絡(luò)中每個(gè)節(jié)點(diǎn)中，并且通過協(xié)調(diào)工作來提供一個(gè)節(jié)能的解決方案，以滿足移動(dòng)云服務(wù)的可靠性。

通信中間件允許系統(tǒng)中不同實(shí)體之間的通信，解決移動(dòng)環(huán)境的異質(zhì)性問題。監(jiān)控系統(tǒng)由不同的監(jiān)控服務(wù)組成。上下文管理器負(fù)責(zé)監(jiān)視每個(gè)節(jié)點(diǎn)及其環(huán)境，收集信息并對(duì)其進(jìn)行處理和存儲(chǔ)。副本管理器根據(jù)移動(dòng)網(wǎng)絡(luò)的當(dāng)前狀態(tài)實(shí)現(xiàn)業(yè)務(wù)副本的激活/休眠配置。

圖1 移動(dòng)云可靠服務(wù)架構(gòu)的組成

2.1 通信中間件

通信中間件允許在兩種不同實(shí)體在不同通信模式下進(jìn)行通信[8]，第一種模式是發(fā)布-訂閱模式，例如，基于推送的通信模型，監(jiān)控服務(wù)通知副本管理器對(duì)感興趣的事件進(jìn)行管理。感興趣的事情如電池的電量級(jí)別降低5%，或活動(dòng)副本不可到達(dá)；第二種模式是請(qǐng)求-響應(yīng)模式，例如，副本管理器請(qǐng)求上下文管理器相關(guān)信息來評(píng)估節(jié)點(diǎn)承載服務(wù)副本的適當(dāng)性，并獲得反映它的分?jǐn)?shù)。這兩種模式的組合通常被稱為SOA2.0，其中服務(wù)不僅是被動(dòng)的實(shí)體，還包括能夠主動(dòng)接收和生成事件。

2.2 監(jiān)測(cè)系統(tǒng)

監(jiān)控系統(tǒng)包含一組監(jiān)控服務(wù)，它感知節(jié)點(diǎn)相關(guān)的上下文信息，以此檢測(cè)可能會(huì)影響服務(wù)可用性的潛在事件。 在提出的架構(gòu)中，對(duì)節(jié)點(diǎn)能力(例如，剩余電量，存儲(chǔ)，內(nèi)存等)和網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)進(jìn)行監(jiān)控。但是，監(jiān)視上下文通常是以高能耗和高帶寬為代價(jià)。一般而言，獲取相關(guān)節(jié)點(diǎn)尤其是本地節(jié)點(diǎn)的信息很容易，但是由于動(dòng)態(tài)網(wǎng)絡(luò)拓?fù)湫枰B續(xù)的監(jiān)測(cè)[9-10]。因此，經(jīng)濟(jì)成本會(huì)隨網(wǎng)絡(luò)的規(guī)模呈現(xiàn)指數(shù)增長(zhǎng)。為此，本文采用路由協(xié)議提供的信息來估計(jì)網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)。在每個(gè)節(jié)點(diǎn)中建立并維護(hù)一個(gè)路由表，其中包含相關(guān)可到達(dá)節(jié)點(diǎn)的信息，以及每個(gè)節(jié)點(diǎn)的網(wǎng)關(guān)和跳數(shù)。通過節(jié)點(diǎn)的直接連接，系統(tǒng)可以估計(jì)它在網(wǎng)絡(luò)拓?fù)渲械奈恢谩?/p>

2.3 上下文管理器服務(wù)

上下文管理器服務(wù)負(fù)責(zé)處理和存儲(chǔ)從檢測(cè)系統(tǒng)接收到的信息。副本管理器通過使用此信息，更改調(diào)整副本的激活/休眠配置。

圖2 自適應(yīng)服務(wù)激活/休眠機(jī)制

圖2顯示了由上下文管理器管理的上下文模型。盡管所有節(jié)點(diǎn)共享相同的上下文模型，但信息存儲(chǔ)主要在本地節(jié)點(diǎn)，只有節(jié)點(diǎn)的分?jǐn)?shù)才能共享，以減少帶寬消耗。另外，除了常見的上下文信息(如網(wǎng)絡(luò)拓?fù)浠螂姵啬芰?之外，本文還利用自適應(yīng)配置算法提高了上下文模型的相關(guān)適應(yīng)性。上下文相關(guān)信息模型主要可以分為三個(gè)子部分：節(jié)點(diǎn)特征，服務(wù)需求和網(wǎng)絡(luò)拓?fù)洹?/p>

2.4 副本管理器

副本管理器通過執(zhí)行自適應(yīng)配置算法以實(shí)現(xiàn)服務(wù)副本激活/休眠的有效配置。遵循基于組件的設(shè)計(jì)，即允許重用組件，甚至在運(yùn)行時(shí)交換這些組件來動(dòng)態(tài)調(diào)整其行為。如圖3所示，它由三個(gè)主要組成部分組成：評(píng)估組件，控制組件和管理器組件。

圖3 副本管理器的結(jié)構(gòu)圖

評(píng)估組件包含評(píng)估函數(shù)，用于協(xié)調(diào)器組件評(píng)估節(jié)點(diǎn)是否適合托管特定服務(wù)。評(píng)估是基于上下文管理器通過上下文信息接口提供的信息。 每個(gè)上下文函數(shù)的權(quán)重將取決于應(yīng)用程序領(lǐng)域和具體情況。例如，如果系統(tǒng)的電池電量不足，則評(píng)估函數(shù)可以動(dòng)態(tài)更改，以便為該上下文特征分配更高的優(yōu)先級(jí)。 因此，可以定義不同的評(píng)估者組件來解決同一應(yīng)用程序域中可能發(fā)生的不同情況。

控制組件包含一組描述副本管理器的觸發(fā)器激活策略規(guī)則。其將通過事件監(jiān)聽接口提供的上下文事件作為輸入。任何規(guī)則的觸發(fā)都會(huì)激活協(xié)調(diào)組件，從而啟動(dòng)自適應(yīng)配置過程。

當(dāng)檢測(cè)到可能影響服務(wù)質(zhì)量屬性的上下文更改時(shí)，管理組件將負(fù)責(zé)與系統(tǒng)中的其他管理員達(dá)成協(xié)議，目的是獲知是否有一個(gè)更好的激活/休眠服務(wù)的副本。自適應(yīng)配置完成后，通過服務(wù)激活接口執(zhí)行副本的激活或休眠。

3 副本管理器中的自適應(yīng)配置算法

副本管理器中不同副本執(zhí)行自適應(yīng)配置算法時(shí)，會(huì)根據(jù)移動(dòng)網(wǎng)絡(luò)的當(dāng)前狀態(tài)實(shí)現(xiàn)服務(wù)副本激活/休眠的高效配置。每個(gè)節(jié)點(diǎn)有三種可能的狀態(tài)：“本地模式”，“客戶端模式”或“服務(wù)器模式”。當(dāng)相鄰節(jié)點(diǎn)中沒有可到達(dá)節(jié)點(diǎn)時(shí)，節(jié)點(diǎn)處于“本地模式”狀態(tài)。而且，當(dāng)上下文的改變觸發(fā)自適應(yīng)配置進(jìn)程修改用于服務(wù)副本激活/休眠的當(dāng)前配置時(shí)，該狀態(tài)被用作初始狀態(tài)。服務(wù)的可用性和系統(tǒng)對(duì)上下文信息變化的反應(yīng)時(shí)間，與“本地模式”狀態(tài)和新狀態(tài)(“客戶端模式”或“服務(wù)器模式”)之間轉(zhuǎn)換所需的時(shí)間成正比。

節(jié)點(diǎn)之間的自適應(yīng)配置基于以下消息的交換：(1)SCORE(得分)，節(jié)點(diǎn)通過這個(gè)消息來傳達(dá)分?jǐn)?shù)，即通過副本管理器中的評(píng)估組件來實(shí)施評(píng)估功能獲得，分?jǐn)?shù)范圍限制在0至1之間，1表示最佳分?jǐn)?shù)；(2)SERVER_REQUEST(服務(wù)請(qǐng)求)，當(dāng)請(qǐng)求節(jié)點(diǎn)想要建立客戶端-服務(wù)器連接時(shí)，使用該消息與接收者節(jié)點(diǎn)進(jìn)行連接，其中請(qǐng)求節(jié)點(diǎn)將作為客戶端而接收者節(jié)點(diǎn)作為服務(wù)器。 接收者節(jié)點(diǎn)是否響應(yīng)此請(qǐng)求，取決于將誰作為服務(wù)器。 如果有另一個(gè)節(jié)點(diǎn)可以作為服務(wù)器，從接收節(jié)點(diǎn)的角度來看，它將拒絕這個(gè)請(qǐng)求。 否則，它會(huì)接受它；(3)SERVER_REJECTION(服務(wù)拒絕)，這個(gè)消息用來回應(yīng)SERVER_REQUEST信息，表示接收者節(jié)點(diǎn)拒絕該請(qǐng)求，即拒絕作為發(fā)送者節(jié)點(diǎn)的服務(wù)器；(4)SERVER_ACCEPTANCE(服務(wù)接受)，此消息用于響應(yīng)SERVER_REQUEST消息，表示接收者節(jié)點(diǎn)接受這個(gè)請(qǐng)求并作為發(fā)行者節(jié)點(diǎn)的服務(wù)器。

用于副本激活/休眠的自適應(yīng)配置算法的偽代碼如算法1所示。

算法1：用于副本激活/休眠的自適應(yīng)配置算法。

1)myscore =計(jì)算得分Score()；

3)等待直到 (接受到得分的數(shù)量 =N或 定時(shí)器到期)；

4)candidateNode= 計(jì)算BestNode()；

5)if candidateNode = myID then

6) state := SERVER_MODE；

7)else

8) 發(fā)送請(qǐng)求到 candidateNode;

9) 等待直到(candidateNode 響應(yīng) 或 定時(shí)器到期)；

10)if定時(shí)器到期then

式中：N為GA操作代數(shù)；Nmax為最大GA代數(shù)；Pc(1)和Pm(1)為初始交叉率和初始變異率；c和m為Pc和Pm的比例系數(shù)

11) 返回步驟 8；

12)elseif接受到SERVER_ACCEPTANCEthen

13) serverID = candidateNode;

14) state = CLIENT_MODE;

15)elseifSERVER_REJECTION具有附加信息then

17) candidateNode =計(jì)算BestNode();

18)elseERVER_REJECTION沒有附加信息then

19) 等待T個(gè)時(shí)刻;

20) 返回步驟8;

當(dāng)一個(gè)節(jié)點(diǎn)開始自適應(yīng)配置時(shí)，第一步是計(jì)算它的分?jǐn)?shù)并將其廣播到組群中。然后，節(jié)點(diǎn)進(jìn)入被動(dòng)模式，等待接收其鄰居的分?jǐn)?shù)。當(dāng)節(jié)點(diǎn)收到鄰居節(jié)點(diǎn)的所有分?jǐn)?shù)或者定時(shí)器到期時(shí)，節(jié)點(diǎn)計(jì)算其中最合適的節(jié)點(diǎn)作為服務(wù)器。在計(jì)算最佳節(jié)點(diǎn)時(shí)，節(jié)點(diǎn)將選擇得分最高的節(jié)點(diǎn)，該節(jié)點(diǎn)可以是其本身。當(dāng)最好的節(jié)點(diǎn) 是節(jié)點(diǎn)本身時(shí)，它將直接進(jìn)入“服務(wù)器模式”，其余節(jié)點(diǎn)都采取相同的決定。這種方法避免了服務(wù)器必須將其選擇結(jié)果傳送給其余節(jié)點(diǎn)，從而改善了系統(tǒng)帶寬。定時(shí)器的使用是因?yàn)橄G失，如果一個(gè)節(jié)點(diǎn)在特定時(shí)間內(nèi)沒有收到鄰居節(jié)點(diǎn)的分?jǐn)?shù)，就可以認(rèn)為該消息已經(jīng)丟失。

4 實(shí)驗(yàn)及分析

4.1 實(shí)驗(yàn)設(shè)置

為驗(yàn)證本文提出的云計(jì)算可靠服務(wù)軟件架構(gòu)體系，構(gòu)建了一個(gè)實(shí)驗(yàn)場(chǎng)景，用來展示系統(tǒng)如何根據(jù)其計(jì)算要求來配置服務(wù)的激活。在這個(gè)例子中有兩個(gè)服務(wù)：服務(wù)A和服務(wù)B。兩者都通過XML文件來給出他們的需求。場(chǎng)景中存在4個(gè)節(jié)點(diǎn)，各節(jié)點(diǎn)的屬性如表1所示。圖4給出了該實(shí)驗(yàn)場(chǎng)景中，具有不同計(jì)算需求的兩種服務(wù)下，系統(tǒng)架構(gòu)中的副本配置過程。

表1 場(chǎng)景中各節(jié)點(diǎn)的屬性

圖4 具有不同計(jì)算需求的兩種服務(wù)的系統(tǒng)架構(gòu)中的副本配置

4.2 結(jié)果分析

實(shí)驗(yàn)場(chǎng)景中，服務(wù)A需要處理能力，而服務(wù)B需要存儲(chǔ)能力。通過對(duì)XML文件進(jìn)行解析，將需求引入到評(píng)估函數(shù)中。在此例中，默認(rèn)的評(píng)估函數(shù)為，

(1)

式中，dC表示節(jié)點(diǎn)直接連接的數(shù)量，其是從節(jié)點(diǎn)路由表提供的信息中獲得。N表示組群中的歸一化節(jié)點(diǎn)數(shù)，范圍為0到1。rB表示歸一化的節(jié)點(diǎn)剩余電量。W1和W2分別表示每個(gè)上下文特征的權(quán)重系數(shù)。本文中，W1和W2的值分別設(shè)置為0.6和0.4。

利用式(1)，將得到的每個(gè)服務(wù)的具體情況作為一個(gè)間隔函數(shù)，其中根據(jù)候選節(jié)點(diǎn)提供的計(jì)算需求范圍，將評(píng)估函數(shù)乘以一個(gè)權(quán)重(Hi和Pi)。本文中，H1和P1的值分別設(shè)置為0.5和0.9。式(2)和式(3)分別表示服務(wù)A和服務(wù)B的評(píng)估函數(shù)，即：

(2)

(3)

在確定每個(gè)服務(wù)器的評(píng)估函數(shù)后，開始執(zhí)行自適應(yīng)配置系統(tǒng)，步驟如下：

1)初始化。在自適應(yīng)配置算法執(zhí)行前，所有節(jié)點(diǎn)均處于“本地模式”狀態(tài)。此時(shí)，兩個(gè)服務(wù)的自適應(yīng)配置過程將并行執(zhí)行。

2)評(píng)估。所有節(jié)點(diǎn)進(jìn)行自我評(píng)估，并把分?jǐn)?shù)傳遞給相鄰節(jié)點(diǎn)。評(píng)估結(jié)果如表2所示。

表2 節(jié)點(diǎn)對(duì)服務(wù)A和B的評(píng)估得分

3)節(jié)點(diǎn)選擇。根據(jù)評(píng)分結(jié)果，節(jié)點(diǎn)1和節(jié)點(diǎn)4將分別轉(zhuǎn)換為服務(wù)A和服務(wù)B的主機(jī)。應(yīng)該注意的是，由于其存儲(chǔ)能力，在其他條件下，節(jié)點(diǎn)3將是服務(wù)B更好的候選者。但是，在這種情況下，節(jié)點(diǎn)3的電池電量不足，導(dǎo)致選擇節(jié)點(diǎn)4作為主機(jī)。

4)最后，獲得配置結(jié)果。即節(jié)點(diǎn)1托管服務(wù)A，節(jié)點(diǎn)2，3和4作為客戶端。節(jié)點(diǎn)4托管服務(wù)B，節(jié)點(diǎn)1，2和3作為客戶端。如本場(chǎng)景所示，定義服務(wù)的計(jì)算需求有助于調(diào)整系統(tǒng)的行為，并為副本的激活/休眠提供更合理的配置，以滿足節(jié)點(diǎn)的計(jì)算特性。

5 結(jié)束語

本文提出了一個(gè)基于服務(wù)副本管理和節(jié)點(diǎn)自適應(yīng)配置的服務(wù)軟件架構(gòu)，通過自適應(yīng)配置算法來激活或休眠副本，有效地緩解了移動(dòng)系統(tǒng)的動(dòng)態(tài)性問題，從而提高了系統(tǒng)的可靠性。尤其對(duì)于無法使用通用網(wǎng)絡(luò)基礎(chǔ)設(shè)施的偏遠(yuǎn)地區(qū)來說，通常需要通過移動(dòng)云中的數(shù)據(jù)存儲(chǔ)和處理服務(wù)來支持不同工作組之間的協(xié)作。下一步的工作計(jì)劃中，將對(duì)利用集群技術(shù)擴(kuò)展架構(gòu)以及在不同路由協(xié)議下的移動(dòng)模型進(jìn)行具體研究，以提高系統(tǒng)的可擴(kuò)展性和靈活性。

[1] 柳 興, 袁超偉, 楊 震,等. 移動(dòng)云計(jì)算中基于移動(dòng)代理的用戶切換與接入控制[J]. 北京郵電大學(xué)學(xué)報(bào), 2014, 37(2):88-92.

[2] 崔 勇, 宋 健, 繆蔥蔥,等. 移動(dòng)云計(jì)算研究進(jìn)展與趨勢(shì)[J]. 計(jì)算機(jī)學(xué)報(bào), 2017, 40(2):273-295.

[3] Fernando N, Loke S W, Rahayu W. Mobile cloud computing: A survey[J]. Future Generation Computer Systems, 2013, 29(1):84-106.

[4] Khan A U R, Othman M, Madani S A, et al. A Survey of Mobile Cloud Computing Application Models[J]. IEEE Communications Surveys & Tutorials, 2014, 16(1):393-413.

[5] 王榮軍, 胡立強(qiáng). 基于云計(jì)算與SOA的IT支撐系統(tǒng)整合研究[J]. 電信技術(shù), 2013, 1(7):11-15.

[6] 張 露, 尚艷玲. 云計(jì)算環(huán)境下資源調(diào)度系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)[J]. 計(jì)算機(jī)測(cè)量與控制, 2017, 25(1):131-134.

[7] Dinh H T, Lee C, Niyato D, et al. A survey of mobile cloud computing: architecture, applications, and approaches[J]. Wireless Communications & Mobile Computing, 2013, 13(18):1587-1611.

[8] Abolfazli S, Sanaei Z, Shiraz M, et al. MOMCC: Market-oriented architecture for Mobile Cloud Computing based on Service Oriented Architecture[A]. IEEE International Conference on Communications in China Workshops[C]. IEEE, 2012:8-13.

[9] 王素貞, 杜治娟. 基于移動(dòng)Agent的移動(dòng)云計(jì)算系統(tǒng)構(gòu)建方法[J]. 計(jì)算機(jī)應(yīng)用, 2013, 33(5):1276-1280.

[10] Felemban M, Basalamah S, Ghafoor A. A distributed cloud architecture for mobile multimedia services[J]. IEEE Network, 2013, 27(5):20-27.