CN101645789A - 基于上下文服务的会议通知***及方法 - Google Patents

Abstract

一种基于上下文服务的会议通知***和方法，***设有五个部件：客户端，服务总线，BPEL执行引擎，上下文服务模块和通信服务模块。会议通知方法是：用户从客户端输入会议通知请求后，服务总线接收该请求，转发至BPEL执行引擎，由其启动会议通知流程模块，该模块针对每位与会者分别执行会议通知服务：先调用上下文服务模块，获知以何种方式通知当前与会者及其联系方式和通知内容，再经由服务总线调用通信服务模块中的对应服务单元，向该与会者发出会议通知，并把通知结果返回给会议通知流程模块，由该模块判断是否通知下一位与会者，并在遍历全部与会者后，返回最终结果给客户端。本发明使用多种通信手段，结合语义推理技术，自动完成会议通知服务。

Description

基于上下文服务的会议通知***及方法

技术领域

本发明涉及一种基于上下文服务的会议通知***及方法，属于面向服务的体系结构(SOA技术)、语义网技术与浏览器/服务器(B/S技术)相结合的技术领域。

背景技术

统一消息***UMS(Unify Message System)是一种综合采用电话、E-mail、VoiceEmail、传真与呼机的面向统一的消息类型的一种电信技术方案，UMS有效地集成了呼叫和消息管理***，可以将互联网与电话、传真等服务结合，并相互取长补短，汇集了多种信息渠道的获取方式，使用户可以使用熟悉的公用电话交换网络***高效地控制和管理不同类型的信息。用户可通过PC机、电话机、传真机、PDA、手机等多种设备访问该***中的任何信息，而且仅需要一个唯一的标识号：UMID(统一信息号码)即可完成之。

目前，已经进入应用的统一消息***有：用勤科技(UDS)和AllyTalk，酷博自动短信语音通知***也具备多通信能力。但是，上述这些***均不是针对特定场合使用的***，只是提供一个通用平台。目前，也没有发现多媒体会议***能够在会议通知环节使用这些通用框架。

采用上下文感知的框架结构的典型应用有专利申请《基于上下文感知的智能门户***》(申请号：200810040699.9)；该***同时使用了语义网中针对上下文的本体推理技术。但是，该***不具有跨平台的特性，即其必须在相同环境下获取和处理上下文信息，不具有分布式应用的特点。

Web服务是一种建立可互操作的分布式应用程序的工作平台。Web服务平台是一套定义应用程序如何在Web上实现互操作性的标准，它作为一个组件模型，采用以Web服务为基础单元的面向服务的体系结构(SOA，Service-Oriented Architecture)，将应用程序中称为服务的不同功能单元通过设置在这些服务之间的接口和契约联系起来。采用中立方式定义的这些接口，独立于实现服务的硬件平台、操作***和编程语言，从而使得构建在该***中的各种服务能够以一种统一和通用的方式进行交互。在SOA中，进程是使用一组离散的服务创建的。业务流程执行语言(BPEL，Business Process ExecutionLanguage)就是用于控制这些服务的语言，它是一种使用XML编写的、用于自动化业务流程的编程语言，也被称作WSBPEL或BPEL4WS。BPEL广泛用于与Web服务相关的项目开发中，其优点为具有可移植性和能够有效保护投资。

语义网是能够根据语义进行判断的网络。简单地说，语义网是一种能够理解人类语言的智能网络，它不但能够理解人类的语言，而且还能够使人与电脑之间的交互可以像人与人之间那样轻松地交流。语义网中涉及到一个重要概念是本体论。简单的说，本体论是概念化的详细说明，一个本体往往是一个正式的词汇表，其作用是定义某一领域内的专业词汇和这些词汇之间的关系。目前，利用语义网中定义的本体进行推理还处于发展阶段，大部分基于描述逻辑的推理机只能够针对类层次进行一致性推理，对个体的推理支持性还不够。基于规则的推理功能虽然强大和灵活，但是因其本身不包含针对本体自身的逻辑推理，所以在使用时，不能充分发挥本体推理的优势。在现代语义网研究中，还涉及到对本体模块化的研究，这类研究集中于静态划分本体的过程，主要基于本体语义之间的关系。目前也没有针对实时的个体信息来划分本体的相关研究。

发明内容

本发明的目的是提供一种基于上下文服务的会议通知***及方法，该***使用面向服务的SOA架构，创建了一个会议通知BPEL流程，实现整个会议通知过程的完全自动化。会议预定的组织者只需填入少量必要的参数，就能在无人工参与的前提下，自动完成会议通知服务。

为了达到上述目的，本发明提供了一种基于上下文服务的会议通知***，其特征在于：该***设有下述五个部件：

以浏览器/服务器架构组建的客户端，作为人机交互界面，该部件用于获取用户设置的会议信息，并把该信息封装成简单对象访问协议SOAP消息后，采用超文本传输协议HTTP经服务总线转发给其它部件进行处理，并接收和显示返回的处理结果；

提供消息传输路由和转发的服务总线，用于接收客户端的输入信息并统一转换为规格化消息Normalized Message，转发给后续部件处理；设有消费者绑定组件和提供者绑定组件，前者用于侦听和接收来自客户端的HTTP请求并把该请求转换为规格化消息，然后路由给BPEL执行引擎；后者负责接收来自BPEL执行引擎中会议通知流程模块的调用web服务的规格化消息，并将该消息转换为用于调用web服务的SOAP消息后，分发给上下文服务模块或通信服务模块；

直接设置在服务总线上、相对独立的业务流程执行语言BPEL执行引擎，该部件直接采用规格化消息与服务总线进行交互，并设有会议通知流程模块，该模块存储有会议通知业务流程的控制脚本及相关配置文件；接收到客户端的请求消息后，BPEL执行引擎自动触发并执行会议通知业务流程模块中的控制脚本，按照业务流程调用相应的web服务；并在业务处理结束后，把会议通知结果返回给客户端；

