本發(fā)明涉及金融設備技術領域，特別是涉及插件升級的方法、系統(tǒng)及裝置。

背景技術：

在軟件設計中，為了方便對軟件進行功能擴展，通常采用插件方式進行開發(fā)，將軟件所要實現(xiàn)的一個一個功能封裝在插件中。通過插件式的軟件架構(gòu)，不需要修改應用程序，就可以增減應用程序的功能，提高了軟件的可擴展性。對軟件插件升級通常的做法是：通過服務器對用戶端軟件的所有插件統(tǒng)一進行升級，以及統(tǒng)一的軟件版本管理。

然而這種插件升級方式的靈活度受限，特別是在應用軟件和硬件相關的場合，例如現(xiàn)金處理設備(ATM(Automatic Teller Machine，自動取款機)、VTM(Virtual Teller Machine，虛擬柜員機)、清分機、售票機等)，由于用戶端的應用軟件及其功能插件與設備硬件特性緊密相關，同一功能的用戶端存在著不同廠商提供的硬件設備，沒法做到軟件版本統(tǒng)一管理以及插件統(tǒng)一升級，因此容易導致因插件版本與設備硬件不兼容引起的設備故障、賬務長短款等問題，為避免此類問題，需要人工一對一的對用戶端的軟件插件進行升級維護，維護效率低，維護成本高。

技術實現(xiàn)要素：

基于此，本發(fā)明實施例提供一種插件升級的方法、系統(tǒng)及裝置，能夠提高對用戶端軟件插件升級維護的效率。

本發(fā)明一方面提供一種插件升級的方法，包括：

服務器確定待升級的用戶端；根據(jù)待升級的用戶端、各用戶端待升級的插件創(chuàng)建與用戶端的設備屬性對應的升級任務列表；

用戶端向服務器發(fā)送升級任務的查詢請求；

服務器獲取所述用戶端對應的設備屬性，查詢已創(chuàng)建的升級任務列表中有所述用戶端對應的升級任務，向所述用戶端返回所述升級任務的清單；所述升級任務的清單中至少包括需升級的插件、插件版本以及下載地址；

所述用戶端根據(jù)所述升級任務的清單下載相應的插件，將本地的控制軟件的相應插件升級到對應版本。

本發(fā)明又一方面提供一種插件升級的方法，包括：

向服務器發(fā)送升級任務的查詢請求；

接收服務器返回的與本端的設備屬性對應的升級任務的清單；所述升級任務的清單中至少包括需升級的插件、插件版本以及下載地址；

根據(jù)所述升級任務的清單下載相應的插件，將本地的控制軟件的相應插件升級到對應版本。

本發(fā)明又一方面提供一種插件升級的方法，包括：

確定待升級的用戶端；根據(jù)待升級的用戶端、各用戶端待升級的插件創(chuàng)建與用戶端的設備屬性對應的升級任務列表；

接收用戶端發(fā)送的升級任務的查詢請求，獲取所述用戶端對應的設備屬性，查詢已創(chuàng)建的升級任務列表中有所述用戶端對應的升級任務；

向所述用戶端返回所述升級任務的清單，所述升級任務的清單中至少包括需升級的插件、插件版本以及下載地址。

本發(fā)明又一方面提供一種插件升級的系統(tǒng)，包括服務器和用戶端，所述服務器和用戶端通信連接，所述服務器包括：

任務創(chuàng)建模塊，用于確定待升級的用戶端；根據(jù)待升級的用戶端、各用戶端待升級的插件創(chuàng)建與用戶端的設備屬性對應的升級任務列表；

所述用戶端包括：

任務查詢模塊，用于向服務器發(fā)送升級任務的查詢請求；

所述服務器還包括：

任務下發(fā)模塊，用于獲取所述用戶端對應的設備屬性，查詢已創(chuàng)建的升級任務列表中有所述用戶端對應的升級任務，向所述用戶端返回所述升級任務的清單；所述升級任務的清單中至少包括需升級的插件、插件版本以及下載地址；

所述用戶端還包括：

升級執(zhí)行模塊，用于根據(jù)所述升級任務的清單下載相應的插件，將本地的控制軟件的相應插件升級到對應版本。

本發(fā)明又一方面提供一種插件升級的裝置，包括：

任務查詢模塊，用于向服務器發(fā)送升級任務的查詢請求；以及用于接收服務器返回的與本端的設備屬性對應的升級任務的清單；所述升級任務的清單中至少包括需升級的插件、插件版本以及下載地址；

升級執(zhí)行模塊，用于根據(jù)所述升級任務的清單下載相應的插件，將本地的控制軟件的相應插件升級到對應版本。

本發(fā)明又一方面提供一種插件升級的裝置，包括：

任務創(chuàng)建模塊，用于確定待升級的用戶端；根據(jù)待升級的用戶端、各用戶端待升級的插件創(chuàng)建與用戶端的設備屬性對應的升級任務列表；

任務下發(fā)模塊，用于接收用戶端發(fā)送的升級任務的查詢請求，獲取所述用戶端對應的設備屬性，查詢已創(chuàng)建的升級任務列表中有所述用戶端對應的升級任務；以及用于向所述用戶端返回所述升級任務的清單；所述升級任務的清單中至少包括需升級的插件、插件版本以及下載地址。

