專利名稱：多媒體信息共享方法
技術領域：
本發(fā)明涉及多媒體信息存儲及共享技術領域，特別涉及一種多媒體信息共享方 法。
背景技術：
近年來，隨著多媒體信息技術的發(fā)展，用戶對于多媒體信息的需求越來越大。相應 的，各類業(yè)務系統(tǒng)對多媒體信息共享提出了更高的要求。系統(tǒng)與系統(tǒng)之間通過實時或準實 時的方式，共享文字、聲音、圖片、動畫等多媒體信息，為最終用戶提供高質(zhì)量、豐富、及時的 多媒體內(nèi)容。多媒體信息需要的存儲量大，類型也比較多。所以對于多媒體信息的存儲、共享和 管理成為多媒體信息共享系統(tǒng)最關鍵的部分，也是整個多媒體信息共享系統(tǒng)基礎構架設計 的重要關注面。現(xiàn)在比較流行的基礎架構如下1、將多媒體文件存入關系型數(shù)據(jù)庫，再配以相應的描述信息。通過數(shù)據(jù)庫自帶接 口、ffebservice, FTP等傳統(tǒng)方式來分享信息2、將多媒體文件放在文件服務器上，然后在關系型數(shù)據(jù)庫中存儲描述該多媒體文 件信息及相關信息的描述文本。通過關系型數(shù)據(jù)庫檢索信息，再通過檢索到的信息定位到 文件服務器，然后下載相應的多媒體信息文件。這兩種方式都存在著各自的優(yōu)缺點。(1)第一種結構優(yōu)點A、做到了信息的統(tǒng)一管理，全部存儲在數(shù)據(jù)庫。依賴數(shù)據(jù)庫技術，所以開發(fā)人員比 較容易學習并應用；B、由于數(shù)據(jù)統(tǒng)一管理，所以通過一種接口就可以完成所有的任務；C、通過數(shù)據(jù)庫的事務處理確保了數(shù)據(jù)的原子性和完整性。缺陷A、多媒體信息存入關系型數(shù)據(jù)庫中，會導致關系型數(shù)據(jù)庫的存儲空間占用巨大。 在系統(tǒng)維護和備份上會造成相當?shù)碾y度，甚至在到達一定規(guī)模后導致存儲資源不足而無法 備份的情況；B、數(shù)據(jù)庫表空間被多媒體數(shù)據(jù)迅速撐大，導致數(shù)據(jù)庫性能急劇降低。數(shù)據(jù)寫入和 查詢速度都會受到影響；C、數(shù)據(jù)庫接口不是為了共享大容量多媒體信息而設計的接口，不能很好支持大容 量多媒體信息，例如多線程并發(fā)下載，斷點續(xù)傳等。(2)第二種結構優(yōu)點A、對于非文本類的信息以文件的方式放在文件服務器上，數(shù)據(jù)庫只存儲文本類信 息。所以數(shù)據(jù)庫所占用的空間不大。有利于維護和數(shù)據(jù)庫操作的快速性；
4
B、多媒體信息以文件的形式組織有利于管理、上傳和下載。該結構解決了第一種結構中存在的技術問題，但還是存在如下技術缺陷A、不能使用統(tǒng)一的接口，數(shù)據(jù)庫信息只能用數(shù)據(jù)庫接口讀取，而文件服務器的信 息用對應的客戶端來單獨下載；B、由于信息分開存放，通過不同的形式上傳和下載信息的不同部分，所以存在信 息有可能不同步的情況；C、從文件服務器下載的多媒體文件有可能因為不確定的網(wǎng)絡因素而變得不完整， 甚至是錯誤的。

