一種插件倉庫管理方法與系統的制作方法
【專利摘要】本發(fā)明公開了一種插件倉庫管理方法與系統，應用本發(fā)明的插件倉庫管理方法與系統，可以根據預設定的規(guī)則對用戶的權限進行鑒定，使用戶可以獲取對應權限的插件，根據用戶意愿將目標插件進行自動打包，且可以將不同服務器不同位置的插件打包到目的倉庫位置，若未指定目標服務器，還可以根據插件服務器資源使用情況挑選服務器，實現負載均衡。
【專利說明】一種插件倉庫管理方法與系統

【技術領域】
[0001]本發(fā)明涉及插件管理領域，特別是涉及一種插件倉庫管理方法與系統。

【背景技術】
[0002]目前集成開發(fā)環(huán)境Eclipse插件倉庫的創(chuàng)建有兩種方法:一是在eclipse IDE創(chuàng)建更新點工程，然后在工程中添加IDE已有的插件，通過執(zhí)行更新點創(chuàng)建操作，可以生成插件倉庫；二是在eclipse RCP應用程序導出的時候選中同時導出倉庫的復選項可以導出包含有該RCP程序所使用的插件的倉庫。通過以上兩種方式導出的倉庫復制到web容器的工作目錄下面就可以作為一個標準的插件更新點向eclipse RCP或者其他可以通過更新點來獲取插件供應的應用程序提供插件供應服務。
[0003]但目前的兩種方式導出的插件倉庫只是作為一種靜態(tài)的網絡資源，任何插件用戶都可以通過其URL來獲取倉庫的所有插件，倉庫所在的web容器或是插件的提供者無法控制插件用戶獲取倉庫插件的權限，這會造成定制化插件或者是收費性的插件容易被侵權，不方便插件倉庫的管理。


【發(fā)明內容】