上述技術方案，服務器可從全部通信連接的用戶端中靈活確定出待升級的用戶端以及待升級的插件，并創(chuàng)建相應的與用戶端的設備屬性對應的升級任務列表；各個用戶端通過向服務器發(fā)送升級任務的查詢請求，服務器根據(jù)所述用戶端的設備屬性查詢已創(chuàng)建的升級任務列表中是否有該用戶端對應的升級任務，若有則向?qū)脩舳朔祷叵鄳纳壢蝿盏那鍐?，包括需升級的插件、插件版本以及下載地址；從而各個用戶端可分別根據(jù)服務器返回的升級任務的清單下載相應的插件，將本地的控制軟件的相應插件升級到對應版本。由此可靈活確定需要升級的用戶端以及用戶端軟件插件，并且可以同時對多個用戶端進行差異化的插件升級，無需人工一對一的進行升級維護，提高了升級維護效率。

附圖說明

圖1為一實施例的插件升級的方法的示意性流程圖；

圖2為一實施例中服務器端創(chuàng)建的升級任務列表的ER圖；

圖3為與圖2中升級任務列表關聯(lián)的各升級任務的清單的ER圖；

圖4為一實施例中服務器端基于區(qū)域?qū)傩缘玫降挠脩舳藢傩詷浣Y(jié)構(gòu)的示意圖；

圖5為一實施例中服務器端基于設備類型得到的用戶端屬性樹結(jié)構(gòu)的示意圖；

圖6為基于圖4的用戶端屬性樹結(jié)構(gòu)得到的用戶端數(shù)據(jù)表的ER圖；

圖7為基于圖5的用戶端屬性樹結(jié)構(gòu)得到的用戶端數(shù)據(jù)表的ER圖；

圖8為一實施例中服務器端保存的版本檔案中數(shù)據(jù)結(jié)構(gòu)的邏輯示意圖；

圖9為一實施例中服務器端保存的版本檔案中升級檔案數(shù)據(jù)表的ER圖；

圖10為與圖9中升級檔案數(shù)據(jù)表關聯(lián)的版本信息數(shù)據(jù)表的ER圖；

圖11為一實施例的服務器端主動型的插件升級的方法的應用場景的示意圖；

圖12為一實施例的用戶端主動型的插件升級的方法的應用場景的示意圖；

圖13為另一實施例的插件升級的方法的示意性流程圖；

圖14為另一實施例的插件升級的方法的示意性流程圖；

圖15為一實施例的插件升級的系統(tǒng)的示意性結(jié)構(gòu)圖；

圖16為一實施例的插件升級的裝置的示意性結(jié)構(gòu)圖；

圖17為一實施例的插件升級的裝置的示意性結(jié)構(gòu)圖。

具體實施方式

為了使本發(fā)明的目的、技術方案及優(yōu)點更加清楚明白，以下結(jié)合附圖及實施例，對本發(fā)明進行進一步詳細說明。應當理解，此處所描述的具體實施例僅僅用以解釋本發(fā)明，并不用于限定本發(fā)明。

圖1為一實施例的插件升級的方法的示意性流程圖；在該實施例中，所述用戶端為ATM、VTM、清分機、售票機等現(xiàn)金設備，這類用戶端的控制軟件均包含若干插件；并且這類用戶端還與遠程的服務器通信連接。參考圖1所示，本實施例插件升級的方法包括步驟：

S11，服務器確定待升級的用戶端；根據(jù)待升級的用戶端、各用戶端待升級的插件創(chuàng)建與用戶端的設備屬性對應的升級任務列表；

本實施例中，所述設備屬性信息包括用戶端對應的區(qū)域?qū)傩曰蛘咴O備類型屬性。服務器可根據(jù)選定的設備屬性確定待升級的用戶端，例如：預先根據(jù)設備屬性信息建立用戶端屬性樹結(jié)構(gòu)，從預先建立的用戶端屬性樹結(jié)構(gòu)中確定出歸屬于所述選定的設備屬性的用戶端，作為待升級的用戶端。由此可提供確定待升級的用戶端的效率。

本實施例中，服務器端創(chuàng)建的升級任務列表可包括兩類關聯(lián)的數(shù)據(jù)表，一類為記錄升級任務列表概況的數(shù)據(jù)表，其對應的ER圖參考圖2所示，至少包括升級任務ID以及對應的設備屬性。另一類為反應各升級任務清單的數(shù)據(jù)表，對應的ER圖參考圖3所示，至少包括升級任務ID、插件名、插件版本以及下載地址等信息，升級任務概況的數(shù)據(jù)表與各升級任務清單的數(shù)據(jù)表通過升級任務ID為外鍵進行關聯(lián)。

S12，用戶端向服務器發(fā)送升級任務的查詢請求；

本實施例中，用戶端在啟動時，檢查服務器端是否有屬于自己的升級任務，具體做法為向服務器發(fā)送升級任務的查詢請求。可以理解的是，所述升級任務的查詢請求中至少包含所述用戶端的設備ID以及其所屬的設備屬性。