發(fā)明內(nèi)容
(一)要解決的技術問題本發(fā)明要解決的技術問題是在分別存儲多媒體文件和其描述文本的情況下，如 何保證多媒體信息在出入多媒體信息庫時的原子性和完整性，并簡化客戶端的操作難度和 多媒體信息庫的維護。( 二 )技術方案—種多媒體信息共享方法，包括以下步驟Sl 驗證客戶端上傳的多媒體信息中的多媒體文件和用于描述所述多媒體文件的 描述文本，通過驗證后，將所述多媒體文件上傳至文件服務器，將所述描述文本上傳至數(shù)據(jù) 庫；S2:從數(shù)據(jù)庫和文件服務器分別下載所述描述文本和所述多媒體信息并驗證，通 過驗證后，將所述多媒體信息發(fā)送給所述客戶端。其中，所述步驟Sl具體包括Sll 根據(jù)事先定義的關于所述描述文本的結構定義文本驗證所述描述文本是否 有效，若有效，執(zhí)行步驟S12，否則返回錯誤消息，結束上傳；S12:驗證所述多媒體文件是否與描述文本中記錄的多媒體文件相同，若相同執(zhí)行 步驟S13，否則返回錯誤消息，結束上傳；S13 將所述多媒體文件上傳至所述文件服務器，同時上傳所述多媒體文件的校驗 fn息；S14:上傳所述描述文本至數(shù)據(jù)庫，再次根據(jù)事先定義的結構化文本驗證所述描述 文本是否有效，并根據(jù)所述描述文本中記錄的多媒體文件驗證已上傳的多媒體文件和校驗 信息，若都通過驗證，返回成功消息，否則返回錯誤消息，結束上傳。其中，所述步驟S13中的校驗信息采用MD5算法生成。其中，所述在步驟S13的上傳過程中若產(chǎn)生網(wǎng)絡中斷，再次上傳時采用斷點續(xù)傳 方式，若網(wǎng)絡中斷達到預定次數(shù)以上，則結束上傳。其中，所述步驟S14中所述上傳描述文本至數(shù)據(jù)庫的方式為將所述描述文本加 入到消息隊列，等待入庫。其中，所述步驟S2包括S21 將所述描述文本根據(jù)描述的多媒體文件類型的不同進行轉(zhuǎn)換，將轉(zhuǎn)換后的描 述文本加入所述消息隊列；
S22:檢查消息隊列，如果有消息則取出所述描述文本，并根據(jù)事先定義的關于所 述描述文本的結構定義文本驗證取出的描述文本是否有效，若通過驗證，則執(zhí)行步驟S23， 否則返回錯誤信息，并結束下載；S23:根據(jù)取出的描述文本中的多媒體文件的鏈接信息到服務器下載多媒體文件 和校驗信息，下載完成后，根據(jù)校驗信息校驗下載的媒體文件，若通過校驗，執(zhí)行步驟S24， 否則，返回錯誤消息，并結束下載；S24 將所述多媒體信息發(fā)送給所述客戶端。其中，所述步驟S21中，按多媒體文件的類型將所述轉(zhuǎn)換后的描述文本加入不同 類型的消息隊列，步驟S22中，從所述各自的消息隊列中取出所述描述文本。其中，所述步驟S22中，從所述各自的消息隊列中取出所述描述文本。其中，所述步驟S23的下載過程中采用多線程和斷點續(xù)傳方式下載?！N多媒體信息共享系統(tǒng)，包括多媒體信息上傳模塊，用于驗證客戶端上傳的多媒體信息中的多媒體文件和用于 描述所述多媒體文件的描述文本，通過驗證后，并將所述多媒體文件上傳至文件服務器，將 所述描述文本上傳至數(shù)據(jù)庫；多媒體信息下載模塊，用于從數(shù)據(jù)庫和文件服務器分別下載所述描述文本和所述 多媒體信息并驗證，通過驗證后，將所述多媒體信息發(fā)送給所述客戶端。(三)有益效果本發(fā)明將多媒體信息和描述文本分別存儲，并通過在上傳和下載時對多媒體信息 進行驗證，保證了信息的原子性和完整性，并簡化了客戶端的操作難度和多媒體信息庫的 維護。


