專利名稱：用于開放式平臺的存儲器管理系統(tǒng)和方法
技術(shù)領(lǐng)域：
本發(fā)明涉及一種存儲器管理系統(tǒng)和方法，明確地說涉及一種用于開放式平臺的存儲 器管理系統(tǒng)和方法。
背景技術(shù)：
隨著數(shù)字家庭演進的潮流與因特網(wǎng)的蓬勃發(fā)展，以服務為導向的思考方式來開發(fā)應 用軟件也成為一種趨勢，例如居家保全、健康照護、家庭自動化控制、影音娛樂等服 務，因此為了滿足不同服務需求的用戶，和遠程應用程序安裝與管理的方便性，并省卻 用戶安裝設定上的困擾， 一種開放性軟件架構(gòu)平臺的設計因而有其重要性與必要性，如
OSGi (Open Services Gateway Initiative)開放式服務網(wǎng)關(guān)創(chuàng)始協(xié)會所提出的開放式服務 平臺(Open Service Platform)即為其中一種解決方案。
由于開放式平臺提供了開放性平臺架構(gòu)，所以可依據(jù)用戶的不同需求，動態(tài)地載入 各種不同性質(zhì)服務的應用程序，以為用戶提供多樣化的服務。但由于在開放式平臺上可 動態(tài)地增加服務程序，因此有可能載入過多或不符合所述系統(tǒng)平臺能力的服務程序，而 造成開放式平臺上系統(tǒng)的資源負荷或不足。
而開放式平臺與這些應用程序共用虛擬機(Virtual Machine)上的一個存儲器空間， 配置并使用所述存儲器來提供服務，因此當原虛擬機上設定的可使用存儲器空間不能夠 滿足所有服務執(zhí)行時所需要的存儲器大小時，就會產(chǎn)生存儲器不足(Out of Memory)的 異常(Exception),發(fā)生此異常的執(zhí)行線程將會被中止，但因為開放式平臺其開放與服 務共享的架構(gòu)，所述被中止的執(zhí)行線程所產(chǎn)生的實例有可能仍然被其它應用程序所引
用，因此系統(tǒng)無法回收其所占據(jù)的存儲器。所以對整個系統(tǒng)而言，輕者將影響系統(tǒng)其它 應用程序的執(zhí)行效率，嚴重的將會中斷正在執(zhí)行中的服務，而造成系統(tǒng)不穩(wěn)定。
常規(guī)技術(shù)請參考現(xiàn)有技術(shù)論文和專利(1) Sumpa Biswas, Matthew Simpson, Rajeev Barua, "Memory Overflow Protection for Embedded Systems using Run-time Checks, Reuse and Compression," CASES'04 September 22-25， 2004. (2) ndrajit Poddar, Robbie John Minshall， "Memory leak detection and analysis in WebSphere Application Server," http :〃www-12 8 .ibm ,com/developerworks/
websphere/library/techarticles/0606_poddar/0606_poddar.html， Jun 28, 2006. (3) Chen, D.Messer, A. Milojicic， D. Sandhya Dwarkadas, "Garbage collector assisted memory offloading for memory-constrained devices," Mobile Computing Systems and Applications 2003, Oct 9-10， 2003. (4)第7,010,661 B2號美國專利，專利名稱「Efficient Service Management in Home Gateways」。(5)第5,699,539號美國專利，專利名稱「 Virtual memory management system and method using data compression」。(6)第6,950,874號美國專禾U，專禾ll名稱 「 Method and system for management of resource leases in an application framework system」。(7)第6,151,688號美國專利，專利名稱「Resource management in a clustered computer system」。
上述現(xiàn)有技術(shù)論文和專利的技術(shù)在于加入一些存儲器檢查機制，來避免產(chǎn)生存儲器 不足的異常情形，或者在執(zhí)行期間壓縮實例和分享、利用其它存儲器空間來得到足夠可 用空間；或者以分散式的概念來進行有效的資源利用與共享。然而常規(guī)技術(shù)無法有效地 解決存儲器資源不足的問題，且不符合開放式平臺標準其開放與精簡的基本精神，不適 用于一般家庭的用戶。
因此，有必要提供一種用于開放式平臺的存儲器管理系統(tǒng)和方法，以解決上述問題。