S13，服務器獲取所述用戶端對應的設備屬性，查詢已創(chuàng)建的升級任務列表中有所述用戶端對應的升級任務，向所述用戶端返回所述升級任務的清單；所述升級任務的清單中至少包括需升級的插件、插件版本以及下載地址；

本實施例中，服務器可根據(jù)預先建立用戶端屬性樹結(jié)構(gòu)獲取請求用戶端的設備屬性，服務器端創(chuàng)建的升級任務列表以用戶端的設備屬性作為索引，因此服務器可根據(jù)用戶端對應的設備屬性查詢已創(chuàng)建的升級任務列表，檢測其中是否有該設備屬性相關的升級任務。若有，進一步的，以升級任務ID作為外鍵關聯(lián)到對應的任務清單數(shù)據(jù)表，得到對應的任務詳情(清單)，例如：升級任務ID、需升級的插件、插件版本以及下載地址。由此可得到用戶端對應的插件升級信息，然后將插件升級的詳情下發(fā)給對應的用戶端。

S14，所述用戶端根據(jù)所述升級任務的清單下載相應的插件，將本地的控制軟件的相應插件升級到對應版本。

用戶端根據(jù)服務器下發(fā)的升級任務的清單，得到本次需要升級的插件、插件目標版本，并自動鏈接到相應的下載地址下載相應的插件，進而將本地的控制軟件的相應插件升級到對應版本。

作為一優(yōu)選實施方式，所述設備屬性信息包括區(qū)域?qū)傩曰蛘咴O備類型屬性。本實施例的插件升級的方法還包括步驟：在服務器端預先根據(jù)區(qū)域?qū)傩詣?chuàng)建第一用戶端屬性樹結(jié)構(gòu)，以及根據(jù)設備類型屬性創(chuàng)建第二用戶端屬性樹結(jié)構(gòu)。下面結(jié)合圖4～圖7對在服務器端創(chuàng)建的用戶端屬性樹結(jié)構(gòu)及相關的用戶端數(shù)據(jù)表進行舉例說明。其中用戶端的區(qū)域?qū)傩钥筛鶕?jù)用戶端所屬單位的組織結(jié)構(gòu)進行劃分，參考圖4所示，可根據(jù)銀行的結(jié)構(gòu)劃分現(xiàn)金設備的區(qū)域?qū)傩裕瑢y行管轄區(qū)域按樹形劃分為若干一級區(qū)域?qū)傩?，如分行?～n，每個一級區(qū)域?qū)傩韵掠挚蓜澐譃槿舾啥墔^(qū)域?qū)傩裕缰杏?～n；如此類推葉子節(jié)點是具體的現(xiàn)金設備。在該樹形結(jié)構(gòu)中，最小的區(qū)域?qū)傩员闶翘囟ǖ哪硞€設備(可用設備ID進行標識)。根據(jù)該樹形結(jié)構(gòu)可建立第一用戶數(shù)據(jù)表，其ER圖如圖6所示，第一用戶數(shù)據(jù)表可以葉子節(jié)點之外的區(qū)域?qū)傩?例如區(qū)域ID)作為外鍵。設備ID、區(qū)域ID均可根據(jù)實際情況設定，屬于同一級的區(qū)域?qū)傩缘膮^(qū)域ID各不相同，屬于同一級的區(qū)域?qū)傩缘脑O備ID各不相同。

此外，也可根據(jù)設備類型將若干用戶端組織為樹形結(jié)構(gòu)。參考圖5所示，例如按照功能進行組織，包含若干一級類型屬性，如功能類型1～n(例如ATM為類型1，VTM為類型2等)，每個一級類型屬性下又包含若干個二級類型屬性，如廠商1～n,二級類型屬性下又可包含若干三級類型屬性，如型號1～n；如此類推葉子節(jié)點是某臺具體的現(xiàn)金設備。該樹形結(jié)構(gòu)中，最小的類型屬性便是特定的某個設備。如圖7所示，根據(jù)該樹形結(jié)構(gòu)可建立第二用戶數(shù)據(jù)表，其ER圖如圖7所示，其中葉子節(jié)點便是設備ID，第二用戶數(shù)據(jù)表可以葉子節(jié)點之外的各級類型屬性作為外鍵。設備ID、各級類型屬性的ID可根據(jù)實際情況設定，屬于同一級類型屬性的各類型屬性ID各不相同。

基于上述的服務器端創(chuàng)建的用戶端屬性樹結(jié)構(gòu)以及對應的用戶端數(shù)據(jù)表，對應的，在步驟S12中服務器獲取所述用戶端對應的設備屬性的過程可包括：查詢所述第一用戶端數(shù)據(jù)表或第二用戶端數(shù)據(jù)表，得到所述用戶端對應的設備屬性?；谏鲜鲇脩舳藬?shù)據(jù)表，其邏輯清晰，索引效率高。