为会议通知业务流程提供上下文感知的上下文服务模块，用于根据从客户端输入的会议和与会者的上下文信息以及语义网的本体推理和规则推理，决策以何种方式向与会者通知开会消息并合成相应的通知内容；设有三个子模块：业务逻辑单元、本体划分单元和模型推理单元；其中业务逻辑单元的功能是获取上下文信息，把该上下文信息发送给模型推理单元并把模型推理单元分析后的决策结果返回给会议通知流程模块；模型推理单元的功能是接收业务逻辑单元送来的上下文信息，并把该信息映射成对应的本体实例，再结合本体模型分别对其进行基于本体推理和规则推理的分析，决策以何种方式通知与会者；本体划分单元的功能是向模型推理单元提供与本体实例相对应的本体模型，将完整的多媒体会议本体转化为以邻接表形式存储的图，再基于扩展的广度优先算法和模型推理单元的本体实例进行本体切割，切除该多媒体会议本体的冗余部分，保留有效的子本体，形成相应的本体模型返回给模型推理单元，提高模型推理单元的推理效率；

执行会议通知服务操作的通信服务模块，该模块基于web服务技术，分别由封装为电子邮件Email服务、短信服务和语音服务的三个单元所组成，其中，Email服务单元利用简单邮件传输协议SMTP通过指定邮箱转发会议通知的电子邮件；短信服务单元基于运营商的短信网关应用程序编程接口API运行web服务，向移动用户发送会议通知的短信；语音服务单元采用从文本到语音TTS技术把会议通知文本转化成电脑合成语音，再通过会话发起协议SIP技术自动拨打与会者的电话，发出语音会议通知。

为了达到上述目的，本发明还提供了一种采用上述会议通知***的会议通知方法，其特征在于：客户端接收用户输入的会议通知请求后，把该请求发送到服务总线，服务总线再将其转发至BPEL执行引擎，并由执行引擎启动会议通知流程模块，该模块针对每位与会者分别执行下述会议通知服务：先调用上下文服务模块，获知以何种方式通知当前各个与会者以及与会者的联系方式和通知内容，再经由服务总线调用通信服务模块中的对应通知服务单元，向该与会者发出邮件、短信或语音的会议通知；并把每个会议通知结果返回给会议通知流程模块，由该模块判断是否通知下一位与会者，并在遍历全部与会者后，给客户端返回最终结果。

本发明基于上下文服务的会议通知***及方法，其主要功能是在多媒体会议开会前，根据上下文信息选择包括邮件、短信、电话等的相应通信方式，通知与会者的开会时间和相关会议信息。实际操作中，主要根据开会时间、通知时间、与会者联系方式等不同的上下文信息来制定按照时间优先顺序进行通知服务的策略。

本发明***使用了语义网中的相关技术，该技术结合了两类推理机：基于本体的推理机和基于规则的推理机。其中，通过基于本体的推理机，推导出类和属性的潜在从属关系；再通过基于规则的本体推理，获得具体业务逻辑的推理结果。因此，本发明的创新特点之一就是充分发挥两类推理机的优势，使得推理结果完备，而且灵活、可扩展。

为了提升使用本体推理技术的效率，本发明首创了一种动态切割大本体的本体模块化方法。该方法是结合图论的基础知识，根据对本体网络的建模，依照本体顶点间关系属性的权重，将大本体划分为基于上下文信息组的小本体模块，从而使得本体推理在保证其正确性的基础上，同时提高了推理的效率。

总之，本发明的主要创新优点和改进之处是：

应用的独创性：本发明作为多媒体会议***下完成会议通知服务的一个业务***，充分利用并结合了电信网和互联网的通信功能，实现了自动化服务和智能化服务的特色，在相关技术领域中属于应用上的一次创新。

服务的灵活性：该***是基于面向服务的体系架构SOA的web服务***，具有跨平台服务的优点，并且由于业务流程采用松散耦合的方式，在今后业务的扩展和修改上，会充分体现其高度的灵活性和宽泛的适应性。

业务的智能性：本发明使用了语义网技术中的本体推理技术，把如何通知与会者的策略选择问题，通过上下文信息本体化并进行推理机的双重推理来实现。这种基于本体的推理方式在于以较少的表达语句组成知识库，并蕴涵较多的信息；并且通过共享知识概念具有很好的网络互操作性以及***扩展性。

推理的高效性：为了提升本体推理的效率，本发明通过本体的切割过程，减少了推理机在推理过程中对于冗余信息的处理，从而提升了推理的效率。

附图说明

图1是本发明基于上下文服务的会议通知***结构组成示意图。

图2是本发明基于上下文服务的会议通知***执行会议通知操作流程图。

图3是本发明***的上下文服务模块的推理过程的流程图。

图4是本发明***的本体划分单元执行本体划分算法的操作过程流程图。

图5是完整的多媒体会议本体描述示意图。

图6是经过本体切割后的多媒体会议本体描述示意图。

图7是本发明模型推理单元使用两类推理机进行推理过程中的数据流图。

图8是本发明中解释本体推理中所使用的一些本体概念的结构图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面结合附图对本发明作进一步的详细描述。

参见图1，介绍本发明基于上下文服务的会议通知***的结构组成。

该***设有下述五个部件：

客户端是基于J2EE和浏览器/服务器架构构建的，该部件作为人机交互界面，用于获取用户输入设置的会议信息，该会议信息至少包括：会议主题，会议时间，会议发起者，与会者名单，该信息被封装成简单对象访问协议SOAP消息后，采用HTTP协议经服务总线转发给***的其它部件进行处理，并接收和显示返回的处理结果；

服务总线是提供消息传输路由和执行转发操作，用于接收客户端的输入消息并统一转换为规格化消息Normalized Message后，转发给后续部件处理；设有消费者绑定组件和提供者绑定组件，前者用于侦听和接收来自客户端的HTTP请求并把该请求转换为规格化消息，再路由给BPEL执行引擎；后者接收来自BPEL执行引擎中会议通知流程模块的调用web服务的规格化消息，并将该消息转换为调用web服务的SOAP消息后，分发给上下文服务模块或通信服务模块。

