CN101237451B - Ip机顶盒的中间件***及其通讯的方法 - Google Patents

Abstract

本发明提供的IP机顶盒的中间件***以及使用该中间件***通讯的方法，该中间件***包括基于组件开发模式的第一应用开发层、动态可扩展接口描述层和基于解释性数据的开发模式的第二应用开发层；第一应用开发层包括信令服务控制模块和可选配的功能模块；第二应用开发层生成和处理信息传输中的消息；动态可扩展接口描述层，包括为所述第二应用开发层访问第一应用开发层所提供的接口，第二应用开发层通过接口从信令服务控制模块和功能模块获取对应的应用服务的功能支持。应用本发明能够实现客户端与服务端的丰富交互功能，并且便于服务提供商参与应用服务的开发，提供他们的积极性。

Description

IP机顶盒的中间件***及其通讯的方法

技术领域

本发明涉及IP机顶盒领域，尤其涉及IP机顶盒的中间件技术及IP机顶盒的中间件***的通讯方法。

背景技术

IPTV和数字电视在全球发展迅猛。在中国，各大运营商都在利用他们自身的网络全力推动家庭数字化。虽然现在的IPTV或数字电视的产品都比较成熟，但他们的都依然比较有局限性。目前的数字电视业务基于广播电视信号网络，这种单向网络仅能提供更多的频道、准点播(广播方式)及有限的交互服务，缺乏良好的盈利模式。而目前的IPTV产品则仍以提供单纯的实时点播服务为主，然而在IP网络上满足大量用户的点播需要是极其困难的，而且盈利模式单一。因此可见，目前广播电视信号网络缺乏足够强大的双向交互增值服务支持。增值业务是IPTV或数字电视发展的关键因素，要在IPTV或数字电视上发展增值业务，需要发挥服务提供商参与的积极性，才能让这个新兴的产业兴旺起来。

熟悉通讯领域的服务提供商能参与开发通讯服务，如电话会议、统一通讯、可视彩铃等等；而其他行业领域的服务提供商则能为用户提供更细致的其他服务，如电视银行、电视商务、电视政务、电视博客等等。相应的，目前这个领域的中间件技术存在基于组件的开发模式，包括基于二进制代码机制(如采用C/C++)和基于虚拟机中间代码机制(如采用JAVA)，对于满足应用需求几乎没有功能局限，但相对而言，开发复杂度和难度较大，不便于修改，而且服务发布方式单一。另外还存在一种基于WEB的开发模式，应用服务开发和发布以网站方式进行，由于基于解释性数据，开发难度较低，且便于修改，服务发布，但功能非常有限，扩展困难。虽然目前也有同时支持这两种模式的中间件产品，但完全分离，无法通过优势互补提供更多样化或更灵活的应用实现手段。

发明内容

本发明的目的在于提供一种IP机顶盒的中间件***及通讯的方法，能够实现机顶盒客户端与服务端的丰富交互功能，并且便于服务提供商参与应用服务的开发，提供他们的积极性。

本发明提供一种IP机顶盒的中间件***，包括：基于组件开发模式的第一应用开发层、动态可扩展接口描述层和基于解释性数据的开发模式的第二应用开发层；

所述第一应用开发层，包括信令服务控制模块和可选配的功能模块，所述信令服务控制模块用于为信息传输及通讯服务提供双向传输协议支持；所述可选配的功能模块用于为应用服务提供功能支持；

所述第二应用开发层，用于生成和处理交互式应用服务的消息；所述消息包含消息类型信息及承载会话属性信息，以及以下至少一种信息：设备属性信息、应用服务的业务逻辑、以及业务内容；

所述动态可扩展接口描述层，包括为所述第二应用开发层访问所述第一应用开发层所提供的接口，所述第二应用开发层通过所述接口从所述信令服务控制模块和功能模块获取对应的应用服务的功能支持。

本发明还提供一种IP机顶盒的中间件***进行通讯的方法，包括步骤：