圖1是根據(jù)本發(fā)明實施例的多媒體信息共享方法中所采用的多媒體信息庫結構 示意圖；圖2是根據(jù)本發(fā)明實施例的多媒體信息共享方法中多媒體信息入庫的流程圖；圖3是根據(jù)本發(fā)明實施例的多媒體信息共享方法中多媒體信息出庫的流程圖。
具體實施例方式下面結合附圖和實施例，對本發(fā)明的具體實施方式
作進一步詳細描述。以下實施 例用于說明本發(fā)明，但不用來限制本發(fā)明的范圍。如圖1所示，本實施例中，將多媒體信息中的多媒體文件及其描述信息分開存儲， 即多媒體信息庫包括FTP文件服務器和多媒體文件描述文本數(shù)據(jù)庫。采用FTP文件服務器 存儲多媒體文件，多媒體文件描述文本數(shù)據(jù)庫存儲多媒體文件描述信息，本實施例中采用 XML文件來描述多媒體文件信息，即使用XML數(shù)據(jù)庫作為多媒體文件描述文本數(shù)據(jù)庫實體 化方式，XML文件中包括指向多媒體信息的路徑等信息。為了使上傳或下載多媒體信息時， 達到多媒體文件與描述其信息的XML文件同步，在作為本地客戶端的業(yè)務平臺部署本地代 理，業(yè)務平臺通過本地代理向所述FTP文件服務器和多媒體文件描述文本數(shù)據(jù)庫分別上傳 或下載所述多媒體文件和所述多媒體文件描述文本。并在上傳和下載時進行多媒體信息驗證，以達到多媒體文件和描述其信息的XML文件同步，從而保證多媒體信息的原子性和完 整性。業(yè)務平臺通過代理向多媒體信息庫上傳多媒體信息，即入庫的步驟如圖2所示。 步驟S201，業(yè)務平臺通過本地代理將多媒體信息(包含多媒體文件及描述其信息的XML文 件)提交給本地代理。步驟S202，所述本地代理對XML文件進行驗證，具體地，采用事先定義 好的XSD文件驗證所述XML文件的有效性，即XML的文件的結構是否符合描述多媒體文件 的信息，若未通過驗證，則執(zhí)行步驟S208，返回錯誤信息，并結束本次入庫。若通過驗證，則 執(zhí)行步驟S203，本地代理驗證XML文件中的多媒體文件指向與業(yè)務平臺提交到本地代理的 多媒體文件是否相同，若不同，則執(zhí)行步驟S208。若相同，則執(zhí)行步驟S204，由于在上傳多 媒體文件后上傳XML文件才能保證整個入庫過程的原子性和完整性，所以本地代理先將多 媒體文件及校驗信息上傳至FTP文件服務器。其中，將多媒體文件通過MD5散列算法生成一 個字符串，這個字符串存成文件，就是校驗信息。在上傳的過程中可能因為各種網(wǎng)絡因素導 致傳輸過程中斷，所以對于失敗的情況需要做斷點續(xù)傳處理，如果中斷達到預定次數(shù)以上， 如10次以上，則執(zhí)行步驟S208，該次數(shù)以配置的方式存在，可以隨實際網(wǎng)絡情況更改。若上 傳成功，則執(zhí)行步驟S206，將XML文件上傳到多媒體文件描述文本數(shù)據(jù)庫。具體地，在上傳 時采用消息隊列的方式，本地代理先將XML文件壓入消息隊列，等待入庫。步驟S207，在入 庫時，再次根據(jù)事先定義好的XSD文件驗證XML文件是否有效，并根據(jù)XML文件中記錄的多 媒體文件驗證已上傳的多媒體文件和校驗信息，驗證方式為首先驗證上傳的多媒體文件 是否存在，其次采用跟前述方式相同的MD5散列算法生成字符串，與上傳的校驗信息比較， 若都通過驗證，則執(zhí)行步驟S209，返回成功入庫的消息，否則，執(zhí)行步驟S208。多媒體信息入庫后，即多媒體文件上傳到FTP文件服務器，XML文件上傳到多媒體 文件描述文本數(shù)據(jù)庫后，所述多媒體信息開始出庫流程，其步驟如圖3所示。步驟S301，當多媒體信息入庫時，啟動實時同步機制，即將XML文件根據(jù)其描述的 媒體文件類型進行轉(zhuǎn)換，并將轉(zhuǎn)換后的文件壓入消息隊列，準備出庫。由于多媒體文件是由 多媒體文件內(nèi)容提供商(content provider, CP)提供，即轉(zhuǎn)換時按照CP的要求進行轉(zhuǎn)換， 其轉(zhuǎn)換文件為事先存儲在多媒體文件描述文本數(shù)據(jù)庫中的XSLT文件，該文件可將XML文件 記錄的內(nèi)容結構轉(zhuǎn)換成CP所要求的內(nèi)容結構。在將轉(zhuǎn)換后的文件壓入消息隊列時，按各個 CP的要求將轉(zhuǎn)換后的文件壓入相應的CP消息隊列，每個CP都有自己獨立的消息隊列。步 驟S302，本地代理檢查相應的CP消息隊列，若有消息，則從該消息隊列中取出XML文件。步 驟S303，取出XML文件后，本地代理并根據(jù)事先定義好的XSD文件驗證XML文件是否有效， 若未通過驗證，則執(zhí)行步驟S306，返回錯誤信息，并結束本次出庫。若通過驗證。則執(zhí)行步 驟S304，本地代理根據(jù)取出的XML文件中的多媒體文件的路徑信息從FTP文件服務器中下 載對應的多媒體文件及校驗信息，在下載過程中優(yōu)選采用多線程和斷點續(xù)傳方式下載，以 提高下載速度。步驟S305，根據(jù)校驗信息校驗所述多媒體文件是否正確，若未通過驗證，則 執(zhí)行步驟S306。若通過驗證，則執(zhí)行步驟S307，通過本地代理的API通知業(yè)務平臺有新的 消息到達，并給出相應的多媒體信息。本發(fā)明還提出了一種多媒體信息共享系統(tǒng)，包括多媒體信息上傳模塊，用于驗證 客戶端上傳的多媒體信息中的多媒體文件和用于描述所述多媒體文件的描述文本，通過驗 證后，并將所述多媒體文件上傳至文件服務器，將所述描述文本上傳至數(shù)據(jù)庫；多媒體信息下載模塊，用于從數(shù)據(jù)庫和文件服務器分別下載所述描述文本和所述多媒體信息并驗證， 通過驗證后，將所述多媒體信息發(fā)送給所述客戶端。本實施例中，上述兩個模塊在代理中實 現(xiàn)，如圖1中的本地代理，可以是具有上述兩個模塊功能的代理服務器或是本地代理軟件。
以上實施方式僅用于說明本發(fā)明，而并非對本發(fā)明的限制，有關技術領域的普通 技術人員，在不脫離本發(fā)明的精神和范圍的情況下，還可以做出各種變化和變型，因此所有 等同的技術方案也屬于本發(fā)明的范疇，本發(fā)明的專利保護范圍應由權利要求限定。
權利要求
一種多媒體信息共享方法，其特征在于，包括以下步驟S1驗證客戶端上傳的多媒體信息中的多媒體文件和用于描述所述多媒體文件的描述文本，通過驗證后，將所述多媒體文件上傳至文件服務器，將所述描述文本上傳至數(shù)據(jù)庫；S2從數(shù)據(jù)庫和文件服務器分別下載所述描述文本和所述多媒體信息并驗證，通過驗證后，將所述多媒體信息發(fā)送給所述客戶端。
2.如權利要求1所述的多媒體信息共享方法，其特征在于，所述步驟Sl具體包括511根據(jù)事先定義的關于所述描述文本的結構定義文本驗證所述描述文本是否有效， 若有效，執(zhí)行步驟S12，否則返回錯誤消息，結束上傳；512驗證所述多媒體文件是否與描述文本中記錄的多媒體文件相同，若相同執(zhí)行步驟 S13，否則返回錯誤消息，結束上傳；513將所述多媒體文件上傳至所述文件服務器，同時上傳所述多媒體文件的校驗信息；514上傳所述描述文本至數(shù)據(jù)庫，再次根據(jù)事先定義的結構化文本驗證所述描述文 本是否有效，并根據(jù)所述描述文本中記錄的多媒體文件驗證已上傳的多媒體文件和校驗信 息，若都通過驗證，返回成功消息，否則返回錯誤消息，結束上傳。
3.如權利要求2所述的多媒體信息共享方法，其特征在于，所述步驟S13中的校驗信息 采用MD5算法生成。
4.如權利要求2所述的多媒體信息共享方法，其特征在于，所述在步驟S13的上傳過程 中若產(chǎn)生網(wǎng)絡中斷，再次上傳時采用斷點續(xù)傳方式，若網(wǎng)絡中斷達到預定次數(shù)以上，則結束 上傳。
5.如權利要求2所述的多媒體信息共享方法，其特征在于，所述步驟S14中所述上傳描 述文本至數(shù)據(jù)庫的方式為將所述描述文本加入到消息隊列，等待入庫。
6.如權利要求1所述的多媒體信息共享方法，其特征在于，所述步驟S2包括521將所述描述文本根據(jù)描述的多媒體文件類型的不同進行轉(zhuǎn)換，將轉(zhuǎn)換后的描述文 本加入所述消息隊列；522檢查消息隊列，如果有消息則取出所述描述文本，并根據(jù)事先定義的關于所述描 述文本的結構定義文本驗證取出的描述文本是否有效，若通過驗證，則執(zhí)行步驟S23，否則 返回錯誤信息，并結束下載；523根據(jù)取出的描述文本中的多媒體文件的鏈接信息到服務器下載多媒體文件和校 驗信息，下載完成后，根據(jù)校驗信息校驗下載的媒體文件，若通過校驗，執(zhí)行步驟S24，否則， 返回錯誤消息，并結束下載；524將所述多媒體信息發(fā)送給所述客戶端。
7.如權利要求6所述的多媒體信息共享方法，其特征在于，所述步驟S21中，按多媒體 文件的類型將所述轉(zhuǎn)換后的描述文本加入不同類型的消息隊列，步驟S22中，從所述各自 的消息隊列中取出所述描述文本。
8.如權利要求7所述的多媒體信息共享方法，其特征在于，所述步驟S22中，從所述各 自的消息隊列中取出所述描述文本。
9.如權利要求6所述的多媒體信息共享方法，其特征在于，所述步驟S23的下載過程中 采用多線程和斷點續(xù)傳方式下載。2
10. 一種多媒體信息共享系統(tǒng)，其特征在于，包括多媒體信息上傳模塊，用于驗證客戶端上傳的多媒體信息中的多媒體文件和用于描述 所述多媒體文件的描述文本，通過驗證后，并將所述多媒體文件上傳至文件服務器，將所述 描述文本上傳至數(shù)據(jù)庫；多媒體信息下載模塊，用于從數(shù)據(jù)庫和文件服務器分別下載所述描述文本和所述多媒 體信息并驗證，通過驗證后，將所述多媒體信息發(fā)送給所述客戶端。
全文摘要
本發(fā)明公開了一種多媒體信息共享方法，包括以下步驟驗證客戶端上傳的多媒體信息中的多媒體文件和用于描述所述多媒體文件的描述文本，通過驗證后，并將所述多媒體文件上傳至文件服務器，將所述描述文本上傳至數(shù)據(jù)庫；從數(shù)據(jù)庫和文件服務器分別下載所述描述文本和所述多媒體信息并驗證，通過驗證后，將所述多媒體信息發(fā)送給所述客戶端。本發(fā)明將多媒體信息和描述文本分別存儲，并通過在上傳和下載時對多媒體信息進行驗證，保證了信息的原子性和完整性，并簡化了客戶端的操作難度和多媒體信息庫的維護。
文檔編號H04L29/08GK101895536SQ20101022246
公開日2010年11月24日 申請日期2010年6月30日 優(yōu)先權日2010年6月30日
發(fā)明者張本金, 李剛, 楊熹林 申請人:北京新媒傳信科技有限公司