会议通知流程模块是在BPEL执行引擎中执行的过程控制脚本，该脚本里含有整个会议通知业务的详细描述。当客户端的请求消息到达时，会触发会议通知流程模块按照业务顺序调用相应的web服务，并把通知与会者的结果返回给客户端。BPEL执行引擎为服务总线内部相对独立的一个模块，它与服务总线间直接通过规范化消息进行交互。

业务流程执行语言BPEL执行引擎是相对独立地设置在服务总线上(图中虚线表示执行引擎部署在服务总线上，它与服务总线直接以规格化消息进行交互通信，不需要经过绑定组件)。并设有会议通知流程模块，该模块存储有整个会议通知业务流程的控制脚本及相关配置文件；接收到客户端的请求消息后，BPEL执行引擎自动触发并执行会议通知业务流程模块中的控制脚本，按照业务流程调用相应的web服务；在业务处理结束后，再把通知结果返回给客户端。

上下文服务模块是***的核心模块，为整个会议通知业务流程提供上下文信息处理：先根据从客户端输入的会议和与会者的上下文信息以及语义网的本体推理和规则推理，决策判断以何种方式向与会者通知开会消息。该上下文服务模块以web服务模式设置于***中，为提高响应速率，该模块的操作分为两个阶段：第一阶段初始化是提前从本体库中将所需要的本体读取到内存，并为之建立邻接表，以便快速划分本体；第二阶段运行过程是完成初始化后，动态实时维护内存中的数据，以便会议通知流程模块随时调用上下文服务。

该模块设有三个子模块：业务逻辑单元、本体划分单元和模型推理单元。其中业务逻辑单元设有上下文获取、结果查询和内容合成的三个子模块，该单元的功能是接收会议通知流程发起的服务调用，获取上下文信息，把该上下文信息发送给模型推理单元，合成会议通知内容，并把模型推理单元分析后的决策结果及通知内容返回给会议通知流程模块，再经其转发给通信服务模块。本体划分单元的功能是向模型推理单元提供与本体实例相对应的本体模型，将每个完整的多媒体会议本体转化为以邻接表形式存储的图，再基于扩展的广度优先算法和模型推理单元的本体实例进行本体切割，切除该多媒体会议本体的冗余部分，保留规模较小且有效的子本体，形成相应的本体模型返回给模型推理单元，提高模型推理单元的推理效率。模型推理单元的功能是接收业务逻辑单元送来的上下文信息，并把该信息映射成对应的本体实例，再结合本体模型分别对其进行基于本体推理和规则推理的分析，决策以何种方式通知与会者。模型推理单元中设有本体库和规则库。

通信服务模块由基本的邮件，短信，语音服务子模块组成，这些子模块按照面向服务的架构被封装成web服务，为上层提供基本的服务能力。Email服务使用JavaMail创建邮件用户代理，通过一个公共邮箱转发会议通知。短信服务把短信网关提供的API封装成web服务，可实现到移动和联通两类短信模拟网关的短消息发送功能。语音服务通过TTS技术(从文本到语音技术)把会议通知文本内容转化成电脑合成语音，再通过会话初始协议SIP技术主动拨打与会者的电话进行语音通知。

本发明的会议通知***的会议通知方法是：客户端接收用户输入的会议通知请求后，把该请求发送到服务总线，服务总线再将其转发至BPEL执行引擎，并由执行引擎启动会议通知流程模块，该模块针对每位与会者分别执行下述会议通知服务：先调用上下文服务模块，获知以何种方式通知当前与会者以及与会者的联系方式和通知内容，再经由服务总线调用通信服务模块中的对应通知服务单元，向该与会者发出邮件、短信或语音的会议通知；并把每个会议通知结果返回给会议通知流程模块，由该模块判断是否通知下一位与会者，并在遍历通知全部与会者后，给客户端返回最终结果。

参见图2，具体介绍上述会议通知流程的各个操作步骤：

步骤1，起始阶段：接收从客户端输入的服务请求参数(包括会议时间、主题和与会者名单等)，BPEL执行引擎启动会议通知流程模块，并执行初始化操作：将已通知的与会者人数、无法通知的与会者人数和总共已处理的人数三个统计变量都初始化赋值为零。

步骤2，循环通知判断：按照与会者名单列表逐一判断是否有未通知的与会者，如果有，则顺序执行步骤3；否则，跳转执行步骤8。

步骤3，调用上下文服务：上下文服务模块先把会议通知流程模块中存储的相关信息，包括此时要通知的与会者ID、会议时间、会议主题、会议***都赋值给上下文请求消息，再对该准备通知的与会者进行鉴权，查看其是否已在该***注册；若该与会者已经在该***注册，即***存有其相关信息，则上下文服务模块使用语义网中的本体推理技术，通过本体划分单元将切割后的本体模型送入模型推理单元，再由模型推理单元结合上下文实例判断以何种方式通知与会者，并由业务逻辑单元合成相应的通知文本：如果选用策略1，则顺序执行步骤4，如果选用策略2，则跳转执行步骤5，如果选用策略3，则跳转执行步骤6；若***没有该与会者信息，则不再进行本体推理，直接跳转执行步骤7。

步骤4，使用邮件通知服务：先赋值邮件发送参数，即把会议通知内容和目的地址都赋值给发送邮件请求消息sendMailRequest中，由具有发送邮件功能的Email服务单元利用JavaMail服务接口将会议通知内容发送到指定的SMTP服务器上，登录指定邮件服务器的域名、用户名及密码均可通过Email服务单元的配置文件进行配置；当邮件发送操作完毕后，跳转执行步骤7。

步骤5，使用短信通知服务：先赋值短信发送参数，即把手机终端号码和会议通知内容都赋值给发送短信请求消息sendMessageRequest中，由短信服务单元基于收发短信的Parlay短信网关转发给与会者；短信网关所需的用户名、密码以及短信特服号均可通过短信服务单元的配置文件进行调整；当短信发送完毕后，跳转执行步骤7。

