專利名稱：基于ip機頂盒實現(xiàn)交互增值業(yè)務(wù)的中間件系統(tǒng)及其方法
技術(shù)領(lǐng)域：
本發(fā)明涉及嵌入式系統(tǒng)領(lǐng)域，尤其涉及用于機頂盒的中間件技術(shù)及實現(xiàn) 交互增值業(yè)務(wù)的方法。
背景技術(shù)：
IPTV和數(shù)字電視在全球發(fā)展迅猛。在中國，各大運營商都在利用他們自 身的網(wǎng)絡(luò)全力推動家庭數(shù)字化。雖然現(xiàn)在的IPTV或數(shù)字電視的產(chǎn)品都比較成 熟，但他們的都依然比較有局限性。目前的數(shù)字電視業(yè)務(wù)基于廣播電視信號 網(wǎng)絡(luò)，這種單向網(wǎng)絡(luò)僅能提供更多的頻道、準點播(廣播方式)及有限的交 互服務(wù)，缺乏良好的盈利模式。而目前的IPTV產(chǎn)品則仍以提供單純的實時點 播服務(wù)為主，然而在IP網(wǎng)絡(luò)上滿足大量用戶的點播需要是極其困難的，而且 盈利模式單一。因此可見，目前廣播電視信號網(wǎng)絡(luò)缺乏足夠強大的雙向交互 增值服務(wù)支持。增值業(yè)務(wù)是IPTV或數(shù)字電視發(fā)展的關(guān)鍵因素，要在IPTV或 數(shù)字電視上發(fā)展增值業(yè)務(wù)，需要發(fā)揮服務(wù)提供商參與的積極性，才能讓這個 新興的產(chǎn)業(yè)興旺起來。目前這個領(lǐng)域最廣泛的中間件技術(shù)之一是基于組件(或稱構(gòu)件)的開發(fā) 模式，包括基于二進制代碼機制(如采用C/C++)和基于虛擬機中間代碼機 制(如采用JAVA)。這種模式功能強大適應性強，但應用月l務(wù)的開發(fā)和分發(fā) 的復雜度和難度比較大。另外的一種常見技術(shù)是基于WEB的開發(fā)模式，由于 基于解釋性數(shù)據(jù)，應用服務(wù)的開發(fā)難度較低，但功能局限，擴展困難，很難 適應對界面樣式和界面邏輯有復雜或特殊要求的應用服務(wù)需求，也很難使應 用服務(wù)同時兼容不同的終端設(shè)備。雖然目前也有同時支持這兩種模式的中間 件產(chǎn)品，但完全分離，無法通過優(yōu)勢互補提供更多樣化或更靈活的應用實現(xiàn)手段，也無法有效地發(fā)揮解釋性數(shù)據(jù)在應用服務(wù)開發(fā)中的作用。 發(fā)明內(nèi)容本發(fā)明的目的在于提供一種基于IP機頂盒實現(xiàn)交互增值業(yè)務(wù)的中間件 系統(tǒng)及其方法，有利于同時滿足兩個不同領(lǐng)域的服務(wù)提供商的參與需求，有 利于優(yōu)勢互補。本發(fā)明提供一種基于IP機頂盒實現(xiàn)交互增值業(yè)務(wù)的中間件系統(tǒng)，包括 基于組件開發(fā)模式的第一應用開發(fā)層、動態(tài)可擴展接口描述層和基于解釋性 數(shù)據(jù)的開發(fā)模式的第二應用開發(fā)層；所述第一應用開發(fā)層，包括信令服務(wù)控制模塊和可選配的功能模塊，所 述信令服務(wù)控制模塊用于為信息傳輸及通訊服務(wù)提供雙向傳輸協(xié)議支持；所 述可選配的功能模塊用于為應用服務(wù)提供功能支持；所述第二應用開發(fā)層，用于生成和處理交互式應用服務(wù)的消息；所述消 息包含消息頭和消息體；所述消息頭包含消息類型信息及會話屬性信息，以 及以下至少一種信息設(shè)備屬性信息、能力描述信息，以及輔助參數(shù)信息； 所述消息體包括所述應用服務(wù)的業(yè)務(wù)邏輯和/或業(yè)務(wù)內(nèi)容；所述動態(tài)可擴展4妾口描述層，包括為所述第二應用開發(fā)層訪問所述第一 應用開發(fā)層所提供的接口 ，所述第二應用開發(fā)層通過所述4妄口從所述信令服 務(wù)控制模塊和功能模塊獲取對應的應用服務(wù)的功能支持。本發(fā)明還提供一種基于IP機頂盒實現(xiàn)交互增值業(yè)務(wù)的方法，接收到用戶 請求應用服務(wù)的指令時，中間件系統(tǒng)的第二應用開發(fā)層生成會話屬性信息， 并根據(jù)終端設(shè)備的設(shè)備屬性信息構(gòu)造消息，通過雙向傳輸協(xié)議實現(xiàn)與終端設(shè) 備和服務(wù)器的通訊；所述消息包括消息頭和消息體，所述消息頭用于承載消 息類型信息及會話屬性信息，以及以下至少一種信息設(shè)備屬性信息、能力描述信息，以及輔助參數(shù)信息會話屬性信息、設(shè)備屬性信息；所述消息體用 于承載應用服務(wù)的業(yè)務(wù)邏輯和/或業(yè)務(wù)內(nèi)容；通訊過程至少包括以下一個步驟所述第二應用開發(fā)層生成會話屬性信息，并連同所述設(shè)備屬性信息構(gòu)造 消息，將該消息發(fā)送至所述服務(wù)器，請求與所述服務(wù)器所提供的應用服務(wù)建 立服務(wù)會話和維護會話連接；在建立會話后，所述第二應用開發(fā)層根據(jù)所述用戶指令構(gòu)造消息，從所 述服務(wù)器獲取所述應用服務(wù)所對應的業(yè)務(wù)邏輯和/或業(yè)務(wù)內(nèi)容；將所述業(yè)務(wù)內(nèi) 容根據(jù)所述業(yè)務(wù)邏輯進行顯示；當接收到用戶下一步的指令時，所述第二應用開發(fā)層才艮據(jù)所述業(yè)務(wù)邏輯 進行處理。本發(fā)明的中間件中結(jié)合了基于組件開發(fā)模式的第 一應用開發(fā)層和基于解 釋性數(shù)據(jù)的開發(fā)模式的第二應用開發(fā)層，同時滿足兩個不同領(lǐng)域的服務(wù)提供 商的參與需求，并充分結(jié)合他們的優(yōu)勢進行互補，優(yōu)化增值業(yè)務(wù)的開發(fā)模式， 避免了現(xiàn)有技術(shù)要么功能限制太大要么技術(shù)門檻太高的弊端，也可以提高開 發(fā)效率和吸引更多的參與者，從而能為用戶提供各種多樣化的增值業(yè)務(wù)。另 外，本發(fā)明采用雙向傳輸協(xié)議承載交互消息，以使的客戶端與服務(wù)器端之間 能夠進行雙向交互，為用戶提供了豐富互動增值服務(wù)的平臺。