接收到用户请求应用服务的指令时，所述中间件***的第二应用开发层生成会话属性信息，并根据所述IP机顶盒的设备属性信息构造消息，并通过双向传输协议实现所述IP机顶盒与服务器的通讯；通讯过程至少包括以下一个步骤：

所述第二应用开发层生成会话属性信息，并连同所述设备属性信息构造消息，将该消息发送至所述服务器，请求与所述服务器所提供的应用服务建立服务会话和维护会话连接；

在建立会话后，所述第二应用开发层根据该用户指令构造消息，从所述服务器获取所述应用服务所对应的业务逻辑和/或业务内容；将所述业务内容根据所述业务逻辑进行显示；

当接收到用户下一步的指令时，所述第二应用开发层根据所述业务逻辑进行处理。

本发明的中间件***中混合了两种开发模式，有机地结合了基于组件开发模式的第一应用开发层和基于解释性数据的开发模式的第二应用开发层，同时满足不同领域的服务/技术提供商的参与需求，并充分结合他们的优势进行互补，优化增值业务的开发模式，避免了现有技术要么功能限制太大要么技术门槛太高的弊端，也可以提高开发效率和吸引更多的参与者，从而能为用户提供各种多样化的增值业务。另外，本发明采用适应通讯领域发展需求和符合国际标准的SIP协议(Session Initiation Protocol，会话发起协议)作为双向传输协议承载交互消息，以使得客户端与服务器端之间具有极强的双向交互能力，避免了HTTP协议的单向缺点和私有协议的完善性不足等局限，并且通过单一协议同时为信息服务与通讯服务提供支持，为用户提供了丰富互动增值服务的平台。

附图说明

图1为本发明所述的中间件***的分层结构示意图；

图2为利用本发明的中间件***进行通讯的流程图。

具体实施方式

本发明所提供的技术方案可用于双向数字电视、IPTV等具有IP网络接入能力的嵌入式***机顶盒，通过本发明的中间件提供一个增值业务支撑平台，使不同领域的技术提供商和业务提供商一起参与提供增值业务，并各施其职。由于多媒体子***(IP Multimedia Subsystem，简称IMS)是面向下一代网络***的国际标准，具有周全的考虑及强大的扩展性，并提供了统一的通讯架构。采用本发明的终端设备(以下所述终端设备均指IP机顶盒)可接入IMS***，并利用IMS的优秀特性及标准的通讯流程应用于双向数字电视和IPTV等***，以简化开发难度以及增强通用性。

本发明所述的终端设备的客户端***分为以下层次：资源层、中间件层、应用层。

其中，资源层包括操作***及终端固有外设的驱动支持。

中间件层即本发明所述的中间件***，如图1所示，包含所涉及的三个子层：基于组件开发模式的第一应用开发层、动态可扩展接口描述层和基于解释性数据的开发模式的第二应用开发层。中间件层服务于应用层，为应用层提供接口，为应用层的扩展提供基础和支持。

其中，应用层通过利用中间件层的各种能力，根据服务提供商的要求定制应用，为最终用户提供各种增值业务。

本发明所述的中间件***包括基于组件开发模式的第一应用开发层和基于解释性数据的开发模式的第二应用开发层；二者均可以服务于交互增值业务开发，但是支持模式不同，通过互补结合两者的优势。以下分别阐述二者的实现过程。

基于组件开发模式的第一应用开发层可独立作为传统的中间件服务于应用层，为应用开发提供基于高级语言(如C/C++、JAVA等)的程序接口。采用这种开发模式实现的各种应用服务组件通过特定方式(例如预载、下载等)装载到机顶盒客户端***中。基于该层所提供的支持可以开发出多种复杂的应用服务，但由于该层需要基于嵌入式开发环境，技术门槛较高，且不便于远程发布应用服务以及应用服务的统一管理，因此该层主要面向专业技术领域的服务提供商，以及主要用于实现较为复杂的应用服务，例如电话会议/多方通话、游戏等在通讯逻辑、图形界面等方面有复杂或特殊需求的应用服务。