步骤6，使用语音通知服务：先赋值语音发送参数，即把用户终端号码和会议通知的文本内容都赋值给呼叫与会者请求消息callParticipantRequest中，并调用语音合成技术，把上述通知的文本内容转化成音频形式后，再通过基于SIP协议的网络终端呼叫通知与会者后；顺序执行步骤7。

步骤7，处理上下文服务结果：若***有该与会者注册信息，则把已完成通知服务的该与会者及其通知方式记录到响应参数消息responseParameters中，再对总共已处理人数的统计变量加1后，返回步骤2，执行下一轮循环通知判断操作。若***没有该与会者注册信息，则先将无法通知的与会者人数加1，同时把该无法通知的与会者姓名填入相应的结果字符串后，返回步骤2，执行下一轮循环通知判断操作。

步骤8，响应请求，返回结果：通知完最后一个与会者后，把最终结果以下述两个列表方式返回给客户端：列表1是无法通知的与会者名单，列表2是已通知的与会者名单及其通知方式。

本发明方法步骤3中的调用上下文服务是本发明流程中的关键操作，它是由上下文服务模块担任操作的主要角色，并使用了语义网中用于形式化描述某一领域内的共享概念，以及这些概念之间关系的本体及本体推理技术。在语义网中，每个本体中的概念被理解为图Graph中的顶点vertex，各个概念之间的各种关系(包括继承、属性、实例化和规则等)被理解为各顶点之间的不同的边edge。本体推理技术用来处理上下文信息并得出有效的推理结果。

为了更有效地利用多媒体会议本体，本发明提出了一套基于本体的、由业务逻辑单元、本体划分单元和模型推理单元三大部分组成的推理框架。

参见图3，详细描述该步骤3在对准备通知的与会者通过鉴权后，上下文服务模块执行的推理操作过程。

(31)初始化：因为本体中的概念和各概念间的关系可用数据结构中的图模型来描述，而邻接表是实现图的最普遍方式。模型推理单元将已建成的多媒体会议本体以“主体-属性-属性值”的形式存储于本体库，并在本体划分单元中建立该本体对应的邻接表，以便使用数据结构中的图模型来描述该本体中的概念及各概念间的关系。

(32)接受请求消息和获取上下文：业务逻辑单元接收客户端输入的会议通知请求，其中包括会议的主题、时间、发起者、与会者名单各个参数；这些参数构成多媒体会议的上下文信息，并被包装为遵守SOAP协议的格式化消息；然后，业务逻辑层单元执行获取上下文的操作；所获取的上下文既有来自服务请求的各种参数，也有来自本体库中的包括联系方式和性别的与会者注册信息。

(33)将获取的上下文信息映射到本体：基于已建立的多媒体会议本体中的概念层次逐一进行映射，将上下文信息转换为基于具体业务场景添加相关参数构成的本体实例(individual)，完成本体映射后的上下文信息被称为数据模型；再在模块本体库中查看是否存在有相应映射的数据模型，如果有，则跳转执行步骤(35)；否则，顺序执行后续步骤，进行本体切割。

(34)根据已有的数据模型分割多媒体会议本体：根据已生成的邻接表数据、设定的门限值以及已有的数据模型进行扩展的广度优先搜索，保留与上下文信息相关的本体概念，剔除在推理中无关的其它本体概念，将多媒体会议本体分割为适宜推理机进行有效推理的子本体，以供本体划分单元使用。同时将这些子本体与数据模型的关系通过键值对方式存储于模块本体库，便于以后快速查找和使用。

(35)完成基于本体的基础推理：先根据已建立的数据模型和划分后的子本体，创建推理模型；再由本体推理机对该推理模型执行本体逻辑推理，将该初步推理结果仍以三元组形式保存在推理模型中；该过程以推理方式展示了该数据模型中未以显式表现出的内在逻辑，为后续规则推理打下基础。

(36)完成基于规则的推理操作：先读取存储于规则库的规则文件，再在上述本体推理结果的推理模型中，添加会议通知所需的业务逻辑内容，完成基于规则的推理；该规则是根据实际应用需求制定的具体业务细节；通过已有的规则引擎，进行二次推理后可得到最终的推理结果。完成该二次推理后，得到的最终推理结果和前述初步推理结果都存放在推理模型中。

(37)查询推理结果并合成通知内容：经过两轮推理后的推理模型，已具有了所需的推理结果。但是除了有用结果以外，模型中也存储了许多其它信息，因此使用SPARQL语言在推理模型中查询结果，获取每个与会者采用何种通知方式的推理结果；并结合所需的上下文信息、根据业务逻辑需求进行内容合成，组合构成会议通知文字内容。内容合成模块的一种中文模板如下：

“XXX先生/女士；您好！XXX邀请您参加X年X月X日X时X分的多媒体会议。会议主题为“XXXX”，请做好相应准备。”，其中的各个“X”字符表示需要通过上下文获取而填充的相关信息。

(38)给服务请求者返回推理结果：按照web服务规范，把推理结果返回给服务请求者，其中返回的参数包括有：通知服务的选择参数，各个与会者对应的通知内容及其联系方式，以及与会者是否注册的布尔变量；如果与会者未注册，则所述前三个参数均为空。

本体划分单元的目的是提升模型推理单元的工作效率和避免产生冗余信息。在模型推理单元中，多媒体会议本体是综合整个业务领域的一个大本体，并且随着对具体业务领域的深入建模，该本体会不断地扩展。然而，进行基于本体的模型推理时，既要获取上下文信息所对应的本体实例；也需要经过划分处理的本体模型。当推理机获取到包括本体模型和本体实例的两方面数据时，会随着该两个数据规模的扩大而增加执行时间。所以，在输入的本体实例信息量不变的情况下，要尽可能减少输入不必要的本体模型信息。在多媒体会议中，建立了一个从物理环境到会议过程以及底层通信能力的完整描述的本体，参见图5。当需要判断采取哪种通知服务时，推理过程中只需加入时间本体和与会者的本体信息，而可以省略其他的本体。这样可以减少推理机的推理时间，提高推理效率，减少不必要的推理冗余。另外，对于本体的划分，也有利于本体的日常维护和管理。