[0004]有鑒于此，本發(fā)明的主要目的在于提供一種插件倉庫管理方法與系統，可以通過權限驗證來限制用戶插件資源的使用權限。
[0005]為實現上述目的，本發(fā)明提供了一種插件倉庫管理方法，包括:
[0006]獲取用戶標識和查詢條件，根據預設定的規(guī)則確定所述用戶標識所對應的可用插件范圍；
[0007]根據所述查詢條件在所述可用插件范圍中檢索目標插件，并根據預設定的打包計劃將所述目標插件打包到目標倉庫；
[0008]生成所述目標倉庫的路徑并將所述路徑發(fā)送至與所述用戶標識對應的客戶端；
[0009]所述將所述目標插件打包到目標倉庫包括:
[0010]判斷所述目標插件是否為本地插件，如果否則鏡像所述目標插件到本地為本地插件；
[0011]判斷所述目標倉庫是否有指定的服務器位置，如果否，則根據預設規(guī)則為所述目標倉庫指定服務器；
[0012]判斷所述目標倉庫所在的服務器位置是否為本機，如果是，則將所述本地插件打包至指定的本地目錄下，如果否則將所述本地插件打包至指定名稱的插件倉庫中，再將所述插件倉庫鏡像到所述目標倉庫所在的服務器目錄下并清除本地的所述插件倉庫。
[0013]優(yōu)選地，獲取用戶標識和查詢條件，根據預設定的規(guī)則確定所述用戶標識所對應的可用插件范圍后還包括:
[0014]將所述用戶標識和對應的可用插件范圍記錄到數據庫中。
[0015]優(yōu)選地，所述插件倉庫管理方法還包括，掃描第三方提交的插件，根據預設定的所述打包規(guī)則將所述第三方提交的插件打包到測試倉庫。
[0016]優(yōu)選地，生成所述目標倉庫的路徑并發(fā)送至與所述用戶標識對應的客戶端后還包括:
[0017]監(jiān)聽所述目標倉庫是否使用完畢，如果是則清除所述目標倉庫。
[0018]優(yōu)選地，根據預設定的所述打包規(guī)則將所述第三方提交的插件打包到測試倉庫后還包括，將所述測試倉庫信息記錄到所述數據庫中。
[0019]優(yōu)選地，所述預設定的打包計劃包括:
[0020]預設定的將所述目標插件打包到目標倉庫的時間點、周期和倉庫名稱生成規(guī)則。
[0021]優(yōu)選地，所述查詢條件為插件關鍵字和過濾條件。
[0022]本發(fā)明還提供了一種插件倉庫管理系統，包括:
[0023]獲取模塊，用于獲取用戶標識和查詢條件；
[0024]權限驗證模塊，用于根據預設定的規(guī)則確定所述用戶標識所對應的可用插件范圍；
[0025]檢索模塊，用于根據所述查詢條件在所述可用插件范圍中檢索目標插件；
[0026]第一打包模塊，用于根據預設定的打包計劃將所述目標插件打包到目標倉庫；
[0027]路徑生成模塊，用于生成所述目標倉庫的路徑；
[0028]路徑發(fā)送模塊，用于將所述路徑發(fā)送至與所述用戶標識對應的客戶端；
[0029]所述第一打包模塊包括:
[0030]第一判斷模塊，用于判斷所述目標插件是否為本地插件，如果否則鏡像所述目標插件到本地為本地插件；
[0031]第二判斷模塊，用于判斷所述目標倉庫是否有指定的服務器位置，如果否，則根據預設規(guī)則為所述目標倉庫指定服務器；
[0032]第三判斷模塊，用于判斷所述目標倉庫所在的服務器位置是否為本機，如果是，則將所述本地插件打包至指定的本地目錄下，如果否則將所述本地插件打包至指定名稱的插件倉庫中，再將所述插件倉庫鏡像到所述目標倉庫所在的服務器目錄下并清除本地的所述插件倉庫。
[0033]優(yōu)選地，所述插件倉庫管理系統還包括:
[0034]清除模塊，用于監(jiān)聽所述目標倉庫是否使用完畢，如果是則清除所述目標倉庫。
[0035]優(yōu)選地，所述插件倉庫管理系統還包括:
[0036]第二打包模塊，用于掃描第三方提交的插件，根據預設定的所述打包規(guī)則將所述第三方提交的插件打包到測試倉庫。
[0037]應用本發(fā)明提供的一種插件倉庫管理方法與系統，可以根據預設定的規(guī)則對用戶的權限進行鑒定，使用戶可以獲取對應權限的插件，根據用戶意愿將目標插件進行自動打包，且可以將不同服務器不同位置的插件打包到目的倉庫位置，若未指定目標服務器，還可以根據插件服務器資源使用情況挑選服務器，實現負載均衡。

【專利附圖】

【附圖說明】
[0038]為了更清楚地說明本發(fā)明實施例或現有技術中的技術方案，下面將對實施例或現有技術描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本發(fā)明的實施例，對于本領域普通技術人員來講，在不付出創(chuàng)造性勞動的前提下，還可以根據提供的附圖獲得其他的附圖。
[0039]圖1為本發(fā)明一種插件倉庫管理方法的流程圖；
[0040]圖2為本發(fā)明一種插件倉庫管理方法的詳細流程圖；
[0041]圖3為本發(fā)明一種插件倉庫管理方法的具體實施例流程圖；
[0042]圖4為本發(fā)明一種插件倉庫管理方法的又一具體實施例流程圖；
[0043]圖5為本發(fā)明一種插件倉庫管理系統的結構示意圖；
[0044]圖6為本發(fā)明一種插件倉庫管理系統的詳細結構示意圖；
[0045]圖7為本發(fā)明一種插件倉庫管理系統的實施例整體架構圖；
[0046]圖8為本發(fā)明一種插件倉庫管理系統的實施例系統數據關系映射圖。