本實施例中，在服務器端還預先建立有各用戶端的控制軟件的版本檔案，該版本檔案中記錄的數(shù)據(jù)內(nèi)容包括控制軟件的歷史版本信息，參考圖8所示，可包括版本號、版本升級時間、對應的升級任務ID等信息；進一步的，每個歷史版本下又進一步關聯(lián)有插件的控制軟件版本信息。參考圖9所示，基于上述版本檔案的數(shù)據(jù)結(jié)構(gòu)，在服務器端的數(shù)據(jù)庫中還預先創(chuàng)建了有用于保存用戶端對應的控制軟件的版本檔案的數(shù)據(jù)表，包括一級數(shù)據(jù)表和與之關聯(lián)的二級數(shù)據(jù)表，分別參考圖9、圖10，其中一級數(shù)據(jù)表用于保存用戶端ID(即設備ID)、用戶端控制軟件的版本號、版本升級時間、對應的升級任務ID等，二級數(shù)據(jù)表記錄了升級任務ID、插件名、插件版本以及下載地址等信息。并且，一級數(shù)據(jù)表與二級數(shù)據(jù)表以升級任務ID為外鍵進行關聯(lián)。

本實施例中，在用戶端記錄其控制軟件的當前控制軟件版本信息，包括控制軟件當前版本號、包含的插件名以及插件控制軟件版本信息；也可以像服務器端一樣，對歷史版本信息均記錄下來，形成一版本檔案。優(yōu)選的，本實施例中用戶端以覆蓋的方式僅記錄控制軟件的當前版本信息，以節(jié)省用戶端的存儲空間。

基于服務器端的版本檔案和用戶端本地記錄的控制軟件版本信息，作為一優(yōu)選實施方式，用戶端將本地的控制軟件的相應插件升級到對應版本之后，還會更新本地記錄的控制軟件版本信息，并將更新后的控制軟件版本信息上報給服務器；對應的，服務器在收到用戶端上報的控制軟件版本信息后，更新服務器端存儲的該用戶端的控制軟件的版本檔案。由此服務器端可統(tǒng)一管理各用戶端的控制軟件的控制軟件版本信息，方便管理人員管理，即管理員可通過查看各用戶端在服務器中的版本檔案信息，確定出哪些用戶端的控制軟件需要升級，或者用戶端控制軟件的哪些插件需要升級，便于對分散在各地的用戶端進行統(tǒng)一且差異化的升級管理；另一方面，在用戶端和服務器兩處均存儲了控制軟件版本信息，也有利于增強系統(tǒng)數(shù)據(jù)的可靠性，例如：當某用戶端出現(xiàn)故障時，可根據(jù)服務器端保存的對應版本檔案信息對該用戶端進行恢復。

圖11為本發(fā)明一實施例的服務器端主動型的插件升級的方法的應用場景的示意圖，如圖11所示，本應用場景下，由服務器主動管理用戶端插件升級，用戶端插件升級的過程如下：

S111，管理人員基于服務器端保存的各用戶端的控制軟件的版本檔案，對服務器端進行升級設置；

本實施例中，可設置待升級的設備屬性，例如設置某分行下的設備屬性，或者設置某廠商的設備屬性。對應的，只需輸入或者選擇某分行的設備屬性，或者某廠商的設備屬性，由此可從全部用戶端中確定若干個待升級的用戶端。既方便對用戶端進行靈活的管理，又可保證維護效率。

S112，服務器端接收升級設置，根據(jù)設置的設備屬性確定待升級的用戶端以及待升級的插件，創(chuàng)建升級任務列表；

服務器端可同時創(chuàng)建多個用戶端對應的升級任務，構(gòu)成升級任務列表。

S113，用戶端啟動時，向服務器發(fā)送升級任務的查詢請求；

所述升級任務的查詢請求中至少包含用于確定所述用戶端對應的設備屬性的信息；

S114，服務器獲取所述用戶端對應的設備屬性，查詢已創(chuàng)建的升級任務列表中有所述用戶端對應的升級任務，向用戶端發(fā)送所述升級任務的清單；

本實施例中，可根據(jù)該用戶端在用戶端屬性樹結(jié)構(gòu)中的中位置，確定出所述用戶端對應的設備屬性，進而檢測升級任務列表中是否存在有該用戶端相關的升級任務。

若確定出升級任務列表中沒有該用戶端相關的升級任務，可返回空的響應，或者不做回應。

S115，用戶端在收到服務器端發(fā)送的升級任務的清單后，便可根據(jù)所述升級任務的清單下載相應的插件，將本地的控制軟件的相應插件升級到對應版本。

若用戶端在收到服務器端返回的空響應，或者，在發(fā)出升級任務的查詢請求后設定時間內(nèi)未收到服務器端的響應，則確定為當前沒有升級任務，不進行控制軟件的升級。

S116，用戶端將本地的控制軟件的相應插件升級到對應版本之后，更新本地記錄的控制軟件版本信息；

S117，用戶端將更新后的控制軟件版本信息上報給服務器。

客戶端直接將更新后的控制軟件版本信息發(fā)送給服務器。

S118，服務器在收到用戶端上報的控制軟件版本信息后，更新服務器端存儲的所述用戶端的控制軟件的版本檔案。該方案可以降低服務器的運算量。