本发明采用的本体划分算法是以数据结构中传统的基于广度优先算法BFS作为基础，进行了下述两方面的改进。

对顶点的标记属性的改进：广度优先法BFS描述顶点的标记属性有三种：已标记、未标记和已遍历；扩展的BFS法的标记属性修改为关系深度值depth，表示该顶点与源顶点间的距离远近，深度值越高，表示其与源顶点的关系越紧密，每个顶点都有其对应的深度值。

对源顶点的数量的改进：广度优先法只考虑一个源顶点，扩展的BFS法要考虑多个源顶点；因此，遍历顶点时，既要判断该顶点是否已被遍历，还要考虑该顶点距离其它各个源顶点的距离远近，并选择其中与其距离最近的源顶点，由该源顶点计算其深度值。

在实施本体划分算法以前还有一个前提条件，就是建立基于多媒体会议本体的邻接表。邻接表中除了基本的本体概念及各概念间的关系外，同时还存储有该顶点与其它顶点间各个概念关系的边权值W。该边权值与深度值一致，同为非负整数。每个边权值的赋值大小取决于本体模型中各概念的下述四种关系的权重值：w_s(继承关系)，w_p(属性关系)，w_i(实例化关系)，w_tb(规则关系)；关系权重值越高，则边权值也越高。在进行深度优先搜索时，被遍历到的某个顶点V的深度值是执行该遍历操作的顶点U的深度值减去两个顶点U和V之间的边权值的差，即depth[v]＝depth[u]-W(u，v)。

参见图4，在上述步骤(34)中，本体划分单元执行的具体操作流程包括下列内容：

(341)遍历图中的非源顶点，即遍历排除上下文信息映射的本体概念所对应的源顶点以外的所有顶点，如果仍有非源顶点未被遍历，则设置该非源顶点的初始化值为0，表示此时的所有顶点与该非源顶点之间没有任何语义关系或语义深度；如果已遍历完非源顶点，顺序执行后续操作。

(342)遍历图中的源顶点，即判断是否还有源顶点未被遍历；如果有，则由用户自行初始化设置该源顶点的深度值，或由***动态调整其深度值，该深度值的数值大小是与所获取的子本体的大小相对应的；当深度值设置较大时，则所获取的子本体会较大；如果深度值设置较小时，则所获取的子本体较小；设置深度值后，将该源顶点添加到队列Q中；如果已遍历完源顶点，顺序执行后续操作。

(343)当图中所有的源顶点均被初始化设置并添加到队列Q后，对该队列Q进行遍历，即判断该队列Q是否为空，若不为空，则先取出排在该队列Q中的第一个顶点U后，顺序执行后续步骤；否则，跳转执行步骤(348)；

(344)遍历该顶点U的邻接表，即判断是否未遍历完该邻接表，若未遍历完，则顺序执行后续步骤；否则，返回执行步骤(343)；

(345)比较该顶点U与其邻接表中的未遍历的一个邻接点V的深度值大小，也即获取两者深度值的差，如果depth[v]＜(depth[u]-W(u，v))，则顺序执行后续步骤；否则，返回执行步骤(344)；

(346)修改该顶点V的深度值为：depth[u]-W(u，v)，因depth[v]＜(depth[u]-W(u，v))时，有下述两种可能：一是顶点V还未遍历到，其初始值为0；另一种情况是虽然遍历到顶点V，但其深度值不为0；这样，通过顶点U向其邻接点V赋予更高的深度值，可以保证遍历搜索的完整性；

(347)判断该顶点V是否已存储于队列Q中，如果顶点V是刚被遍历到，则队列Q中没有该顶点，则先把顶点V加入到该队列Q中，再返回执行步骤(345)；如果顶点V的深度值已被修改，则该顶点V已经被加入到队列Q中，直接返回执行步骤(345)；

(348)当遍历完该队列Q后，说明已根据语义深度完成了本体的切割，此时，把顶点中深度值大于0的各个顶点及其相互之间的关系边都筛选出来，形成与上下文信息所组对应的子本体。

参见图5，介绍和描述当前的多媒体会议信息完整的大本体。图示抽象了OWL语言中对于概念类的描述，除了包含有会议通知所需的主要本体外，还包含了会议发言所需的相关本体。例如，在该本体中，“会议”作为一个父类本体概念，其下有“即时会议”、“预约会议”两个子本体概念；两个子本体通过继承关系继承了父类本体“会议”的属性特征，如数据属性“主题”、“ID”以及对象属性“开会时间”、“持续时间”等；而“与会者”、“列席者”、“***”这些相对独立的本体概念，与“会议”本体间则是包含与被包含的属性关系。针对会议通知，所需的主要本体知识是“预约会议”、“开会时间”、“与会者”等本体概念，而“即时会议”、“结束会议”等本体概念则是相对冗余的概念。对于本体推理机，使用更大的本体将意味着会推导出更多的冗余信息。这样，不仅耗用存储空间资源，同时也会降低推理的速度，浪费时间资源。为了提升推理效率，通过本体划分单元，可以根据已知的上下文信息把多媒体会议大本体切割成合适大小的子本体后，再放入到推理机中进行推理。

经过本体切割后，得到简化的本体模型(参见图6所示)。图中的矩形斜条纹代表数据模型所对应的本体实例，也为该本体中的源顶点。以这些源顶点为中心进行扩展的广度优先遍历，可切除掉其中与业务逻辑不相关的冗余部分，如图5中的本体概念“人”的物理属性，以及“web服务”中除“通知服务”以外的其它子本体均被切除掉。图中虚线表示的是本体概念间的规则关系，该规则关系是由规则库中提取出的与会议通知相关的业务规则。例如其中的一条规则描述如下：“对于会议通知的请求时间比会议时间提前24小时的情况，在与会者具有邮件联系方式的条件下，则该通知请求所对应的通知服务为邮件服务”；该规则涉及到本体概念有“会议”、“开会时间”、“请求时间”、“与会者”、“邮箱”、“通知请求”、“邮件服务”以及“通知服务”。