为了使采用本发明中间件***的终端设备可作为标准IMS客户端接入IMS***，并提供标准SIP(Session Initiation Protocol，会话发起协议)服务，第一应用开发层中通常包含具备符合标准的SIP信令服务控制模块(包括信令通讯控制模块及基本通讯服务模块)，与以IMS为核心的服务平台的联系均通过SIP协议完成，通过服务平台统一的通讯架构进行身份验证、权限控制、路由、计费、安全保障等。另外，第一应用开发层中还可以包括多个选配的功能模块，功能模块可以根据需要包括媒体库及图形库，可扩展外设支持库以及其他辅助模块。

信令通讯控制模块，负责维护和管理所有的SIP通讯流程，但可以不涉及通讯服务逻辑；

基本通讯服务模块，利用SIP通讯标准建立的一些基本通讯服务，为中间件提供必要或常用的功能支持，如VOIP、状态呈现等；

媒体库，提供实时媒体传输、媒体播放及音视频输入输出控制等功能；

图形库，提供图形用户界面(GUI)支持；

需要说明的是，功能模块并不必须或仅仅包含以上模块，可以根据实际需求确定，可能会减少、改变或者增加需要的模块。

基于第一应用开发层实现应用服务采用组件开发模式，就是说需要在嵌入式开发环境下，通过调用上述各模块提供的API，开发出新的功能或应用。采用的开发语言为高级程序语言(如C/C++及Java等)，具体由API决定。由于这种开发模式权限较大，限制较小，因此可以满足高复杂度及较高性能的需求。以这种模式开发的新功能或应用，可以通过将扩展包下载到机顶盒客户端本地由中间件***触发运行。

第二应用开发层基于解释性数据的开发机制，支持服务的远程发布，类似于WEB网站开发模式，应用服务器通过解释性数据(例如XML、HTML等)与终端交流，以此实现服务流程和提供服务内容。解释性数据并不受制于软硬件平台和嵌入式环境，也不局限于特定开发语言，因此应用开发具有很大的自由度。

基于第二应用开发层所实现的应用，通过以这种解释性数据所构成的消息提供业务。这些消息分为请求消息和回复消息两大类型，请求消息用于主动发起特定操作，而回复消息则用以回应请求消息的处理结果(成功或失败，以及更多的信息)。在一个实施例中，这种消息(包括请求与回复)可以通过SIP协议承载，即由SIP协议负责实现通讯传输功能以及相关的职能(例如认证、路由、安全等)。因此，采用这种解释性数据实现应用服务仅需要专注于业务逻辑，而不需要直接涉及通讯逻辑，从而通过分工原则缩小开发者的关注面，降低技术难度。本发明所述的解释性数据采用可扩展标记语言(Extensible Markup Language，简称XML)定义(为便于说明，在本发明中定义的这种数据格式命名为INP)，包括三种主要的数据内容类型：消息流程控制数据、业务逻辑控制数据、业务内容呈现数据。

其中，消息流程控制数据用以定义消息的主要功能，这些功能适用于所有应用服务，具有一般化的通用性。这些功能在消息流程控制数据中以不同的数据域表现，包括：设备域，用以描述终端设备的软硬件信息，例如软件版本等；方法域，用以描述消息的类型和作用，类型分为请求和回复两种，作用如请求连接(开始业务)、断开连接(结束业务)、获取数据、推送/发送数据以及连接保持(Keep-Alive)等；会话域，用以描述一个特定服务会话，便于区分不同的会话。在一个实施例中，可以将消息流程控制数据作为INP消息的消息头，而其他数据则作为消息内容，因此还包括内容域用以包含消息内容。

其中，业务逻辑控制数据用以定义业务逻辑，包括：动作内容，是在服务器端定义(应用服务发布时已经定义)，并传送至客户端，用以指导和控制客户端执行业务逻辑的逻辑流程和操作序列(如显示/切换界面、获取界面数据、获取用户输入数据、媒体播放、拨打/接听电话等等)；结果内容，作为动作内容的处理结果，是在客户端根据用户操作和业务逻辑动态生成，并传送回服务器端，用以确定和获得下一步的业务逻辑和/或业务内容。动作内容中包括功能调用操作，以调用第一应用开发层提供的功能。