發(fā)明內(nèi)容
本發(fā)明提供一種用于開放式平臺的存儲器管理系統(tǒng)，其包括本地開放式平臺，所述 本地開放式平臺包括中央處理器監(jiān)控服務包、存儲器監(jiān)控服務包、動態(tài)探索服務包、 管理代理人服務包和代理人服務包。所述中央處理器監(jiān)控服務包用以動態(tài)監(jiān)控目前中央 處理器使用情況。所述存儲器監(jiān)控服務包用以動態(tài)監(jiān)控目前存儲器使用情況。所述動態(tài) 探索服務包將所述中央處理器和存儲器使用情況信息散布于因特網(wǎng)，且在因特網(wǎng)上搜索 與取回可存取至少一遠程開放式平臺的信息。所述管理代理人服務包在存儲器超過閾值 時，用以決定遠程開放式平臺候選人，提出標準服務需求。所述遠程開放式平臺候選人 會在本地開放式平臺的擴充型服務注冊表內(nèi)注冊相關(guān)標準服務包存取接口，本地便可通 過相對應的標準服務的存取接口，而使用遠程開放式平臺的本地服務注冊表所提供的相 對應的標準服務的實例，進而使用所述遠程開放式平臺候選人所提供的相對應的標準服 務。
本發(fā)明提供一種用于開放式平臺的存儲器管理方法，其包括以下步驟動態(tài)監(jiān)控本
地開放式平臺的目前中央處理器和目前存儲器使用情況；動態(tài)地將所述中央處理器和存
儲器使用情況信息散布于因特網(wǎng)，且在因特網(wǎng)上搜索與取回可存取至少一遠程開放式平
臺的信息；在存儲器超過閾值時，決定遠程開放式平臺候選人，提出標準服務需求；和
產(chǎn)生相對應的標準服務存取接口，以使用所述遠程開放式平臺候選人的標準服務。
6利用本發(fā)明的系統(tǒng)和方法，可在沒有專業(yè)管理人員的環(huán)境下，解決開放式平臺上存 儲器不足所引起的問題，以維持執(zhí)行上的穩(wěn)定性，并降低用戶和管理者的困擾。本發(fā)明 的系統(tǒng)和方法能使用遠程開放式平臺產(chǎn)生的可共用標準服務包，以卸載本地開放式平臺 相關(guān)的標準服務包，借此強迫釋放存儲器空間，以維持系統(tǒng)的穩(wěn)定性，并且在不需要將 系統(tǒng)重新啟動的前提下，使原先已在執(zhí)行的服務程序能繼續(xù)執(zhí)行而不受其影響，保持用 戶在使用服務上的愉悅感，將為用戶在實際數(shù)字生活應用上增加其信任感，并增加意愿 釆用數(shù)字生活相關(guān)產(chǎn)品，而使得數(shù)字生活便利性的概念能更加地具體化。