圖1為本發(fā)明所述的基于IP機頂盒實現(xiàn)交互增值業(yè)務(wù)的中間件系統(tǒng)的結(jié) 構(gòu)框圖；圖2為本發(fā)明所述的第二應用開發(fā)層生成的消息的結(jié)構(gòu)圖；圖3為本發(fā)明所述的基于IP機頂盒實現(xiàn)交互增值業(yè)務(wù)的方法的流程圖。
具體實施方式
本發(fā)明所提供的技術(shù)方案可用于互動電視(包括雙向數(shù)字電視、IPTV 等)具有IP網(wǎng)絡(luò)接入能力的嵌入式系統(tǒng)機頂盒，通過本發(fā)明的中間件提供一個 增值業(yè)務(wù)支撐平臺，使不同領(lǐng)域的技術(shù)提供商和業(yè)務(wù)提供商一起參與提供增 值業(yè)務(wù)，并各施其職。由于多媒體子系統(tǒng)(IP Multimedia Subsystem,簡稱IMS ) 是面向下一代網(wǎng)絡(luò)系統(tǒng)的國際標準，具有周全的考慮及強大的擴展性，并提 供了統(tǒng)一的通訊架構(gòu)。采用本發(fā)明的終端設(shè)備可接入IMS系統(tǒng)，并利用IMS的 優(yōu)秀特性及標準的通訊流程應用于互動電視系統(tǒng)，以簡化開發(fā)難度以及增強 通用性。本發(fā)明所述的終端設(shè)備的客戶端系統(tǒng)分為以下層次資源層、中間件層、 應用層。其中，資源層包括操作系統(tǒng)及終端固有外設(shè)的驅(qū)動支持。其中，中間件層即本發(fā)明所述的中間件系統(tǒng)，包含所涉及的三個子層基于組件開發(fā)模式的第一應用開發(fā)層、動態(tài)可擴展接口描述層和基于解釋性數(shù)據(jù)的開發(fā)模式的第二應用開發(fā)層。中間件層服務(wù)于應用層，為應用層提供接口，為應用層的擴展提供基礎(chǔ)和支持。其中，應用層通過利用中間件層的各種能力，根據(jù)服務(wù)提供商的要求定制應用，為最終用戶提供各種增值業(yè)務(wù)。基于組件開發(fā)模式功能強大、效能高，但基于解釋性凄t據(jù)開發(fā)模式不依 賴于平臺和嵌入式環(huán)境，也不依賴于特定高級開發(fā)語言的特點仍有具有很大吸引力，這種類似于WEB網(wǎng)站開發(fā)的方式更容易讓服務(wù)提供者參與，使其專 注于應用的業(yè)務(wù)邏輯而不需要在專業(yè)技術(shù)領(lǐng)域(如嵌入式4支術(shù)和通訊技術(shù)等) 投入太多精力和資源。但傳統(tǒng)WEB技術(shù)的開發(fā)模式所顯現(xiàn)的局限雖然在個人 電腦領(lǐng)域得以緩解，但在嵌入式領(lǐng)域就特別明顯。其中一方面通過解釋性語 言實現(xiàn)界面效果的復雜性對終端的效能影響非常高，尤其對于資源有限性能要求高的嵌入式機頂盒；另一方面，瀏覽器支持的能力有限，標準以外的功 能通常通過瀏覽器插件實現(xiàn)，但是插件的開發(fā)通常依賴特定瀏覽器，而且資 源使用也受制于瀏覽器，因此技術(shù)實現(xiàn)復雜、繁瑣而且性能較低。由此可見， 采用更具彈性而且耦合性較低的方式為基于解釋性數(shù)據(jù)開發(fā)模式提供擴展支 持非常重要，而且面向應用開發(fā)的解釋性語言需要擺脫WEB模式傳統(tǒng)思路的 約束。如圖1所示，本發(fā)明所述的中間件系統(tǒng)包括基于組件開發(fā)模式的第 一應用 開發(fā)層和基于解釋性數(shù)據(jù)的開發(fā)模式的第二應用開發(fā)層；二者均可以服務(wù)于 交互增值業(yè)務(wù)開發(fā)(即服務(wù)于客戶端系統(tǒng)的應用層)，但是支持模式不同， 通過動態(tài)可擴展接口描述層結(jié)合兩種模式，利用分工和互補原則擺脫傳統(tǒng)模 式的制約，增強適應能力和擴展能力。尤其針對基于描述性凄t據(jù)的應用開發(fā) 方式，與現(xiàn)存的WEB技術(shù)相比，更適合于互動電視服務(wù)。以下闡述實現(xiàn)細節(jié)?；诮M件開發(fā)模式的第一應用開發(fā)層類似于傳統(tǒng)的中間件，為應用開發(fā) 提供基于高級語言(如C/C+十、JAVA等)的程序接口?；谶@種傳統(tǒng)的中間 件形式可獲得強大的功能支持，但技術(shù)門檻較高。為了使釆用本發(fā)明中間件系統(tǒng)的終端設(shè)備可作為標準IMS客戶端接入 IMS系統(tǒng)，并提供標準SIP服務(wù)，第一應用開發(fā)層中通常包含信令服務(wù)控制模 塊，為信息傳輸及通訊服務(wù)提供雙向傳輸協(xié)議支持。在一個實施例中，該模 塊可以是符合標準的SIP信令服務(wù)控制模塊(包括信令通訊控制模塊及基本通 訊服務(wù)模塊)，與以IMS為核心的服務(wù)平臺的聯(lián)系可以通過SIP協(xié)議完成，通 過服務(wù)平臺統(tǒng)一的通訊架構(gòu)進行身份驗證、權(quán)限控制、路由、計費、安全保 障等。信令通訊控制模塊，負責維護和管理SIP通訊流程，但可以不涉及通訊服 務(wù)邏輯；基本通訊服務(wù)模塊，利用SIP通訊標準建立的一些基本通訊服務(wù)，為中間件提供必要或常用的功能支持，如VOIP、狀態(tài)呈現(xiàn)等；另外，第一應用開發(fā)層中還可以根據(jù)實際需求包括其他功能模塊，才能 為應用層提供足夠的服務(wù)能力。動態(tài)可擴展接口描述層用以描述終端設(shè)備的功能接口 ，包括第一應用開 發(fā)層提供給第二應用開發(fā)層訪問的接口 。這些接口描述終端設(shè)備的功能如何 被使用，以及以何種方式被使用(包括方法或事件的名稱、參數(shù)等)。第二 應用開發(fā)層通過該接口從信令服務(wù)控制模塊和功能模塊獲取對應的應用服務(wù) 的功能支持。上文所述的第二應用開發(fā)層需要通過調(diào)用所述的第 一應用開發(fā)層所提供 的程序接口，用以為基于解釋性數(shù)據(jù)的應用開發(fā)提供功能支持，也就是說終端本地功能越豐富，通過第二應用開發(fā)層進行應用開發(fā)所能利用到能力和支 持就越豐富和靈活。然而不同終端設(shè)備支持的功能不相同，終端設(shè)備的功能 也會擴展增加。在WEB技術(shù)中，客戶端瀏覽器并沒有提供簡便、動態(tài)、彈性 高、耦合性較低的擴展支持能力，這極大地局限了WEB技術(shù)的應用支持能力。 另 一方面，由于基于組件開發(fā)模式所提供的接口無法被解釋性語言所直接訪 問，故需要通過一個接口轉(zhuǎn)換層結(jié)合兩個開發(fā)層的兩種開發(fā)模式，因此在本 發(fā)明中加入動態(tài)可擴展接口描述層，實現(xiàn)接口轉(zhuǎn)換。本發(fā)明的中間件提供動態(tài)可擴展接口描述層依賴和使用接口描述文件聲 明終端功能接口，這種文件中的內(nèi)容可以通過解釋性數(shù)據(jù)(例如XML)定義， 以實現(xiàn)動態(tài)的擴展性，也便于被第二應用開發(fā)層使用。同時，動態(tài)可擴展接 口描述層還通常包含接口轉(zhuǎn)換實現(xiàn)模塊，用以將第一應用開發(fā)層所提供的程 序接口重新封裝成可與接口描述文件相適應的接口形式。每個文件負責描述 一組有特定關(guān)聯(lián)關(guān)系的接口 (例如同一個模塊的接口)，通過文件的目錄結(jié)構(gòu)及文件名即可定位到這一組接口 。每個接口的描述可以包^^妄口的名稱、 輸入/輸出參數(shù)等詳細的使用說明，這些描述可被接口轉(zhuǎn)換模塊識別和解釋。動態(tài)可擴展接口描述層所描述的接口包括內(nèi)部功能接口與可擴展功能接 口，內(nèi)部功能指不依賴客戶端設(shè)備和平臺的差異而不同的固定功能，其它即 屬于可擴展部分。在第二應用開發(fā)層中聲明一個終端設(shè)備功能調(diào)用時，可聲 明接口所屬范疇，例如，缺省時為調(diào)用內(nèi)部功能，否則為調(diào)用可擴展功能。上面所述的接口描述文件通過預置或連同升級包(包含升級的功能庫及 對應的接口描述文件)下載到終端設(shè)備本地。通過動態(tài)可擴展接口描述層， 由第二應用開發(fā)層定義的邏輯流程就可以訪問和4吏用這些接口 ，既可支持和 適應不同的終端設(shè)備，也支持和適應客戶端功能的擴展和升級。第二應用開發(fā)層基于解釋性數(shù)據(jù)的開發(fā)機制，支持服務(wù)的遠程發(fā)布，服務(wù)器通過解釋性數(shù)據(jù)(XML)與終端設(shè)備交流，以此實現(xiàn)應用服務(wù)流程和提 供應用服務(wù)內(nèi)容。解釋性數(shù)據(jù)并不受制于軟硬件平臺和嵌入式環(huán)境，也不局 限于特定開發(fā)語言，因此應用開發(fā)具有很大的自由度?；诘诙瞄_發(fā)層所實現(xiàn)的應用，通過以這種解釋性數(shù)據(jù)所構(gòu)成的消 息提供業(yè)務(wù)。第二應用開發(fā)層負責生成和處理交互式應用服務(wù)的消息；如圖2 所示，這些消息包括消息頭和消息體兩個部分；消息頭提供與不同的應用服 務(wù)有需求共性但又無直接關(guān)系的信息，消息頭通常不能缺省而且有固定的組 成部分，消息體由消息流程控制數(shù)據(jù)組成；消息體攜帶與應用服務(wù)直接有關(guān) 的信息，根據(jù)不同的需求可能攜帶不同的內(nèi)容，消息體通常由業(yè)務(wù)邏輯控制 數(shù)據(jù)和業(yè)務(wù)內(nèi)容呈現(xiàn)數(shù)據(jù)構(gòu)成；由于業(yè)務(wù)內(nèi)容的呈現(xiàn)需由業(yè)務(wù)邏輯決定，因 此在消息體包含業(yè)務(wù)內(nèi)容呈現(xiàn)數(shù)據(jù)時通常需要同時包含業(yè)務(wù)邏輯控制數(shù)據(jù)； 為了滿足擴展應用需求，消息體中還可以包含其他類型的數(shù)據(jù)內(nèi)容。結(jié)合圖2, 參見圖1,第二應用開發(fā)層包括以下模塊消息頭處理模塊、邏輯處理模塊、數(shù)據(jù)呈現(xiàn)模塊、模板管理模塊和資源包管理模塊。這種消息分為請求消息和回復消息兩大類型，請求消息用于主動發(fā)起特 定操作，而回復消息則用以回應請求消息的處理結(jié)果(成功或失敗，以及更 多的信息)。這種消息(包括請求與回復)通過SIP協(xié)議承載，即由SIP協(xié)議 負責實現(xiàn)通訊傳輸功能以及相關(guān)的職能(例如認^〖正、路由、安全等)。因此， 采用這種解釋性數(shù)據(jù)實現(xiàn)應用服務(wù)僅需要專注于業(yè)務(wù)邏輯，而不需要直接涉 及通訊邏輯，從而通過分工原則縮小開發(fā)者的關(guān)注面，降低技術(shù)難度。 一個Language,簡稱XML )定義(為便于說明，在本發(fā)明中定義的這種數(shù)據(jù)格式 命名為信息導航協(xié)議——Information Navigation Protocol,簡稱INP協(xié)議)，包 括三種主要的數(shù)據(jù)內(nèi)容類型消息流程控制數(shù)據(jù)、業(yè)務(wù)邏輯控制數(shù)據(jù)、業(yè)務(wù) 內(nèi)容呈現(xiàn)數(shù)據(jù)。消息流程控制數(shù)據(jù)用以定義消息的主要功能，這些功能適用于所有應用 服務(wù)，具有一般化的通用性。這些功能在消息中以不同的數(shù)據(jù)域表現(xiàn)，包括設(shè)備域、方法域、會話域、能力域和參數(shù)域。其中方法域和會話域是不可缺 省的數(shù)據(jù)域。設(shè)備域，用以承載設(shè)備屬性信息，描述終端設(shè)備的軟硬件信息，其中包 括設(shè)備型號信息和軟件系統(tǒng)版本，以及可選的生產(chǎn)商信息等。方法域，用以消息類型信息，描述消息的類型和功能；其中包括消息類 型信息、消息功能信息，以及用以完成消息的匹配和說明作用的其他輔助信 息。消息類型信息，即標識當前消息包是請求消息或回復消息。消息功能信 息，對于請求消息的功能包括請求連接(開始業(yè)務(wù))、斷開連接(結(jié)束業(yè)務(wù))、 獲取數(shù)據(jù)、推送/發(fā)送數(shù)據(jù)等；對于回復消息的功能包括針對不同請求消息功 能的各種成功和失敗的回應。為了匹配一個回復消息與其對應的請求消息，以便于完成相關(guān)的處理過程，因此也需要在方法域中包含描述此對應關(guān)系的 信息。在一個客戶端與服務(wù)器端之間，可能會有多個相同功能的消息同時或 不同時傳遞，因此在方法域中也需要包含起區(qū)分作用的信息。除此之外，還 可能包含對消息的功能說明以及針對此功能的輔助參數(shù)等信息。上面提到的請求功能的意義如下請求連接，是客戶端用以向服務(wù)器請求建立某一個應用服務(wù)的會話，并 請求執(zhí)行此應用服務(wù)；斷開連接，用以結(jié)束某一月良務(wù)會話，即結(jié)束對應的應用月良務(wù)；獲取數(shù)據(jù)，是客戶端用以主動向服務(wù)器請求，并將引起服務(wù)器發(fā)送下一 步的業(yè)務(wù)邏輯和業(yè)務(wù)內(nèi)容，從而導致客戶端的界面更換；發(fā)送數(shù)據(jù)，是服務(wù)器端收到獲取數(shù)據(jù)請求后，用以將下一步的業(yè)務(wù)邏輯 和業(yè)務(wù)內(nèi)容傳遞到客戶端；推送數(shù)據(jù)，是客戶端或者服務(wù)器端，在未引發(fā)當前業(yè)務(wù)界面更換的情況 下，用以向另外一方傳遞數(shù)據(jù)，從而實現(xiàn)在不影響當前界面的情況下繼續(xù)業(yè) 務(wù)數(shù)據(jù)交換；為了讓會話中的兩端都能監(jiān)測會話的有效性，還可以通過定期發(fā)送的會 話保持請求(Keep-Alive )確保兩端都在有效狀態(tài)，否則即表示會話意外中斷； 為了滿足以后的功能需求，可以定義和添加新的請求類型。會話域，用以承載會話屬性信息，描述一個特定服務(wù)會話。 一個服務(wù)會 話表示終端執(zhí)行一個應用服務(wù)從開始(連接成功)至結(jié)束(斷開連接)的整 個過程，服務(wù)器可以同時為多個終端提供同一個應用服務(wù)，因此不同的終端 與服務(wù)器之間必須建立獨立的服務(wù)會話。為了標識特定的會話以及便于區(qū)分 不同的會話，每個消息中攜帶會話屬性信息。此外，為了保證會話屬性信息 在客戶端與服務(wù)器端都具有唯一性，因此生成完整的會話屬性信息需要兩端 共同參與。能力域，用以承載能力描述信息，用以描迷終端支持的能力，或者描述 服務(wù)器端應用服務(wù)對終端要求的能力，以便另一方能夠判斷是否可以繼續(xù)進 行當前應用服務(wù)，其中的能力主要包括功能接口和界面模板。參數(shù)域，用以承載輔助參數(shù)信息，配合特定消息的功能需求提供額外的 數(shù)據(jù)，詳細定義視具體情況而定。消息流程控制數(shù)據(jù)作為INP消息的消息頭，為了滿足未來的擴展需求，可以通過在消息頭中增加新的數(shù)據(jù)域?qū)崿F(xiàn)。而其他與具體應用服務(wù)直接相關(guān)的 數(shù)據(jù)則作為消息內(nèi)容，因此消息中還可能包括內(nèi)容域用以包含消息內(nèi)容。消 息內(nèi)容可能包括業(yè)務(wù)邏輯控制數(shù)據(jù)和/或業(yè)務(wù)內(nèi)容呈現(xiàn)數(shù)據(jù)，同時針對擴展需 求也可能包含其它數(shù)據(jù)內(nèi)容。第二應用開發(fā)層中包含的消息頭處理模塊，用 以生成或處理消息流程控制it據(jù)。業(yè)務(wù)邏輯控制數(shù)據(jù)用以定義業(yè)務(wù)邏輯，其中包括動作內(nèi)容和結(jié)果內(nèi)容。 業(yè)務(wù)邏輯是在設(shè)計和開發(fā)應用服務(wù)時定義，在應用服務(wù)部署時已經(jīng)確定。這 套數(shù)據(jù)格式定義類似于一種腳本語言，然而它不僅包括從月艮務(wù)器端傳送到客 戶端并在客戶端本地執(zhí)行的處理流程，即動作內(nèi)容，也包括客戶端傳送回服 務(wù)器端進行進一步處理的客戶端執(zhí)行結(jié)果數(shù)據(jù)，即結(jié)果內(nèi)容。在一個業(yè)務(wù)邏 輯控制數(shù)據(jù)中只能包含動作內(nèi)容或結(jié)果內(nèi)容其中 一種。不同于一般的腳本語言(如JavaScript、 Python等)，這套數(shù)據(jù)格式并不包含復雜的程序邏輯功能， 例如條件判斷、循環(huán)、函數(shù)定義等，主要是提供如何調(diào)用終端本地功能、控 制業(yè)務(wù)內(nèi)容顯示、獲取用戶操作以及返回結(jié)果等一些基本功能，目的是避免 重新創(chuàng)建一套新的復雜且功能完整的程序語言，而希望通過盡量簡單的語法 實現(xiàn)如何組織本地功能滿足業(yè)務(wù)邏輯的需求。同時，可通過嵌入其他具有完 整程序語言特性的腳本語言(如JavaScript等)，提供必要的復雜程序邏輯(即 前面所述的條件判斷、循環(huán)、函數(shù)定義等等)。動作內(nèi)容主要的部分為動作元素，每個動作元素用以定義一組調(diào)用終端 的本地功能(即第一應用開發(fā)層所提供的功能接口)的調(diào)用序列，其中的功 能包括事件訂閱以及函數(shù)調(diào)用等。每個調(diào)用序列中的調(diào)用應該順序且連貫執(zhí) 行，這些調(diào)用所聲明的接口 (名稱以及參數(shù)、返回值等)應該與動態(tài)可擴展 接口描述層的接口描述文件中的描述一致。動作內(nèi)容中還包括全局和局部的 變量元素，用以實現(xiàn)動能調(diào)用之間的數(shù)據(jù)存儲和傳遞。動作元素之間可以互 相關(guān)聯(lián)執(zhí)行，也可以通過事件觸發(fā)執(zhí)行，同時也需要聲明其中一個作為"入 口點"的動作元素(首先被執(zhí)行)。每個動作元素中還可能包括需用參數(shù)， 用以聲明當前動作元素執(zhí)行完畢后所必需采集到的參數(shù)，用以生成結(jié)果內(nèi)容。 每個動作元素執(zhí)行后可能會立刻或者延后生成并向服務(wù)器端發(fā)送結(jié)果內(nèi)容， 因此動作元素中需要聲明具體的發(fā)送模式。為了滿足復雜的程序語言特性以 輔助業(yè)務(wù)邏輯的實現(xiàn)，動作內(nèi)容中還可以包括一個腳本元素，用以嵌入其他腳本語言(如JavaScript等)。結(jié)果內(nèi)容，作為動作內(nèi)容的處理結(jié)果，是在客戶端根據(jù)用戶操作和業(yè)務(wù) 邏輯動態(tài)生成，并傳送回M^務(wù)器端，用以確定和獲得下一步的業(yè)務(wù)邏輯和/或 業(yè)務(wù)內(nèi)容。結(jié)果內(nèi)容中包含一個或若干結(jié)果元素，每個結(jié)果元素對應一個動 作元素；每個結(jié)果元素中包含一個或若干個返回值，每個返回值對應動作元 素中的一個需用參數(shù)。結(jié)果內(nèi)容傳送至服務(wù)器端后，服務(wù)器端可根據(jù)應用服 務(wù)的業(yè)務(wù)邏輯進行處理，以確定相關(guān)的下一步驟的邏輯和內(nèi)容并發(fā)送至客戶 端，從而引發(fā)客戶端的后續(xù)處理。第二應用開發(fā)層中包括的邏輯處理模塊，負責對業(yè)務(wù)邏輯控制數(shù)據(jù)的解 析，根據(jù)規(guī)則執(zhí)行動作內(nèi)容，同時也根據(jù)動作內(nèi)容中的描述自動生成結(jié)果內(nèi) 容并傳送回服務(wù)器端。在動作內(nèi)容的執(zhí)行過程中，需要特別處理多個動作序 列間的順序和并發(fā)管理。業(yè)務(wù)內(nèi)容呈現(xiàn)數(shù)據(jù)用以定義業(yè)務(wù)界面效果以及提供業(yè)務(wù)內(nèi)容。與WEB技 術(shù)不同，業(yè)務(wù)內(nèi)容呈現(xiàn)數(shù)據(jù)所定義的界面效果并不包括完整詳細的界面實現(xiàn)， 而是第二應用開發(fā)層通過調(diào)用已儲存于客戶端的界面模板，并向其插入業(yè)務(wù) 內(nèi)容數(shù)據(jù)，同時也可能包括一定程度上調(diào)整界面模板的樣式效果。這種方法 特點在于，將界面實現(xiàn)最復雜的部分(包括界面主體功能、布局及邏輯等) 采用基于組件的開發(fā)模式，而業(yè)務(wù)內(nèi)容呈現(xiàn)數(shù)據(jù)中僅攜帶樣式效果定義數(shù)據(jù) 和業(yè)務(wù)內(nèi)容數(shù)據(jù)，因此與采用HTML語言定義界面相比數(shù)據(jù)精簡很多，處理和 顯示效率也提高很多，同時基于組件開發(fā)模式開發(fā)的界面實現(xiàn)可具有復雜的 功能(例如動畫界面效果或復雜的布局等等)，并不受制于HMTL語法以及瀏 覽器的支持能力。界面模板分為兩類頁面框架和控件。頁面框架定義界面的整體布局、 功能及表現(xiàn)形式，不同的頁面框架滿足不同的需求，例如導航頁面和詳細內(nèi) 容頁面在布局和功能上的需求就非常不同；另一方面不同的表現(xiàn)形式也影響 界面效果，例如靜態(tài)和動態(tài)的表現(xiàn)形式，列表式和轉(zhuǎn)盤式的表現(xiàn)形式等等。 控件應被包含并使用于頁面框架中， 一個頁面框架可包含若干個控件，每種 控件都有特定的功能和作用，如多選列表控件、按鈕控件、圖文控件等等。 同一控件可被多個頁面框架采用，而一個頁面框架中也可以包含多個相同的 控件。頁面框架與控件的功能由設(shè)計者定義，具有很高的自由度。界面模板 均可支持一定程度的可定制屬性，如背景圖屬性、寬高屬性等，具體支持的 屬性視具體模板而定，使能根據(jù)實際的需求對表現(xiàn)效果提供一定可調(diào)整范圍 和適應性，在業(yè)務(wù)內(nèi)容呈現(xiàn)數(shù)據(jù)中可能包含對模板屬性的設(shè)置數(shù)據(jù)。界面模 板以模板庫的形式組織，即一個模板庫中包括若干頁面框架和控件，而且模 板庫中的每一個頁面框架和控件都必須具有唯一的名稱，便于辨別和區(qū)分。 模板庫可通過預置或動態(tài)加載的方式裝載到客戶端。當某一模板庫已預置或 下載至客戶端后，即可增加一系列頁面框架和控件的支持，同時客戶端也通過模板庫的名稱以及版本來確定對于應用服務(wù)界面的支持能力。此外， 一個 模板庫中的頁面框架可使用到另 一模板庫中的控件，但必須同時支持兩個模 板庫才有效。在前面所述的消息流程控制數(shù)據(jù)中的能力域，可聲明支持或要求的模板庫(包括版本信息)。同時，界面模板也分為通用模板和專用模板。通用模板，即具有通用性 作用的界面模板，能夠滿足多種應用服務(wù)的需要，且能提供給所有應用服務(wù) 使用。但顯而易見的是，通用性與特殊要求存在一定程度的矛盾，通用性模 板目的在于滿足通常情況下的普通需求，并不能保障能夠滿足所有的，尤其 個性化、高復雜度或特殊的需求。通用模板以模板庫的方式預置或升級下載 到客戶端，其檢測和升級的處理邏輯與具體應用服務(wù)無關(guān)。專用才莫^^反，即不 一定具有通用性作用，主要滿足個性化需求，僅能為相關(guān)聯(lián)的特定應用服務(wù) 使用。通過專用模板，可針對性滿足特定應用服務(wù)的復雜需求，例如股票動 態(tài)走勢圖這類特殊要求的界面。專用模板的下載與關(guān)聯(lián)的應用服務(wù)直接有關(guān)， 被包含在對應的服務(wù)資源包中下載(服務(wù)資源包將在后文介紹)。專用模板只需要根據(jù)具體應用服務(wù)的需求特別開發(fā)即可，但開發(fā)工作量和難度相對大一些，但能滿足個性化要求；而對應的，通用模板要滿足一定共性需求，因此必須通過摸索搜集出一定的界面需求模式，從而歸納出若干 具通用性意義的模板，以滿足多個不同的應用服務(wù)的需要(或一定程度的需 要)。業(yè)務(wù)內(nèi)容呈現(xiàn)數(shù)據(jù)主要包括框架元素和控件元素?？蚣茉赝ㄟ^模板名 稱對應于特定頁面框架模板，第二應用開發(fā)層在分析和處理業(yè)務(wù)內(nèi)容呈現(xiàn)數(shù) 據(jù)時，通過該名稱來調(diào)用或匹配對應的頁面框架模板。控件元素通過模板名 稱對應于控件模板，用以描述如何使用該控件模板。由于頁面框架模板在設(shè) 計時已經(jīng)確定包含了哪些控件模板，以及這些控件模板之間的關(guān)聯(lián)關(guān)系，因 此在業(yè)務(wù)內(nèi)容呈現(xiàn)數(shù)據(jù)中所羅列的控件元素需要與所屬框架元素對應的頁面框架模板包含的控件模板一一對應?？丶刂羞€可能需要聲明所關(guān)聯(lián)的事件及觸發(fā)的動作元素?？蚣茉睾涂丶囟季哂腥愔匾獙傩詢?nèi)置屬性、 擴展屬性和不可見數(shù)據(jù)屬性。內(nèi)置屬性，指框架元素或控件元素最常用的或 最可能使用到的、具通用性的可定制屬性，例如背景屬性、控件的寬高屬性 等，這類屬性采用獨立的標簽顯式聲明。擴展屬性，指由具體頁面框架模板 或控件模板特別定義的個性化屬性，這類屬性沒有各自專用的標簽，在聲明 時需要注明屬性名稱。不可見數(shù)據(jù)屬性，用于在業(yè)務(wù)內(nèi)容呈現(xiàn)數(shù)據(jù)中攜帶于 框架元素或控件元素有關(guān)聯(lián)的數(shù)據(jù)，而且這些數(shù)據(jù)并不自動呈現(xiàn)在界面上， 僅供業(yè)務(wù)邏輯控制數(shù)據(jù)使用。第二應用開發(fā)層包含的數(shù)據(jù)呈現(xiàn)模塊，用以實現(xiàn)對業(yè)務(wù)內(nèi)容數(shù)據(jù)進行分析 處理及呈現(xiàn)；第二應用開發(fā)層包含的模板管理模塊，用以負責管理預置的和 動態(tài)加載的模板庫，也負責管理和訪問攜帶在資源包中加載的專用模板。第 二應用開發(fā)層在分析和處理業(yè)務(wù)內(nèi)容呈現(xiàn)數(shù)據(jù)時，會通過模板管理模塊調(diào)用 需要的頁面框架模板，然后通過數(shù)據(jù)呈現(xiàn)模塊將其中各元素的屬性數(shù)據(jù)分別 設(shè)置到對應的頁面框架和控件中，并生成界面。第二應用開發(fā)層還包括的資源包管理模塊，負責對應用服務(wù)的資源包進 行管理。每個應用服務(wù)都可有對應的唯——個資源包，用以滿足該應用服務(wù) 的一些非通用性功能需求，也可用于提供在該應用服務(wù)中常用的數(shù)據(jù)內(nèi)容， 以減少實時下載時的負擔。資源包通常包含兩類數(shù)據(jù)靜態(tài)資源與可執(zhí)行資 源。靜態(tài)資源，主要指預先下載的圖片、文字(大文本)，甚至音頻等數(shù)據(jù) 資源。常見的靜態(tài)資源主要是圖片，例如重復使用到的背景、圖標等圖片文 件，可降低下載占用的時間以提高應用服務(wù)的界面內(nèi)容顯示效率?？蓤?zhí)行資 源，指的是釆用組件開發(fā)模式提供的若干動態(tài)庫文件，這些資源主要包括 專用模板(即專用界面效果實現(xiàn))及其他特殊功能實現(xiàn)。某一應用服務(wù)可以 完全采用專用模板實現(xiàn)服務(wù)界面，也可以部分依賴或完全不依賴專用模板(通過通用模板實現(xiàn)界面)，具體選擇視所能提供的通用模板的能力情況以及該 應用服務(wù)對界面的要求(例如游戲通常都需要獨立開發(fā)界面效果，無法采用 通用界面模板)。提供專用模板的動態(tài)庫文件必須提供符合模板庫統(tǒng)一規(guī)則 的接口。其他特殊功能主要指一些為了滿足特定應用服務(wù)某種目的或需求的 擴展功能，例如此應用服務(wù)專用的加密或檢驗算法。在資源包中，需要包括 與提供此類擴展功能的動態(tài)庫文件對應的接口描述文件，否則業(yè)務(wù)邏輯控制 數(shù)據(jù)無法使用這些擴展功能。另外，資源包中還可以包括對應應用服務(wù)的描 述信息和輔助信息。資源包中的各種資源，尤其可執(zhí)行資源，僅能被資源包對應的應用服務(wù) 使用，而不能開放給其他應用服務(wù)，主要出于安全性的考慮。這種限制機制 保障了某一個應用服務(wù)的專用功能不會被他用，同時也局限了專用功能可能 產(chǎn)生的刻意或非刻意危險性的作用面。而對于資源包及其中資源本身合法性 和安全性，則可以通過外部管理機制和手段進行監(jiān)管，例如服務(wù)發(fā)布管理系 統(tǒng)、驗證系統(tǒng)、數(shù)字簽名等等。資源包管理模塊需要負責資源包的下載及生命周期維護。在進入應用服 務(wù)前，需要預先將對應的資源包下載到客戶端。在應用服務(wù)執(zhí)行完畢后，即 可根據(jù)客戶端的本地策略決定該資源包的后續(xù)處理。當客戶端存儲空間緊張的條件下，無法長期保存應用^^務(wù)資源，那么可考慮采用使用后即清除的方 式處理，節(jié)省存儲空間。而當客戶端存儲空間允許，可考慮采用保存若干用 戶常用的應用服務(wù)的資源包的方式，便于提高應用服務(wù)的執(zhí)行效率。在后一 種情況下，需要通過在請求連接消息的消息流程控制數(shù)據(jù)的能力域中添加資 源包版本信息實現(xiàn)客戶端與服務(wù)器端的協(xié)商，檢測當前保存的資源包是否最 新，否則重新下載。具體的實施方式由實際條件和需求決定，同時兼顧用戶 友好性的目標。第二應用開發(fā)層所提供的INP協(xié)議對于每次的應用服務(wù)提供和執(zhí)行都必 須建立對應的服務(wù)會話(以下簡稱INP會話)，并通過該會話維護應用服務(wù)的 執(zhí)行過程和生命周期。在SIP協(xié)議中同樣存在會話概念(以下簡稱SIP會話)， 可以結(jié)合兩者并充分利用這一機制為INP會話提供維護支持。具體來說，當 客戶端準備開始一個應用服務(wù)時(通常由用戶操作觸發(fā))，客戶端向服務(wù)器端 發(fā)送一個SIP協(xié)議INVITE請求，該請求中除了攜帶SDP (會話描述協(xié)議， Session Description Protocol)協(xié)議數(shù)據(jù)(SDP Offer,具體含義請參閱RFC3261 和RFC3264)外，還包括INP協(xié)議數(shù)據(jù)(請求連接)；服務(wù)器端在成功建立 SIP會話的INVITE回復中，也同時攜帶SDP數(shù)據(jù)(SDP Answer,具體含義 請參閱RFC3261和RFC3264 )和INP數(shù)據(jù)(INP回復消息)，由此成功建立 SIP會話和INP會話。當需要結(jié)束會話時，其中一端向另一端發(fā)送一個SIP協(xié) 議BYE請求，該請求中包含INP協(xié)議的斷開連接消息，從而同時結(jié)束這個 SIP會話和INP會話。在會話過程中，INP協(xié)議的傳輸可以選擇性采用SIP通 道或者其他協(xié)議通道進行，具體由實施者決定。如果采用其他協(xié)議通道，該 通道必須在建立SIP會話時，通過SDP協(xié)議協(xié)商建立。無論采用哪種通道， SIP通訊平臺(IMS )對INP服務(wù)都具有有效的管理控制能力。對于INP會話 狀態(tài)的檢測和保持，既可以獨立采用INP協(xié)議的會話保持機制來實現(xiàn)，也可 以結(jié)合和依賴SIP協(xié)議原本的會話保持機制來實現(xiàn)。對應于上文所述的基于IP機頂盒實現(xiàn)交互增值業(yè)務(wù)的中間件系統(tǒng)，本發(fā) 明提供了基于IP機頂盒實現(xiàn)交互增值業(yè)務(wù)的方法。由于SIP通訊方法有標準 規(guī)范，具體參閱標準文檔，在此僅針對基于所述的第二應用開發(fā)層的通訊方 法。以下進行詳細闡述。如圖3所示，終端設(shè)備與服務(wù)器使用上述中間件系統(tǒng)交互消息，當IP機頂盒接收到用戶觸發(fā)某個應用服務(wù)的指令時，客戶端執(zhí)行應用服務(wù)(步驟一 ), 通過第二應用開發(fā)層構(gòu)造各種交互消息，實現(xiàn)終端設(shè)備與服務(wù)器進行交互。首先，第二應用開發(fā)層根據(jù)所述會話屬性信息和設(shè)備屬性信息構(gòu)造連接請求消息，將該消息發(fā)送至所述服務(wù)器(步驟二)，與所述服務(wù)器建立連接； 同時，可以在此請求消息中的能力域提供已獲得的服務(wù)資源包版本信息(如 果客戶端在上一次使用后對資源包進行了存儲)，用以檢測資源包是否更新； 服務(wù)器對接收到的消息進行處理分析(步驟三)，然后向客戶端發(fā)送成功回復 (步驟四)，在此回復中，可能攜帶服務(wù)資源包的最新版本號；客戶端接收到 服務(wù)器發(fā)送的成功回復后，第二應用開發(fā)層分析及處理該消息，與服務(wù)器段 之間建立服務(wù)會話(步驟五)；同時，客戶端會進行資源包版本檢測(步驟六)， 如果回復中攜帶的資源包版本號比本地存儲的資源包新，客戶端隨即通過資 源包管理模塊進行資源包的下載，待下載完畢后繼續(xù)后續(xù)流程。通常，在建 立會話及確認最新的資源包后，客戶端會發(fā)起獲取數(shù)據(jù)的請求消息，從服務(wù) 器獲取業(yè)務(wù)邏輯中的動作內(nèi)容和業(yè)務(wù)內(nèi)容(步驟七)；客戶端執(zhí)行業(yè)務(wù)邏輯(步 驟八)，且根據(jù)業(yè)務(wù)邏輯的定義顯示指定的業(yè)務(wù)內(nèi)容；客戶端對業(yè)務(wù)內(nèi)容進行 分析處理，根據(jù)業(yè)務(wù)內(nèi)容中的定義調(diào)用對應的頁面框架界面模板，并將內(nèi)容 數(shù)據(jù)設(shè)置到頁面框架模板及其中的控件模板中以生成業(yè)務(wù)界面，最后通過顯 示設(shè)備向用戶呈現(xiàn)及等待后續(xù)用戶指令(步驟九)。之后將觸發(fā)由業(yè)務(wù)邏輯決 定的各種流程(步驟十)，例如，在接收到用戶觸發(fā)的指令時，第二應用開發(fā) 層根據(jù)業(yè)務(wù)邏輯進行處理，其中可能包括引起通過動態(tài)可擴展接口描述層從 第一應用開發(fā)層獲取終端資源或調(diào)用終端功能(包括封裝為功能形式的服務(wù)， 如網(wǎng)絡(luò)電話功能/服務(wù))。其中的業(yè)務(wù)邏輯包括在適當時機或條件下將處理生成 的結(jié)果內(nèi)容發(fā)給服務(wù)器，以便服務(wù)器產(chǎn)生下一次的業(yè)務(wù)邏輯和/或業(yè)務(wù)內(nèi)容。 最后，根據(jù)用戶指令，客戶端生成和發(fā)送斷開消息至服務(wù)器(步驟八)，結(jié)束 當前服務(wù)會話和退出服務(wù)，服務(wù)器回復以確認服務(wù)會話結(jié)束(步驟九)。機頂盒客戶端發(fā)起觸發(fā)應用服務(wù)請求時，中間件系統(tǒng)的第二應用開發(fā)層生成會話 屬性信息，并根據(jù)終端設(shè)備的設(shè)備屬性信息構(gòu)造消息，并通過雙向傳輸協(xié)議實現(xiàn)與終端設(shè)備和服務(wù)器的通訊；會話建立后的后續(xù)消息都必須攜帶建立會 話時確定的會話屬性信息，用以區(qū)分會話連接及相關(guān)資源；通訊過程可以包 括建立會話連接的過程、會話維持和斷開的過程、以及應用服務(wù)的實現(xiàn)過程。以下列舉一個應用月l務(wù)的交互流程。通常機頂盒進入應用服務(wù)及退出應 用服務(wù)的流程是固定的。機頂盒執(zhí)行某一應用服務(wù)時，中間件系統(tǒng)的第二應 用開發(fā)層生成會話屬性信息，并連同設(shè)備屬性信息構(gòu)造消息，將該消息發(fā)送 至所述服務(wù)器，該消息經(jīng)過服務(wù)平臺(以IMS系統(tǒng)為核心)路由到提供該服 務(wù)的服務(wù)器，在路由檢測中IMS可對客戶端的訪問權(quán)限進行檢驗。服務(wù)器接 收到連接請求后，可以經(jīng)過一定的處理分析過程，如檢查服務(wù)器當前的客戶 端接入負荷是否過高、客戶端的設(shè)備類型(根據(jù)設(shè)備類型提供不同的數(shù)據(jù)內(nèi) 容或服務(wù)方式)等等，如果沒有問題則發(fā)送成功回復。即完成進入該服務(wù)的 流程，在機頂盒與應用服務(wù)器之間建立起一個服務(wù)會話。電視業(yè)務(wù)通常都需 要界面，故在連接成功后，機頂盒發(fā)起獲取控制服務(wù)邏輯的腳本及界面描述 數(shù)據(jù)等業(yè)務(wù)內(nèi)容(即業(yè)務(wù)邏輯控制數(shù)據(jù)及業(yè)務(wù)內(nèi)容呈現(xiàn)數(shù)據(jù))的請求。進入 服務(wù)流程后，將可能涉及很多不同形式的通訊流程，因為這段期間的通訊流 程是不確定的，由業(yè)務(wù)邏輯決定。常見的流程有獲取下一個或下一組界面的 業(yè)務(wù)內(nèi)容，機頂盒與服務(wù)器端之間的業(yè)務(wù)內(nèi)容交互(沒有界面切換)，以及由 業(yè)務(wù)邏輯中觸發(fā)的其他SIP服務(wù)流程，如在服務(wù)中發(fā)起了 一個VOIP的通話流 程。與這些不確定的通訊流程同時并存，即在服務(wù)會話過程中，長期存在的 是連接保持功能。連接保持的通訊流程可以是定時自動觸發(fā)的，不隨業(yè)務(wù)邏 輯的改變而改變，也不影響業(yè)務(wù)邏輯，主要為保持這個服務(wù)會話的有效性， 以避免其中一方意外失去聯(lián)系，而造成另外一方無法釋放相關(guān)資源。最后， 當服務(wù)完畢，或者用戶強行退出服務(wù)時，機頂盒將發(fā)起斷開連接的請求，服務(wù)器回復后，此服務(wù)會話結(jié)束。結(jié)束流程也是一個固定的通訊流程，例外的 情況是在正確結(jié)束會話之前，連接保持功能已經(jīng)檢測到其中 一方意外斷開， 即宣告服務(wù)會話意外結(jié)束，另外一方采取本地策略進行善后工作。本發(fā)明提供的中間件通訊方法及消息結(jié)構(gòu)，針對互動電視領(lǐng)域的需求和特點，避免了傳統(tǒng)WEB技術(shù)的數(shù)據(jù)臃腫、性能低及擴展難度大的缺點，所述 的第二應用開發(fā)層提供了一套面向業(yè)務(wù)邏輯和業(yè)務(wù)內(nèi)容的通用實施方法，便 于服務(wù)提供商根據(jù)需求迅速定制和開發(fā)出各類增值業(yè)務(wù)。以上所述的本發(fā)明實施方式，并不構(gòu)成對本發(fā)明保護范圍的限定。任何 在本發(fā)明的精神和原則之內(nèi)所作的修改、等同替換和改進等，均應包含在本 發(fā)明的權(quán)利要求保護范圍之內(nèi)。
權(quán)利要求
1、一種基于IP機頂盒實現(xiàn)交互增值業(yè)務(wù)的中間件系統(tǒng)，其特征在于，包括基于組件開發(fā)模式的第一應用開發(fā)層、動態(tài)可擴展接口描述層和基于解釋性數(shù)據(jù)的開發(fā)模式的第二應用開發(fā)層；所述第一應用開發(fā)層，包括信令服務(wù)控制模塊和可選配的功能模塊，所述信令服務(wù)控制模塊用于為信息傳輸及通訊服務(wù)提供雙向傳輸協(xié)議支持；所述可選配的功能模塊用于為應用服務(wù)提供功能支持；所述第二應用開發(fā)層，用于生成和處理交互式應用服務(wù)的消息；所述消息包含消息頭和消息體；所述消息頭包含消息類型信息及會話屬性信息，以及以下至少一種信息設(shè)備屬性信息、能力描述信息，以及輔助參數(shù)信息；所述消息體包括所述應用服務(wù)的業(yè)務(wù)邏輯和/或業(yè)務(wù)內(nèi)容；所述動態(tài)可擴展接口描述層，包括為所述第二應用開發(fā)層訪問所述第一應用開發(fā)層所提供的接口，所述第二應用開發(fā)層通過所述接口從所述信令服務(wù)控制模塊和功能模塊獲取對應的應用服務(wù)的功能支持。
2、根據(jù)權(quán)利要求1所述的基于IP機頂盒實現(xiàn)交互增值業(yè)務(wù)的中間件系統(tǒng)， 其特征在于所述第二應用開發(fā)層還包括數(shù)據(jù)呈現(xiàn)模塊，用于處理所述業(yè)務(wù) 內(nèi)容，并調(diào)用指定的界面模板生成圖形界面。
3 、根據(jù)權(quán)利要求2所述的基于IP機頂盒實現(xiàn)交互增值業(yè)務(wù)的中間件系統(tǒng)， 其特征在于所述界面模板包括頁面框架模板和控件模板；所述頁面框架模 板用以設(shè)定頁面中各控件模板的布局與關(guān)系，以及設(shè)定所述頁面的主體功能 和操作模式；所述控件模板用以設(shè)定具有特定功能和任務(wù)的頁面單元。
4、根據(jù)權(quán)利要求2所述的基于IP機頂盒實現(xiàn)交互增值業(yè)務(wù)的中間件系統(tǒng)， 其特征在于所述界面模板分為供所有應用服務(wù)使用的通用模板和供特定應 用服務(wù)使用的專用模板。
5、 根據(jù)權(quán)利要求2或3或4所述的基于IP機頂盒實現(xiàn)交互增值業(yè)務(wù)的中 間件系統(tǒng)，其特征在于所述第二應用開發(fā)層還包括模板管理模塊，負責管 理所述界面模板，所述數(shù)據(jù)呈現(xiàn)模塊在處理所述業(yè)務(wù)內(nèi)容時通過所述模板管 理模塊調(diào)用相應的界面模板。
6、 根據(jù)權(quán)利要求5所述的基于IP機頂盒實現(xiàn)交互增值業(yè)務(wù)的中間件系統(tǒng)， 其特征在于所述第二應用開發(fā)層還包括應用服務(wù)的資源包管理模塊，用于 管理每個應用^^務(wù)所對應的資源包；所述資源包中包含預先下載的至少一個 資源文件。
7、 根據(jù)權(quán)利要求6所述的基于IP機頂盒實現(xiàn)交互增值業(yè)務(wù)的中間件系統(tǒng)， 其特征在于所述資源文件包括所述專用模板。
8、 根據(jù)權(quán)利要求1所述的基于IP機頂盒實現(xiàn)交互增值業(yè)務(wù)的中間件系統(tǒng)， 其特征在于所述雙向傳輸協(xié)議為SIP協(xié)議。
9、 根據(jù)權(quán)利要求1所述的基于IP機頂盒實現(xiàn)交互增值業(yè)務(wù)的中間件系統(tǒng)， 其特征在于所述動態(tài)可擴展接口描述層的接口包括內(nèi)部功能接口與可擴展 功能接口 ；所述內(nèi)部功能為不依賴終端設(shè)備和平臺的固定功能。
10、 一種基于IP機頂盒實現(xiàn)交互增值業(yè)務(wù)的方法，其特征在于，接收到 用戶請求應用服務(wù)的指令時，中間件系統(tǒng)的第二應用開發(fā)層生成會話屬性信 息，并根據(jù)終端設(shè)備的設(shè)備屬性信息構(gòu)造消息，通過雙向傳輸協(xié)議實現(xiàn)與終 端設(shè)備和服務(wù)器的通訊;所述消息包括消息頭和消息體，所述消息頭用于承 載消息類型信息及會話屬性信息，以及以下至少一種信息設(shè)備屬性信息、 能力描述信息，以及輔助參數(shù)信息；所述消息體用于承載應用服務(wù)的業(yè)務(wù)邏 輯和/或業(yè)務(wù)內(nèi)容；通訊過程至少包括以下一個步驟所述第二應用開發(fā)層生成會話屬性信息，并連同所述設(shè)備屬性信息構(gòu)造消息，將該消息發(fā)送至所述服務(wù)器，請求與所述服務(wù)器所提供的應用服務(wù)建立服務(wù)會話和維護會話連接；在建立會話后，所述第二應用開發(fā)層根據(jù)所述用戶指令構(gòu)造消息，從所 述服務(wù)器獲取所述應用服務(wù)所對應的業(yè)務(wù)邏輯和/或業(yè)務(wù)內(nèi)容；將所述業(yè)務(wù)內(nèi) 容根據(jù)所述業(yè)務(wù)邏輯進行顯示；當接收到用戶下一步的指令時，所述第二應用開發(fā)層根據(jù)所述業(yè)務(wù)邏輯 進行處理。
11、 根據(jù)權(quán)利要求10所述的基于IP機頂盒實現(xiàn)交互增值業(yè)務(wù)的方法，其 特征在于，所述第二應用開發(fā)層獲取所述業(yè)務(wù)內(nèi)容之后還包括步驟對所述業(yè)務(wù)內(nèi)容進行分析處理，根據(jù)業(yè)務(wù)內(nèi)容中的定義調(diào)用對應的頁面 框架模板，并將內(nèi)容數(shù)據(jù)設(shè)置到頁面框架模板及所述頁面框架模板內(nèi)的控件 模板中，以生成業(yè)務(wù)界面。
12、 根據(jù)權(quán)利要求IO所述的基于IP機頂盒實現(xiàn)交互增值業(yè)務(wù)的方法，其 特征在于，所述雙向傳輸協(xié)議為SIP協(xié)議。
13、 根據(jù)權(quán)利要求IO所述的基于IP機頂盒實現(xiàn)交互增值業(yè)務(wù)的方法，其 成的結(jié)果內(nèi)容。
14、 根據(jù)權(quán)利要求IO所述的基于IP機頂盒實現(xiàn)交互增值業(yè)務(wù)的方法，其 特征在于所述第二應用開發(fā)層根據(jù)業(yè)務(wù)邏輯進行處理的過程至少包括以下其中一 個步驟所述第二應用開發(fā)層根據(jù)所述用戶的進一步指令和業(yè)務(wù)邏輯通過動態(tài)可 擴展接口描述層從所述第一應用開發(fā)層調(diào)用指定的功能接口 ，并產(chǎn)生相應的結(jié)果內(nèi)容；所述第二應用開發(fā)層將用戶指令和所述動作內(nèi)容以及所述會話屬性信息 構(gòu)造消息，發(fā)送至所述服務(wù)器，以獲取下一步的業(yè)務(wù)邏輯和/或業(yè)務(wù)內(nèi)容；所述第二應用開發(fā)層根據(jù)用戶的退出指令構(gòu)造消息，并發(fā)送至服務(wù)器， 結(jié)束當前服務(wù)會話，退出當前應用服務(wù)。
全文摘要
本發(fā)明提供的基于IP機頂盒實現(xiàn)交互增值業(yè)務(wù)的中間件系統(tǒng)，第一應用開發(fā)層包括信令服務(wù)控制模塊和可選配的功能模塊，信令服務(wù)控制模塊為信息傳輸及通訊服務(wù)提供雙向傳輸協(xié)議支持；可選配的功能模塊為應用服務(wù)提供功能支持；第二應用開發(fā)層，生成和處理交互式應用服務(wù)的消息；消息包含消息頭和消息體；消息頭包含消息類型信息及會話屬性信息，以及以下至少一種信息設(shè)備屬性信息、能力描述信息，以及輔助參數(shù)信息；所述消息體包括應用服務(wù)的業(yè)務(wù)邏輯和/或業(yè)務(wù)內(nèi)容；動態(tài)可擴展接口描述層，包括為第二應用開發(fā)層訪問第一應用開發(fā)層所提供的接口，第二應用開發(fā)層通過接口從信令服務(wù)控制模塊和功能模塊獲取對應的應用服務(wù)的功能支持。本發(fā)明還提供相應的方法。
文檔編號H04N21/478GK101252547SQ200810027390
公開日2008年8月27日 申請日期2008年4月14日 優(yōu)先權(quán)日2008年4月14日
發(fā)明者劉建平, 帥 廖, 朱建輝, 梅舒帆, 黃裕佳 申請人:廣州匯思通訊科技有限公司