专利名称：服务网格溯源信息收集系统及方法
技术领域：
本发明涉及一种服务网格溯源信息收集系统及方法，尤其是一种能够实现，在服务网格中提供对溯源信息的全生命周期的支持，实现服务网格中对溯源信息的创建、记录、查询、管理四个阶段的操作的系统及方法。
背景技术：
为了实现网格系统的开放性和可扩展性，从结构上更方便的共享各种异构资源的能力，实现它们的互操作，全球性网格论坛(Global Grid Forum，简称GGF)在2002年联合提出了开放网格服务体系结构(Open Grid ServiceArchitecture，简称OGSA)框架，将面向服务及其协议的研发成为扩充网格功能的一致途径，通过服务间的交互完成网格资源的能力共享与协同工作。OGSA的提出推进了计算网格与Web服务技术的融合，明确了基于服务的网格框架，迅速得到了产业界和学术界的重视。
溯源信息是指在现实生活的一次实验应用(如应用程序执行)中，关于结果或数据如何获得的过程记录信息，实验完成后，其他用户可根据记录的溯源信息来验证实验的有效性、重现实验或重生产产品，分析探究应用规律。溯源信息的必要性已经在很多领域体现出来，在重要的分布式计算工程领域，每次应用都会有很多数据和计算资源在产生和销毁，例如，在一个化学实验的Web服务中，会产生大量的输入和输出数据，通过对这些数据进行分析，可以得到这次实验的执行时间，执行顺序等资料，对于分析化学反应得中间过程提供了更多有效信息。
网格从最初的元计算到计算网格再到现今的服务网格，经历了三个重要阶段，在现今的服务网格中，所有资源都封装为服务，通过服务调用来实现对资源的访问，在这些服务调用过程中产生大量溯源信息，但在多数情况下，这些信息没有得到充分利用。在面向服务体系结构(Service-OrientedArchitecture，简称SOA)中，“溯源信息”代表了服务的输出结果是如何产生的中间数据信息。
在现今各个使用溯源信息的领域，都没有提供对溯源信息全生命周期的操作支持，且还存在以下不足1.溯源信息采集没有提供统一的结构和通用的协议来记录数据，不支持其他通用的网格服务，扩展性弱；2.存储的数据没有统一的数据格式，不利于数据的存储和后期查询；3.溯源信息的调用与服务同步进行，时延较大。
溯源信息生命周期有如下4个阶段创建、记录、查询、管理，一个完整的溯源信息系统必须支持以上所有功能。
发明内容
本发明的主要目的在于提供一种服务网格溯源信息收集系统与方法，以实现在服务网格中提供对溯源信息的全生命周期的支持，实现服务网格中对溯源信息的创建、记录、查询、管理四个阶段的操作。
为此，本发明提供如下技术方案实现上述目的本发明提供了一种服务网格溯源信息收集系统，其特征在于包括存储模块，用于存储溯源信息；创建模块，用于创建溯源信息；记录模块，与创建模块、存储模块连接，用于将创建模块生成的溯源信息保存到存储模块中；查询模块，与存储模块连接，用于对网格环境容器节点的动态、静态信息进行实时监控，根据溯源信息统计服务调用频率；以及对链式服务调用和多路服务调用进行回溯；管理模块，与存储模块连接，用于管理所存储的溯源信息。
所述系统支持交互式溯源信息，并以可扩展标志语言(eXtensible Markup Language，简称XML)格式存储；所述的存储模块具体包括用于存储溯源信息的数据库和/或本地文件系统；所述的创建模块具体包括简单对象访问协议(Simple Object Access Protocol，简称SOAP)报文处理器，所述的SOAP报文处理器用于过滤提取SOAP报文；所述的记录模块具体包括缓存处理单元，所述的缓存单元用于完成溯源信息的记录和服务调用的异步进行；所述的查询模块具体包括XML文档寻址语言(XPath)封装解析器，用于封装XPath查询关键字；所述的服务网格溯源信息收集系统，还包括显示模块，与查询模块连接用于显示查询到的溯源信息。
本发明还提供了一种服务网格溯源信息收集方法，包括根据网格系统中溯源信息的具体表达方式，创建相关数据结构创建溯源信息的步骤；对创建溯源信息步骤产生的溯源信息进行组织，记录网格环境下的溯源信息的步骤；通过缓存处理单元存储溯源信息的步骤；包括回溯分析服务及状态统计服务的查询溯源信息的步骤；管理所存储的溯源信息的步骤。
本发明将溯源信息应用到网格环境中，提供对溯源信息全生命周期创建、记录、查询、管理的操作支持，溯源信息具有统一的数据格式，便于存储、查询与管理。
下面结合附图和具体实施例进一步说明本发明的技术方案。
图1为服务网格溯源信息收集系统结构图。
图2为服务网格溯源信息收集方法流程图。
图3为SOAP报文处理流程图。
图4为缓存单元执行流程示图。
图5为链式调用示意图。
图6为链式调用流程图。
具体实施例方式
实施例一、服务网格溯源信息收集系统结构如图1所示，以层次化结构实现各个功能模块底层存储模块支持数据库以及本地文件系统，负责对XML格式的溯源信息进行存储；中间层为各个功能模块创建模块利用SOAP报文处理器负责创建溯源信息；记录模块与创建模块和存储模块连接，用于对创建的溯源信息进行存储，同时利用缓存处理单元实现异步传输操作，提高记录效率；查询模块与存储模块连接，用于对已经存储的溯源信息进行查询，包括完成状态统计服务对网格环境容器节点的动态、静态信息进行实时监控，同时统计根据溯源信息统计服务调用频率及回溯分析服务对链式服务调用和多路服务调用进行回溯重现；XPath封装解析器用于对XPath查询关键字进行包装，实现面向普通用户的基于关键溯源信息关键属性的多层次应用程序编程接口(Application Programming Interface，简称API)；还包括管理模块与存储模块连接，用于对大量记录的溯源信息进行相应的管理操作，如对过期信息的删除等以及异常处理模块负责对系统出现的异常情况进行处理；上层为显示模块，存有网络环境拓扑视图、溯源信息管理视图、SOAP调试视图供不同级别用户使用。
实施例二、图2为服务网格溯源信息收集方法流程图，包括根据网格系统中溯源信息的具体表达方式，创建相关数据结构创建溯源信息的步骤；对创建溯源信息步骤产生的溯源信息进行组织，记录网格环境下的溯源信息的步骤；通过缓存处理单元存储溯源信息的步骤；包括回溯分析服务及状态统计服务的查询溯源信息的步骤；管理所存储的溯源信息的步骤。
还包括通过客户端工具显示查询到的溯源信息的步骤。
实施例三、基于实施例二，服务网格溯源信息收集方法可应用如下方式创建溯源信息，SOAP报文处理器负责对客户端请求和服务端回馈的SOAP报文进行过滤提取，并生成最终的XML格式的溯源信息。具体为当客户端调用服务或服务反馈信息时，SOAP报文处理器首先对服务配置信息进行预处理，判断服务是否具有溯源信息配置信息，如果服务开发人员希望所开发的服务不需要对溯源信息进行记录，则不进行任何操作，直接将SOAP消息发送到客户端或服务端；如果服务具有溯源信息配置信息，则进行相应处理，然后开始对SOAP报文进行提取处理，并开始创建一次溯源信息记录。
为了方便对服务添加溯源配置信息，SOAP报文处理器只需对服务配置文件进行处理，而无需对服务本身细节信息进行考虑。在此，SOAP报文处理器负责解析“Provenance StoreP_Store_URL_Value”这样的名值对(名ProvenanceStore表示服务配置对应的Parameter，值P_Store_URL_Value表示服务指定的溯源信息仓库URL地址)，SOAP报文处理器在判定服务配置信息中含有“ProvenanceStore”参数后，会对其值进行处理，首先判定溯源信息仓库统一资源定位符(Uniform Resource Location，简称URL)是否为空，如果为空，则设定溯源信息仓库地址为容器默认配置，否则，设定溯源信息仓库地址为该URL，具体处理流程如图3所示
步骤11、客户端发生请求或服务端发生反馈时，读取服务配置文件信息；步骤12、解析配置文件信息；步骤13、判断服务中是否具有溯源信息配置文件，若有则执行步骤14；若没有，则创建溯源信息结束；步骤14、解析溯源信息仓库地址URL；步骤15、判断溯源信息仓库URL是否为空，若为空则设定溯源信息仓库地址为容器默认配置；否则设定溯源信息仓库地址为该URL；步骤16、截取SOAP报文；步骤17、解析报文，提取信息；步骤18、创建溯源信息。
实施例四、在网格服务中有三个因素与性能有直接关系(1)客户机向远程Web服务发出一个请求的时间(CT)；(2)处理消息所花费的时间(PT)，这里的消息具体说来，是XML的解析、相应流程的管理、服务的调用以及最终响应编码；(3)服务本身执行所用的时间(ST)，即服务自身所执行业务逻辑所花费的时间。在溯源信息记录阶段，通过“Axis Handler”方式进行对溯源信息的截获，将对“Handler”的处理时间定义为(RT)，那么整个服务调用过程的总时间(TotalTime)为TotalTime＝CT+PT+ST+RT，CT和PT由客户机本身性能来决定，ST针对不同服务也有不同的取值范围，在溯源信息记录处理阶段，所能控制的是RT。
基于实施例二，为了尽量减少RT给用户请求带来的时间效率影响，在“Axis Pivot”中加入缓存机制实现溯源信息的记录和服务调用的异步进行。缓存线程负责将这些服务调用产生的溯源信息对象存储一个固定时间周期，到达预定周期后进行信息记录，然后再清除这些对象。其具体流程如图4所示步骤21、将溯源信息存入缓存空间Cache；步骤22、保留缓存溯源信息；步骤23、到达缓存周期后，将缓存的溯源信息存入指定溯源信息仓库；步骤24、释放缓存空间Cache。
实施例五、基于实施例二，可按如下方式实现溯源信息的查询，查询模块中的XPath封装解析器用于对存储的溯源信息进行查询，在溯源信息仓库中找到所有与XPath路径相匹配的关键字属性结点是XPath封装解析器查询处理的核心，结合溯源信息的构造结构，从中提取关键属性，并提供对这些关键字属性进行封装的XPath查询语法，关键字属性列表如下表所示。针对不同用户，查询可以直接通过输入关键字查询或直接输入“XQuery语句”进行查询。
实施例六、基于实施例二，可采用如下方式实现溯源信息回溯分析服务和状态统计服务，根据溯源信息的构造流程及表示方法，制定针对链式服务调用的路径回溯分析机制。对于链式调用而言，确定“自顶向下、自左至右”的分析视角。
对于多个参与者(其中客户端参与者和最终目标服务是两个特例)的链式调用，每个参与者的执行空间被划分为R-S-R-S四块，如图5链式示意图中参与者B，其中S表示发送者(Sender)，R表示接收者(Receiver)。从执行方向上看，所有参与者的左侧构成正向路径，右侧构成逆向路径，其中n为参与者个数(n为正整数)，整个链式调用具有如下特征1、除去客户端和最终服务端，每个参与者对应4条参与者记录；2、总共产生4(n-2)+2*2＝4(n-1)条发送/接收消息；3、第1条至第2(n-2)+2＝2(n-1)条记录构成正向路径；4、第2(n-1)+1＝2n-1至4(n-1)条记录构成逆向路径。
所述的回溯分析服务过程包括如下步骤步骤41a、建立存储列表；步骤42a、解析溯源信息，获得客户端与服务端信息；步骤43a、获得服务信息；步骤44a、判断所述的服务信息是否为同一客户端或服务端，若是则合并服务信息；否则继续执行步骤43a；步骤45a、将客户端与服务端信息放入存储列表。
以三个参与者(A-B-C)的链式调用为例，整个流程如图6所示，其中IDn中包含时间戳信息1.服务调用开始；2.A创建发送消息“A.Sender”；3.A创建“IDA”；4.“A.Sender+IDA”放入队列5.B创建接收消息“B1.Receiver”；6.B创建“IDB1”；7.“B1.Receiver+IDB1”放入队列
8.B创建发送消息”B2.Sender”；9.B创建”IDB2”；10.“B2.Sender+IDB2”放入队列11.C创建接收消息”C.Receiver”；12.C创建“IDC”；13.“C.Receiver+IDC”放入队列14.C创建发送消息“C.Sender”；15.“C.Sender+IDC”放入队列16.B创建接收消息“B2.Receiver”；17.“B2.Receiver+IDB2”放入队列；18.B创建发送消息“B1.Sender”；19.“B1.Receiver+IDB1”放入队列；20.A创建接收消息“A.Receiver”；21.“A.Receiver+IDA”放入队列；(以上为记录流程)22.取出第1到2(n-1)条正向路径记录；23.判断是否出现同样前缀名，若有，则为同一个参与者，进行合并；24..根据“IDn”中时间戳信息进行排序；25.排序后的顺序即为原始调用路径。
执行完毕，列表中的信息标示了一次链式调用的完整流程。
在状态统计服务中，首先调用容器提供的API，然后根据API分别收集如下信息资源定位描述服务(Resource Location & Description Service，简称RLDS)RLDS名、RLDS访问点；所有可用容器节点列表、容器静态信息(操作系统类型、主机名、中央处理器(Central Processing Unit，简称CPU)类型、CPU频率、文件系统类型、机器类型、磁盘总空间、内存大小、端口)、容器动态信息(CPU当前负载、当前空闲内存空间、当前空闲磁盘空间)；所有可用服务列表、服务名、服务类别、服务WSDL文件位置、服务访问点、所在节点、服务描述信息。
具体实施步骤为步骤41b、调用容器提供的API；步骤42b、根据API收集状态信息；步骤43b、构造视图，展现状态信息。
实施例七、基于实施例二，溯源信息系统提供基于“Eclipse Rich ClientPlatform”技术的富客户端，是溯源信息的界面展现形式，通过对图形界面进行一些简单的操作，提高了溯源信息系统的可管理性、易操作性。目前提供了浏览整个网格环境的拓扑视图，以及针对普通用户的SOPA调试视图和溯源信息管理视图两种模式的视图。
网格环境拓扑视图快捷、迅速的获取到整个基于广域网络科研环境的网格环境下的各个级别的拓扑结构(区域级、RLDS级、节点服务器级、服务级)以及容器结点的动态、静态信息，同时也提供了网格信息查询语言(GridInformation Query Language，简称GIQL)接口，方便高级用户能够自定义查询的信息。另外，拓扑视图也提供了与多模式查询视图的接口，针对列表中的每个可用服务，可以通过相应链接进入溯源信息管理视图和SOAP调试视图。
溯源信息管理视图中，服务列表为从网格环境拓扑视图中选取的网格环境中所有的可用服务，视图提供显示、查询、条件面板，用户可以结合查询面板和条件面板，制定多种查询条件，获取自己感兴趣的溯源信息显示在显示面板中。
网格服务调用都是通过SOAP方式进行，服务客户端负责将相关信息屏蔽，使得用户不用关心相关SOAP细节即可进行服务调用。但是在服务部署初始阶段，为了检测服务是否可用，使用一个简单SOAP报文即可。SOAP调试视图中，用户只需输入简单的测试SOAP报文，即可获得服务的反馈信息，其中也包含了相应的溯源信息。同时，视图也提供了一定的管理功能。
最后应说明的是以上实施例仅用以说明本发明的技术方案而非限制，尽管参照较佳实施例对本发明进行了详细说明，本领域的普通技术人员应当理解，可以对本发明的技术方案进行修改或者等同替换，而不脱离本发明技术方案的精神和范围。
权利要求
1.一种服务网格溯源信息收集系统，其特征在于包括存储模块，用于存储溯源信息；创建模块，用于创建溯源信息；记录模块，与创建模块、存储模块连接，用于将创建模块生成的溯源信息保存到存储模块中；查询模块，与存储模块连接，用于对网格环境容器节点的动态、静态信息进行实时监控，根据溯源信息统计服务调用频率；以及对链式服务调用和多路服务调用进行回溯；管理模块，与存储模块连接，用于管理所存储的溯源信息。
2.根据权利要求1所述的服务网格溯源信息收集系统，其特征在于所述的存储模块具体包括用于存储溯源信息的数据库和/或本地文件系统。
3.根据权利要求1所述的服务网格溯源信息收集系统，其特征在于所述的创建模块具体包括SOAP报文处理器，所述的SOAP报文处理器用于过滤提取SOAP报文。
4.根据权利要求1所述的服务网格溯源信息收集系统，其特征在于所述的记录模块具体包括缓存处理单元，所述的缓存单元用于完成溯源信息的记录和服务调用的异步进行。
5.根据权利要求1所述的服务网格溯源信息收集系统，其特征在于所述的查询模块具体包括XPath封装解析器，用于封装XPath查询关键字。
6.根据权利要求1或2或3或4或5所述的服务网格溯源信息收集系统，其特征在于还包括显示模块，与查询模块连接用于显示查询到的溯源信息。
7.根据权利要求1或2或3或4或5所述的服务网格溯源信息收集系统，其特征在于还包括异常处理模块与所述各功能模块连接，用于向客户端返回出错信息。
8.根据权利要求6所述的服务网格溯源信息收集系统，其特征在于所述的显示模块存有网络环境拓扑视图、溯源信息管理视图、SOAP调试视图。
9.一种服务网格溯源信息收集方法，其特征在于包括根据网格系统中溯源信息的具体表达方式，创建相关数据结构创建溯源信息的步骤；对创建溯源信息步骤产生的溯源信息进行组织，记录网格环境下的溯源信息的步骤；通过缓存处理单元存储溯源信息的步骤；包括回溯分析服务及状态统计服务的查询溯源信息的步骤；管理所存储的溯源信息的步骤。
10.根据权利要求9所述的服务网格溯源信息收集方法，其特征在于所述的创建溯源信息具体包括步骤11、客户端发生请求或服务端发生反馈时，读取服务配置文件信息；步骤12、解析配置文件信息；步骤13、判断服务中是否具有溯源信息配置文件，若有则执行步骤14；若没有，则创建溯源信息结束；步骤14、解析溯源信息仓库URL；步骤15、判断溯源信息仓库URL是否为空，若为空则设定溯源信息仓库地址为容器默认配置；否则设定溯源信息仓库地址为该URL；步骤16、截取SOAP报文；步骤17、解析报文，提取信息；步骤18、创建溯源信息。
11.根据权利要求9所述的服务网格溯源信息收集方法，其特征在于所述的记录溯源信息及存储溯源信息具体包括步骤21、将溯源信息存入缓存空间Cache；步骤22、保留缓存溯源信息；步骤23、到达缓存周期后，将缓存的溯源信息存入指定溯源信息仓库；步骤24、释放缓存空间Cache。
12.根据权利要求9所述的服务网格溯源信息收集方法，其特征在于所述的查询溯源信息的步骤具体为包括关键字查询和/或查询语句查询的Xpath封装解析器查询步骤。
13.根据权利要9所述的服务网格溯源信息收集方法，其特征在于所述的回溯分析服务包括步骤41a、建立存储列表；步骤42a、解析溯源信息，获得客户端与服务端信息；步骤43a、获得服务信息；步骤44a、判断所述的服务信息是否为同一客户端或服务端，若是则合并服务信息；否则继续执行步骤43a；步骤45a、将客户端与服务端信息放入存储列表。
14.根据权利要求9所述的服务网格溯源信息收集方法，其特征在于所述的状态统计服务包括步骤41b、调用容器提供的API；步骤42b、根据API收集状态信息；步骤43b、构造视图，展现状态信息。
15.根据权利要求9至14中任一所述的服务网格溯源信息收集方法，其特征在于还包括通过客户端工具显示查询到的溯源信息的步骤。
全文摘要
本发明涉及一种服务网格溯源信息收集系统，系统采用层次化结构，包括底层存储模块；中间层包括创建模块、记录模块、查询模块、管理模块及异常处理模块；上层为显示模块。本发明还涉及一种服务网格溯源信息收集方法，包括创建溯源信息、记录溯源信息、存储溯源信息、查询溯源信息、显示溯源信息及管理溯源信息的步骤。本发明能够实现在服务网格中提供对溯源信息的全生命周期的支持，实现服务网格中对溯源信息的创建、记录、查询、管理四个阶段的操作。
文档编号H04L12/54GK101043381SQ200710098579
公开日2007年9月26日 申请日期2007年4月20日 优先权日2007年4月20日
发明者刘旭东, 程国强, 沃天宇 申请人:北京航空航天大学