一種組件管理系統(tǒng)及組件管理方法
【技術領域】
[0001]本發(fā)明涉及計算機軟件開發(fā)技術領域，具體地說，涉及一種組件管理系統(tǒng)及組件管理方法。
【背景技術】
[0002]隨著計算機硬件和軟件的飛速發(fā)展，計算機應用的功能愈來愈強大，實現也愈來愈靈活。通常，計算機應用中集成了許多功能，通常利用插件實現其中的某種子功能。
[0003]插件是遵循一定規(guī)范的應用程序接口編寫出來的，并用于開發(fā)實現原純凈系統(tǒng)平臺、應用軟件平臺不具備的功能的程序。由于插件需要調用原純凈系統(tǒng)提供的函數庫或者數據，因而其只能運行在程序規(guī)定的系統(tǒng)平臺下(可能同時支持多個平臺)，而不能脫離指定的平臺而單獨運行。例如在IE中，安裝相關的插件后，WEB瀏覽器能夠直接調用插件程序，用于處理特定類型的文件。
[0004]圖1為基于插件的系統(tǒng)架構原理圖。插件一般以動態(tài)庫的形式并平臺加載，平臺成功加載插件以后，插件的代碼就成為平臺的一部分，無論是何種形式的插件，必需依賴于平臺進程運行，插件不能以單獨的進程運行。
[0005]以IE瀏覽器中的ActiveX安全控件為例，ActiveX控件是一種可重用的軟件組件，通過使用ActiveX控件，可以很快地在網址、臺式應用程序、以及開發(fā)工具中加入特殊的功能。如StockTicker控件可以用來在網頁上即時地加入活動信息，動畫控件可用來向網頁中加入動畫特性。
[0006]插件技術主要存在以下幾個方面的缺點。一方面，插件開發(fā)成本高，難度大。對于插件開發(fā)者來說，如果想針對某個平臺開發(fā)一款插件，前提是必需熟悉平臺的開發(fā)標準和規(guī)范，在開發(fā)的過程中還要依賴平臺的框架，這增加了插件開發(fā)者的開發(fā)成本和開發(fā)難度。另一方面，插件同平臺的耦合性太高，導致應用平臺的風險加倍。當平臺成功加載某個插件以后，插件的代碼成為平臺的一部分。如果一個插件因自身程序的BUG導致崩潰，整個平臺會隨之崩潰。
[0007]因此，亟需一種能降低子功能模塊與整個應用平臺之間的耦合性的管理系統(tǒng)和方法。

【發(fā)明內容】