在另一優(yōu)選實施方式中，在客戶端將本地的控制軟件的相應插件升級到對應版本之后，步驟S117還可替換為：用戶端向服務器端發(fā)送升級完成的消息，所述消息的內(nèi)容包括升級任務ID和升級完成狀態(tài)，但不包括具體的軟件版本信息。對應的，步驟S118可替換為，服務器在收到上述消息之后，可根據(jù)升級完成狀態(tài)和所述升級任務ID檢索獲得對應的控制軟件版本信息，進而根據(jù)所述控制軟件版本信息更新服務器端存儲的所述用戶端的控制軟件的版本檔案。即服務器在收到上述消息之后，若檢測到為升級成功的升級完成狀態(tài)，則根據(jù)所述升級任務ID檢索獲得對應的控制軟件版本信息，進而更新服務器端存儲的所述用戶端的控制軟件的版本檔案。該方案有利于進一步減少用戶端與服務器之間的數(shù)據(jù)傳輸量。

在實際使用中，某區(qū)域?qū)傩缘娜坑脩舳嘶蛘吣硡^(qū)域?qū)傩缘哪承┯脩舳?，因硬件環(huán)境的變更或者需求功能變更，其控制軟件的插件需回退到某個歷史版本。針對該情況，作為另一優(yōu)選實施方式，本實施例的用戶端還可主動請求版本回退，實現(xiàn)過程包括：若用戶端檢測到回退指令，向服務器發(fā)送版本檔案的查詢請求，所述版本檔案的查詢請求中至少包括用于確定所述用戶端對應的設備屬性的信息；服務器獲取與所述用戶端對應的控制軟件的版本檔案，向所述用戶端返回所述版本檔案；用戶端向所述服務器發(fā)送回退更新請求，所述回退更新請求中至少包括從所述版本檔案中確定出的目標版本/升級時間點；服務器根據(jù)所述目標版本/升級時間點確定出對應的歷史升級任務，向所述用戶端返回所述歷史升級任務的清單；所述歷史升級任務的清單中至少包括需回退的插件、插件版本以及下載地址；用戶端根據(jù)所述歷史升級任務的清單下載相應的插件，將本地的控制軟件的相應插件回退更新到對應的版本，完成用戶端控制軟件的版本回退。

圖12為本發(fā)明一實施例的用戶端主動型的插件升級的方法的應用場景的示意圖，本應用場景下，由用戶端主動發(fā)起升級請求(這里指的是回退版本的請求)，實現(xiàn)用戶端插件升級的過程如下：

S121，管理人員對用戶端進行設置，向用戶端發(fā)出控制軟件的回退指令。

S122，用戶端檢測到回退指令，向服務器發(fā)送版本檔案的查詢請求；

S123，服務器獲取所述用戶端對應的控制軟件的版本檔案；向所述用戶端返回所述版本檔案；

S124，管理人員可在用戶端根據(jù)服務器返回的版本檔案，確定當前需回退的控制軟版本，或者歷史上的升級時間點，對用戶端進行回退設置；

S125，用戶端接收所述回退設置，向所述服務器發(fā)送回退更新請求，所述回退更新請求中至少包括從所述版本檔案中確定出的目標版本/升級時間點；

S126，服務器根據(jù)所述目標版本/升級時間點確定出對應的歷史升級任務，并獲得該歷史升級任務對應的清單；

S127，向所述用戶端返回該條歷史升級任務的清單；該條倆是升級任務的清單中至少包括需回退的插件、插件版本以及下載地址；

S128，用戶端根據(jù)該條歷史升級任務的清單下載相應的插件，將本地的控制軟件的相應插件回退更新到對應的版本；并更新本地記錄的控制軟件版本信息；

S129，將更新后的控制軟件版本信息上報給服務器；

S130，服務器在收到用戶端上報的控制軟件版本信息后，更新服務器端存儲的所述用戶端的控制軟件的版本檔案。該方案可以降低服務器的運算量。

同理，在另一優(yōu)選實施方式中，在客戶端將本地的控制軟件的相應插件回退更新到對應的版本之后，步驟S129還可替換為：用戶端向服務器端發(fā)送回退更新完成的消息，所述消息的內(nèi)容包括升級任務ID和升級完成狀態(tài)，但不包括具體的軟件版本信息。對應的，步驟S130可替換為，服務器在收到上述回退更新完成的消息之后，可根據(jù)所述升級任務ID和升級完成狀態(tài)檢索獲得對應的控制軟件版本信息，進而根據(jù)所述控制軟件版本信息更新服務器端存儲的所述用戶端的控制軟件的版本檔案。該方案有利于進一步減少用戶端與服務器之間的數(shù)據(jù)傳輸量。

基于上述實施例的插件升級的方法，可基于服務器主動對選定的用戶端進行升級維護，創(chuàng)建相應的升級任務列表；使得各個用戶端可分別根據(jù)服務器返回的升級任務的清單下載相應的插件，將本地的控制軟件的相應插件升級到對應版本；由此可靈活確定需要升級的用戶端以及用戶端的軟件插件，并且可以同時對多個用戶端進行差異化的插件升級，無需人工一對一的進行升級維護；同時，還可基于用戶端主動發(fā)起升級請求，以此對有回退需要的用戶端控制軟件實現(xiàn)快速回退，進一步提高了升級維護效率。

圖13為另一實施例的插件升級的方法的示意性流程圖；在該實施例中，以應用于用戶端為例，對完成插件升級的方式進行說明。所述用戶端為ATM、VTM、清分機、售票機等現(xiàn)金設備，這類用戶端的控制軟件均包含若干插件；并且這類用戶端還與遠程的服務器通信連接。參考圖13所示，本實施例中的插件升級的方法包括步驟：