其中，业务内容呈现数据用以定义业务界面效果以及提供业务内容。

动态可扩展接口描述层用以描述终端设备的功能接口，即终端设备可以被使用的功能，以及以何种方式被使用(包括方法或事件的名称、参数等)。

上文所述的第二应用开发层中提到业务逻辑需要通过调用所述的第一应用开发层所提供的终端本地功能，终端本地功能越丰富，第二应用开发层所能提供的能力和支持就越丰富灵活。然而不同终端设备支持的功能不相同，而且终端设备的功能也会扩展增加。在WEB技术中，客户端浏览器可支持的功能是预制固定的，并没有提供简便而且动态的扩展支持能力，这极大地局限了WEB技术的应用支持能力。另一方面，由于基于组件开发模式所提供的接口无法被解释性语言所直接访问，故需要通过一个接口转换层结合两个开发层的两种开发模式。

本发明的中间件提供动态可扩展接口描述层依赖和使用接口描述文件声明终端功能接口，这种文件中的内容是通过解释性数据定义的，以实现动态的扩展性，也便于被第二应用开发层使用。同时，动态可扩展接口描述层还必须包含接口转换实现模块，用以将第一应用开发层所提供的接口重新封装成可与接口描述文件相适应的接口形式。每个文件负责描述一组有关的接口，通过接口描述文件的目录结构及文件名即可定位到这一组接口。每个接口的描述需要包括接口的名称、输入/输出参数等详细的使用说明，这些描述可被接口转换模块识别和解释。

动态可扩展接口描述层所描述的接口分为内部功能接口与可扩展功能接口两大部分，内部功能指不依赖客户端设备和平台的差异而不同的固定功能，其它即属于可扩展部分。在第二应用开发层中声明一个终端设备功能调用时，可声明接口所属范畴，缺省时为调用内部功能，否则为调用可扩展功能。

上面所述的接口描述文件通过预置或连同升级包(包含升级的功能库及对应的接口描述文件)下载到终端设备本地。通过动态可扩展接口描述层，由第二应用开发层定义的逻辑流程就可以访问和使用这些接口，既可支持和适应不同的终端设备，也支持和适应客户端功能的扩展和升级。

基于所述的中间件***提供应用服务的一个实施例子如下：一个具压缩加密技术背景的技术提供商(以下简称A商)，基于所述第一应用开发层开发出一种数据压缩加密功能，并将此以适应中间件***的扩展包形式提供下载到机顶盒客户端，作为一个扩展的功能模块，用以为客户端增加此功能支持。而且此扩展包中携带所述功能的接口描述文件，用以声明这一功能的使用方法。而另一个原本已经基于第二应用开发层提供某种信息服务的服务提供商(以下简称B商)，通过修改/升级原有业务逻辑，加入调用上述的压缩加密功能，为原有应用服务增强其信息安全性。从此例可见，B商仍然专注于自身擅长的业务领域，通过A商的专业技术为其服务提供更强的支持；而同时，A商也仅专注于自身擅长的领域，并将其技术服务于不同的B商。由此充分体现出优势互补的意义。

上文所述的中间件***面向通讯服务，因此涉及的通讯流程多样化，然而由于采用国际标准，故基于SIP协议的通讯服务流程均符合标准，详细信息可参阅相关SIP协议标准资料。与本发明相适应的通讯***平台建基于IMS，其细节不在此陈述，具体请参阅IMS标准文档。在本发明的一个实施例中，为本发明所述的终端设备提供应用服务的应用服务器，需要以符合标准的方式接入IMS，常见为直接采用SIP协议接入。一方面可通过SIP协议直接提供应用服务(即基于第一应用开发层提供的应用服务，如VOIP)，另一方面也可以通过前面所述的INP解释性数据来提供应用服务(即基于第二应用开发层提供的应用服务)，具体选择哪种方式可根据服务提供商自身的能力和需求来决定。