参见图7，介绍本发明的整个推理过程中的数据流情况。为了实现上述推理结果，需要在推理过程中先后使用本体推理和规则推理的两类推理机进行推理。下面分别说明之：

先完成本体推理：其过程分为两种类型：基于本体概念(Class)的推理和基于本体实例(Individual)的推理。这些推理用于实现一致性的验证，以及对实例和类的检查。

以多媒体会议通知业务逻辑场景为例，在进行本体推理之前，会从本体映射模块中得到对应的下述本体实例：开会时间，(通知)请求时间，***信息，与会者信息及其对应的通知方式；以及同时为启动服务流程而生成的请求服务实例信息。这些本体实例与经过本体切割后的本体模型共同融入到本体推理机中。主要进行了下述四方面的推理和检查。

1.基数性(Cardinality)检查：会议本体中要求每个会议至少要有一个与会者，如果在上下文信息中没有包含需要通知的与会者，则本体推理机会认为这种推理存在不一致性，向上报出异常。

2.一致性检查：针对与会者的实例，凡是成为与会者的个体都不能再成为该会议中的另外两个角色，即与会者、会议***和列席者三者是互斥的角色。在本体推理中如果发现某个本体实例同时兼有上述两种角色，则推理机会向上报出异常。

3.数据类型检查：在联系方式中的手机和邮箱两种联系方式都为数据属性，而它们所对应的数据属性值分别为整型和字符串类型。如果在对本体实例进行赋值时，出现了错误的数据类型，则在本体推理过程中会被检测出来。

4.父类子类实例推理：在多媒体会议中，“通知时间段”作为“持续时间段”的子类，它的数据属性“持续时间值”是由两个时刻类“开会时间”和“请求时间”相减后构成的。在本体映射中，首先计算生成“持续时间值”实例，通过本体推理可以判断该实例是属于“紧急时间段”、“适中时间段”或者“宽裕时间段”本体概念的实例。“紧急时间段”、“适中时间段”以及“宽裕时间段”均为“持续时间段”的子类，它们的本体概念是这样定义的：凡是属于“持续时间段”的本体实例，该实例的数据属性“持续时间值”的数值落在对应的时间段范围，则该实例对应属于三个本体概念之一。详见图8。

5.属性推理：在“通知服务”与“通知请求”之间具有互逆的属性，即服务与被服务的关系。如果在个体申明中推理机得知“web服务”的本体实例a是服务于(serve)“web请求”的实例b，那么根据互逆属性的一一对应性质，就可以得到实例b向实例a发出“请求”(requestFor)的属性联系。

规则推理是根据不同的上下文信息，按照时间优先级进行通知服务的规则策略。具体策略见下表(其中的T1为开会时间，T2为通知时间，单位是小时)：

策略选择的标准主要有两种：时间效率和通信成功率。根据时间优先级，可以把通信方式按照离开会时间的紧迫程度进行排列。时间效率从低到高的排列：邮件的时间效率最低，其次是短信通知方式，最高效的是电话通知。按照通信效率看，服务会根据以前的一些统计记录，选择一种相对容易的通信方式，比如某与会者的联系方式没有手机，则只能采用邮件方式进行通知。

通过本体推理，为后续的规则推理打下了必要的基础。在推理过程中，有些潜在的上下文信息是必需通过本体推理获得的。而在规则推理中，只需要定义核心的业务描述即可。例如，多媒体会议通知***中，使用短信进行通知的规则判断需要两个前提条件：一是与会者具有手机联系方式，这个可以通过上下文本体映射获得；二是需要“通知时间段”的本体实例也属于“适中时间段”的本体实例，而该条件需要在本体推理中判断“通知时间段”本体实例的属性值“持续时间值”是否满足“适中时间段”大于2小时，小于24小时的条件判断。若满足，则使用邮件通知的规则推理中两个前提条件均满足，则整个规则也满足，便可得到由邮件通知该与会者的结论。

本发明已经进行了多次实施试验，试验的结果是成功的，实现了发明目

Claims (9)

1、一种基于上下文服务的会议通知***，其特征在于：该***设有下述五个部件：

以浏览器/服务器架构组建的客户端，作为人机交互界面，该部件用于获取用户设置的会议信息，并把该信息封装成简单对象访问协议SOAP消息后，采用超文本传输协议HTTP经服务总线转发给其它部件进行处理，并接收和显示返回的处理结果；

提供消息传输路由和转发的服务总线，用于接收客户端的输入信息并统一转换为规格化消息Normalized Message，转发给后续部件处理；设有消费者绑定组件和提供者绑定组件，前者用于侦听和接收来自客户端的HTTP请求并把该请求转换为规格化消息，然后路由给BPEL执行引擎；后者负责接收来自BPEL执行引擎中会议通知流程模块的调用web服务的规格化消息，并将该消息转换为用于调用web服务的SOAP消息后，分发给上下文服务模块或通信服务模块；

直接设置在服务总线上、相对独立的业务流程执行语言BPEL执行引擎，该部件直接采用规格化消息与服务总线进行交互，并设有会议通知流程模块，该模块存储有会议通知业务流程的控制脚本及相关配置文件；接收到客户端的请求消息后，BPEL执行引擎自动触发并执行会议通知业务流程模块中的控制脚本，按照业务流程调用相应的web服务；并在业务处理结束后，把会议通知结果返回给客户端；

为会议通知业务流程提供上下文感知的上下文服务模块，用于根据从客户端输入的会议和与会者的上下文信息以及语义网的本体推理和规则推理，决策以何种方式向与会者通知开会消息并合成相应的通知内容；设有三个子模块：业务逻辑单元、本体划分单元和模型推理单元；其中业务逻辑单元的功能是获取上下文信息，把该上下文信息发送给模型推理单元并把模型推理单元分析后的决策结果返回给会议通知流程模块；模型推理单元的功能是接收业务逻辑单元送来的上下文信息，并把该信息映射成对应的本体实例，再结合本体模型分别对其进行基于本体推理和规则推理的分析，决策以何种方式通知与会者；本体划分单元的功能是向模型推理单元提供与本体实例相对应的本体模型，将完整的多媒体会议本体转化为以邻接表形式存储的图，再基于扩展的广度优先算法和模型推理单元的本体实例进行本体切割，切除该多媒体会议本体的冗余部分，保留有效的子本体，形成相应的本体模型返回给模型推理单元，提高模型推理单元的推理效率；