S21，向服務器發(fā)送升級任務的查詢請求；

本實施例中，本端在啟動時，向服務器發(fā)送升級任務的查詢請求，所述升級任務的查詢請求包含有用于確定本端對應的設備屬性的信息。

S22，接收服務器返回的與本端的設備屬性對應的升級任務的清單；所述升級任務的清單中至少包括需升級的插件、插件版本以及下載地址；

服務器返回的升級任務，即可以是僅針對本端的升級任務，也可以是針對包含本端在內(nèi)的、歸屬于相同設備屬性的多個用戶端的的升級任務，具體可基于服務器端預先建立的用戶端屬性樹結(jié)構(gòu)實現(xiàn)。

S23，根據(jù)所述升級任務的清單下載相應的插件，將本地的控制軟件的相應插件升級到對應版本。

作為一優(yōu)選實施方式，將本地的控制軟件的相應插件升級到對應版本之后，還需更新本地記錄的控制軟件版本信息，并將更新后的控制軟件版本信息上報給服務器，指示服務器更新服務器端存儲的所述用戶端的控制軟件的版本檔案。

作為一優(yōu)選實施方式，所述的插件升級的方法還可包括步驟：

S24，若檢測到回退指令，向所述服務器發(fā)送版本檔案的查詢請求；

S25，接收所述服務器返回的與本端對應的控制軟件的版本檔案；

S26，向所述服務器發(fā)送回退更新請求，所述回退更新請求中至少包括從所述版本檔案中確定出的目標版本/升級時間點；

S27，接收所述服務器返回的與所述目標版本/升級時間點對應的歷史升級任務的清單，所述歷史升級任務的清單中至少包括需回退更新的插件、插件版本以及下載地址；

S28，根據(jù)所述歷史升級任務的清單下載相應的插件，將本地的控制軟件的相應插件回退更新到對應版本。

需要說明的是，對于某一用戶端來說，上述步驟S21～S23、步驟S24～S28兩部分的執(zhí)行先后順序可互換，即先執(zhí)行步驟S24～S28，再步驟S21～S23。

圖14為另一實施例的插件升級的方法的示意性流程圖；在該實施例中，以應用于服務器為例，對完成插件升級的方式進行說明。所述服務器與若干用戶端通信連接，所述用戶端為ATM、VTM、清分機、售票機等現(xiàn)金設備，這類用戶端的控制軟件均包含若干插件。參考圖14所示，本實施例中的插件升級的方法包括步驟：

S31，確定待升級的用戶端；根據(jù)待升級的用戶端、各用戶端待升級的插件創(chuàng)建與用戶端的設備屬性對應的升級任務列表；

S32，接收用戶端發(fā)送的升級任務的查詢請求，獲取所述用戶端對應的設備屬性，查詢已創(chuàng)建的升級任務列表中有所述用戶端對應的升級任務；

上述升級任務列表中的升級任務，即可以是僅針對某一個用戶端的升級任務，也可以是針對歸屬于某一設備屬性的多個用戶端的升級任務，若為后者，則在接收到歸屬于該設備屬性的任意用戶端的查詢請求時，則均能查詢已創(chuàng)建的升級任務列表中的同一升級任務。

S33，向所述用戶端返回所述升級任務的清單，所述升級任務的清單中至少包括需升級的插件、插件版本以及下載地址。

作為一優(yōu)選實施方式，上述插件升級的方法還包括：服務器預先根據(jù)設備屬性信息建立用戶端屬性樹結(jié)構(gòu)，參考圖4、圖5所示，所述設備屬性信息包括用戶端對應的區(qū)域?qū)傩曰蛘咴O備類型屬性；所述服務器確定待升級的用戶端的過程包括：服務器根據(jù)選定的設備屬性，從所述用戶端屬性樹結(jié)構(gòu)中確定出歸屬于所述選定的設備屬性的用戶端，作為待升級的用戶端。

作為一優(yōu)選實施方式，上述插件升級的方法還包括：若收到用戶端上報的控制軟件版本信息，則對本地存儲的所述用戶端的控制軟件的版本檔案進行相應的更新。

作為一優(yōu)選實施方式，上述插件升級的方法還包括：

S34，若檢測到用戶端發(fā)送的版本檔案的查詢請求，則獲取與所述用戶端對應的控制軟件的版本檔案，并向所述用戶端返回所述版本檔案；

S35，若接收到用戶端發(fā)送的回退更新請求，所述回退更新請求中至少包括從所述版本檔案中確定出的目標版本/升級時間點；則根據(jù)所述目標版本/升級時間點確定出對應的歷史升級任務，向所述用戶端返回所述歷史升級任務的清單；所述歷史升級任務的清單中至少包括需回退的插件、插件版本以及下載地址。

需要說明的是，對于某一用戶端來說，上述步驟S31～S33、步驟S34～S35兩部分的執(zhí)行先后順序可互換，即先執(zhí)行步驟S34～S35，再步驟S31～S33，或者兩部分并發(fā)執(zhí)行。

需要說明的是，對于前述的各方法實施例，為了簡便描述，將其都表述為一系列的動作組合，但是本領域技術人員應該知悉，本發(fā)明并不受所描述的動作順序的限制，因為依據(jù)本發(fā)明，某些步驟可以采用其它順序或者同時進行。