对应于上文所述的嵌入式设备的中间件***，本发明提供了使用该中间件进行通讯的方法。由于SIP通讯方法有标准规范，具体参阅标准文档，在此仅针对基于所述的第二应用开发层的通讯方法。以下进行详细阐述。

终端设备与服务器使用上述中间件***交互消息，当IP机顶盒接收到用户触发某个应用服务的指令时，机顶盒执行应用服务(步骤一)。通过机顶盒的第二应用开发层构造各种交互消息，实现终端设备与服务器进行交互。

首先，第二应用开发层根据所述会话属性信息和设备属性信息构造连接请求消息，将该消息发送至所述服务器(步骤二)，与所述服务器建立连接，之后，通过根据会话属性信息和设备属性信息构造的消息维护会话连接；服务器对接收到的消息进行处理分析(步骤三)，然后向机顶盒发送成功回复(步骤四)，机顶盒接收到服务器发送的成功回复后，第二应用开发层分析及处理该消息，与服务器建立服务会话(步骤五)。通常，在建立会话后机顶盒会发起获取数据的请求消息，从服务器获取业务逻辑中的动作内容和业务内容(步骤六)，并向用户呈现服务界面及等待用户指令。之后将触发由业务逻辑决定的各种流程(步骤七)，例如，在接收到用户触发的指令时，根据业务逻辑进行处理，其中可能包括引起通过动态可扩展接口描述层从第一应用开发层获取终端资源或调用终端功能(包括封装为功能形式的服务，如网络电话功能/服务)。其中业务逻辑包括在适当时机或条件下将处理生成的结果内容发给服务器，以便服务器产生下一次的业务逻辑和/或业务内容。最后，根据用户指令，机顶盒生成和发送断开消息至服务器(步骤八)，结束当前服务会话和退出服务，服务器回复以确认服务会话结束(步骤九)。机顶盒发起触发应用服务请求时，中间件***的第二应用开发层生成会话属性信息，并根据终端设备的设备属性信息构造消息，并通过双向传输协议实现与终端设备和服务器的通讯；会话建立后的后续消息都必须携带建立会话时确定的会话属性信息，用以区分会话连接及相关资源；通讯过程可以包括建立会话连接的过程、会话维持和断开的过程、以及应用服务的实现过程。

以下列举一个应用服务的交互流程。通常机顶盒进入应用服务及退出应用服务的流程是固定的。机顶盒执行某一应用服务时，中间件***的第二应用开发层生成会话属性信息，并连同设备属性信息构造消息，将该消息发送至所述服务器，该消息经过服务平台(以IMS***为核心)路由到提供该服务的服务器，在路由检测中IMS可对客户端的访问权限进行检验。服务器接收到连接请求后，可以经过一定的处理分析过程，如检查服务器当前的客户端接入负荷是否过高、客户端的设备类型(根据设备类型提供不同的数据内容或服务方式)等等，如果没有问题则发送成功回复。即完成进入该服务的流程，在机顶盒与应用服务器之间建立起一个服务会话。电视业务通常都需要界面，故在连接成功后，机顶盒发起获取控制服务逻辑的脚本及界面描述数据等业务内容的请求。进入服务流程后，将可能涉及很多不同形式的通讯流程，因为这段期间的通讯流程是不确定的，由业务逻辑决定。常见的流程有获取下一个或下一组界面的业务内容，机顶盒与服务器端之间的业务内容交互(没有界面切换)，以及由业务逻辑中触发的其他SIP服务流程，如在服务中发起了一个VOIP的通话流程。与这些不确定的通讯流程同时并存，即在服务会话过程中，长期存在的是连接保持功能。连接保持的通讯流程可以是定时自动触发的，不随业务逻辑的改变而改变，也不影响业务逻辑，主要为保持这个服务会话的有效性，以避免其中一方意外失去联系，而造成另外一方无法释放相关资源。最后，当服务完毕，或者用户强行退出服务时，机顶盒将发起断开连接的请求，服务器回复后，此服务会话结束。结束流程也是一个固定的通讯流程，例外的情况是在正确结束会话之前，连接保持功能已经检测到其中一方意外断开，即宣告服务会话意外结束，另外一方采取本地策略进行善后工作。

