專利名稱：服務器與客戶端間智能數(shù)據(jù)交互發(fā)布系統(tǒng)及方法
技術(shù)領(lǐng)域：
本發(fā)明涉及信息處理領(lǐng)域，尤其涉及一種用于實現(xiàn)服務器與客戶端間智能數(shù)據(jù)交互的數(shù)據(jù)發(fā)布系統(tǒng)及方法。
背景技術(shù)：
隨著互聯(lián)網(wǎng)的不斷發(fā)展及互聯(lián)網(wǎng)用戶的不斷增加，對各個領(lǐng)域特別是IT (信息技術(shù))行業(yè)的生存模式都帶來了或多或少的改變。就軟件開發(fā)及銷售業(yè)來說，目前就出現(xiàn)了一種新興的應用程序Web系統(tǒng)發(fā)布模式。在該模式中，軟件開發(fā)者(包括軟件服務商)開發(fā)的應用程序都發(fā)布在一個獨立的第三方平臺上并且可以按自己的定價向用戶銷售，用戶則可以通過網(wǎng)絡訪問第三方平臺選擇、購買自己中意的應用程序，并且用戶在第三方平臺上購買應用程序的支出通過第三方平臺的中轉(zhuǎn)就能夠直接轉(zhuǎn)化為軟件開發(fā)者的收入，這一過程中第三方平臺僅向軟件開發(fā)者收取一定的管理費用，并且管理費用中的一部分被用來對發(fā)布的應用程序進行審核，從而保證用戶的購買安全。由于發(fā)布成本非常低廉、應用程序特別豐富的緣故，這一 Web系統(tǒng)發(fā)布模式得到了軟件開發(fā)者和用戶雙方面的歡迎。隨著上述 Web系統(tǒng)發(fā)布模式在業(yè)內(nèi)的地位變得越來越重要，應用程序變得越來越多，用戶需求也變得越來越復雜，這使得與應用程序捆綁的單一技術(shù)服務注定無法完全滿足用戶層出不窮的新需求，由此也引出現(xiàn)有模式在以下兩個方面存在的問題。一方面，目前在上述Web系統(tǒng)發(fā)布模式中，應用程序交付給第三方平臺后就不能再更改，無論作何更改都必須在第三方平臺上重新發(fā)布程序，并由用戶通過第三方平臺重新下載并安裝來完成更新。下面以一示例說明上述升級過程存在的問題，以客戶端-服務器交互模式的應用程序為例，軟件服務商提供的應用程序由用戶通過第三方平臺下載在手機等終端并安裝運行后便成為客戶端一方，另一端軟件服務商則部署服務器通過網(wǎng)絡為這些客戶端提供各種類型的數(shù)據(jù)服務，客戶端通過應用程序在開發(fā)時所內(nèi)置的接口便可以訪問到服務器上相應類型的數(shù)據(jù)；然而，隨著用戶需求的變化，服務器難免會對提供的數(shù)據(jù)類型及其對應的接口作出調(diào)整，但在現(xiàn)有模式下，客戶端與服務器之間只進行單純的內(nèi)容數(shù)據(jù)交互，一旦涉及到服務器上的數(shù)據(jù)類型和接口變更(例如增加一個數(shù)據(jù)類型及其對應的訪問接口)，現(xiàn)有客戶端則無法獲知，只能通過在第三方平臺重新發(fā)布修改后的應用程序 (內(nèi)置有調(diào)整后的接口)并再次由用戶下載并安裝運行后，客戶端才能得知變更后的接口進而才能通過該接口訪問到服務器上變更后的服務數(shù)據(jù)。綜上所述可知，現(xiàn)有模式下服務器上數(shù)據(jù)類型和接口的變更無法實時、直接地通知給客戶端，從而導致用戶需求無法及時得到滿足。另一方面，基于上述用戶需求日益多元化的考慮，客戶端的體積也愈見龐大，對應的服務器要提供的數(shù)據(jù)接口也勢必越來越繁雜，從而加大了客戶端和服務器交互的難度。 現(xiàn)有技術(shù)中服務器與客戶端的數(shù)據(jù)交互可以參考圖1所示，主要包括以下兩個步驟首先客戶端2根據(jù)業(yè)務需求調(diào)用自身程序中內(nèi)置的數(shù)據(jù)接口向服務器1發(fā)起請求，隨后服務器1 根據(jù)客戶端2的請求向客戶端2返回所請求的數(shù)據(jù)。而在用戶需求多元化的趨勢下，上述數(shù)據(jù)交互方式便暴露出以下問題首先，多元化的服務必然需要大量的數(shù)據(jù)接口，這使得客戶端與服務器的代碼臃腫、結(jié)構(gòu)混亂，從而難以維護；其次，服務器將多種需求的數(shù)據(jù)接口混雜在一起，從而無法及時針對新增需求進行快速、合理的接口新增、刪除和修改等操作。