基于與上述實施例中的插件升級的方法相同的思想，本發(fā)明還提供插件升級的系統(tǒng)及裝置，系統(tǒng)及裝置可用于執(zhí)行上述對應的插件升級的方法。為了便于說明，插件升級的系統(tǒng)/裝置實施例的結(jié)構(gòu)示意圖中，僅僅示出了與本發(fā)明實施例相關的部分，本領域技術人員可以理解，圖示結(jié)構(gòu)并不構(gòu)成對系統(tǒng)/裝置的限定，可以包括比圖示更多或更少的部件，或者組合某些部件，或者不同的部件布置。

圖15為本發(fā)明一實施例的插件升級的系統(tǒng)的示意性結(jié)構(gòu)圖，包括服務器100和用戶端200，所述服務器100和若干用戶端200通信連接。

其中，所述服務器100包括：任務創(chuàng)建模塊101，用于確定待升級的用戶端；根據(jù)待升級的用戶端、各用戶端待升級的插件創(chuàng)建與用戶端的設備屬性對應的升級任務列表；

所述用戶端200包括：任務查詢模塊201，用于向服務器發(fā)送升級任務的查詢請求；

所述服務器100還包括：任務下發(fā)模塊102，用于獲取所述用戶端對應的設備屬性，查詢已創(chuàng)建的升級任務列表中有所述用戶端對應的升級任務，向所述用戶端返回所述升級任務的清單；所述升級任務的清單中至少包括需升級的插件、插件版本以及下載地址；

所述用戶端200還包括：升級執(zhí)行模塊202，用于根據(jù)所述升級任務的清單下載相應的插件，將本地的控制軟件的相應插件升級到對應版本。

作為一優(yōu)選實施方式，所述用戶端200還包括：版本上報模塊(圖中未示出)，用于在將本地的控制軟件的相應插件升級到對應版本之后，更新本地記錄的控制軟件版本信息，將更新后的控制軟件版本信息上報給服務器；所述服務器100還包括：檔案更新模塊(圖中未示出)，用于在收到用戶端上報的控制軟件版本信息后，更新服務器端存儲的所述用戶端的控制軟件的版本檔案。

作為一優(yōu)選實施方式，所述服務器100還包括：用戶樹創(chuàng)建模塊(圖中未示出)，用于預先根據(jù)設備屬性信息建立用戶端屬性樹結(jié)構(gòu)，參考圖4、圖5所示。以便根據(jù)用戶端屬性樹結(jié)構(gòu)確定待升級的用戶端。

作為一優(yōu)選實施方式，參考圖16、圖17所示，所述用戶端200還包括：回退請求模塊203，用于若檢測到回退指令，向所述服務器發(fā)送版本檔案的查詢請求；所述服務器100還包括：檔案管理模塊103，用于獲取與所述用戶端對應的控制軟件的版本檔案，向所述用戶端返回所述版本檔案；所述回退請求模塊203還用于向所述服務器發(fā)送回退更新請求，所述回退更新請求中至少包括從所述版本檔案中確定出的目標版本/升級時間點；所述服務器100還包括：回退確認模塊104，用于根據(jù)所述目標版本/升級時間點確定出對應的歷史升級任務，向所述用戶端返回所述歷史升級任務的清單；所述歷史升級任務的清單中至少包括需回退的插件、插件版本以及下載地址；所述用戶端200還包括：回退執(zhí)行模塊204，用于根據(jù)服務器發(fā)送的歷史升級任務的清單下載相應的插件，將本地的控制軟件的相應插件回退更新到對應版本。

上述實施例的插件升級的系統(tǒng)，服務器可從全部通信連接的用戶端中靈活確定出待升級的用戶端以及待升級的插件，并創(chuàng)建相應的與用戶端的設備屬性對應的升級任務列表；用戶端通過向服務器發(fā)送升級任務的查詢請求，服務器根據(jù)所述用戶端的設備屬性查詢已創(chuàng)建的升級任務列表中是否有該用戶端對應的升級任務，若有則向?qū)脩舳朔祷叵鄳纳壢蝿盏那鍐?，包括需升級的插件、插件版本以及下載地址；從而用戶端可分別根據(jù)服務器返回的升級任務的清單下載相應的插件，將本地的控制軟件的相應插件升級到對應版本。由此可在服務器端靈活確定需要升級的用戶端以及用戶端軟件插件，并且可以同時對多個用戶端進行差異化的插件升級，無需人工一對一的進行升級維護，提高了升級維護效率。

參考圖16，本發(fā)明一實施例的插件升級的裝置的示意性結(jié)構(gòu)圖，該裝置可以應用于與服務器連接的用戶端，例如任一聯(lián)網(wǎng)的ATM機。本實施例的插件升級的裝置包括：任務查詢模塊201、以及升級執(zhí)行模塊202，各模塊詳述如下：

所述任務查詢模塊201，用于向服務器發(fā)送升級任務的查詢請求；以及用于接收服務器返回的與本端的設備屬性對應的升級任務的清單；所述升級任務的清單中至少包括需升級的插件、插件版本以及下載地址；

