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服务单元利用基于Java语言的邮件应用程序JavaMail服务接口将邮件信息发送到指定的邮件服务器上，再由该服务器转发给与会者；跳转执行步骤(7)；
(5)使用短信通知服务：先赋值短信发送参数，即把短信网关所需的用户名和密码、手机终端号码和会议通知内容都赋值给发送短信请求消息sendMessageRequest中，由短信服务单元基于运营商提供的短信网关把通知短消息发送给与会者；跳转执行步骤(7)；
(6)使用语音通知服务：先赋值语音发送参数，即把用户终端号码和会议通知的文本内容都赋值给呼叫与会者请求消息callParticipantRequest中，并调用语音合成技术，把上述通知的文本内容转化成音频文件后，再通过基于SIP协议的网络终端自动呼叫与会者，播放语音内容后；顺序执行步骤(7)；
(7)处理通知结果：若系统有该与会者注册信息，则把已完成通知服务的该与会者及其通知方式记录到响应参数消息responseParameters中，再对总共已处理人数的统计变量加1后，返回步骤(2)，执行下一轮循环通知判断操作；若系统没有该与会者注册信息，则先将无法通知的与会者人数加1，同时把该无法通知的与会者姓名填入相应的结果字符串后，返回步骤(2)，执行下一轮循环通知判断操作；
(8)返回结果响应：通知完最后一个与会者后，把最终结果以下述两个列表方式返回给客户端：列表1是无法通知的与会者名单，列表2是已通知的与会者名单及其通知方式。
7.根据权利要求6所述的会议通知方法，其特征在于：所述步骤(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的各个顶点及其相互之间的关系边都筛选出来，形成与上下文信息所对应的子本体。