背景技术
目前,服务的实现利用OWL-DL来描述概念及概念之间的关系,并将其作为数据表示的方法与数据存储的逻辑结构,虽然这样的策略使得服务网络系统的架构显得清晰,但也存在着一些目前尚难以克服的缺陷:
由于目前相关理论与技术发展的限制,对OWL-DL描述的概念进行解析在效率上还存在着很大的问题,因而为了提高服务网络的可用性,构建外围的性能优化工具是非常必要的;
限于现有工具存在的缺陷及相关技术的巨大瓶颈,服务网络数据模型在空间占用上和时间占用问题都非常严重;
现有的服务网络系统缺乏分布式计算的能力:
经文献检索发现,传统的支持并行程序设计与开发的系统和方法主要有:并行程序设计语言(HPF、Erlang、X10、Cilk)、并行编译器、高性能并行函数库(Intel的TBB、Microsoft TPL、IBMAmino)、可移植的多线程库(Pthread)、消息传递库(MPI、PVM)、自动并行化工具(OpenMP)、协同编程语言(Linda)、基于模板的并行程序设计方法(Frameworks)、并行组件编程方法(CCA)等等。上述现有技术中的这些系统和方法,有的抽象程度太低,需要并行程序设计人员过多的关注底层细节,如消息传递、同步、加减锁等,致使编程效率低,程序代码错误多;有的不能满足当前最新的应用和系统需求;有的存在可移植性、可扩展性差的缺陷;有的是因为面向特殊专用领域,如空气动力学模拟、求解偏微分方程等,因而通用性很差。
由于服务网络的概念刚刚被提出,针对于服务网络本身的研究还非常匮乏。本发明直接从服务网络系统的源码层面进行分析,结合服务网络的应用场景构建了一套服务网络性能优化方法。
并且,随着多核微处理器的普及,并行计算机走进了更加大众化的计算领域,研究并提出一套通用的并行程序设计方法和系统已经迫在眉睫。
发明内容
鉴于上述技术问题,本发明提出了一种服务网络性能优化系统,通过构建服务网络的优化工具及提供一整套基于服务网络的应用程序接口,来提升服务网络查询,编辑,注册,推理等行为的性能。
本发明提出一种服务网络性能优化系统,通过构建服务网络的优化工具及提供该优化工具基于服务网络的应用程序接口,实现优化工具与服务网络的自动挂接,其特征在于,该系统还包括:
服务网络缓冲区,包括多个缓冲表,每张缓冲表包括4个数据关系表:
数据关系表一存储服务的特征信息,数据关系表二存储服务之间的关系,数据关系
表三存储服务的接口信息,数据关系表四存储服务的参数信息;
同步守护线程,它包括两个独立的线程,负责从服务网络知识库同步信息到缓冲层的线程,和负责从缓冲层同步信息到服务网络知识库的线程,以保证服务网络中的数据与服务网络缓冲区的数据同步;
服务网络优化API,它是服务网络优化工具提供的一整套基于缓冲块的应用程序接口,这些API通过责任委托的机制与服务网络原有的API无缝结合;
API选择器,用于决定将用户的服务请求委托给优化API或者旧API的工具,其中服务网络旧API是指服务网络默认提供的一整套应用程序接口。
所述同步守护线程由3个线程构成,它们是:
服务网络优化层守护线程,用于创建与管理其他守护线程,以及系统的初始化操作,该线程作为主线程,它的操作包括同步创建负责从服务网络知识库同步信息到缓冲层的线程,和负责从缓冲层同步信息到服务网络知识库的线程;
服务网络知识库同步线程,该线程在运行过程中存在正运行态、空闲态以及休眠态,该线程定时通过外部唤醒信号或自动唤醒信号被从休眠态自动唤醒,每次唤醒之后会检查所有同步项的同步标志,如果有数据需要同步,则执行主线程所包括的同步操作,此时处于正运行态,否则检查下一项,此时处于空闲态,如此交替在正运行态和空闲态之间跳转,不断地进行同步/检查操作,处理完所有的同步项之后,该线程通过产生的外部休眠信号或自动休眠信号,自动转入休眠态;
缓冲层信息同步线程,该线程负责将服务网络知识库中的信息同步到缓冲层。
在没有用户选定的情况下,所述系统会采用API选择规则来决定使用优化API或者旧API,该选择规则的算法如下:
检查缓冲层数据的完整性,如不完整则使用原始API,算法结束;
检查优化层API是否能满足该调用请求,如不满足则使用原始API,算法结束;
调用优化层API处理请求。
与现有技术相比,本发明直接从服务网络系统的源码层面进行分析,结合服务网络的应用场景构建服务网络性能优化方法,并且该方法采用并行程序设计,进一步提高了服务网络的性能,大量提高服务网络信息交换速度,并对使用者透明。
具体实施方式
在不改变服务网络模型架构的前提下,通过即插即用动态加入的方式,提供以下的功能:
1、提供对服务网络信息的预解析工具,将预解析结果放入缓冲块中;
2、提供一整套基于缓冲块的应用程序接口(API),这些API通过责任委托的机制与服务网络原有的API无缝结合;
3、同时提供2个线程来智能的保证服务网络于缓冲块之间信息的同步。
本发明主要通过对服务网络内部信息进行预提取,并通过设计数据缓冲区的结构,对外提供完整的访问API来提升服务网络的服务网络查询、编辑以及注册性能。该本优化方法可作为服务网络的一个插件形式存在。为了实现本发明的目的,本发明通过构建3个相对独立的模块来实现。本发明中设计的内容及概念主要有以下几个部分:
模块1:服务网络缓冲区:
服务网络缓冲区主要包含以下一些内容及概念服务网络定义。由服务作为网络的节点,与服务之间的关系组成的三维立体铰链的网络。具体又可分为两层:抽象服务层和 具体服务层。
服务网络缓冲区(SNC)的定义。服务网络缓冲区是对服务网络信息的一个再整理,使得其中的数据易于解析,易于获取,但是会丢失一些语义信息。
模块2:同步守护线程:
优化守护线程(OD)的定义。优化守护线程是两个独立的线程,保证服务网络中的数据于服务网络缓冲区的数据同步。
模块3:服务网络优化API及API选择器
服务网络旧API(SNO API):服务网络默认提供的一整套应用程序接口。
服务网络新API(SNN API):服务网络优化工具提供的一整套应用程序接口,其功能是SNO API的子集。
API选择器:一个决定将请求委托给新或者旧API的工具。
服务网络API(SN API):对用户可见的API。
本发明以动态插入接口形式,为服务网络的核心部分-服务网络应用程序接口提供更快的访问处理性能,大大的提高了服务网络的可用性。
如图1所示,为本发明三个组成模块在服务网络API接口中的数据流向示意图。
下面通过具体实施例进一步说明本发明的技术方案。
本发明的服务网络缓冲区包括多个缓冲表,每张缓冲表包括4个数据关系表。
数据关系表一主要存储服务的大部分特征信息,每项服务的主要特征信息均包括服务ID、服务名、名空间、功能描述、商业类型、分类方式、,分类名、提供者公司、提供者联系方式、服务反应时间以及同步标志位等信息。
数据关系表二主要用来存储服务之间的关系,每一关系项均包括关系主体服务的ID,关系客体服务的ID、关系名、关系ID、同步标志位等信息。
数据关系表三主要用来存储服务的接口信息,每一接口项均包括有接口名称,接口描述,前置条件,服务影响效果,同步标志位等信息组成。
数据关系表四主要用来存储服务的参数信息。每一项包括参数名,参数类型,参数ID,对应的接口ID。
在每张缓冲表中,都会存在一个异步标志位:SYNED,用来表示该服务信息的当前状态,这里分为四种情况处理:
SYNED==0:该服务信息与本体数据库同步,无需更新操作。
SYNED==1:该服务信息被修改,等待守护进程将其与本体层数据库同步。
SYNED==2:该服务信息是由用户通过服务网络外部添加,还未同步到本体层中。
SYNED==3:该服务已被删除,但是删除的信息尚未同步到本体层中。
守护进程循环检测每张表的同步信息,根据标志位情况做出相应的处理。
同步守护线程由3个互相联系的线程构成。
其中,主线程名为服务网络优化层守护线程(Service Network Optimizer Daemon,SNOP),主要负责创建与管理其他守护线程,处理一些初始化的工作。SNOP的工作流程非常简单清晰,其流程图见图2,该流程包括同步创建负责从服务网络知识库同步信息到缓冲层的线程,和负责从缓冲层同步信息到服务网络知识库的线程,前者作为运行态线程1,后者作为运行态线程2。
本发明的第二个线程是服务网络知识库同步线程(Cache2OntoDaemon)。该线程的行为比较复杂,在运行过程中存在着多种状态:即正运行态、空闲态以及休眠态。该线程的状态转换图如图3所示:该线程每隔一定的时间会通过外部唤醒信号或自动唤醒信号被从休眠态31自动唤醒,每次唤醒之后会检查所有同步项的同步标志,如果有数据需要同步,则执行主线程所包括的同步操作,此时处于正运行态32,否则检查下一项,此时处于空闲态33,并可交替在正运行态和空闲态之间跳转,不断地进行同步/检查操作,处理完所有的同步项之后,线程通过产生的外部休眠信号或自动休眠信号,自动转入休眠态。
第三个线程是缓冲层信息同步线程(Onto2CacheDaemon)。该线程负责将服务网络知识库中的信息同步到缓冲层。该线程由于每次运行都需要耗费相当的资源,因此被设置为被动唤醒,以尽可能释放系统资源。该线程的状态转换图如图4所示。
本发明的服务网络优化API及API选择器的具体实施方式如下:
服务网络优化层提供一整套与服务网络本身对应的应用程序接口,这些应用程序接口完成与其功能相应的服务网络应用程序接口一致的功能,但是可以减少10倍以上的访问时间。
服务网络优化层提供用户指定和智能的API自动选择器,系统首先会根据用户的设定去决定是否使用优化层API来替代原始API,如果用户没有指定,系统会采用API选择规则来决定使用何种API。其算法如下:
检查缓冲层数据的完整性,如不完整则使用原始API,算法结束。
检查优化层API是否能满足该调用请求,如不满足则使用原始API,算法结束。
调用优化层API处理请求。