【具體實施方式】
[0047]下面將結合本發(fā)明實施例中的附圖，對本發(fā)明實施例中的技術方案進行清楚、完整地描述，顯然，所描述的實施例僅僅是本發(fā)明一部分實施例，而不是全部的實施例?；诒景l(fā)明中的實施例，本領域普通技術人員在沒有做出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都屬于本發(fā)明保護的范圍。
[0048]本發(fā)明提供一種插件倉庫管理方法，如圖1所示，為本發(fā)明插件倉庫管理方法實施例的流程圖，包括:
[0049]步驟SlOl:獲取用戶標識和查詢條件，根據預設定的規(guī)則確定所述用戶標識所對應的可用插件范圍；
[0050]用戶提交關于需要獲取的插件的查詢條件和自身的用戶標識，查詢條件如關鍵字和過濾條件，用戶標識如可以被識別的證書序列號，系統獲取了用戶標識和查詢條件后根據證書序列號確定該用戶可使用的插件范圍。
[0051]步驟S102:根據所述查詢條件在所述可用插件范圍中檢索目標插件，并根據預設定的打包計劃將所述目標插件打包到目標倉庫；
[0052]預設定的打包計劃可包括自動打包的時間點、周期、倉庫名稱生成規(guī)則，該規(guī)則可由系統管理員制定。
[0053]步驟S103:生成所述目標倉庫的路徑并將所述路徑發(fā)送至與所述用戶標識對應的客戶端；
[0054]將用戶需要的目標插件打包到倉庫后生成該倉庫對應的路徑URL，用戶可通過該路徑訪問倉庫獲取需要的插件。
[0055]如圖2所示，所述將所述目標插件打包到目標倉庫具體包括:
[0056]步驟S201:判斷所述目標插件是否為本地插件，如果否則進入步驟S202 ;
[0057]步驟S202:鏡像所述目標插件到本地為本地插件；
[0058]步驟S203:判斷所述目標倉庫是否有指定的服務器位置，如果否則進入步驟S204 ；
[0059]步驟S204:根據預設規(guī)則為所述目標倉庫指定服務器；
[0060]步驟S205:判斷所述目標倉庫所在的服務器位置是否為本機，如果是則進入步驟S206，如果否則進入步驟S207 ；
[0061]步驟S206:將所述本地插件打包至指定的本地目錄下；
[0062]步驟S207:將所述本地插件打包至指定名稱的插件倉庫中，再將所述插件倉庫鏡像到所述目標倉庫所在的服務器目錄下并清除本地的所述插件倉庫。
[0063]應用本實施例提供的一種插件倉庫管理方法，可以根據預設定的規(guī)則對用戶的權限進行鑒定，使用戶可以獲取對應權限的插件，根據用戶意愿將目標插件進行自動打包，且可以將不同服務器不同位置的插件打包到目的倉庫位置，若未指定目標服務器，還可以根據插件服務器資源使用情況挑選服務器，實現負載均衡。
[0064]上述實施例的打包步驟可以將不同位置下的插件打包到不同服務器的分布式倉庫中，不同位置指其他網站的更新點的插件，本地計算機上位于多個不同目錄下的插件(包括插件工程的源碼)，分布式倉庫是指有一個主服務器web容器中運行主管理系統，其他多個服務器web容器中運行者副管理系統，該副管理系統受主管理系統的控制，這些服務器上的所有的插件倉庫集合就構成了一個完整的分布式倉庫。
[0065]管理員可以指定打包計劃自動打包，制訂自動打包計劃，通過網頁來設置自動打包的時間點、周期、倉庫名字生成規(guī)則等計劃內容，提交后會保存到服務器的事務計劃的配置文件中，該配置文件為一個格式良好且有效的XML文件，系統會周期性掃描所述計劃配置文件，并按照計劃執(zhí)行打包任務。管理員也可以手動進行插件打包，管理員登錄進入管理web頁面后，添加需要打包插件位置的URL或者絕對路徑，目標倉庫的名字位置(可以是本地或是其他插件服務器)。系統檢測插件位置，如果是其他更新站點的插件，則系統先鏡像遠程更新站點的目標插件到本地；如果是本地插件源，則不做處理。
[0066]遠程更新站點插件鏡像到本地后被當做本地的插件源，然后檢測目標倉庫的位置。如果是本機，則在本地的web容器工作目錄創(chuàng)建一個所述目標倉庫名字的文件夾，然后把所述插件源的插件打包到該目錄下。如果是在其他服務器上，則把先在本地打包好指定名字的插件倉庫，然后把該倉庫鏡像到目標服務器的web容器的工作目錄中，最后清除本地打包的倉庫。
[0067]當管理員未指定目標服務器時，系統自動分析各插件服務器的資源如磁盤容量、內存容量、CPU處理能力等的使用情況以及用戶訪問量來選擇最適合的服務器，盡可能讓用戶訪問量根據各服務器的資源剩余量和處理能力均勻分布到各個服務器中，實現分布式插件倉庫服務器的負載均衡。
[0068]本發(fā)明的又一具體實施例，可通過對用戶端進行插件ID授權實現管理。系統維護一個插件總庫，該插件總庫并不是一個標準的插件倉庫，它沒有插件的描述文件，只有二進制的元數據jar包。系統數據庫中記錄了插件總庫中的所有插件的信息，包括一個全局唯一的 ID 主鍵、插件內部的 ID(Bundle-SymbolicName)、版本(Bundle-Vers1n)、開發(fā)者、功能描述等插件的一些基本信息，其中ID和版本的組合和插件ID是一對一的映射關系。
[0069]同時系統還對每個現存的插件倉庫的基本信息也錄入了數據庫中。插件倉庫和插件總庫中的插件是多對多的數據映射關系。
[0070]每個用戶端在首次使用時都要求輸入軟件開發(fā)商授予該軟件的證書文件；
[0071]當用戶首次需要向本系統獲取插件時，系統要求其必須提交其證書序列號以及用戶的相關信息(軟件開發(fā)商、用戶姓名、郵箱、聯系方式等基本信息)。
[0072]系統會把用戶端提交的證書序列號通過其軟件開發(fā)商指定的證書認證服務接口來獲取該用戶端可使用插件的范圍，并把插件范圍信息和所述用戶提交的所有信息一同錄入數據庫中。
[0073]系統根據用戶端的插件使用范圍從插件信息數據庫中檢索出其所需的插件集合，并從插件總庫中把這些插件的元數據打包到I個或多個插件倉庫，并在插件倉庫信息數據庫中添加相應的記錄，然后系統會把這些倉庫的完整的URL返回給用戶端，最后用戶端會通過這些URL直接去插件倉庫獲取插件。
[0074]用戶每次訪問數據庫所進行的操作都被記錄在數據庫中。系統管理員可以從日志數據庫中看到所有用戶每一次訪問插件倉庫所進行的操作記錄。
[0075]如圖3所示，為客戶端獲取插件的【具體實施方式】流程圖，圖4為一具體實施例用戶進行插件高級查詢的流程圖。
[0076]本發(fā)明的另一實施例，還可掃描第三方提交的插件，根據預設定的所述打包規(guī)則將所述第三方提交的插件打包到測試倉庫，另外提供了一種插件倉庫的垃圾回收機制，監(jiān)聽用戶查詢創(chuàng)建的臨時插件倉庫是否使用完畢，如果用戶端已經使用完該倉庫，系統會及時清理該倉庫；監(jiān)聽被鏡像到子服務器上的倉庫是否完成操作，如果鏡像成功，則會清除掉主服務器上的該倉庫；如果一個倉庫創(chuàng)建時間比較久，且其中的插件版本比較老并且有新的版本產生，或者已經長久不再使用，系統會清除掉該類倉庫。
[0077]本發(fā)明還提供了一種插件倉庫管理系統，如圖5和圖6所示，為本發(fā)明插件倉庫管理系統的實施例結構示意圖，包括:
[0078]獲取模塊101，用于獲取用戶標識和查詢條件；
[0079]權限驗證模塊102，用于根據預設定的規(guī)則確定所述用戶標識所對應的可用插件范圍；
[0080]檢索模塊103，用于根據所述查詢條件在所述可用插件范圍中檢索目標插件；
[0081]第一打包模塊104，用于根據預設定的打包計劃將所述目標插件打包到目標倉庫；
[0082]路徑生成模塊105，用于生成所述目標倉庫的路徑；
[0083]路徑發(fā)送模塊106，用于將所述路徑發(fā)送至與所述用戶標識對應的客戶端；
[0084]所述第一打包模104塊具體包括:
[0085]第一判斷模塊201，用于判斷所述目標插件是否為本地插件，如果否則鏡像所述目標插件到本地為本地插件；
[0086]第二判斷模塊202，用于判斷所述目標倉庫是否有指定的服務器位置，如果否，則根據預設規(guī)則為所述目標倉庫指定服務器；
[0087]第三判斷模塊203，用于判斷所述目標倉庫所在的服務器位置是否為本機，如果是，則將所述本地插件打包至指定的本地目錄下，如果否則將所述本地插件打包至指定名稱的插件倉庫中，再將所述插件倉庫鏡像到所述目標倉庫所在的服務器目錄下并清除本地的所述插件倉庫。
[0088]本發(fā)明系統的另一實施例對應于上述實施例還包括:
[0089]清除模塊，用于監(jiān)聽所述目標倉庫是否使用完畢，如果是則清除所述目標倉庫。
[0090]第二打包模塊，用于掃描第三方提交的插件，根據預設定的所述打包規(guī)則將所述第三方提交的插件打包到測試倉庫。
[0091]提供了插件倉庫垃圾回收機制和對第三方插件的收錄功能。
[0092]本實施例系統的【具體實施方式】可基于B/S架構，如圖7所示，系統用戶劃分為4類角色:管理員、內部插件開發(fā)人員、第三方插件開發(fā)人員、插件消費者。每種角色擁有不同的操作權限。
[0093]管理員:手動執(zhí)行倉庫打包的操作、制訂無人值守的自動打包計劃、查看所有倉庫中插件的詳細信息并可以進行增刪改查的操作，修改開發(fā)人員和消費者的權限，添加內部開發(fā)人員賬戶的權限，注銷開發(fā)人員和消費者賬戶的權限。
[0094]內部插件開發(fā)人員:向系統提交插件的權限。
[0095]第三方開發(fā)人員:注冊賬戶，向系統提交插件的權限。
[0096]插件消費者:消費者應用程序訪問主站點查詢、獲取或更新插件的權限。
[0097]如圖8所示為本實施例的系統數據關系映射圖。
[0098]本發(fā)明的方法與系統可以使用Equinox p2 (provis1ning platform)技術，對位于不同計算機上不同位置的eclipse插件或者是未編譯的源代碼進行打包到同一個倉庫，并對打包好的倉庫進行分布式存儲、發(fā)布，對每一個插件進行編號，設置一個全局唯一的編碼并進行對插件的內部的ID和版本進行一對一映射，把該映射及插件的一些附加信息(功能描述、分類、開發(fā)者、插件提交日期等)一同錄入數據庫中，并建立好插件與更新點倉庫信息表的關聯關系，支持第三方插件開發(fā)者提交插件到系統；對插件消費用戶通過對其授權文件添加授權插件的ID進行插件的使用的權限限制；支持倉庫管理人員管理所有服務器上的插件及倉庫；支持用戶對插件的高級查詢，并動態(tài)生成用戶意愿插件集合的倉庫；支持臨時倉庫及長久不用插件及倉庫的回收；支持手動和無人值守的周期性自動化倉庫打包模式；支持分布式插件倉庫服務器的負載均衡。
[0099]最后，還需要說明的是，在本文中，諸如第一和第二等之類的關系術語僅僅用來將一個實體或者操作與另一個實體或操作區(qū)分開來，而不一定要求或者暗示這些實體或操作之間存在任何這種實際的關系或者順序。而且，術語“包括”、“包含”或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、物品或者設備不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、物品或者設備所固有的要素。在沒有更多限制的情況下，由語句“包括一個……”限定的要素，并不排除在包括所述要素的過程、方法、物品或者設備中還存在另外的相同要素。
[0100]以上對本發(fā)明所提供的方法與系統進行了詳細介紹，本文中應用了具體個例對本發(fā)明的原理及實施方式進行了闡述，以上實施例的說明只是用于幫助理解本發(fā)明的方法及其核心思想；同時，對于本領域的一般技術人員，依據本發(fā)明的思想，在【具體實施方式】及應用范圍上均會有改變之處，綜上所述，本說明書內容不應理解為對本發(fā)明的限制。
【權利要求】
1.一種插件倉庫管理方法，其特征在于，包括: 獲取用戶標識和查詢條件，根據預設定的規(guī)則確定所述用戶標識所對應的可用插件范圍； 根據所述查詢條件在所述可用插件范圍中檢索目標插件，并根據預設定的打包計劃將所述目標插件打包到目標倉庫； 生成所述目標倉庫的路徑并將所述路徑發(fā)送至與所述用戶標識對應的客戶端； 所述將所述目標插件打包到目標倉庫包括: 判斷所述目標插件是否為本地插件，如果否則鏡像所述目標插件到本地為本地插件；判斷所述目標倉庫是否有指定的服務器位置，如果否，則根據預設規(guī)則為所述目標倉庫指定服務器； 判斷所述目標倉庫所在的服務器位置是否為本機，如果是，則將所述本地插件打包至指定的本地目錄下，如果否則將所述本地插件打包至指定名稱的插件倉庫中，再將所述插件倉庫鏡像到所述目標倉庫所在的服務器目錄下并清除本地的所述插件倉庫。
2.根據權利要求1所述的插件倉庫管理方法，其特征在于，獲取用戶標識和查詢條件，根據預設定的規(guī)則確定所述用戶標識所對應的可用插件范圍后還包括: 將所述用戶標識和對應的可用插件范圍記錄到數據庫中。
3.根據權利要求2所述的插件倉庫管理方法，其特征在于，還包括，掃描第三方提交的插件，根據預設定的所述打包規(guī)則將所述第三方提交的插件打包到測試倉庫。
4.根據權利要求3所述的插件倉庫管理方法，其特征在于，生成所述目標倉庫的路徑并發(fā)送至與所述用戶標識對應的客戶端后還包括: 監(jiān)聽所述目標倉庫是否使用完畢，如果是則清除所述目標倉庫。
5.根據權利要求4所述的插件倉庫管理方法，其特征在于，根據預設定的所述打包規(guī)則將所述第三方提交的插件打包到測試倉庫后還包括，將所述測試倉庫信息記錄到所述數據庫中。
6.根據權利要求5所述的插件倉庫管理方法，其特征在于，所述預設定的打包計劃包括: 預設定的將所述目標插件打包到目標倉庫的時間點、周期和倉庫名稱生成規(guī)則。
7.根據權利要求6所述的插件倉庫管理方法，其特征在于，所述查詢條件為插件關鍵字和過濾條件。
8.一種插件倉庫管理系統，其特征在于，包括: 獲取模塊，用于獲取用戶標識和查詢條件； 權限驗證模塊，用于根據預設定的規(guī)則確定所述用戶標識所對應的可用插件范圍； 檢索模塊，用于根據所述查詢條件在所述可用插件范圍中檢索目標插件； 第一打包模塊，用于根據預設定的打包計劃將所述目標插件打包到目標倉庫； 路徑生成模塊，用于生成所述目標倉庫的路徑； 路徑發(fā)送模塊，用于將所述路徑發(fā)送至與所述用戶標識對應的客戶端； 所述第一打包模塊包括: 第一判斷模塊，用于判斷所述目標插件是否為本地插件，如果否則鏡像所述目標插件到本地為本地插件； 第二判斷模塊，用于判斷所述目標倉庫是否有指定的服務器位置，如果否，則根據預設規(guī)則為所述目標倉庫指定服務器； 第三判斷模塊，用于判斷所述目標倉庫所在的服務器位置是否為本機，如果是，則將所述本地插件打包至指定的本地目錄下，如果否則將所述本地插件打包至指定名稱的插件倉庫中，再將所述插件倉庫鏡像到所述目標倉庫所在的服務器目錄下并清除本地的所述插件倉庫。
9.根據權利8所述的插件倉庫管理系統，其特征在于，還包括: 清除模塊，用于監(jiān)聽所述目標倉庫是否使用完畢，如果是則清除所述目標倉庫。
10.根據權利要求9所述的插件倉庫管理系統，其特征在于，還包括: 第二打包模塊，用于掃描第三方提交的插件，根據預設定的所述打包規(guī)則將所述第三方提交的插件打包到測試倉庫。
【文檔編號】H04L29/08GK104506628SQ201410826524
【公開日】2015年4月8日 申請日期:2014年12月25日 優(yōu)先權日:2014年12月25日
【發(fā)明者】唐健, 陳毅林, 尼四凱 申請人:深圳市科漫達智能管理科技有限公司