發(fā)明內(nèi)容
鑒于上述現(xiàn)有技術(shù)的缺點，本發(fā)明的主要目的在于提供一種用于實現(xiàn)服務器與客戶端間智能數(shù)據(jù)交互的數(shù)據(jù)發(fā)布系統(tǒng)及方法，以解決現(xiàn)有模式存在的上述問題。為實現(xiàn)上述目的，本發(fā)明的實施例提供了一種數(shù)據(jù)發(fā)布系統(tǒng)，用于實現(xiàn)與客戶端之間的數(shù)據(jù)交互，包括后端服務系統(tǒng)、接口管理裝置及接口匯總裝置；其中，所述后端服務裝置用于存儲各種類型的服務數(shù)據(jù)，并向所述客戶端提供用于對應訪問各類型數(shù)據(jù)的接口；所述接口管理裝置根據(jù)用于對所述后端服務裝置的接口進行管理，并根據(jù)管理結(jié)果生成接口表；所述接口匯總裝置用于將所述接口表轉(zhuǎn)換為所述客戶端能夠識別的格式文檔后發(fā)送給所述客戶端；所述格式文檔由所述客戶端用來得知所述用于對應訪問各類型數(shù)據(jù)的接口。在一個實施例中，所述后端服務裝置包括多個數(shù)據(jù)單元，所述多個數(shù)據(jù)單元用于分類型對所述服務數(shù)據(jù)進行存儲，并且各自對應地提供不同的接口。本發(fā)明的實施例還提供了一種數(shù)據(jù)發(fā)布方法，用于實現(xiàn)服務器與客戶端之間的數(shù)據(jù)交互，該方法包括如下步驟Si.在所述服務器中存儲各種類型的服務數(shù)據(jù)，并向所述客戶端提供用于對應訪問各類型數(shù)據(jù)的接口；S2.對所述服務器的接口進行管理，并根據(jù)管理結(jié)果生成接口表；S3.將所述接口表轉(zhuǎn)換為所述客戶端能夠識別的格式文檔后發(fā)送給所述客戶端； 所述格式文檔由所述客戶端用來得知所述用于對應訪問各類型數(shù)據(jù)的接口。在一個實施例中，步驟Sl所述在服務器中存儲各種類型的服務數(shù)據(jù)包括設(shè)置多個數(shù)據(jù)單元分類型對所述服務數(shù)據(jù)進行存儲，并且各自對應地提供不同的接口。由上述技術(shù)方案可知，本發(fā)明的實施例所提供的數(shù)據(jù)發(fā)布系統(tǒng)和數(shù)據(jù)發(fā)布方法， 能夠?qū)⒎掌魃仙婕皵?shù)據(jù)類型和接口的變化及時、直接地通知給客戶端，從而實現(xiàn)不經(jīng)過第三方平臺完成客戶端的更新，使用戶需求能夠及時得到滿足。另一方面，本發(fā)明實施例提供的數(shù)據(jù)發(fā)布系統(tǒng)和數(shù)據(jù)發(fā)布方法，通過分類型、分接口對服務數(shù)據(jù)進行存儲、管理，同時配合前述客戶端更新的方案，能夠避免多元化需求所帶來的代碼臃腫、結(jié)構(gòu)混亂和難以維護等問題。


