基于ip机顶盒实现交互增值业务的中间件系统及其方法

专利名称：基于ip机顶盒实现交互增值业务的中间件系统及其方法
技术领域：
本发明涉及嵌入式系统领域，尤其涉及用于机顶盒的中间件技术及实现 交互增值业务的方法。
背景技术：
IPTV和数字电视在全球发展迅猛。在中国，各大运营商都在利用他们自 身的网络全力推动家庭数字化。虽然现在的IPTV或数字电视的产品都比较成 熟，但他们的都依然比较有局限性。目前的数字电视业务基于广播电视信号 网络，这种单向网络仅能提供更多的频道、准点播(广播方式)及有限的交 互服务，缺乏良好的盈利模式。而目前的IPTV产品则仍以提供单纯的实时点 播服务为主，然而在IP网络上满足大量用户的点播需要是极其困难的，而且 盈利模式单一。因此可见，目前广播电视信号网络缺乏足够强大的双向交互 增值服务支持。增值业务是IPTV或数字电视发展的关键因素，要在IPTV或 数字电视上发展增值业务，需要发挥服务提供商参与的积极性，才能让这个 新兴的产业兴旺起来。目前这个领域最广泛的中间件技术之一是基于组件(或称构件)的开发 模式，包括基于二进制代码机制(如采用C/C++)和基于虛拟机中间代码机 制(如采用JAVA)。这种模式功能强大适应性强，但应用月l务的开发和分发 的复杂度和难度比较大。另外的一种常见技术是基于WEB的开发模式，由于 基于解释性数据，应用服务的开发难度较低，但功能局限，扩展困难，很难 适应对界面样式和界面逻辑有复杂或特殊要求的应用服务需求，也很难使应 用服务同时兼容不同的终端设备。虽然目前也有同时支持这两种模式的中间 件产品，但完全分离，无法通过优势互补提供更多样化或更灵活的应用实现手段，也无法有效地发挥解释性数据在应用服务开发中的作用。 发明内容本发明的目的在于提供一种基于IP机顶盒实现交互增值业务的中间件 系统及其方法，有利于同时满足两个不同领域的服务提供商的参与需求，有 利于优势互补。本发明提供一种基于IP机顶盒实现交互增值业务的中间件系统，包括 基于组件开发模式的第一应用开发层、动态可扩展接口描述层和基于解释性 数据的开发模式的第二应用开发层；所述第一应用开发层，包括信令服务控制模块和可选配的功能模块，所 述信令服务控制模块用于为信息传输及通讯服务提供双向传输协议支持；所 述可选配的功能模块用于为应用服务提供功能支持；所述第二应用开发层，用于生成和处理交互式应用服务的消息；所述消 息包含消息头和消息体；所述消息头包含消息类型信息及会话属性信息，以 及以下至少一种信息设备属性信息、能力描述信息，以及辅助参数信息； 所述消息体包括所述应用服务的业务逻辑和/或业务内容；所述动态可扩展4妾口描述层，包括为所述第二应用开发层访问所述第一 应用开发层所提供的接口 ，所述第二应用开发层通过所述4妄口从所述信令服 务控制模块和功能模块获取对应的应用服务的功能支持。本发明还提供一种基于IP机顶盒实现交互增值业务的方法，接收到用户 请求应用服务的指令时，中间件系统的第二应用开发层生成会话属性信息， 并根据终端设备的设备属性信息构造消息，通过双向传输协议实现与终端设 备和服务器的通讯；所述消息包括消息头和消息体，所述消息头用于承载消 息类型信息及会话属性信息，以及以下至少一种信息设备属性信息、能力描述信息，以及辅助参数信息会话属性信息、设备属性信息；所述消息体用 于承载应用服务的业务逻辑和/或业务内容；通讯过程至少包括以下一个步骤所述第二应用开发层生成会话属性信息，并连同所述设备属性信息构造 消息，将该消息发送至所述服务器，请求与所述服务器所提供的应用服务建 立服务会话和维护会话连接；在建立会话后，所述第二应用开发层根据所述用户指令构造消息，从所 述服务器获取所述应用服务所对应的业务逻辑和/或业务内容；将所述业务内 容根据所述业务逻辑进行显示；当接收到用户下一步的指令时，所述第二应用开发层才艮据所述业务逻辑 进行处理。本发明的中间件中结合了基于组件开发模式的第 一应用开发层和基于解 释性数据的开发模式的第二应用开发层，同时满足两个不同领域的服务提供 商的参与需求，并充分结合他们的优势进行互补，优化增值业务的开发模式， 避免了现有技术要么功能限制太大要么技术门槛太高的弊端，也可以提高开 发效率和吸引更多的参与者，从而能为用户提供各种多样化的增值业务。另 外，本发明采用双向传输协议承载交互消息，以使的客户端与服务器端之间 能够进行双向交互，为用户提供了丰富互动增值服务的平台。