执行会议通知服务操作的通信服务模块，该模块基于web服务技术，分别由封装为电子邮件Email服务、短信服务和语音服务的三个单元所组成，其中，Email服务单元利用简单邮件传输协议SMTP通过指定邮箱转发会议通知的电子邮件；短信服务单元基于运营商的短信网关应用程序编程接口API运行web服务，向移动用户发送会议通知的短信；语音服务单元采用从文本到语音TTS技术把会议通知文本转化成电脑合成语音，再通过会话发起协议SIP技术自动拨打与会者的电话，发出语音会议通知。

2、根据权利要求1所述的会议通知***，其特征在于：所述本体是语义网中用于形式化描述某一领域内的共享概念，以及这些概念之间关系的一个模型；每个本体中的概念被理解为图Graph中的顶点vertex，各个概念之间的包括继承、属性、实例化和规则的各种关系则被理解为各顶点之间的不同的边edge。

3、根据权利要求1所述的会议通知***，其特征在于：所述用户设置的会议信息至少包括：会议主题，会议时间，会议发起者，与会者名单。

4、根据权利要求1所述的会议通知***，其特征在于：所述上下文服务模块是以web服务模式设置于该***，为提高响应速率，该模块的操作分为两个阶段：第一阶段初始化是提前从本体库中将所需要的本体读取到内存，并为之建立邻接表，以便快速划分本体；第二阶段运行过程是完成初始化后，动态实时维护内存中的数据，以便会议通知流程模块随时调用上下文服务；其中的业务逻辑单元设有上下文获取、结果查询和内容合成的三个子模块，模型推理单元中设有本体库和规则库。

5、一种采用权利要求1所述的会议通知***的会议通知方法，其特征在于：客户端接收用户输入的会议通知请求后，把该请求发送到服务总线，服务总线再将其转发至BPEL执行引擎，并由执行引擎启动会议通知流程模块，该模块针对每位与会者分别执行下述会议通知服务：先调用上下文服务模块，获知以何种方式通知当前各个与会者以及与会者的联系方式和通知内容，再经由服务总线调用通信服务模块中的对应通知服务单元，向该与会者发出邮件、短信或语音的会议通知；并把每个会议通知结果返回给会议通知流程模块，由该模块判断是否通知下一位与会者，并在遍历全部与会者后，给客户端返回最终结果。

6、根据权利要求5所述的会议通知方法，其特征在于：所述方法包括下列操作步骤：

(1)起始阶段：接收从容户端输入的包括会议时间、主题和与会者名单的服务请求参数，BPEL执行引擎启动会议通知流程模块，并将已通知的和无法通知的与会者人数、总共已处理的人数三个统计变量都初始化赋值为零；

(2)循环通知判断：按照与会者名单列表逐一判断是否有未通知的与会者，如果有，则顺序执行步骤(3)；否则，跳转执行步骤(8)；

(3)调用上下文服务：上下文服务模块先把会议通知流程模块中存储的包括要通知的与会者ID、会议时间、主题及会议***信息赋值给上下文请求消息，再对该准备通知的与会者进行鉴权，查看其是否已在该***注册；若***有该与会者信息，则上下文服务模块使用语义网中的本体推理技术，通过本体划分单元将切割后的本体模型送入模型推理单元，由模型推理单元结合上下文实例判断以何种方式通知与会者，并由业务逻辑单元合成相应的通知文本：如果选用策略1，则顺序执行步骤(4)，如果选用策略2，则跳转执行步骤(5)，如果选用策略3，则跳转执行步骤(6)；若***没有该与会者信息，则不再进行本体推理，直接跳转执行步骤(7)；

(4)使用邮件通知服务：先赋值邮件发送参数，即把会议通知内容和目的邮箱地址赋值给发送邮件请求消息sendMailRequest中，由mail服务单元利用JavaMail服务接口将邮件信息发送到指定的邮件服务器上，再由该服务器转发给与会者；跳转执行步骤(7)；

(5)使用短信通知服务：先赋值短信发送参数，即把短信网关所需的用户名和密码、手机终端号码和会议通知内容都赋值给发送短信请求消息sendMessageRequest中，由短信服务单元基于运营商提供的短信网关把通知短消息发送给与会者；跳转执行步骤(7)；

(6)使用语音通知服务：先赋值语音发送参数，即把用户终端号码和会议通知的文本内容都赋值给呼叫与会者请求消息callParicipantRequest中，并调用语音合成技术，把上述通知的文本内容转化成音频文件后，再通过基于SIP协议的网络终端自动呼叫与会者，播放语音内容后；顺序执行步骤(7)；

(7)处理通知结果：若***有该与会者注册信息，则把已完成通知服务的该与会者及其通知方式记录到响应参数消息responseParameters中，再对总共已处理人数的统计变量加1后，返回步骤(2)，执行下一轮循环通知判断操作；若***没有该与会者注册信息，则先将无法通知的与会者人数加1，同时把该无法通知的与会者姓名填入相应的结果字符串后，返回步骤(2)，执行下一轮循环通知判断操作；

(8)返回结果响应：通知完最后一个与会者后，把最终结果以下述两个列表方式返回给客户端：列表1是无法通知的与会者名单，列表2是已通知的与会者名单及其通知方式。

7、根据权利要求5所述的会议通知方法，其特征在于：所述步骤(3)中，上下文服务模块在对准备通知的与会者通过鉴权后，进一步执行下列操作内容：

(31)初始化：模型推理单元将已建成的多媒体会议本体以“主体-属性-属性值”的形式存储于本体库，并在本体划分单元中建立该本体对应的邻接表，以便使用数据结构中的图模型来描述该本体中的概念及各概念间的关系；