圖1示例性示出現(xiàn)有技術(shù)中客戶端與服務器之間的數(shù)據(jù)交互的結(jié)構(gòu)框圖；圖2示例性示出本發(fā)明數(shù)據(jù)發(fā)布系統(tǒng)實施例一的結(jié)構(gòu)框圖；圖3示例性示出本發(fā)明數(shù)據(jù)發(fā)布系統(tǒng)實施例二的結(jié)構(gòu)框圖；圖4示例性示出本發(fā)明數(shù)據(jù)發(fā)布方法的實施例流程圖。
具體實施例方式下面將詳細描述本發(fā)明的具體實施例。應當注意，這里描述的實施例只用于舉例說明，并不用于限制本發(fā)明。圖2示例性示出本發(fā)明實施例中數(shù)據(jù)發(fā)布系統(tǒng)實施一的結(jié)構(gòu)框圖。如圖所示，本實施例的數(shù)據(jù)發(fā)布系統(tǒng)11包括后端服務裝置12、接口管理裝置13及接口匯總裝置14。其中，后端服務裝置12用于存儲各種類型的服務數(shù)據(jù)，并向客戶端10提供用于對應訪問各類型數(shù)據(jù)的接口 121;接口管理裝置13用于對后端服務裝置12的接口 121進行管理，并根據(jù)管理結(jié)果生成接口表131，在一個實施例中，接口管理裝置13對接口 121的管理包括增加、 刪除、修改等操作中的任意一個或組合；接口匯總裝置14用于將接口表131轉(zhuǎn)換為客戶端 10能夠識別的格式文檔后發(fā)送給客戶端10，該格式文檔是由客戶端10用來得知上述用于對應訪問各類型數(shù)據(jù)的接口。在一個實施例中，后端服務裝置12在收到客戶端10根據(jù)所述格式文檔得到的接口 121而發(fā)起的訪問請求后，便向客戶端10提供該接口 121對應類型的服務數(shù)據(jù)。在一個實施例中，上述發(fā)布系統(tǒng)可用于發(fā)布根據(jù)用戶需求命名的各個欄目、對應各個欄目的接口以及一些重要的附屬信息，附屬信息例如可以包括在客戶端的哪個位置調(diào)用某一接口、某欄目下是否含有子欄目、某欄目是否被淘汰不再使用等等。在一個實施例中，后端服務裝置12包括多個數(shù)據(jù)單元122，用于分類型對所述服務數(shù)據(jù)進行存儲，并且各自對應地提供不同的接口 121。參考上述內(nèi)容，在一個實施例中，上述數(shù)據(jù)單元122僅用于對后端服務裝置12中的數(shù)據(jù)按照已經(jīng)劃分好的類型(例如新聞、娛樂、游戲等)進行存儲，而對數(shù)據(jù)的分類和篩選則是由系統(tǒng)維護人員來完成。這樣，通過對后端服務裝置12中的數(shù)據(jù)進行分類存儲，避免了各種類型的數(shù)據(jù)混雜在一起給維護帶來的困難，也使數(shù)據(jù)類型與接口可以一一對應，便于數(shù)據(jù)進行的查找與調(diào)用。在一個實施例中，接口匯總裝置14所轉(zhuǎn)換的格式文檔為xml格式。參考上述內(nèi)容，在一個實施例中，所述的ml文檔需滿足如下三個要求第一，該xml文檔是在遵守客戶端和服務器端共同協(xié)議的基礎(chǔ)上生成的；第二，該xml文檔完全是發(fā)布系統(tǒng)發(fā)布的信息；第三，該xml文檔能夠讓客戶端自動識別。這里的所謂自動識別是指一旦客戶端完成對xml 代碼的解析，xml文檔在協(xié)議規(guī)定的范圍內(nèi)發(fā)生變化時，不需要更改客戶端的解析程序仍然可以解析xml文檔，這是增加新需求而不升級客戶端的前提，也是客戶端能夠自適應服務器端的前提。在一個實施例中，接口管理裝置13可以在生成新的接口表131后通過接口匯總裝置14向客戶端10發(fā)起接口表131的更新。在另一個實施例中，也可以是客戶端10例如在每次啟動運行時，主動向數(shù)據(jù)發(fā)布系統(tǒng)的接口管理裝置13發(fā)起接口表13 1的更新請求。下文通過一個示例來對上述數(shù)據(jù)發(fā)布系統(tǒng)的工作過程進行具體描述。首先，用戶通過第三方平臺購買了一款應用程序并下載、安裝運行在手機等終端上成為客戶端。該客戶端初始提供了例如游戲、音樂和小說等三個欄目，而三個欄目下各自可以包括多個子欄目，這些欄目或子欄目分別對應于服務器上各類型數(shù)據(jù)的訪問接口，用戶在客戶端界面上點擊各欄目或子欄目所看到的內(nèi)容便是通過上述訪問接口而從服務器上得到的數(shù)據(jù)。對于上述欄目或子欄目的新增、修改和刪除等操作可以根據(jù)用戶需求來實
5現(xiàn)，這里所說的用戶需求例如可以是由軟件服務商通過市場調(diào)研、分析等行為而得到的。接續(xù)，當軟件服務商了解到用戶有需求在客戶端增加一個例如新聞的欄目時，便著手在后端服務裝置12中增加一個新的數(shù)據(jù)單元122，用于存儲該欄目所對應的服務數(shù)據(jù)并生成對應的新接口 121 ；隨后，在接口管理裝置13中對后端服務裝置12的接口進行管理，根據(jù)管理結(jié)果生成新的接口表131并向客戶端發(fā)起更新；最后，通過接口匯總裝置14將該接口表131轉(zhuǎn)換為客戶端能夠識別的xml文檔并發(fā)送給客戶端10 ；這時，客戶端10便能夠根據(jù)xml文檔修改自身的顯示界面，使自身界面在內(nèi)置的三個欄目之外顯示出新增的第四個新聞欄目，并且用戶在客戶端10界面上點擊該欄目時，客戶端10便能根據(jù)從xml文檔中得到的接口向后端服務裝置12發(fā)起訪問請求，進而從后端服務裝置12中對應的新增數(shù)據(jù)單元122處得到新增類型的服務數(shù)據(jù)。如上文實例所述，后端服務裝置12上涉及數(shù)據(jù)類型和接口的變更，無需通過第三方平臺便能直接向客戶端10進行更新；而且更新內(nèi)容可以僅限于接口表，與客戶端自身所占的存儲空間相比，接口表相對很小，如此便能夠兼具節(jié)省帶寬、縮短更新時間的效果；由此也避免了現(xiàn)有模式中所有改動均需通過第三方平臺，而且一旦更新便需重新下載整個客戶端的問題。圖3示例性示出本發(fā)明數(shù)據(jù)發(fā)布系統(tǒng)實施例二的結(jié)構(gòu)框圖。如圖所示，在上述實施例一的結(jié)構(gòu)基礎(chǔ)上，數(shù)據(jù)發(fā)布系統(tǒng)11還包括訪問路由裝置15，其設(shè)置在客戶端11與后端服務裝置12之間，所述訪問路由裝置15包括表項單元151，用于存儲后端服務裝置12中各類型服務數(shù)據(jù)所在的數(shù)據(jù)單元122與接口 121之間的映射關(guān)系；路由單元152，用于根據(jù)客戶端的訪問請求中攜帶的接口信息，在查詢表項單元151后將該訪問請求重定向至查詢得到的數(shù)據(jù)單元122。在一個實施例中，路由單元152還包括緩存單元1521，其由設(shè)置有緩存時間的多個緩存集群組成，用于存儲后端服務裝置12中常用的數(shù)據(jù)單元122，并定時與后端服務裝置12進行高速的數(shù)據(jù)同步；日志單元1522，用于記錄客戶端10與后端服務裝置12之間的交互過程。參考上述內(nèi)容，在一個實施例中，上述緩存單元1521主要用于存儲客戶端10常用的數(shù)據(jù)單元122，這樣當客戶端10請求這些常用的數(shù)據(jù)單元122時，不再需要訪問后端服務裝置12中的數(shù)據(jù)單元122，而是直接訪問緩存單元1521即可，這樣不僅大大提高了客戶端10讀取數(shù)據(jù)的速度，也減少了對后端服務裝置12進行頻繁訪問所造成的壓力。日志單元1522的記錄包括事件日志、告警日志、安全日志、網(wǎng)絡日志及流量日志等，通過對日志進行統(tǒng)計、分析，系統(tǒng)管理員可以有效地掌握后端服務裝置12的運行狀況，從而及時發(fā)現(xiàn)和排除錯誤原因，了解客戶訪問情況，并為下一步用戶體系分析打下良好的基礎(chǔ)。綜上所述，本實施例的數(shù)據(jù)發(fā)布系統(tǒng)具備相當?shù)撵`活性，能夠快速、準確的實現(xiàn)客戶端與服務器之間的數(shù)據(jù)交互。進一步而言，其中的后端服務裝置將數(shù)據(jù)單元進行分類存儲，使得對客戶端需求的覆蓋面較廣、擴展性較強、易于維護；接口管理裝置能夠保障接口與數(shù)據(jù)單元的同步性，并對接口進行科學的管理；接口匯總裝置能夠快速準確的為客戶端提供數(shù)據(jù)訪問接口 ；其中引入的訪問路由裝置能夠?qū)蛻舳顺Ｓ玫臄?shù)據(jù)單元進行存儲，以使客戶端可以快速的進行數(shù)據(jù)訪問，還可以對客戶端的訪問事件進行記錄，從而便于維護， 也能夠避免數(shù)據(jù)的丟失。圖4示例性示出本發(fā)明數(shù)據(jù)發(fā)布系統(tǒng)的的實施例的流程圖。本實施例的數(shù)據(jù)發(fā)布方法用于實現(xiàn)服務器與客戶端之間的數(shù)據(jù)交互，如圖所示，其包括以下步驟Si.在所述服務器中存儲各種類型的服務數(shù)據(jù)，并向所述客戶端提供用于對應訪問各類型數(shù)據(jù)的接口；在一個實施例中，步驟Sl所述在服務器中存儲各種類型的服務數(shù)據(jù)具體包括設(shè)置多個數(shù)據(jù)單元分類型對所述服務數(shù)據(jù)進行存儲，并且各自對應地提供不同的接口。S2.對所述服務器的接口進行管理，并根據(jù)管理結(jié)果生成接口表；在一個實施例中，步驟S2所述對接口進行的管理包括增加、刪除、修改操作，這些操作例如可以由管理員手動進行。S3.將所述接口表轉(zhuǎn)換為所述客戶端能夠識別的格式文檔后發(fā)送給所述客戶端；在一個實施例中，步驟S3所述格式文檔為xml格式。在一個實施例中，所述的xml 文檔需滿足如下三個要求第一，該xml文檔是在遵守客戶端和服務器端共同協(xié)議的基礎(chǔ)上生成的；第二，該xml文檔完全是發(fā)布系統(tǒng)發(fā)布的信息；第三，該xml文檔能夠讓客戶端自動識別。這里的所謂自動識別是指一旦客戶端完成對ml代碼的解析，xml文檔在協(xié)議規(guī)定的范圍內(nèi)發(fā)生變化時，不需要更改客戶端的解析程序仍然可以解析xml文檔，這是增加新需求而不升級客戶端的前提，也是客戶端能夠自適應服務器端的前提。在一個實施例中，步驟S3之后還可以包括S4.所述服務器在收到所述客戶端發(fā)起的訪問請求后，向所述客戶端提供該接口對應類型的服務數(shù)據(jù)。在一個實施例中，上述步驟Sl中通過客戶端與服務器端的共同商定來確定文檔生成的協(xié)議，并根據(jù)該協(xié)議來劃分服務數(shù)據(jù)的類型；若有新增需求時，系統(tǒng)維護人員會根據(jù)其類型在后端服務裝置中增加新的數(shù)據(jù)單元，并通知接口管理裝置的系統(tǒng)維護人員對接口進行更新，接著重復執(zhí)行步驟Sl到S4。綜上所述，本實施例的數(shù)據(jù)發(fā)布方法能夠快速、準確的實現(xiàn)客戶端與服務器之間的數(shù)據(jù)交互。進一步而言，對后端服務裝置中的數(shù)據(jù)進行分類存儲使得后端服務裝置的結(jié)構(gòu)更清楚、也使對數(shù)據(jù)的維護和管理更容易；接口管理裝置中存儲的接口與后端服務裝置中存儲的數(shù)據(jù)單元一一對應，使得客戶端可以通過接口來對數(shù)據(jù)進行快速的查找和定位。由上述技術(shù)方案可知，本發(fā)明的實施例所提供的數(shù)據(jù)發(fā)布系統(tǒng)和數(shù)據(jù)發(fā)布方法， 能夠?qū)⒎掌魃仙婕皵?shù)據(jù)類型和接口的變化及時、直接地通知給客戶端，從而在一定程度上實現(xiàn)不經(jīng)過第三方平臺完成客戶端的更新，使用戶需求能夠及時得到滿足。進一步，本發(fā)明實施例提供的數(shù)據(jù)發(fā)布系統(tǒng)和數(shù)據(jù)發(fā)布方法，通過分類型、分接口對服務數(shù)據(jù)進行存儲、 管理，同時配合前述客戶端更新的方案，能夠避免多元化需求所帶來的代碼臃腫、結(jié)構(gòu)混亂和難以維護等問題。雖然已參照幾個典型實施例描述了本發(fā)明，但應當理解，所用的術(shù)語是說明和示例性、而非限制性的術(shù)語。由于本發(fā)明能夠以多種形式具體實施而不脫離發(fā)明的精神或?qū)嵸|(zhì)，所以應當理解，上述實施例不限于任何前述的細節(jié)，而應在隨附權(quán)利要求所限定的精神和范圍內(nèi)廣泛地解釋，因此落入權(quán)利要求或其等效范圍內(nèi)的全部變化和改型都應為隨附權(quán)利要求所涵蓋。
權(quán)利要求
1.一種數(shù)據(jù)發(fā)布系統(tǒng)，用于實現(xiàn)與客戶端之間的數(shù)據(jù)交互，包括后端服務裝置、接口管理裝置及接口匯總裝置；其中，所述后端服務裝置用于存儲各種類型的服務數(shù)據(jù)，并向所述客戶端提供用于對應訪問各類型數(shù)據(jù)的接口；所述接口管理裝置用于對所述后端服務裝置的接口進行管理，并根據(jù)管理結(jié)果生成接口表；所述接口匯總裝置用于將所述接口表轉(zhuǎn)換為所述客戶端能夠識別的格式文檔后發(fā)送給所述客戶端；所述格式文檔由所述客戶端用來得知所述用于對應訪問各類型數(shù)據(jù)的接
2.根據(jù)權(quán)利要求1所述的數(shù)據(jù)發(fā)布系統(tǒng)，其中，所述后端服務裝置包括多個數(shù)據(jù)單元， 所述多個數(shù)據(jù)單元用于分類型對所述服務數(shù)據(jù)進行存儲，并且各自對應地提供不同的接
3.根據(jù)權(quán)利要求2所述的數(shù)據(jù)發(fā)布系統(tǒng)，其中，還包括訪問路由裝置，設(shè)置在所述客戶端與所述后端服務裝置之間，所述訪問路由裝置包括表項單元，用于存儲所述后端服務裝置中各類型服務數(shù)據(jù)所在的數(shù)據(jù)單元與接口之間的映射關(guān)系；路由單元，用于根據(jù)所述客戶端的訪問請求中攜帶的接口信息，在查詢所述表項單元后將該訪問請求重定向至查詢得到的數(shù)據(jù)單元。
4.根據(jù)權(quán)利要求3所述的數(shù)據(jù)發(fā)布系統(tǒng)，其中，所述路由單元還包括緩存單元，用于存儲所述后端服務裝置中常用的數(shù)據(jù)單元，并與所述后端服務裝置進行高速的數(shù)據(jù)交換；日志單元，用于記錄所述客戶端與所述后端服務裝置之間的交互過程。
5.根據(jù)權(quán)利要求1-4任一項所述的數(shù)據(jù)發(fā)布系統(tǒng)，其中，所述對接口的管理包括增加、 刪除、修改操作中的任意一個或組合。
6.根據(jù)權(quán)利要求5所述的數(shù)據(jù)發(fā)布系統(tǒng)，其中，所述格式文檔為xml格式。
7.一種數(shù)據(jù)發(fā)布方法，用于實現(xiàn)服務器與客戶端之間的數(shù)據(jù)交互，該方法包括如下步驟51.在所述服務器中存儲各種類型的服務數(shù)據(jù)，并向所述客戶端提供用于對應訪問各類型數(shù)據(jù)的接口；52.對所述服務器的接口進行管理，并根據(jù)管理結(jié)果生成接口表；53.將所述接口表轉(zhuǎn)換為所述客戶端能夠識別的格式文檔后發(fā)送給所述客戶端；所述格式文檔由所述客戶端用來得知所述用于對應訪問各類型數(shù)據(jù)的接口。
8.如權(quán)利要求7所述的數(shù)據(jù)發(fā)布方法，其中，步驟Sl所述在服務器中存儲各種類型的服務數(shù)據(jù)包括設(shè)置多個數(shù)據(jù)單元分類型對所述服務數(shù)據(jù)進行存儲，并且各自對應地提供不同的接口。
9.如權(quán)利要求7所述的數(shù)據(jù)發(fā)布方法，其中，步驟S2中所述對接口進行的管理包括增加、刪除、修改操作中的任意一個或組合。
10.根據(jù)權(quán)利要求7-9任一項所述的數(shù)據(jù)發(fā)布系統(tǒng)，其中，所述格式文檔為xml格式。
全文摘要
本發(fā)明公開了一種服務器與客戶端間智能數(shù)據(jù)交互發(fā)布系統(tǒng)，包括后端服務系統(tǒng)、接口管理裝置及接口匯總裝置；后端服務裝置用于存儲各種類型的服務數(shù)據(jù)，并向客戶端提供用于對應訪問各類型數(shù)據(jù)的接口；接口管理裝置用于對后端服務裝置的接口進行管理，并根據(jù)管理結(jié)果生成接口表；接口匯總裝置用于將接口表轉(zhuǎn)換為客戶端能夠識別的格式文檔后發(fā)送給客戶端；格式文檔由客戶端用來得知用于對應訪問各類型數(shù)據(jù)的接口。本發(fā)明還公開了一種對應的方法。本發(fā)明所提供的數(shù)據(jù)發(fā)布系統(tǒng)和方法，能夠?qū)⒎掌魃仙婕皵?shù)據(jù)類型和接口的變化及時、直接地通知給客戶端，從而能夠?qū)崿F(xiàn)不經(jīng)過第三方平臺完成客戶端的更新，使用戶需求能夠及時得到滿足。
文檔編號H04L29/06GK102185863SQ20111012464
公開日2011年9月14日 申請日期2011年5月13日 優(yōu)先權(quán)日2011年5月13日
發(fā)明者李建林 申請人:北京瑞信在線系統(tǒng)技術(shù)有限公司