图1为本发明所述的基于IP机顶盒实现交互增值业务的中间件系统的结 构框图；图2为本发明所述的第二应用开发层生成的消息的结构图；图3为本发明所述的基于IP机顶盒实现交互增值业务的方法的流程图。
具体实施方式
本发明所提供的技术方案可用于互动电视(包括双向数字电视、IPTV 等)具有IP网络接入能力的嵌入式系统机顶盒，通过本发明的中间件提供一个 增值业务支撑平台，使不同领域的技术提供商和业务提供商一起参与提供增 值业务，并各施其职。由于多媒体子系统(IP Multimedia Subsystem,简称IMS ) 是面向下一代网络系统的国际标准，具有周全的考虑及强大的扩展性，并提 供了统一的通讯架构。采用本发明的终端设备可接入IMS系统，并利用IMS的 优秀特性及标准的通讯流程应用于互动电视系统，以简化开发难度以及增强 通用性。本发明所述的终端设备的客户端系统分为以下层次资源层、中间件层、 应用层。其中，资源层包括操作系统及终端固有外设的驱动支持。其中，中间件层即本发明所述的中间件系统，包含所涉及的三个子层基于组件开发模式的第一应用开发层、动态可扩展接口描述层和基于解释性数据的开发模式的第二应用开发层。中间件层服务于应用层，为应用层提供接口，为应用层的扩展提供基础和支持。其中，应用层通过利用中间件层的各种能力，根据服务提供商的要求定制应用，为最终用户提供各种增值业务。基于组件开发模式功能强大、效能高，但基于解释性凄t据开发模式不依 赖于平台和嵌入式环境，也不依赖于特定高级开发语言的特点仍有具有很大吸引力，这种类似于WEB网站开发的方式更容易让服务提供者参与，使其专 注于应用的业务逻辑而不需要在专业技术领域(如嵌入式4支术和通讯技术等) 投入太多精力和资源。但传统WEB技术的开发模式所显现的局限虽然在个人 电脑领域得以緩解，但在嵌入式领域就特别明显。其中一方面通过解释性语 言实现界面效果的复杂性对终端的效能影响非常高，尤其对于资源有限性能要求高的嵌入式机顶盒；另一方面，浏览器支持的能力有限，标准以外的功 能通常通过浏览器插件实现，但是插件的开发通常依赖特定浏览器，而且资 源使用也受制于浏览器，因此技术实现复杂、繁瑣而且性能较低。由此可见， 采用更具弹性而且耦合性较低的方式为基于解释性数据开发模式提供扩展支 持非常重要，而且面向应用开发的解释性语言需要摆脱WEB模式传统思路的 约束。如图1所示，本发明所述的中间件系统包括基于组件开发模式的第 一应用 开发层和基于解释性数据的开发模式的第二应用开发层；二者均可以服务于 交互增值业务开发(即服务于客户端系统的应用层)，但是支持模式不同， 通过动态可扩展接口描述层结合两种模式，利用分工和互补原则摆脱传统模 式的制约，增强适应能力和扩展能力。尤其针对基于描述性凄t据的应用开发 方式，与现存的WEB技术相比，更适合于互动电视服务。以下阐述实现细节。基于组件开发模式的第一应用开发层类似于传统的中间件，为应用开发 提供基于高级语言(如C/C+十、JAVA等)的程序接口。基于这种传统的中间 件形式可获得强大的功能支持，但技术门槛较高。为了使釆用本发明中间件系统的终端设备可作为标准IMS客户端接入 IMS系统，并提供标准SIP服务，第一应用开发层中通常包含信令服务控制模 块，为信息传输及通讯服务提供双向传输协议支持。在一个实施例中，该模 块可以是符合标准的SIP信令服务控制模块(包括信令通讯控制模块及基本通 讯服务模块)，与以IMS为核心的服务平台的联系可以通过SIP协议完成，通 过服务平台统一的通讯架构进行身份验证、权限控制、路由、计费、安全保 障等。信令通讯控制模块，负责维护和管理SIP通讯流程，但可以不涉及通讯服 务逻辑；基本通讯服务模块，利用SIP通讯标准建立的一些基本通讯服务，为中间件提供必要或常用的功能支持，如VOIP、状态呈现等；另外，第一应用开发层中还可以根据实际需求包括其他功能模块，才能 为应用层提供足够的服务能力。动态可扩展接口描述层用以描述终端设备的功能接口 ，包括第一应用开 发层提供给第二应用开发层访问的接口 。这些接口描述终端设备的功能如何 被使用，以及以何种方式被使用(包括方法或事件的名称、参数等)。第二 应用开发层通过该接口从信令服务控制模块和功能模块获取对应的应用服务 的功能支持。上文所述的第二应用开发层需要通过调用所述的第 一应用开发层所提供 的程序接口，用以为基于解释性数据的应用开发提供功能支持，也就是说终端本地功能越丰富，通过第二应用开发层进行应用开发所能利用到能力和支 持就越丰富和灵活。然而不同终端设备支持的功能不相同，终端设备的功能 也会扩展增加。在WEB技术中，客户端浏览器并没有提供简便、动态、弹性 高、耦合性较低的扩展支持能力，这极大地局限了WEB技术的应用支持能力。 另 一方面，由于基于组件开发模式所提供的接口无法被解释性语言所直接访 问，故需要通过一个接口转换层结合两个开发层的两种开发模式，因此在本 发明中加入动态可扩展接口描述层，实现接口转换。本发明的中间件提供动态可扩展接口描述层依赖和使用接口描述文件声 明终端功能接口，这种文件中的内容可以通过解释性数据(例如XML)定义， 以实现动态的扩展性，也便于被第二应用开发层使用。同时，动态可扩展接 口描述层还通常包含接口转换实现模块，用以将第一应用开发层所提供的程 序接口重新封装成可与接口描述文件相适应的接口形式。每个文件负责描述 一组有特定关联关系的接口 (例如同一个模块的接口)，通过文件的目录结构及文件名即可定位到这一组接口 。每个接口的描述可以包^^妄口的名称、 输入/输出参数等详细的使用说明，这些描述可被接口转换模块识别和解释。动态可扩展接口描述层所描述的接口包括内部功能接口与可扩展功能接 口，内部功能指不依赖客户端设备和平台的差异而不同的固定功能，其它即 属于可扩展部分。在第二应用开发层中声明一个终端设备功能调用时，可声 明接口所属范畴，例如，缺省时为调用内部功能，否则为调用可扩展功能。上面所述的接口描述文件通过预置或连同升级包(包含升级的功能库及 对应的接口描述文件)下载到终端设备本地。通过动态可扩展接口描述层， 由第二应用开发层定义的逻辑流程就可以访问和4吏用这些接口 ，既可支持和 适应不同的终端设备，也支持和适应客户端功能的扩展和升级。第二应用开发层基于解释性数据的开发机制，支持服务的远程发布，服务器通过解释性数据(XML)与终端设备交流，以此实现应用服务流程和提 供应用服务内容。解释性数据并不受制于软硬件平台和嵌入式环境，也不局 限于特定开发语言，因此应用开发具有很大的自由度。基于第二应用开发层所实现的应用，通过以这种解释性数据所构成的消 息提供业务。第二应用开发层负责生成和处理交互式应用服务的消息；如图2 所示，这些消息包括消息头和消息体两个部分；消息头提供与不同的应用服 务有需求共性但又无直接关系的信息，消息头通常不能缺省而且有固定的组 成部分，消息体由消息流程控制数据组成；消息体携带与应用服务直接有关 的信息，根据不同的需求可能携带不同的内容，消息体通常由业务逻辑控制 数据和业务内容呈现数据构成；由于业务内容的呈现需由业务逻辑决定，因 此在消息体包含业务内容呈现数据时通常需要同时包含业务逻辑控制数据； 为了满足扩展应用需求，消息体中还可以包含其他类型的数据内容。结合图2, 参见图1,第二应用开发层包括以下模块消息头处理模块、逻辑处理模块、数据呈现模块、模板管理模块和资源包管理模块。这种消息分为请求消息和回复消息两大类型，请求消息用于主动发起特 定操作，而回复消息则用以回应请求消息的处理结果(成功或失败，以及更 多的信息)。这种消息(包括请求与回复)通过SIP协议承载，即由SIP协议 负责实现通讯传输功能以及相关的职能(例如认^〖正、路由、安全等)。因此， 采用这种解释性数据实现应用服务仅需要专注于业务逻辑，而不需要直接涉 及通讯逻辑，从而通过分工原则缩小开发者的关注面，降低技术难度。 一个Language,简称XML )定义(为便于说明，在本发明中定义的这种数据格式 命名为信息导航协议——Information Navigation Protocol,简称INP协议)，包 括三种主要的数据内容类型消息流程控制数据、业务逻辑控制数据、业务 内容呈现数据。消息流程控制数据用以定义消息的主要功能，这些功能适用于所有应用 服务，具有一般化的通用性。这些功能在消息中以不同的数据域表现，包括设备域、方法域、会话域、能力域和参数域。其中方法域和会话域是不可缺 省的数据域。设备域，用以承载设备属性信息，描述终端设备的软硬件信息，其中包 括设备型号信息和软件系统版本，以及可选的生产商信息等。方法域，用以消息类型信息，描述消息的类型和功能；其中包括消息类 型信息、消息功能信息，以及用以完成消息的匹配和说明作用的其他辅助信 息。消息类型信息，即标识当前消息包是请求消息或回复消息。消息功能信 息，对于请求消息的功能包括请求连接(开始业务)、断开连接(结束业务)、 获取数据、推送/发送数据等；对于回复消息的功能包括针对不同请求消息功 能的各种成功和失败的回应。为了匹配一个回复消息与其对应的请求消息，以便于完成相关的处理过程，因此也需要在方法域中包含描述此对应关系的 信息。在一个客户端与服务器端之间，可能会有多个相同功能的消息同时或 不同时传递，因此在方法域中也需要包含起区分作用的信息。除此之外，还 可能包含对消息的功能说明以及针对此功能的辅助参数等信息。上面提到的请求功能的意义如下请求连接，是客户端用以向服务器请求建立某一个应用服务的会话，并 请求执行此应用服务；断开连接，用以结束某一月良务会话，即结束对应的应用月良务；获取数据，是客户端用以主动向服务器请求，并将引起服务器发送下一 步的业务逻辑和业务内容，从而导致客户端的界面更换；发送数据，是服务器端收到获取数据请求后，用以将下一步的业务逻辑 和业务内容传递到客户端；推送数据，是客户端或者服务器端，在未引发当前业务界面更换的情况 下，用以向另外一方传递数据，从而实现在不影响当前界面的情况下继续业 务数据交换；为了让会话中的两端都能监测会话的有效性，还可以通过定期发送的会 话保持请求(Keep-Alive )确保两端都在有效状态，否则即表示会话意外中断； 为了满足以后的功能需求，可以定义和添加新的请求类型。会话域，用以承载会话属性信息，描述一个特定服务会话。 一个服务会 话表示终端执行一个应用服务从开始(连接成功)至结束(断开连接)的整 个过程，服务器可以同时为多个终端提供同一个应用服务，因此不同的终端 与服务器之间必须建立独立的服务会话。为了标识特定的会话以及便于区分 不同的会话，每个消息中携带会话属性信息。此外，为了保证会话属性信息 在客户端与服务器端都具有唯一性，因此生成完整的会话属性信息需要两端 共同参与。能力域，用以承载能力描述信息，用以描迷终端支持的能力，或者描述 服务器端应用服务对终端要求的能力，以便另一方能够判断是否可以继续进 行当前应用服务，其中的能力主要包括功能接口和界面模板。参数域，用以承载辅助参数信息，配合特定消息的功能需求提供额外的 数据，详细定义视具体情况而定。消息流程控制数据作为INP消息的消息头，为了满足未来的扩展需求，可以通过在消息头中增加新的数据域实现。而其他与具体应用服务直接相关的 数据则作为消息内容，因此消息中还可能包括内容域用以包含消息内容。消 息内容可能包括业务逻辑控制数据和/或业务内容呈现数据，同时针对扩展需 求也可能包含其它数据内容。第二应用开发层中包含的消息头处理模块，用 以生成或处理消息流程控制it据。业务逻辑控制数据用以定义业务逻辑，其中包括动作内容和结果内容。 业务逻辑是在设计和开发应用服务时定义，在应用服务部署时已经确定。这 套数据格式定义类似于一种脚本语言，然而它不仅包括从月艮务器端传送到客 户端并在客户端本地执行的处理流程，即动作内容，也包括客户端传送回服 务器端进行进一步处理的客户端执行结果数据，即结果内容。在一个业务逻 辑控制数据中只能包含动作内容或结果内容其中 一种。不同于一般的脚本语言(如JavaScript、 Python等)，这套数据格式并不包含复杂的程序逻辑功能， 例如条件判断、循环、函数定义等，主要是提供如何调用终端本地功能、控 制业务内容显示、获取用户操作以及返回结果等一些基本功能，目的是避免 重新创建一套新的复杂且功能完整的程序语言，而希望通过尽量简单的语法 实现如何组织本地功能满足业务逻辑的需求。同时，可通过嵌入其他具有完 整程序语言特性的脚本语言(如JavaScript等)，提供必要的复杂程序逻辑(即 前面所述的条件判断、循环、函数定义等等)。动作内容主要的部分为动作元素，每个动作元素用以定义一组调用终端 的本地功能(即第一应用开发层所提供的功能接口)的调用序列，其中的功 能包括事件订阅以及函数调用等。每个调用序列中的调用应该顺序且连贯执 行，这些调用所声明的接口 (名称以及参数、返回值等)应该与动态可扩展 接口描述层的接口描述文件中的描述一致。动作内容中还包括全局和局部的 变量元素，用以实现动能调用之间的数据存储和传递。动作元素之间可以互 相关联执行，也可以通过事件触发执行，同时也需要声明其中一个作为"入 口点"的动作元素(首先被执行)。每个动作元素中还可能包括需用参数， 用以声明当前动作元素执行完毕后所必需采集到的参数，用以生成结果内容。 每个动作元素执行后可能会立刻或者延后生成并向服务器端发送结果内容， 因此动作元素中需要声明具体的发送模式。为了满足复杂的程序语言特性以 辅助业务逻辑的实现，动作内容中还可以包括一个脚本元素，用以嵌入其他脚本语言(如JavaScript等)。结果内容，作为动作内容的处理结果，是在客户端根据用户操作和业务 逻辑动态生成，并传送回M^务器端，用以确定和获得下一步的业务逻辑和/或 业务内容。结果内容中包含一个或若干结果元素，每个结果元素对应一个动 作元素；每个结果元素中包含一个或若干个返回值，每个返回值对应动作元 素中的一个需用参数。结果内容传送至服务器端后，服务器端可根据应用服 务的业务逻辑进行处理，以确定相关的下一步骤的逻辑和内容并发送至客户 端，从而引发客户端的后续处理。第二应用开发层中包括的逻辑处理模块，负责对业务逻辑控制数据的解 析，根据规则执行动作内容，同时也根据动作内容中的描述自动生成结果内 容并传送回服务器端。在动作内容的执行过程中，需要特别处理多个动作序 列间的顺序和并发管理。业务内容呈现数据用以定义业务界面效果以及提供业务内容。与WEB技 术不同，业务内容呈现数据所定义的界面效果并不包括完整详细的界面实现， 而是第二应用开发层通过调用已储存于客户端的界面模板，并向其插入业务 内容数据，同时也可能包括一定程度上调整界面模板的样式效果。这种方法 特点在于，将界面实现最复杂的部分(包括界面主体功能、布局及逻辑等) 采用基于组件的开发模式，而业务内容呈现数据中仅携带样式效果定义数据 和业务内容数据，因此与采用HTML语言定义界面相比数据精简很多，处理和 显示效率也提高很多，同时基于组件开发模式开发的界面实现可具有复杂的 功能(例如动画界面效果或复杂的布局等等)，并不受制于HMTL语法以及浏 览器的支持能力。界面模板分为两类页面框架和控件。页面框架定义界面的整体布局、 功能及表现形式，不同的页面框架满足不同的需求，例如导航页面和详细内 容页面在布局和功能上的需求就非常不同；另一方面不同的表现形式也影响 界面效果，例如静态和动态的表现形式，列表式和转盘式的表现形式等等。 控件应被包含并使用于页面框架中， 一个页面框架可包含若干个控件，每种 控件都有特定的功能和作用，如多选列表控件、按钮控件、图文控件等等。 同一控件可被多个页面框架采用，而一个页面框架中也可以包含多个相同的 控件。页面框架与控件的功能由设计者定义，具有很高的自由度。界面模板 均可支持一定程度的可定制属性，如背景图属性、宽高属性等，具体支持的 属性视具体模板而定，使能根据实际的需求对表现效果提供一定可调整范围 和适应性，在业务内容呈现数据中可能包含对模板属性的设置数据。界面模 板以模板库的形式组织，即一个模板库中包括若干页面框架和控件，而且模 板库中的每一个页面框架和控件都必须具有唯一的名称，便于辨别和区分。 模板库可通过预置或动态加载的方式装载到客户端。当某一模板库已预置或 下载至客户端后，即可增加一系列页面框架和控件的支持，同时客户端也通过模板库的名称以及版本来确定对于应用服务界面的支持能力。此外， 一个 模板库中的页面框架可使用到另 一模板库中的控件，但必须同时支持两个模 板库才有效。在前面所述的消息流程控制数据中的能力域，可声明支持或要求的模板库(包括版本信息)。同时，界面模板也分为通用模板和专用模板。通用模板，即具有通用性 作用的界面模板，能够满足多种应用服务的需要，且能提供给所有应用服务 使用。但显而易见的是，通用性与特殊要求存在一定程度的矛盾，通用性模 板目的在于满足通常情况下的普通需求，并不能保障能够满足所有的，尤其 个性化、高复杂度或特殊的需求。通用模板以模板库的方式预置或升级下载 到客户端，其检测和升级的处理逻辑与具体应用服务无关。专用才莫^^反，即不 一定具有通用性作用，主要满足个性化需求，仅能为相关联的特定应用服务 使用。通过专用模板，可针对性满足特定应用服务的复杂需求，例如股票动 态走势图这类特殊要求的界面。专用模板的下载与关联的应用服务直接有关， 被包含在对应的服务资源包中下载(服务资源包将在后文介绍)。专用模板只需要根据具体应用服务的需求特别开发即可，但开发工作量和难度相对大一些，但能满足个性化要求；而对应的，通用模板要满足一定共性需求，因此必须通过摸索搜集出一定的界面需求模式，从而归纳出若干 具通用性意义的模板，以满足多个不同的应用服务的需要(或一定程度的需 要)。业务内容呈现数据主要包括框架元素和控件元素。框架元素通过模板名 称对应于特定页面框架模板，第二应用开发层在分析和处理业务内容呈现数 据时，通过该名称来调用或匹配对应的页面框架模板。控件元素通过模板名 称对应于控件模板，用以描述如何使用该控件模板。由于页面框架模板在设 计时已经确定包含了哪些控件模板，以及这些控件模板之间的关联关系，因 此在业务内容呈现数据中所罗列的控件元素需要与所属框架元素对应的页面框架模板包含的控件模板一一对应。控件元素中还可能需要声明所关联的事件及触发的动作元素。框架元素和控件元素都具有三类重要属性内置属性、 扩展属性和不可见数据属性。内置属性，指框架元素或控件元素最常用的或 最可能使用到的、具通用性的可定制属性，例如背景属性、控件的宽高属性 等，这类属性采用独立的标签显式声明。扩展属性，指由具体页面框架模板 或控件模板特別定义的个性化属性，这类属性没有各自专用的标签，在声明 时需要注明属性名称。不可见数据属性，用于在业务内容呈现数据中携带于 框架元素或控件元素有关联的数据，而且这些数据并不自动呈现在界面上， 仅供业务逻辑控制数据使用。第二应用开发层包含的数据呈现模块，用以实现对业务内容数据进行分析 处理及呈现；第二应用开发层包含的模板管理模块，用以负责管理预置的和 动态加载的模板库，也负责管理和访问携带在资源包中加载的专用模板。第 二应用开发层在分析和处理业务内容呈现数据时，会通过模板管理模块调用 需要的页面框架模板，然后通过数据呈现模块将其中各元素的属性数据分别 设置到对应的页面框架和控件中，并生成界面。第二应用开发层还包括的资源包管理模块，负责对应用服务的资源包进 行管理。每个应用服务都可有对应的唯——个资源包，用以满足该应用服务 的一些非通用性功能需求，也可用于提供在该应用服务中常用的数据内容， 以减少实时下载时的负担。资源包通常包含两类数据静态资源与可执行资 源。静态资源，主要指预先下载的图片、文字(大文本)，甚至音频等数据 资源。常见的静态资源主要是图片，例如重复使用到的背景、图标等图片文 件，可降低下载占用的时间以提高应用服务的界面内容显示效率。可执行资 源，指的是釆用组件开发模式提供的若干动态库文件，这些资源主要包括 专用模板(即专用界面效果实现)及其他特殊功能实现。某一应用服务可以 完全采用专用模板实现服务界面，也可以部分依赖或完全不依赖专用模板(通过通用模板实现界面)，具体选择视所能提供的通用模板的能力情况以及该 应用服务对界面的要求(例如游戏通常都需要独立开发界面效果，无法采用 通用界面模板)。提供专用模板的动态库文件必须提供符合模板库统一规则 的接口。其他特殊功能主要指一些为了满足特定应用服务某种目的或需求的 扩展功能，例如此应用服务专用的加密或检验算法。在资源包中，需要包括 与提供此类扩展功能的动态库文件对应的接口描述文件，否则业务逻辑控制 数据无法使用这些扩展功能。另外，资源包中还可以包括对应应用服务的描 述信息和辅助信息。资源包中的各种资源，尤其可执行资源，仅能被资源包对应的应用服务 使用，而不能开放给其他应用服务，主要出于安全性的考虑。这种限制机制 保障了某一个应用服务的专用功能不会被他用，同时也局限了专用功能可能 产生的刻意或非刻意危险性的作用面。而对于资源包及其中资源本身合法性 和安全性，则可以通过外部管理机制和手段进行监管，例如服务发布管理系 统、验证系统、数字签名等等。资源包管理模块需要负责资源包的下载及生命周期维护。在进入应用服 务前，需要预先将对应的资源包下载到客户端。在应用服务执行完毕后，即 可根据客户端的本地策略决定该资源包的后续处理。当客户端存储空间紧张的条件下，无法长期保存应用^^务资源，那么可考虑采用使用后即清除的方 式处理，节省存储空间。而当客户端存储空间允许，可考虑采用保存若干用 户常用的应用服务的资源包的方式，便于提高应用服务的执行效率。在后一 种情况下，需要通过在请求连接消息的消息流程控制数据的能力域中添加资 源包版本信息实现客户端与服务器端的协商，检测当前保存的资源包是否最 新，否则重新下载。具体的实施方式由实际条件和需求决定，同时兼顾用户 友好性的目标。第二应用开发层所提供的INP协议对于每次的应用服务提供和执行都必 须建立对应的服务会话(以下简称INP会话)，并通过该会话维护应用服务的 执行过程和生命周期。在SIP协议中同样存在会话概念(以下简称SIP会话)， 可以结合两者并充分利用这一机制为INP会话提供维护支持。具体来说，当 客户端准备开始一个应用服务时(通常由用户操作触发)，客户端向服务器端 发送一个SIP协议INVITE请求，该请求中除了携带SDP (会话描述协议， Session Description Protocol)协议数据(SDP Offer,具体含义请参阅RFC3261 和RFC3264)外，还包括INP协议数据(请求连接)；服务器端在成功建立 SIP会话的INVITE回复中，也同时携带SDP数据(SDP Answer,具体含义 请参阅RFC3261和RFC3264 )和INP数据(INP回复消息)，由此成功建立 SIP会话和INP会话。当需要结束会话时，其中一端向另一端发送一个SIP协 议BYE请求，该请求中包含INP协议的断开连接消息，从而同时结束这个 SIP会话和INP会话。在会话过程中，INP协议的传输可以选择性采用SIP通 道或者其他协议通道进行，具体由实施者决定。如果采用其他协议通道，该 通道必须在建立SIP会话时，通过SDP协议协商建立。无论采用哪种通道， SIP通讯平台(IMS )对INP服务都具有有效的管理控制能力。对于INP会话 状态的检测和保持，既可以独立采用INP协议的会话保持机制来实现，也可 以结合和依赖SIP协议原本的会话保持机制来实现。对应于上文所述的基于IP机顶盒实现交互增值业务的中间件系统，本发 明提供了基于IP机顶盒实现交互增值业务的方法。由于SIP通讯方法有标准 规范，具体参阅标准文档，在此仅针对基于所述的第二应用开发层的通讯方 法。以下进行详细阐述。如图3所示，终端设备与服务器使用上述中间件系统交互消息，当IP机顶盒接收到用户触发某个应用服务的指令时，客户端执行应用服务(步骤一 ), 通过第二应用开发层构造各种交互消息，实现终端设备与服务器进行交互。首先，第二应用开发层根据所述会话属性信息和设备属性信息构造连接请求消息，将该消息发送至所述服务器(步骤二)，与所述服务器建立连接； 同时，可以在此请求消息中的能力域提供已获得的服务资源包版本信息(如 果客户端在上一次使用后对资源包进行了存储)，用以检测资源包是否更新； 服务器对接收到的消息进行处理分析(步骤三)，然后向客户端发送成功回复 (步骤四)，在此回复中，可能携带服务资源包的最新版本号；客户端接收到 服务器发送的成功回复后，第二应用开发层分析及处理该消息，与服务器段 之间建立服务会话(步骤五)；同时，客户端会进行资源包版本检测(步骤六)， 如果回复中携带的资源包版本号比本地存储的资源包新，客户端随即通过资 源包管理模块进行资源包的下载，待下载完毕后继续后续流程。通常，在建 立会话及确认最新的资源包后，客户端会发起获取数据的请求消息，从服务 器获取业务逻辑中的动作内容和业务内容(步骤七)；客户端执行业务逻辑(步 骤八)，且根据业务逻辑的定义显示指定的业务内容；客户端对业务内容进行 分析处理，根据业务内容中的定义调用对应的页面框架界面模板，并将内容 数据设置到页面框架模板及其中的控件模板中以生成业务界面，最后通过显 示设备向用户呈现及等待后续用户指令(步骤九)。之后将触发由业务逻辑决 定的各种流程(步骤十)，例如，在接收到用户触发的指令时，第二应用开发 层根据业务逻辑进行处理，其中可能包括引起通过动态可扩展接口描述层从 第一应用开发层获取终端资源或调用终端功能(包括封装为功能形式的服务， 如网络电话功能/服务)。其中的业务逻辑包括在适当时机或条件下将处理生成 的结果内容发给服务器，以便服务器产生下一次的业务逻辑和/或业务内容。 最后，根据用户指令，客户端生成和发送断开消息至服务器(步骤八)，结束 当前服务会话和退出服务，服务器回复以确认服务会话结束(步骤九)。机顶盒客户端发起触发应用服务请求时，中间件系统的第二应用开发层生成会话 属性信息，并根据终端设备的设备属性信息构造消息，并通过双向传输协议实现与终端设备和服务器的通讯；会话建立后的后续消息都必须携带建立会 话时确定的会话属性信息，用以区分会话连接及相关资源；通讯过程可以包 括建立会话连接的过程、会话维持和断开的过程、以及应用服务的实现过程。以下列举一个应用月l务的交互流程。通常机顶盒进入应用服务及退出应 用服务的流程是固定的。机顶盒执行某一应用服务时，中间件系统的第二应 用开发层生成会话属性信息，并连同设备属性信息构造消息，将该消息发送 至所述服务器，该消息经过服务平台(以IMS系统为核心)路由到提供该服 务的服务器，在路由检测中IMS可对客户端的访问权限进行检验。服务器接 收到连接请求后，可以经过一定的处理分析过程，如检查服务器当前的客户 端接入负荷是否过高、客户端的设备类型(根据设备类型提供不同的数据内 容或服务方式)等等，如果没有问题则发送成功回复。即完成进入该服务的 流程，在机顶盒与应用服务器之间建立起一个服务会话。电视业务通常都需 要界面，故在连接成功后，机顶盒发起获取控制服务逻辑的脚本及界面描述 数据等业务内容(即业务逻辑控制数据及业务内容呈现数据)的请求。进入 服务流程后，将可能涉及很多不同形式的通讯流程，因为这段期间的通讯流 程是不确定的，由业务逻辑决定。常见的流程有获取下一个或下一组界面的 业务内容，机顶盒与服务器端之间的业务内容交互(没有界面切换)，以及由 业务逻辑中触发的其他SIP服务流程，如在服务中发起了 一个VOIP的通话流 程。与这些不确定的通讯流程同时并存，即在服务会话过程中，长期存在的 是连接保持功能。连接保持的通讯流程可以是定时自动触发的，不随业务逻 辑的改变而改变，也不影响业务逻辑，主要为保持这个服务会话的有效性， 以避免其中一方意外失去联系，而造成另外一方无法释放相关资源。最后， 当服务完毕，或者用户强行退出服务时，机顶盒将发起断开连接的请求，服务器回复后，此服务会话结束。结束流程也是一个固定的通讯流程，例外的 情况是在正确结束会话之前，连接保持功能已经检测到其中 一方意外断开， 即宣告服务会话意外结束，另外一方采取本地策略进行善后工作。本发明提供的中间件通讯方法及消息结构，针对互动电视领域的需求和特点，避免了传统WEB技术的数据臃肿、性能低及扩展难度大的缺点，所述 的第二应用开发层提供了一套面向业务逻辑和业务内容的通用实施方法，便 于服务提供商根据需求迅速定制和开发出各类增值业务。以上所述的本发明实施方式，并不构成对本发明保护范围的限定。任何 在本发明的精神和原则之内所作的修改、等同替换和改进等，均应包含在本 发明的权利要求保护范围之内。
权利要求
1、一种基于IP机顶盒实现交互增值业务的中间件系统，其特征在于，包括基于组件开发模式的第一应用开发层、动态可扩展接口描述层和基于解释性数据的开发模式的第二应用开发层；所述第一应用开发层，包括信令服务控制模块和可选配的功能模块，所述信令服务控制模块用于为信息传输及通讯服务提供双向传输协议支持；所述可选配的功能模块用于为应用服务提供功能支持；所述第二应用开发层，用于生成和处理交互式应用服务的消息；所述消息包含消息头和消息体；所述消息头包含消息类型信息及会话属性信息，以及以下至少一种信息设备属性信息、能力描述信息，以及辅助参数信息；所述消息体包括所述应用服务的业务逻辑和/或业务内容；所述动态可扩展接口描述层，包括为所述第二应用开发层访问所述第一应用开发层所提供的接口，所述第二应用开发层通过所述接口从所述信令服务控制模块和功能模块获取对应的应用服务的功能支持。
2、根据权利要求1所述的基于IP机顶盒实现交互增值业务的中间件系统， 其特征在于所述第二应用开发层还包括数据呈现模块，用于处理所述业务 内容，并调用指定的界面模板生成图形界面。
3 、根据权利要求2所述的基于IP机顶盒实现交互增值业务的中间件系统， 其特征在于所述界面模板包括页面框架模板和控件模板；所述页面框架模 板用以设定页面中各控件模板的布局与关系，以及设定所述页面的主体功能 和操作模式；所述控件模板用以设定具有特定功能和任务的页面单元。
4、根据权利要求2所述的基于IP机顶盒实现交互增值业务的中间件系统， 其特征在于所述界面模板分为供所有应用服务使用的通用模板和供特定应 用服务使用的专用模板。
5、 根据权利要求2或3或4所述的基于IP机顶盒实现交互增值业务的中 间件系统，其特征在于所述第二应用开发层还包括模板管理模块，负责管 理所述界面模板，所述数据呈现模块在处理所述业务内容时通过所述模板管 理模块调用相应的界面模板。
6、 根据权利要求5所述的基于IP机顶盒实现交互增值业务的中间件系统， 其特征在于所述第二应用开发层还包括应用服务的资源包管理模块，用于 管理每个应用^^务所对应的资源包；所述资源包中包含预先下载的至少一个 资源文件。
7、 根据权利要求6所述的基于IP机顶盒实现交互增值业务的中间件系统， 其特征在于所述资源文件包括所述专用模板。
8、 根据权利要求1所述的基于IP机顶盒实现交互增值业务的中间件系统， 其特征在于所述双向传输协议为SIP协议。
9、 根据权利要求1所述的基于IP机顶盒实现交互增值业务的中间件系统， 其特征在于所述动态可扩展接口描述层的接口包括内部功能接口与可扩展 功能接口 ；所述内部功能为不依赖终端设备和平台的固定功能。
10、 一种基于IP机顶盒实现交互增值业务的方法，其特征在于，接收到 用户请求应用服务的指令时，中间件系统的第二应用开发层生成会话属性信 息，并根据终端设备的设备属性信息构造消息，通过双向传输协议实现与终 端设备和服务器的通讯;所述消息包括消息头和消息体，所述消息头用于承 载消息类型信息及会话属性信息，以及以下至少一种信息设备属性信息、 能力描述信息，以及辅助参数信息；所述消息体用于承载应用服务的业务逻 辑和/或业务内容；通讯过程至少包括以下一个步骤所述第二应用开发层生成会话属性信息，并连同所述设备属性信息构造消息，将该消息发送至所述服务器，请求与所述服务器所提供的应用服务建立服务会话和维护会话连接；在建立会话后，所述第二应用开发层根据所述用户指令构造消息，从所 述服务器获取所述应用服务所对应的业务逻辑和/或业务内容；将所述业务内 容根据所述业务逻辑进行显示；当接收到用户下一步的指令时，所述第二应用开发层根据所述业务逻辑 进行处理。
11、 根据权利要求10所述的基于IP机顶盒实现交互增值业务的方法，其 特征在于，所述第二应用开发层获取所述业务内容之后还包括步骤对所述业务内容进行分析处理，根据业务内容中的定义调用对应的页面 框架模板，并将内容数据设置到页面框架模板及所述页面框架模板内的控件 模板中，以生成业务界面。
12、 根据权利要求IO所述的基于IP机顶盒实现交互增值业务的方法，其 特征在于，所述双向传输协议为SIP协议。
13、 根据权利要求IO所述的基于IP机顶盒实现交互增值业务的方法，其 成的结果内容。
14、 根据权利要求IO所述的基于IP机顶盒实现交互增值业务的方法，其 特征在于所述第二应用开发层根据业务逻辑进行处理的过程至少包括以下其中一 个步骤所述第二应用开发层根据所述用户的进一步指令和业务逻辑通过动态可 扩展接口描述层从所述第一应用开发层调用指定的功能接口 ，并产生相应的结果内容；所述第二应用开发层将用户指令和所述动作内容以及所述会话属性信息 构造消息，发送至所述服务器，以获取下一步的业务逻辑和/或业务内容；所述第二应用开发层根据用户的退出指令构造消息，并发送至服务器， 结束当前服务会话，退出当前应用服务。
全文摘要
本发明提供的基于IP机顶盒实现交互增值业务的中间件系统，第一应用开发层包括信令服务控制模块和可选配的功能模块，信令服务控制模块为信息传输及通讯服务提供双向传输协议支持；可选配的功能模块为应用服务提供功能支持；第二应用开发层，生成和处理交互式应用服务的消息；消息包含消息头和消息体；消息头包含消息类型信息及会话属性信息，以及以下至少一种信息设备属性信息、能力描述信息，以及辅助参数信息；所述消息体包括应用服务的业务逻辑和/或业务内容；动态可扩展接口描述层，包括为第二应用开发层访问第一应用开发层所提供的接口，第二应用开发层通过接口从信令服务控制模块和功能模块获取对应的应用服务的功能支持。本发明还提供相应的方法。
文档编号H04N21/478GK101252547SQ200810027390
公开日2008年8月27日 申请日期2008年4月14日 优先权日2008年4月14日
发明者刘建平, 帅 廖, 朱建辉, 梅舒帆, 黄裕佳 申请人:广州汇思通讯科技有限公司