以上所述的本发明实施方式，并不构成对本发明保护范围的限定。任何在本发明的精神和原则之内所作的修改、等同替换和改进等，均应包含在本发明的权利要求保护范围之内。

Claims (10)

1.一种IP机顶盒的中间件***，其特征在于，包括：基于组件开发模式的第一应用开发层、动态可扩展接口描述层和基于解释性数据的开发模式的第二应用开发层； 

所述第一应用开发层，包括信令服务控制模块和可选配的功能模块，所述信令服务控制模块用于为信息传输及通讯服务提供双向传输协议支持；所述可选配的功能模块用于为应用服务提供功能支持； 

所述第二应用开发层，用于生成和处理交互式应用服务的消息；所述消息包含消息类型信息及承载会话属性信息，以及以下至少一种信息：设备属性信息、应用服务的业务逻辑、以及业务内容； 

所述动态可扩展接口描述层，包括为所述第二应用开发层访问所述第一应用开发层所提供的接口，所述第二应用开发层通过所述接口从所述信令服务控制模块和功能模块获取对应的应用服务的功能支持。 

2.根据权利要求1所述的IP机顶盒的中间件***，其特征在于：所述双向传输协议为会话发起协议。 

3.根据权利要求1所述的IP机顶盒的中间件***，其特征在于：所述动态可扩展接口描述层的接口包括内部功能接口与可扩展功能接口；所述内部功能为不依赖终端设备和平台差异性的固定功能。 

4.根据权利要求1所述的IP机顶盒的中间件***，其特征在于：所述动态可扩展接口描述层包括至少一个接口描述文件，所述接口描述文件可预置或通过升级包/扩展包动态加载。 

5.根据权利要求1至4中任一项所述的IP机顶盒的中间件***，其特征在于，所述IP机顶盒为IPTV机顶盒或双向数字电视机顶盒。 

6.一种IP机顶盒的中间件***进行通讯的方法，其特征在于，包括步骤： 

接收到用户请求应用服务的指令时，所述中间件***的第二应用开发层生成会话属性信息，并根据所述IP机顶盒的设备属性信息构造消息，并通过双向传输协议实现所述IP机顶盒与服务器的通讯；通讯过程至少包括以下一个步骤： 

所述第二应用开发层生成会话属性信息，并连同所述设备属性信息构造消息，将该消息发送至所述服务器，请求与所述服务器所提供的应用服务建立服务会话和维护会话连接； 

在建立会话后，所述第二应用开发层根据该用户指令构造消息，从所述服务器获取所述应用服务所对应的业务逻辑和/或业务内容；将所述业务内容根据所述业务逻辑进行显示； 

当接收到用户下一步的指令时，所述第二应用开发层根据所述业务逻辑进行处理。 

7.根据权利要求6所述的IP机顶盒的中间件***进行通讯的方法，其特征在于，所述双向传输协议为会话发起协议。

8.根据权利要求7所述的IP机顶盒的中间件***进行通讯的方法，其特征在于，所述业务逻辑包括所述服务器生成的动作内容和所述机顶盒生成的结果内容。

9.根据权利要求8所述的IP机顶盒的中间件***进行通讯的方法，其特征在于：

所述第二应用开发层根据业务逻辑进行处理的过程至少包括以下其中一个步骤：

所述第二应用开发层根据所述用户的进一步指令和业务逻辑通过动态可扩展接口描述层从所述第一应用开发层调用指定的功能接口，并产生相应的结果内容； 

所述第二应用开发层将用户指令和所述动作内容以及所述会话属性信息构造消息，发送至所述服务器，以获取下一步的业务逻辑和/或业务内容； 

所述第二应用开发层根据用户的退出指令构造消息，并发送至服务器，结束当前服务会话，退出当前应用服务。 

10.根据权利要求6所述的IP机顶盒的中间件***进行通讯的方法，其特征在于，所述第二应用开发层定时向所述服务器发送包含所述会话属性信息的消息，以保持服务会话的有效性。 

Images