[0008]本發(fā)明的目的之一在于解決現有技術中，在進行應用平臺中子功能的開發(fā)時，子功能模塊與整個應用平臺的關聯性過高的技術缺陷。
[0009]本發(fā)明首先提供一種組件管理系統(tǒng)，包括:
[0010]組件構建模塊，其用于構建至少一個組件源程序，所述組件源程序具有組件標識信息和組件訪問入口；
[0011 ] 鏈接生成模塊，其根據組件標識信息為所述至少一個組件源程序生成相應的鏈接文件；
[0012]框架管理模塊，其執(zhí)行鏈接文件從而基于組件標識信息查找組件源程序，獲取并調用組件源程序中的組件訪問入口。
[0013]在一個實施例中，所述組件構建模塊進一步用于:
[0014]根據組件標識信息將原始程序包的原始運行入口修改為組件訪問入口，其中，組件訪問入口中包括組件標識信息；
[0015]將具有組件訪問入口的原始程序包編譯為動態(tài)鏈接庫文件，獲得組件源程序。
[0016]在一個實施例中，所述原始程序包與包含組件管理系統(tǒng)的應用平臺獨立，所述原始程序包的運行不依賴于應用平臺的函數和數據資源。
[0017]在一個實施例中，所述框架管理模塊進一步用于:
[0018]先發(fā)起父進程用于獲取組件源程序中的組件訪問入口，再在父進程中發(fā)起子進程來調用組件訪問入口。
[0019]在一個實施例中，所述框架管理模塊進一步用于:
[0020]將組件源程序的動態(tài)鏈接庫文件加載至內存；
[0021 ] 打開組件源程序的動態(tài)鏈接庫文件，確定組件訪問入口在內存中的地址。
[0022]本發(fā)明還提供一種組件管理方法，包括以下步驟:
[0023]構建至少一個組件源程序，所述組件源程序具有組件標識信息和組件訪問入口 ；
[0024]根據組件標識信息為所述至少一個組件源程序生成相應的鏈接文件；
[0025]執(zhí)行鏈接文件從而基于組件標識信息查找組件源程序，獲取并調用組件源程序中的組件訪問入口。
[0026]在一個實施例中，在構建至少一個組件源程序的步驟中包括:
[0027]根據組件標識信息修改原始程序包的原始運行入口，確定組件源程序的組件訪問入口，其中組件訪問入口中包括組件標識信息；
[0028]將具有組件訪問入口的原始程序包編譯為動態(tài)鏈接庫文件，得到組件源程序。
[0029]在一個實施例中，在獲取組件源程序中的組件訪問入口的步驟中包括:
[0030]將組件源程序的動態(tài)鏈接庫文件加載至內存；
[0031 ] 打開組件源程序的動態(tài)鏈接庫文件，確定組件訪問入口在內存中的地址。
[0032]本發(fā)明還提供一種組件執(zhí)行方法，包括以下步驟:
[0033]接收加載組件的指令；
[0034]根據指令中的組件標識信息執(zhí)行組件的鏈接文件，從而基于組件標識信息查找組件源程序；
[0035]獲取并調用組件源程序中的組件訪問入口 ；
[0036]根據組件訪問入口加載組件。
[0037]在一個實施例中，在獲取組件源程序中的組件訪問入口的步驟中包括:
[0038]將組件源程序的動態(tài)鏈接庫文件加載至內存；
[0039]打開組件源程序的動態(tài)鏈接庫文件，確定組件訪問入口在內存中的地址。
[0040]本發(fā)明的實施例可以將軟件系統(tǒng)結構中的某個子功能模塊或者子系統(tǒng)等抽象成組件，利用組件管理框架來管理這些組件。各組件不能單獨使用，必需依賴于管理框架才能使用，管理框架能夠管控所有組件，不同的組件之間的業(yè)務邏輯完全分離。
[0041]本申請的實施例可以降低組件開發(fā)與應用平臺的耦合性，這主要表現在兩個方面。首先，在進行軟件開發(fā)時，各組件之間的代碼和業(yè)務邏輯相互獨立，互不干涉。組件的研發(fā)人員只需要按照統(tǒng)一的規(guī)范定義好入口函數(類似于普通程序的main函數)，并將各自的代碼編譯成動態(tài)庫以后，并將編譯出的動態(tài)庫按照規(guī)定的命名規(guī)范命名便可。其次，在程序運行時，組件均由框架發(fā)起的子進程加載并執(zhí)行，每個組件均運行在獨立的子進程中，擁有獨立的地址空間和資源。因此一個組件崩潰只會導致框架中負責加載該組件的子進程退出，不會導致整個框架的崩潰。
[0042]本發(fā)明的其它特征和優(yōu)點將在隨后的說明書中闡述，并且，部分地從說明書中變得顯而易見，或者通過實施本發(fā)明而了解。本發(fā)明的目的和其他優(yōu)點可通過在說明書、權利要求書以及附圖中所特別指出的結構來實現和獲得。
【附圖說明】
[0043]附圖用來提供對本發(fā)明的進一步理解，并且構成說明書的一部分，與本發(fā)明的實施例共同用于解釋本發(fā)明，并不構成對本發(fā)明的限制。在附圖中:
[0044]圖1是現有技術中基于插件的系統(tǒng)架構原理圖；
[0045]圖2是實施例一的基于組件的系統(tǒng)架構圖；
[0046]圖3是實施例一的組件管理系統(tǒng)結構圖；
[0047]圖4是實施例二的組件管理方法的步驟流程圖；
[0048]圖5是實施例三的組件加載方法的步驟流程圖；
[0049]圖6是實施例三的一個示例中組件加載方法的步驟流程圖。
【具體實施方式】
[0050]為使本發(fā)明的目的、技術方案和優(yōu)點更加清楚，以下結合附圖對本發(fā)明作進一步地詳細說明。
[0051]以下結合說明書附圖對本