圖1顯示應用本發(fā)明用于開放式平臺的存儲器管理系統(tǒng)和方法的系統(tǒng)架構(gòu)示意圖； 圖2顯示本發(fā)明用于開放式平臺的存儲器管理系統(tǒng)的方框示意圖； 圖3顯示本發(fā)明用于開放式平臺的存儲器管理系統(tǒng)在存儲器不足時的系統(tǒng)方框示意
圖4顯示本發(fā)明實施例用于開放式平臺的存儲器管理方法的步驟1的處理流程示意
圖5顯示本發(fā)明實施例用于開放式平臺的存儲器管理方法的步驟2的處理流程示意
圖6顯示本發(fā)明實施例用于開放式平臺的存儲器管理方法的步驟3的處理流程示意
圖7顯示本發(fā)明實施例用于開放式平臺的存儲器管理方法的步驟4的處理流程示意
圖8顯示本發(fā)明實施例用于開放式平臺的存儲器管理方法的步驟5的處理流程示意
圖9顯示本發(fā)明實施例用于開放式平臺的存儲器管理方法的步驟6的處理流程示意
圖10顯示本發(fā)明實施例用于開放式平臺的存儲器管理系統(tǒng)和方法的動作流程示意
圖11顯示本發(fā)明動態(tài)探索服務包的標準通信協(xié)議示意圖； 圖12顯示利用RMI技術(shù)實現(xiàn)本發(fā)明代理人服務包的示意圖；以及 圖13顯示本發(fā)明代理人服務包的實行軟件模塊的示意圖。
具體實施例方式
7參看圖1，其顯示應用本發(fā)明用于開放式平臺的存儲器管理系統(tǒng)和方法的系統(tǒng)架構(gòu) 示意圖。應用本發(fā)明用于開放式平臺的存儲器管理系統(tǒng)的系統(tǒng)10包括多個用戶家庭 (Home) 11、 12、 13、多個服務提供者(Service provider) 14、 15等。服務提供者14、 15包括服務器141、 151和遠程管理者142、 152。用戶家庭或服務提供者具有各種不同 的使用開放式平臺的設備，例如家用服務網(wǎng)關(guān)(Service Gateway) 111、 121、 131、纜 線調(diào)制解調(diào)器(Cable Modem)、數(shù)字機頂盒(Set-Top Box)與網(wǎng)絡電話(Web Phone) 等設備，此類設備可能散布于各用戶家庭中，并且通過因特網(wǎng)串聯(lián)在一起。雖然這些用 戶設備功能不同，但由于這些設備均是架構(gòu)于開放式平臺之上，其均具有相同的標準服 務包實例。因此，當本地發(fā)生存儲器不足問題時，利用開放式平臺服務共享的基本精神， 要求遠程開放式平臺產(chǎn)生相對應的標準共用服務包實例，并且進一步使用所述相關(guān)標準 服務包，借此去除本地相對應的標準服務包，以達到強制釋放存儲器，并讓系統(tǒng)得以繼 續(xù)正常運作。
參看圖2，其顯示本發(fā)明用于開放式平臺的存儲器管理系統(tǒng)的方框示意圖。本發(fā)明 用于開放式平臺的存儲器管理系統(tǒng)包括本地開放式平臺20，所述本地開放式平臺20包 括中央處理器監(jiān)控服務包(CPU Monitoring Bundle) 21、存儲器監(jiān)控服務包(Memory Monitoring Bundle) 22、代理人服務包(Proxy Bundle) 23、動態(tài)探索服務包(Discovering Bundle) 24、管理代理人服務包(Management Agent Bundle) 25、多個標準服務包26 (Standard Service Bundles)和多個用戶服務包27 (Custom Bundles)。
所述中央處理器監(jiān)控服務包21用以動態(tài)監(jiān)控目前中央處理器使用情況。所述存儲 器監(jiān)控服務包22用以動態(tài)監(jiān)控目前存儲器使用情況。所述動態(tài)探索服務包24將所述中 央處理器和存儲器使用情況信息散布于因特網(wǎng)，且在因特網(wǎng)上搜索與取回可存取至少一 遠程開放式平臺的信息。所述管理代理人服務包25在存儲器超過闞值時，用以決定遠 程開放式平臺候選人，提出標準服務需求。所述代理人服務包23用以依據(jù)遠程開放式 平臺的要求，產(chǎn)生相對應的標準服務存取接口，以使所述遠程開放式平臺能使用所述本 地開放式平臺的標準服務。
所述本地開放式平臺20另外包括開放式平臺(Open Platform) 28，所述開放式平 臺28包括本地服務注冊表(Local Service Registry) 281和擴充型服務注冊表(Extended Service Registry) 282。其開放式平臺建構(gòu)于虛擬機(Virtual Machine) 29上，所述本地 開放式平臺20另外具有操作系統(tǒng)(Operating System) 30和硬件(Hardware) 31。
所述遠程開放式平臺候選人會在本地開放式平臺20的擴充型服務注冊表282內(nèi)注
冊相關(guān)標準服務包存取接口，本地便可通過相對應的標準服務的存取接口，而使用遠程開放式平臺的本地服務注冊表所提供的相對應的標準服務的實例，進而使用所述遠程開 放式平臺候選人所提供的相對應的標準服務
參看圖3，其顯示本發(fā)明用于開放式平臺的存儲器管理系統(tǒng)在存儲器不足時的系統(tǒng) 方框示意圖。本發(fā)明用于開放式平臺的存儲器管理系統(tǒng)除上述本地開放式平臺20夕卜， 另外包括遠程開放式平臺50，遠程開放式平臺50的系統(tǒng)架構(gòu)與所述本地開放式平臺20 大致相同，其包括中央處理器監(jiān)控服務包(CPU Monitoring Bundle) 51、存儲器監(jiān)控 服務包(Memory Monitoring Bundle) 52、代理人服務包(Proxy Bundle) 53、動態(tài)探索 服務包(Discovering Bundle) 54、管理代理人服務包(Management Agent Bundle) 55、 多個標準服務包56 (Standard Service Bundles)和多個用戶服務包57 (Custom Bundles)。
遠程開放式平臺50的所述中央處理器監(jiān)控服務包51用以動態(tài)監(jiān)控目前中央處理器 使用情況。所述存儲器監(jiān)控服務包52用以動態(tài)監(jiān)控目前存儲器使用情況。所述動態(tài)探 索服務包54將所述中央處理器和存儲器使用情況信息散布于因特網(wǎng)，且在因特網(wǎng)上搜 索與取回可存取至少一遠程開放式平臺的信息。所述管理代理人服務包55接收本地開 放式平臺的標準服務需求。所述代理人服務包53用以產(chǎn)生相對應的標準服務，以使所 述本地開放式平臺能使用所述標準服務。
同樣，所述遠程開放式平臺50另外包括開放式平臺(Open Platform) 58，所述開 放式平臺58包括本地服務注冊表(Local Service Registry) 581和擴充型服務注冊表 (Extended Service Registry) 582。其開放式平臺建構(gòu)于虛擬機(Virtual Machine) 59上， 所述遠程開放式平臺50另外具有操作系統(tǒng)(Operating System) 60和硬件(Hardware) 61。
以下配合圖式說明本發(fā)明用于開放式平臺的存儲器管理系統(tǒng)和方法的運作 參看圖4，其顯示本發(fā)明用于開放式平臺的存儲器管理方法的步驟1的處理流程示 意圖。當系統(tǒng)啟動之后，各開放式平臺(例如本地開放式平臺20和遠程開放式平臺
50)會直接載入與啟動所述中央處理器監(jiān)控服務包21、 51、存儲器監(jiān)控服務包22、 52、
代理人服務包23、 53、動態(tài)探索服務包24、 54與管理代理人服務包25、 55五個服務包。
其中，中央處理器監(jiān)控服務包21、 51、存儲器監(jiān)控服務包22、 52會以后臺執(zhí)行方式，
動態(tài)監(jiān)控與收集目前中央處理器與存儲器使用情況，如圖4所示的步驟l所示。
參看圖5，其顯示本發(fā)明用于開放式平臺的存儲器管理方法的步驟2的處理流程示
意圖。所述動態(tài)探索服務包24、 54會詢問中央處理器監(jiān)控服務包21、 51、存儲器監(jiān)控
服務包22、 52目前中央處理器與存儲器的使用情況，如圖5的步驟2.1所示，并且將這
些信息散布于因特網(wǎng)40中，如圖5的步驟2.2所示。
9參看圖6，其顯示本發(fā)明用于開放式平臺的存儲器管理方法的步驟3的處理流程示 意圖。各動態(tài)探索服務包24、 54在將各自開放式平臺內(nèi)中央處理器與存儲器的使用情 況等信息散布于因特網(wǎng)40之后，還在因特網(wǎng)40中搜索與取回目前本地開放式平臺可存 取到的至少一遠程開放式平臺的相關(guān)信息，如圖6的步驟3.1所示。并記錄于本地的信 息表(Information Table) 32中，且更新各信息，如圖6的步驟3.2所示。所述信息表 32記錄各遠程開放式平臺的IP地址(IPAddress)、 CPU使用情形(Usage)、存儲器使 用情形(MEM Usage)與存活時間TTL (Time to Live)等信息。
參看圖7，其顯示本發(fā)明用于開放式平臺的存儲器管理方法的步驟4的處理流程示 意圖。系統(tǒng)啟動后且正常運作中，當本地動態(tài)使用存儲器情形超過所述存儲器的閾值 (Threshold)時，如圖7的步驟4.1所示。那么，本地管理代理人服務包24會根據(jù)所述 信息表32內(nèi)的信息，評估各遠程開放式平臺相關(guān)信息，如TTL、 CPU Usage與MEM Usage等信息，予以加權(quán)比重，以決定出遠程開放式平臺候選人，如圖7的步驟4.2所 示。在本實施例中，所述遠程開放式平臺候選人為遠程開放式平臺50。
本地的管理代理人服務包25會依照所述候選人結(jié)果，通過遠程的管理代理人服務 包55向遠程開放式平臺50提出提供標準服務的需求，如圖7的步驟4.3所示。此時， 所述遠程開放式平臺的管理代理人服務包55收到所述要求后，便會要求其代理人服務 包53，依此需求先建立相關(guān)標準服務的實例，如圖7的步驟4.4所示。所述遠程開放式 平臺的代理人服務包53在收到開放式平臺的管理代理人服務包55的要求后，便會在本 地服務注冊表581內(nèi)，產(chǎn)生相對應的標準服務實例，如圖7的步驟4.5所示。
參看圖8，其顯示本發(fā)明用于開放式平臺的存儲器管理方法的步驟5的處理流程示 意圖。當本地繼續(xù)執(zhí)行新的應用程序時，如果其中某一應用程序所要求的存儲器空間超 過系統(tǒng)可用的存儲器大小，如圖8的步驟5.1所示。那么，管理代理人服務包25會先行 通知遠程管理者和用戶相關(guān)消息，如圖8的步驟5.2所示，讓用戶對于相關(guān)的延遲不會 造成不愉快的感覺，并使得管理者得知本地的存儲器不足的相關(guān)信息。
此時，本地的管理代理人服務包25便會向遠程開放式平臺的管理代理人服務包55 提出提供標準服務包的實際要求，如圖8的步驟5.3所示。所述遠程開放式平臺的管理 代理人服務包55收到所述要求后，便會要求其開放式平臺內(nèi)的代理人服務包53，依此 實際要求，在所述提出實際要求的本地開放式平臺20的擴充型服務注冊表282內(nèi)建立 各相關(guān)標準服務的存取接口，如圖8的步驟5.4所示。
所述代理人服務包53在收到所述遠程開放式平臺50的管理代理人服務包55要求
后，便會在所述提出實際要求的本地開放式平臺20的擴充型服務注冊表282內(nèi)，產(chǎn)生相對應的標準服務的存取接口，以提供給所述提出實際要求的本地開放式平臺20使用， 如圖8的步驟5.5所示。
參看圖9，其顯示本發(fā)明用于開放式平臺的存儲器管理方法的步驟6的處理流程示 意圖。當遠程開放式平臺50成功注冊相關(guān)標準服務包存取接口后，本地開放式平臺20 便可通過擴充型服務注冊表282內(nèi)的相對應的標準服務的存取接口，而使用遠程開放式 平臺50的本地服務注冊表581所提供的相對應的標準服務的實例，進而使用遠程開放 式平臺50所提供的相對應的標準服務，如圖9的步驟6.1所示。
使用遠程開放式平臺50所提供的相對應的標準服務后，本地開放式平臺20便會卸 載相對應的標準服務包，以騰出存儲器空間，如圖9的步驟6.2所示。當整個轉(zhuǎn)換結(jié)果 成功之后，本地開放式平臺20便開始使用遠程開放式平臺50所提供的標準服務包各實 例，使得系統(tǒng)可以再繼續(xù)執(zhí)行新的應用程序，并且不需要重新開機且正常運作。最后， 在整個轉(zhuǎn)換機制完成后，本地開放式平臺20的管理代理人服務包25還會通知管理者和 用戶相關(guān)轉(zhuǎn)換結(jié)果成功與否的信息，如圖9的步驟6.3所示。因為本發(fā)明用于開放式平 臺的存儲器管理方法基于開放式平臺的架構(gòu)，因此，上文所提到的可轉(zhuǎn)換的標準服務包 為各開放式平臺的標準服務包，并存在且可執(zhí)行于每一開放式平臺(例如開放式家用 服務網(wǎng)關(guān))上。
以下就一個目前市場上常見的OSGi家用服務網(wǎng)關(guān)為實施例，來闡述本發(fā)明所提出 的系統(tǒng)架構(gòu)與方法的可實施性。我們以四臺計算機上執(zhí)行Knopflerfish OSGi開放式服務 中介軟件程序，來模擬一臺本地設備與三臺遠程設備，其中我們將所有虛擬機啟動時， 各配置18兆字節(jié)的存儲器大小，并且將存儲器的閾值(Threshold)設定為16兆字節(jié)。 參看圖io，其顯示本發(fā)明用于開放式平臺的存儲器管理系統(tǒng)和方法的實施例的動作流程 示意圖，以下針對每個步驟分別加以說明
步驟1:當系統(tǒng)啟動之后，四臺OSGi家用服務網(wǎng)關(guān)以后臺執(zhí)行方式，利用中央處
理器監(jiān)控服務包與存儲器監(jiān)控服務包兩個服務包，分別收集各自的中央處理器與存儲器
使用情況，動態(tài)探索服務包可利用具有自動探索(Auto Discovering)能力的標準通信協(xié)
議，例如服務定位協(xié)議SLP (Service Location Protocol)、通用即插即用協(xié)議UPnP
(Universal Plug and Play)、爪哇智能網(wǎng)絡架構(gòu)Jini( Java Intelligent Network Infrastructure)
等標準通信協(xié)議，將相關(guān)信息散布到因特網(wǎng)上并收集目前可用的遠程開放式平臺及其遠
程服務等信息，如圖11所示。在此實施例中，選用了輕量化的SLP來實行動態(tài)探索服
務包的具有自動探索能力的標準通信協(xié)議。其中這些收集到的信息包含IP地址、CPU
使用情形(CPUUsage)與存儲器使用情形(MEMUsage)等信息，我們再利用Ping這
11個網(wǎng)絡指令來間接得到TTL相關(guān)信息，并將這些信息存儲于所述OSGi家用服務網(wǎng)關(guān)的 信息表32中，并隨時動態(tài)更新此信息表32，在此實施例中，我們僅存儲CPU使用情形、 存儲器使用情形(MEMUsage)與TTL三項信息，并且將分別將加權(quán)比重設定為35%、 30%與25%，以決定出遠程開放式平臺候選人，如下表1所示。
IP地址可用的存儲器大小(35%)CPU使用情形(30%)TTL (25%)
140.96.194.112，368KB34.7%128
140.96.194.22,872KB27.4%128
140.96.194.36,680KB79.3 %128
步驟2:當系統(tǒng)啟動后且正常運作后，我們刻意利用一些會配置存儲器的服務包執(zhí) 行于本地，使其本地虛擬機上的存儲器使用情況將近15兆字節(jié)，然后我們再下載一個
經(jīng)設計會配置2兆字節(jié)存儲器大小的服務包于本地，此時本地存儲器情形便會超過我們 所設定的閾值16兆字節(jié)，如圖10的步驟2.1所示，因而本地會根據(jù)實施例圖IO的步驟 l所述的信息表內(nèi)的信息，評估各遠程開放式平臺相關(guān)信息，如CPU使用情形(CPU Usage)、存儲器使用情形(MEM Usage)與TTL三項信息，并依照各比重加權(quán)，決定 出最佳遠程開放式平臺候選人。在本實施例中，遠程開放式平臺候選人的IP地址為 140.96.194.1，即遠程1。
因此，本地開放式平臺最后便會通過管理代理人服務包向140.96.194.1所述遠程 OSGi家用服務網(wǎng)關(guān)提出提供標準服務的需求。另外，在此實施例中，我們選定Log與 User Admin兩個標準服務包，作為提供遠程開放式平臺所需求的標準服務包使用。當所 述遠程開放式平臺的管理代理人服務包收到所述需求要求時，會通過代理人服務包依此 需求先在自身本地服務注冊表中，建立相關(guān)標準服務包的實例，如圖10的步驟2.2所示。
在此實施例中，我們利用遠程方法調(diào)用RMI (Remote Method Invocation)技術(shù)來實 行代理人服務包相關(guān)技術(shù)，如圖12所示。在本實施例中以A端或B端說明本地或遠程， 本地開放式平臺的代理人服務包23包括A端服務注冊表(A's Service Registry) 231、 A 端RMI服務注冊表(A's RMI Registry) 232和B端RMI服務注冊表(B's RMI Registry) 233;遠程開放式平臺的代理人服務包53包括B端服務注冊表(B's Service Registry)531 、 B端RMI注冊表(B's RMI Registry) 532和A端RMI注冊表(A's RMI Registry) 533。 RMI技術(shù)可支持遠程注冊服務與提供遠程服務存取的功能，通過RMI技術(shù)，本地不但 可以在自身的服務注冊表中注冊自身的服務，還可通過RMI技術(shù)，將自身的服務注冊到 遠程他人的RMI服務注冊表中，因此通過RMI技術(shù)，本地不但可以享受自身本地的服
12務，還可通過RMI服務注冊表進而使用他人所提供的服務。
參看圖13，其顯示代理人服務包的相關(guān)實行軟件模塊的示意圖。以本地開放式平臺的代理人服務包23為例說明，本地開放式平臺的代理人服務包23包括遠程方法調(diào)用處理器(RMI Handler) 235、遠程服務存取接口 (Remote Service Access Interface) 236。RMI處理器用以完成代理人服務包23的支持遠程注冊服務與提供遠程服務存取的主要功能。所述遠程服務存取接口 236可使遠程的OSGi家用服務網(wǎng)關(guān)通過此接口，將其標準服務提供于本地開放式平臺上。最后，在本地開放式平臺的本地服務注冊表281與擴充型服務注冊表282兩個服務注冊表中，并利用多個屬性(Attribute) 73、 74、 83、 84來決定多個服務實例(Service Instance) 71、 72、 81、 82是屬于本地開放式平臺的服務實例還是遠程開放式平臺的服務存取接口。
步驟3:當本地繼續(xù)執(zhí)行經(jīng)設計會配置2兆字節(jié)存儲器大小的新的應用程序時，此時所述應用程序所要求的存儲器空間即超過系統(tǒng)可用的存儲器大小時，因此便啟動本發(fā)明所提出的存儲器不足的處理方法。在此方法運作之前，管理代理人服務包會先行通知遠程管理者和用戶相關(guān)消息，如圖10的步驟3.1所示，使管理者與用戶得知本地的存儲器不足的相關(guān)信息。此時，本地通過管理代理人服務包向140.96.194.1此遠程OSGi家用服務網(wǎng)關(guān)提出提供標準服務包的實際要求，當所述遠程開放式平臺的管理代理人服務包收到所述實際要求時，會通過代理人服務包依此需求，將Log服務包與User Admin服務包的存取接口注冊于本地開放式平臺上，如圖10的步驟3.2所示。當遠程開放式平臺成功注冊相關(guān)標準服務包實例的存取接口后，本地開放式平臺便會開始使用此標準服務包實例的存取接口，進而使用遠程開放式平臺相關(guān)標準服務包實例，接著本地開放式平臺便會卸載相對應的標準服務包，以騰出所尚缺的存儲器空間，如圖10的步驟3.3所示。
步驟4:最后根據(jù)實驗結(jié)果得知，在本地開放式平臺卸載相對應的Log服務包與UserAdmin服務包兩大服務包之后，可騰出將近1.7兆字節(jié)大小的存儲器空間，因此當本地開始使用遠程所提供的標準服務包各實例時，如圖10的步驟4所示，可使得系統(tǒng)可以再繼續(xù)執(zhí)行步驟3所述的新的應用程序，并且不需要重新開機且正常運作。在整個方法處理完成后，本地開放式平臺會通過管理代理人服務包通知管理者和用戶相關(guān)轉(zhuǎn)換結(jié)果成功與否的信息。
最后，我們進一步闡明，在KnopflerfishOSGi開放式服務中介軟件中，各項標準服務包可通過本發(fā)明所提出的機制而注冊于遠程OSGi家用服務網(wǎng)關(guān)中，且可被遠程OSGi
家用服務網(wǎng)關(guān)所使用的服務包包含服務包注冊表(Bundle Registry)、宣告式服務
13(Declarative Services )、爪哇服務小程序開發(fā)工具組應用程序接口 (JSDKAPI)、記錄服務(Log Service)、測量(Measurement)、元類型(Metatype)、偏好(Preferences)、各樣實用工具程序庫(Misc. Utilities Lib)、 kSOAP服務應用程序接口 (kSOAP ServiceAPI)、用戶管理服務(User Admin. Service)、 WireAdmin應用程序接口 (WireAdminAPI)、延伸性標示語言應用程序接口 (XMLAPI)與初始供應(Initial Provisioning)等標準服務包，最后經(jīng)過實驗結(jié)果統(tǒng)計，可騰出將近5.24兆字節(jié)大小的存儲器空間，證明本發(fā)明用于開放式平臺的存儲器管理系統(tǒng)和方法的可實施性與可行性。
利用本發(fā)明的系統(tǒng)和方法，可在沒有專業(yè)管理人員的環(huán)境下，解決開放式平臺上存儲器不足所引起的問題，以維持執(zhí)行上的穩(wěn)定性，并降低用戶和管理者的困擾。本發(fā)明的系統(tǒng)和方法能使用遠程產(chǎn)生的可共用標準服務包，以卸載本地相關(guān)的標準服務包，借此強迫釋放存儲器空間，以維持系統(tǒng)的穩(wěn)定性，并且在不需要將系統(tǒng)重新啟動的前提下，使原先已在執(zhí)行的服務程序能繼續(xù)執(zhí)行而不受其影響，保持用戶在使用服務上的愉悅感，將為用戶在實際數(shù)字生活應用上增加其信任感，并增加意愿采用數(shù)字生活相關(guān)產(chǎn)品，而使得數(shù)字生活便利性的概念能更加地具體化。
然而，上述實施例僅為說明本發(fā)明的原理及其功效，而非用以限制本發(fā)明。因此，所屬領(lǐng)域的技術(shù)人員可在不脫離本發(fā)明的精神的情況下對上述實施例進行修改和變化。
權(quán)利要求
1. 一種用于開放式平臺的存儲器管理系統(tǒng)，其包括本地開放式平臺，所述本地開放式平臺包括中央處理器監(jiān)控服務包，其用以動態(tài)監(jiān)控目前中央處理器使用情況；存儲器監(jiān)控服務包，其用以動態(tài)監(jiān)控目前存儲器使用情況；動態(tài)探索服務包，將所述存儲器使用情況信息散布于因特網(wǎng)，且在因特網(wǎng)上搜索與取回可存取至少一遠程開放式平臺的信息；管理代理人服務包，其在存儲器超過閾值時，用以決定遠程開放式平臺候選人，提出標準服務需求；以及擴充型服務注冊表，其用以存儲相對應的標準服務存取接口，以使用所述遠程開放式平臺候選人的標準服務。
2. 根據(jù)權(quán)利要求1所述的存儲器管理系統(tǒng)，其另外包括至少一遠程開放式平臺，所述 遠程開放式平臺包括-中央處理器監(jiān)控服務包，其用以動態(tài)監(jiān)控目前中央處理器使用情況； 存儲器監(jiān)控服務包，其用以動態(tài)監(jiān)控目前存儲器使用情況；動態(tài)探索服務包，將所述存儲器使用情況信息散布于因特網(wǎng)，且在因特網(wǎng)上搜索與取回可存取至少一遠程開放式平臺的信息；管理代理人服務包，其用以接收本地開放式平臺所提出的標準服務需求；以及 代理人服務包，其用以向所述本地開放式平臺的所述擴充型服務注冊表產(chǎn)生相對應的標準服務存取接口，以使得所述本地開放式平臺能使用所述標準服務。
3. 根據(jù)權(quán)利要求2所述的存儲器管理系統(tǒng)，其中所述本地開放式平臺和遠程開放式平 臺各具有一信息表，用以記錄遠程開放式平臺的IP地址、CPU使用情形、存儲器 使用情形(MEM Usage)與存活時間(TTL)等信息。
4. 根據(jù)權(quán)利要求3所述的存儲器管理系統(tǒng)，其中所述本地開放式平臺的管理代理人服 務包，依據(jù)所述信息表的信息，予以加權(quán)比重，決定所述遠程開放式平臺候選人。
5. 根據(jù)權(quán)利要求3所述的存儲器管理系統(tǒng)，其中所述本地開放式平臺的動態(tài)探索服務 包詢問所述中央處理器監(jiān)控服務包、存儲器監(jiān)控服務包目前中央處理器與存儲器的 使用情況，并將所述信息散布于因特網(wǎng)，且記錄于所述本地開放式平臺的信息表中。
6. 根據(jù)權(quán)利要求2所述的存儲器管理系統(tǒng)，其中所述本地開放式平臺具有代理人服務 包，用以依據(jù)遠程開放式平臺的要求，產(chǎn)生相對應的標準服務存取接口。
7. 根據(jù)權(quán)利要求2所述的存儲器管理系統(tǒng)，其中所述本地開放式平臺和遠程開放式平臺各具有一本地服務注冊表，用以存儲相對應的標準服務實例。
8. 根據(jù)權(quán)利要求2所述的存儲器管理系統(tǒng)，其中所述本地開放式平臺和遠程開放式平 臺包含使用OSGi標準的開放性服務平臺。
9. 根據(jù)權(quán)利要求1所述的存儲器管理系統(tǒng)，其中所述本地開放式平臺的存儲器空間是 虛擬機在起始時所配置的存儲器空間。
10. —種用于開放式平臺的存儲器管理方法，其包括以下步驟動態(tài)監(jiān)控本地開放式平臺的目前中央處理器和目前存儲器使用情況； 動態(tài)地將所述存儲器使用情況信息散布于因特網(wǎng)，且在因特網(wǎng)上搜索與取回可存取至少一遠程開放式平臺的信息；在存儲器超過閾值時，決定遠程開放式平臺候選人，提出標準服務需求；以及 產(chǎn)生相對應的標準服務存取接口，以使用所述遠程開放式平臺候選人的標準服務。
11. 根據(jù)權(quán)利要求IO所述的存儲器管理方法，其在動態(tài)監(jiān)控步驟之前另外包括啟動所 述本地開放式平臺，直接載入與啟動中央處理器監(jiān)控服務包、存儲器監(jiān)控服務包、 動態(tài)探索服務包、管理代理人服務包和代理人服務包等五個服務包的步驟。
12. 根據(jù)權(quán)利要求IO所述的存儲器管理方法，其中依據(jù)至少一遠程開放式平臺的IP地 址、CPU使用情形、存儲器使用情形(MEM Usage)與存活時間(TTL)等信息決 定所述遠程開放式平臺候選人。
13. 根據(jù)權(quán)利要求12所述的存儲器管理方法，其中至少一遠程開放式平臺的IP地址、 CPU使用情形、存儲器使用情形(MEM Usage)與存活時間(TTL)等信息存儲于 所述本地開放式平臺的信息表內(nèi)，依據(jù)所述信息表的信息，予以加權(quán)比重，以決定 所述遠程開放式平臺候選人。
14. 根據(jù)權(quán)利要求13所述的存儲器管理方法，其中在動態(tài)地將所述存儲器使用情況信 息散布于因特網(wǎng)的步驟中，另外包括動態(tài)詢問目前中央處理器與存儲器的使用情 況，并動態(tài)地將所述信息散布于因特網(wǎng)，且記錄于所述本地開放式平臺的信息表中 的步驟。
15. 根據(jù)權(quán)利要求10所述的存儲器管理方法，其中所述本地開放式平臺提出所述標準 服務需求之后，所述遠程開放式平臺候選人，接收所述標準服務需求，且將相對應 的標準服務實例存儲于本地服務注冊表中。
16. 根據(jù)權(quán)利要求15所述的存儲器管理方法，其中當所述本地開放式平臺繼續(xù)執(zhí)行新的應用程序且超過所述可用的存儲器大小時，向所述遠程開放式平臺候選人提出提 供標準服務包的實際要求，所述遠程開放式平臺候選人接收所述標準服務包的實際 要求后，在本地開放式平臺的擴充型服務注冊表內(nèi)產(chǎn)生相對應的標準服務存取接□。
17.根據(jù)權(quán)利要求16所述的存儲器管理方法，其中所述遠程開放式平臺候選人在本地 開放式平臺的擴充型服務注冊表內(nèi)產(chǎn)生相對應的標準服務的存取接口后，所述本地 開放式平臺利用相對應的標準服務的存取接口，使用所述遠程開放式平臺候選人的 標準服務。
全文摘要
本發(fā)明涉及一種用于開放式平臺的存儲器管理系統(tǒng)和方法。本發(fā)明的存儲器管理系統(tǒng)和方法利用開放式平臺的服務共享的基本原則，當本地開放式平臺的存儲器資源使用超過上限時，利用標準服務包存取接口，使用遠程開放式平臺的標準服務包，以卸載本地相關(guān)的標準服務包，進一步釋放其存儲器空間，以維持系統(tǒng)的穩(wěn)定性。
文檔編號H04L29/06GK101499032SQ200810007119
公開日2009年8月5日 申請日期2008年1月31日 優(yōu)先權(quán)日2008年1月31日
發(fā)明者朱振練, 李坤敏, 蘇柏州 申請人:財團法人工業(yè)技術(shù)研究院