所述升級執(zhí)行模塊202，用于根據(jù)所述升級任務的清單下載相應的插件，將本地的控制軟件的相應插件升級到對應版本。

作為一優(yōu)選實施方式，還可包括回退請求模塊203，用于若檢測到回退指令，向所述服務器發(fā)送版本檔案的查詢請求；還用于向所述服務器發(fā)送回退更新請求，所述回退更新請求中至少包括從所述版本檔案中確定出的目標版本/升級時間點；以及回退執(zhí)行模塊204，用于接收所述服務器返回的與所述目標版本/升級時間點對應的歷史升級任務的清單，并根據(jù)服務器發(fā)送的歷史升級任務的清單下載相應的插件，將本地的控制軟件的相應插件回退更新到對應版本。

本實施例的裝置在啟動時，檢查服務器端是否有屬于自己的升級任務，如有就按照對應的升級任務的信息下載需要更新的插件；還可進行本端控制軟件的回退更新，并在完成更新后，還可通知服務器端更新本端的版本檔案記錄。服務器端登記有包括本次升級在內(nèi)的、本端所有的歷史版本信息。

圖17為本發(fā)明一實施例的插件升級的裝置的示意性結(jié)構(gòu)圖，該裝置可以應用于與若干用戶端通信連接的服務器。如圖17所示，本實施例的插件升級的裝置包括：任務創(chuàng)建模塊101、以及任務下發(fā)模塊102，各模塊詳述如下：

所述任務創(chuàng)建模塊101，用于確定待升級的用戶端；根據(jù)待升級的用戶端、各用戶端待升級的插件創(chuàng)建與用戶端的設備屬性對應的升級任務列表；

所述任務下發(fā)模塊102，用于接收用戶端發(fā)送的升級任務的查詢請求，獲取所述用戶端對應的設備屬性，查詢已創(chuàng)建的升級任務列表中有所述用戶端對應的升級任務；以及用于向所述用戶端返回所述升級任務的清單；所述升級任務的清單中至少包括需升級的插件、插件版本以及下載地址。

作為一優(yōu)選實施方式，還可包括檔案管理模塊103，用于若接收到用戶端發(fā)送的版本檔案的查詢請求，則獲取與所述用戶端對應的控制軟件的版本檔案，向所述用戶端返回所述版本檔案；以及，回退確認模塊104，用于若接收到用戶端發(fā)送的回退更新請求，根據(jù)回退更新請求中的目標版本/升級時間點確定出對應的歷史升級任務，向所述用戶端返回所述歷史升級任務的清單；所述歷史升級任務的清單中至少包括需回退的插件、插件版本以及下載地址。

通過本實施例的裝置，可為選定設備屬性的若干用戶端創(chuàng)建升級任務信息，以對用戶端進行靈活的、差異化的管理，有利于提高用戶端升級維護的效率，降低維護成本；另一方面，還可管理用戶端控制軟件的回退更新，將用戶端控制軟件的插件快速回退到對應的歷史版本。

需要說明的是，上述示例的插件升級的系統(tǒng)/裝置的實施方式中，各模塊之間的信息交互、執(zhí)行過程等內(nèi)容，由于與本發(fā)明前述方法實施例基于同一構(gòu)思，其帶來的技術效果與本發(fā)明前述方法實施例相同，具體內(nèi)容可參見本發(fā)明方法實施例中的敘述，此處不再贅述。

此外，上述示例的插件升級的系統(tǒng)/裝置的實施方式中，各功能模塊的邏輯劃分僅是舉例說明，實際應用中可以根據(jù)需要，例如出于相應硬件的配置要求或者軟件的實現(xiàn)的便利考慮，將上述功能分配由不同的功能模塊完成，即將所述插件升級的裝置的內(nèi)部結(jié)構(gòu)劃分成不同的功能模塊，以完成以上描述的全部或者部分功能。其中各功能模既可以采用硬件的形式實現(xiàn)，也可以采用軟件功能模塊的形式實現(xiàn)。

本領域普通技術人員可以理解，實現(xiàn)上述實施例方法中的全部或部分流程，是可以通過計算機程序來指令相關的硬件來完成，所述的程序可存儲于一計算機可讀取存儲介質(zhì)中，作為獨立的產(chǎn)品銷售或使用。所述程序在執(zhí)行時，可執(zhí)行如上述各方法的實施例的全部或部分步驟。其中，所述的存儲介質(zhì)可為磁碟、光盤、只讀存儲記憶體(Read-Only Memory，ROM)或隨機存儲記憶體(Random Access Memory，RAM)等。

在上述實施例中，對各個實施例的描述都各有側(cè)重，某個實施例中沒有詳述的部分，可以參見其它實施例的相關描述?？梢岳斫?，其中所使用的術語“第一”、“第二”等在本文中用于區(qū)分對象，但這些對象不受這些術語限制。

以上所述實施例僅表達了本發(fā)明的幾種實施方式，不能理解為對本發(fā)明專利范圍的限制。應當指出的是，對于本領域的普通技術人員來說，在不脫離本發(fā)明構(gòu)思的前提下，還可以做出若干變形和改進，這些都屬于本發(fā)明的保護范圍。因此，本發(fā)明專利的保護范圍應以所附權(quán)利要求為準。