(32)接受请求消息和获取上下文：业务逻辑单元接收客户端输入的会议通知请求，其中包括会议的主题、时间、会议***、与会者名单的各种参数；这些参数构成多媒体会议的上下文信息，并被封装为遵守SOAP协议的格式化消息；然后，业务逻辑层单元执行获取上下文的操作；所获取的上下文既有来自服务请求的各种参数，也有来自本体库中的包括联系方式和性别的与会者注册信息；

(33)将获取的上下文信息映射到本体，以供进行本体推理：基于已建立的多媒体会议本体中的概念层次逐一进行映射，将上下文信息转换为本体实例individual，完成本体映射后的本体实例被称为数据模型；获取该基于上下文的数据模型后，在模块本体库中查看是否存在有相应映射的数据模型，如果有，则跳转执行步骤(35)；否则，顺序执行后续步骤；

(34)根据已有的数据模型分割多媒体会议本体：根据已生成的邻接表数据、设定的门限值以及已有的数据模型进行扩展的广度优先搜索，保留与上下文信息相关的本体概念，剔除在推理中无关的其它本体概念，将多媒体会议本体分割为适宜推理机进行有效推理的子本体，同时将这些子本体与数据模型的关系通过键值对方式存储于模块本体库，便于以后快速查找；

(35)完成基于本体的基础推理：先根据已建立的数据模型和划分后的子本体，创建推理模型；再由本体推理机对该推理模型执行逻辑推理后，将该初步推理结果仍以三元组形式保存在推理模型中；该过程基于描述逻辑推理理论展示了该数据模型中未以显式表现出的内在逻辑，为后续规则推理打下基础；

(36)完成基于规则的推理操作：先读取存储于规则库的规则文件，再在上述本体推理结果的推理模型中，添加读取到的会议通知的业务规则，完成基于规则的推理；该规则是根据实际应用需求制定的具体业务细节；完成该二次推理后，得到的最终推理结果和前述初步推理结果都存放在推理模型中；

(37)查询推理结果并合成通知内容：使用SPARQL语言在推理模型中查询结果，将所需的上下文信息、即每个与会者采用何种通知方式的推理结果根据业务逻辑需求进行内容合成，再通过获取的上下文填充相关信息，组合构成会议通知文字内容；

(38)给服务请求者返回推理结果：按照web服务规范，把推理结果返回给服务请求者，其中的参数包括有：与会者通知方式，对应的通知内容及其联系方式，以及与会者是否注册的布尔变量；如果与会者未注册，则所述前三个参数均为空。

8、根据权利要求7所述的会议通知方法，其特征在于：所述扩展的广度优先法是在传统的广度优先算法BFS的基础上作了下述两方面的改进：

对顶点的标记属性的改进：广度优先法BFS对标记属性的描述有三种：已标记、未标记和已遍历；扩展的BFS法的标记属性为关系深度值depth，深度值为非负整数，表示该顶点与源顶点间的距离，深度值越高，表示其与源顶点的关系越紧密，每个顶点都有其对应的深度值；同时，该顶点中还存储有与其它顶点间表示各个概念关系的边权值W，该边权值W也是非负整数，每个边权值的赋值大小取决于本体模型中各概念的下述四种关系的权重值：继承关系、属性关系、实例化关系和规则关系，权重值越高，则边权值也越大；

对源顶点数量的改进：广度优先算法只考虑一个源顶点，扩展的BFS法要考虑多个源顶点；因此，遍历顶点时，既要判断该顶点是否已被遍历，还要考虑该顶点距离其它各个源顶点的距离，并选择与其距离最近的源顶点，由该源顶点计算其深度值；在进行深度优先搜索时，被遍历到的某个顶点V的深度值是执行该遍历操作的顶点U的深度值减去该两个顶点U和V之间的边权值的差，即depth[v]＝depth[u]-W(u，v)。

9、根据权利要求7所述的会议通知方法，其特征在于：所述步骤(34)中，本体划分单元进一步执行下列操作内容：

(341)遍历图中的非源顶点，即遍历排除上下文信息映射的本体概念所对应的源顶点以外的所有顶点，如果有非源顶点未被遍历，则设置该非源顶点的初始化值为0，表示此时的所有顶点与该非源顶点之间没有任何语义关系或语义深度；如果已遍历完非源顶点，顺序执行后续操作；

(342)遍历图中的源顶点，即判断是否还有源顶点未被遍历；如果有，则由用户自行初始化设置该源顶点的深度值，或由***动态调整其深度值，该深度值的数值大小是与所获取的子本体的大小相对应的；设置深度值后，将该源顶点添加到队列中；如果已遍历完源顶点，顺序执行后续操作；

(343)当图中所有的源顶点均被初始化设置并添加到队列后，对该队列进行遍历，即判断该队列是否为空，若不为空，则先取出排在该队列中的第一个顶点U后，顺序执行后续步骤；否则，跳转执行步骤(348)；

(344)遍历该顶点U的邻接表，即判断是否未遍历完该邻接表，若未遍历完，则顺序执行后续步骤；否则，返回执行步骤(343)；

(345)比较该顶点U与其邻接表中的未遍历的一个邻接点V的深度值大小，也即获取两者深度值的差，如果depth[v]＜(depth[u]-W(u，v))，则顺序执行后续步骤；否则，返回执行步骤(344)；

(346)修改该顶点V的深度值为：depth[u]-W(u，v)，因depth[v]＜(depth[u]-W(u，v))时，有下述两种可能：还未遍历到顶点V，其初始值为0；或者虽然遍历到顶点V，其深度值不为0；这样，通过顶点U向其邻接点V赋予更高的深度值，以保证遍历搜索的完整性；

(347)判断该顶点V是否已存储于队列中，如果顶点V是刚被遍历到，则队列中没有该顶点，则先把顶点V加入到该队列中，再返回执行步骤(345)；如果顶点V的深度值已被修改，则该顶点V已经被加入到队列中，直接返回执行步骤(345)；

(348)当遍历完该队列后，说明已根据语义深度完成了本体的切割，此时，把顶点中深度值大于0的各个顶点及其相互之间的关系边都筛选出来，形成与上下文信息所组对应的子本体。

Images