首页 / 专利库 / 物理 / 质量 / 端到端Web服务质量监测方法

端到端Web服务质量监测方法

阅读:308发布:2021-09-18

专利汇可以提供端到端Web服务质量监测方法专利检索,专利查询,专利分析的服务。并且一种端到端Web服务 质量 监测系统及方法,该监测系统包括以下四个模 块 :注册模块、SNMP代理模块、监测模块和评价模块;该监测方法按如下步骤进行:步骤A:注册;步骤B:生成约定质量的各个参数及参数值;步骤C:发送将约定质量参数;步骤D:获取服务会话信息,步骤E:获取服务会话的管理信息;步骤F:得到与约定质量参数所对应的交付质量参数值及 感知 质量参数值;步骤G:监测模块将交付质量参数值、感知质量参数值和传输质量参数值发送给评价模块;步骤H:评价模块对该服务的质量信息进行评估和统计。本 发明 的优点:简单有效且开销较低,并能够客观的、综合的反映服务会话质量信息,以便为服务选取提供客观依据。,下面是端到端Web服务质量监测方法专利的具体信息内容。

1.一种端到端Web服务质量监测系统的监测方法,其特征在于:
按如下步骤进行:
步骤A:服务提供者把其与服务使用者协商后的服务等级协议向服务监测者进行注册;
步骤B:服务监测者提取服务等级协议中的相关信息,生成约定质量的各个参数及参数值;
步骤C:将约定质量参数作为所要监测的QoWS指标,分别在服务提供者端和服务使用者端采用API Hook应用程序接口钩子技术获取服务会话信息,按如下步骤进行:
步骤C1:分别在服务提供者端和服务使用者端拦截HTTP数据包,按如下步骤进行:
步骤C11:通过重载库函数send()、recv()来截获数据包;
步骤C12:记录下所截获的HTTP消息的时间戳,包括HTTP请求报文的发送时刻t(cs)、HTTP请求报文的接收时刻t(sr)、HTTP响应报文的发送时刻t(ss)及HTTP响应报文的接收时刻t(cr):
步骤C13:在服务端管理对象结构和客户端管理对象结构中均设置服务会话标识sessionID;在HTTP请求报文的请求行后插上一个首部行,字段名为SessionID,其值为当前时间戳;
步骤C14:将服务会话标识、时间戳及数据包大小发送到管道中;
步骤C2:对HTTP数据包进行过滤和分析,按如下步骤进行:
步骤C21:从管道里读取数据;
步骤C22:通过对HTTP消息的类型Content-Type和客户能够接收的消息类型Accept首部行进行判断,过滤非SOAP消息;判断消息类型Content-type首部行的值是否含有SOAP信息,如果有则该数据包是SOAP数据包,否则便认为该数据包不是SOAP数据包;如果不存在消息类型Content-Type首部行,则判断客户所能接收的消息类型Accept首部行的值是否含有SOAP信息,如果含有则认为该数据包是SOAP数据包;否则便认为该数据包不是SOAP数据包;
步骤C23:通过处理HTTP GET请求和HTTP POST请求来获取服务操作operation参数值;
步骤C3:采用UCD-SNMP引擎将对应的服务端管理信息对象与客户端管理信息对象进行赋值,按如下步骤进行:
步骤C31:服务使用者端SNMP代理在分析完所发送的服务请求消息后,在客户端管理对象组CQoWS_Group中创建一个服务会话项sessionEntry及相应的服务会话索引sessionIndex,并将服务会话标识sessionID、服务地址servURL、服务操作operation和服务请求消息的发送时刻t(cs)参数进行赋值,同时将服务会话状态status赋值为active;
步骤C32:为客户端管理对象组中的服务会话有效时间validTime赋值,该有效时间用来为服务操作的响应时间设定一个阈值即最大值,如果服务使用者在有效时间内没有接收到服务响应,则视该服务会话为无效;
步骤C33:服务提供者端SNMP代理在分析完所接受的服务请求消息后,在服务端管理对象组的服务会话表SQoWS_Group.sessionTable中创建一个服务会话项sessionEntry及相应的服务会话索引sessionIndex,并将服务会话标识sessionID、客户地址clientAddr、服务地址servURL、服务操作operation和服务请求消息的接收时刻t(sr)参数进行赋值,同时将服务会话状态status赋值为active;
步骤C34:为服务端管理对象组中的服务操作有效时间validTime赋值,该有效时间用来为服务的执行时间设定一个阈值即最大值,如果服务在有效时间内没有执行完毕,则视该服务会话为失效;
步骤C35:服务提供者端SNMP代理如果在有效时间validTime内拦截到所发出的服务响应消息,则status更新为delivered,否则更新为failure;
步骤C36:服务使用者端SNMP代理如果在有效时间validTime内拦截到所接收的服务响应消息,则status更新为perceiveal,否则更新为failure;
步骤D:周期性的向管理域中的服务提供者进行轮询,获取服务会话的管理信息,并且根据该信息中的线索对相应服务使用者端的管理信息进行读取;
步骤E:分别对服务提供者端和服务使用者端的会话信息进行处理,得到与约定质量参数所对应的交付质量参数值及感知质量参数值;
步骤F:根据交付质量参数值、感知质量参数值和传输质量参数值对服务会话的质量及服务质量进行评估和统计。
2.按权利要求1所述的端到端Web服务质量监测方法,其特征在于:所述的步骤C32,按如下步骤进行:
步骤C321:服务使用者端SNMP代理向服务监测者端SNMP管理者发送一个事件通知即扩展的陷入消息;
步骤C322:监测者端SNMP管理者接收到事件通知后,根据约定质量中所指定的服务响应时间对validTime参数进行处理;validTime参数赋值为服务响应时间的2倍,即validTime=2×约定响应时间;
步骤C323:而后发送一条SNMP set指令,将处理后的值赋值给有效时间validTime;
所述的步骤C34,按如下步骤进行:
步骤C341:服务提供者端SNMP代理向服务监测者端SNMP管理者发送一个事件通知即扩展的陷入消息;
步骤C342:监测者端SNMP管理者接收到事件通知后,根据约定质量中所指定的服务响应时间对validTime参数进行处理;validTime参数赋值为增加30%的服务响应时间,即validTime=(1+30%)×约定响应时间;
步骤C343:而后发送一条SNMP set指令,将处理后的值赋值给有效时间validTime。
3.按权利要求1所述的端到端Web服务质量监测方法,其特征在于:所述的步骤F,按如下步骤进行:
步骤F1:对单次服务会话的质量进行评估,按如下步骤进行:
步骤F11:对单次服务会话的各个QoWS指标参数进行评估,计算方法如下:
(1).对于在SLA中所约定的交付质量参数的计算方法
1)对于正参数,即参数值越大所反映的服务质量越好;
2)对于负参数,即参数值越小所反映的服务质量越好;
d d
其中,Ei为第i个QoWS指标参数的交付值与约定值相比的程度,valuei为第i个QoWSa
指标参数在交付质量中的值,valuei为第i个Q0WS指标参数在约定质量中的值;
对于1)和2)的结果:
d
如果Ei为非负数,则说明该交付质量参数达到约定标准的程度;
d
如果Ei为负数,则说明该交付质量参数未达到约定标准的程度;
(2).对于在SLA中所约定的感知质量参数的计算方法如下:
1)对于正参数,即参数值越大所反映的服务质量越好;
2)对于负参数,即参数值越小所反映的服务质量越好;
p p
其中,Ei为第i个QoWS指标参数的感知值与约定值相比的程度,valuei为第i个QoWSa
指标参数在感知质量中的值,valuei为第i个90WS指标参数在约定质量中的值;
对于1)和2)的结果:
p
如果Ei为非负数,则说明该感知质量参数达到约定标准的程度;
p
如果Ei为负数,则说明该感知质量参数未达到约定标准的程度;
步骤F12:对单次服务会话的质量进行综合评估,按下式计算:
d
SingleE为服务会话质量的评估值,m为QoWS指标的个数,其中Ei和
Epi必有一个值为空,即第i个QoWS指标参数要么约定为交付值,要么约定为感知值,因此用Ei表示Edi或Epi;
所述的步骤F2,按如下步骤进行:
步骤F21:对各个QoWS指标参数的长期评估,即生成QoWS指标的统计值,其计算方法为:
1)对于QoWS指标参数交付值的统计:
SQoWSdi为第i个QoWS指标参数的交付统计值,n为服务会话的
个数;
2)对于QoWS指标参数感知值的统计:
p
SQoWSi为第i个QoWS指标参数的感知统计值,n为服务会话的
个数;
步骤F22:对各个QoWS指标参数达到约定值的程度进行评估,按下式计算:
SEi为第i个QoWS指标达到约定值的程度,n为服务会话的个数;
第i个QoWS指标参数要么约定为交付值,要么约定为感知值,因此用Ej表示Edj或Epj;
步骤F2:对各个QoWS指标进行长期评估;
步骤F3:对服务质量进行长期评估,即对服务达到约定质量的程度进行统计,其统计方法按下式进行:
s为服务达到约定质量的程度,SEi为第i个QoWS指标达到约定值的程
度,m为QoWS指标参数的个数。

说明书全文

端到端Web服务质量监测方法

技术领域

[0001] 本发明属于Web服务组合领域,特别涉及一种端到端Web服务质量监测系统及方法。

背景技术

[0002] 以Web服务为代表的软件服务技术正在快速发展,它所具备的松散耦合以及平台无关的优良特性非常适合于Internet环境下异构应用之间的互操作和集成。随着功能相同或相似的Web服务(以下简称服务)日益增多,用户在使用Web服务或者创建组合服务时通常有多个候选Web服务可供选择。在满足用户功能需求的基础上,Web服务质量(Quality of Web Services,QoWS)成为评价候选Web服务的标准,也成为牵动Web服务发展的重要因素。服务提供者所提供的是具有一定质量保障的服务,服务使用者所请求的是具有一定质量约束的服务。
[0003] 服务监测是指对服务质量的监视和测量。服务质量监视是指由特定监视实体对服务质量进行周期性的测量;服务质量测量是指对QoWS模型所定义的属性值的获取。服务监测建立在特定QoWS模型基础上,不同的QoWS模型往往需要不同的服务监测方法。 [0004] 对Web服务质量进行建模可以从服务提供者的视和服务使用者的视角进行。QoWS属性主要包括可用性、可访问性、可靠性、规范性、安全性、响应时间、吞吐率、延迟、价格、网络带宽和信誉度等。可将QoWS属性分成两类:一类是与Web服务所处的服务环境无关,而与Web服务自身的实现相关的内部属性,另一类则是与Web服务所处的服务环境存在联系的外部属性。也可从另一个角度将QoWS属性分成三类:不经常发生变化的静态指标(如Web服务的规范性和安全性)、随着特定环境的变化而变化的动态指标(如服务可用性、网络可用性和执行时间)、根据统计数据计算得到的统计指标(如服务可靠性,网络可靠性,执行可靠性和信誉度)。尽管以上QoWS模型的提出能够在某种程度上支持服务监测与服务评价,然而,现有QoWS模型是单维度的,即没有贯穿在面向服务体系结构的整个流程(服务发布、服务发现、服务选取、服务执行)中,无法代表客观的、综合的服务质量。例如,以服务的响应时间为例,该QoWS属性应具有不同维度:交付响应时间、传输响应时间、感知响应时间、约定响应时间、(指定时间段的)平均响应时间和用户所期望的响应时间。 [0005] 传统面向服务体系结构不支持服务度量和服务监视。当前典型的服务度量技术有:对底层网络数据包进行度量、基于代理、对SOAP引擎库进行修改以及应用响应度量等方法。
[0006] 当前典型的服务监视方法包括:1)扩展UDDI增加了一种新的数据结构,用于描述Web服务的QoWS属性,还定义了一种QoWS证明者角色,用于对服务提供者所宣称的服务质量进行验证;2)传统SOA结构中增加了一个面向服务中间件(SOM),所有Web服务提供者内部增加一个QoWS收集器,定时向SOM提供实时的Web服务QoWS量化值;3)通过中间件平台来对Web服务的服务质量进行监控,它向服务用户提供用户端代理,由代理来截获传输的SOAP消息,从而收集与服务质量有关的数据;4)在SOA模型外引入了可信任的第三QoWS认证中心, 负责对QoWS量化,并根据用户反馈来评估Web服务。现有服务监测方法要么只度量和监视服务端的交付质量,要么只度量和监视用户端的感知质量,无法客观的、真实的反应服务质量。
[0007] 由于网络性能、端系统性能等外部环境的影响,Web服务在服务提供者端的表现和服务使用者所感知到的结果不尽相同。监测Web服务在服务提供者端所表现的质量能够反映服务实际交付的质量,但不能反映使用者实际感知到的质量;同样,监测服务在使用者端所表现的质量能够反映客户实际感知到的质量,但无法客观反映服务提供者所交付的质量。然而现有Web服务质量监测系统要么以服务提供者的交付质量作为监测标准,要么以服务使用者的感知质量作为监测标准,缺乏真实的、客观的、综合的监测机制。 发明内容
[0008] 针对以有技术的不足,本发明提出一种端到端Web服务质量监测系统及方法,以实现从服务提供者和服务使用者两端监测服务会话的质量信息。
[0009] 本发明所需服务器两台,其硬件环境为:Intel Pentium M processor735(1.7GHz,400MHz FSB,2MB L2 cache),1.2GB DDR2(support dual-channel)RAM,CentOS5操作系统。通过中国网通ADSL(带宽2Mbps)或100Mbps局域网接入Internet。 [0010] 本发明所提出的六维QoWS模型,其QoWS属性具有多维性、服务等级协议相关性和可度量性。多维性是指同一QoWS属性具有不同维度的涵义,以满足服务质量在不同生命周期阶段中所具有的不同含义和需求。服务等级协议相关性是指QoWS属性包含服务提供者在服务等级协议中所发布或服务双方所约定的质量属性,以此衡量服务质量的一致性(即用户对服务的满意程度)。可度量性是指QoWS属性能够由第三方实体进行客观的、定量的度量。在服务计算环境中,根据服务质量在不同阶段所具有的不同的含义和表现,将服务质量划分为六个维度:
[0011] 1.期望质量(EQoWS):是指服务使用者在服务选取时所提出的服务质量约束。实际上,用户提出的服务质量约束应该在某个服务质量模型的规范下,否则将是盲目的,无法保证选取的有效性;
[0012] 2.约定质量(AQoWS):是指服务提供者和服务使用者在服务执行前对服务质量所作的约定。服务提供者按照约定质量交付服务;
[0013] 3.交付质量(DQoWS):是指服务提供者实际交付的服务的质量。它描述的是服务在提供者端所表现出来的质量,通过监测得到;
[0014] 4.感知质量(PQoWS):是指服务使用者实际感知到的服务的质量。它描述的是服务在使用者端所表现出来的质量,通过监测得到;
[0015] 5.传输质量(TQoWS):是指传输服务请求和响应消息的网络的质量,通过监测得到;
[0016] 6.统计质量(SQoWS):是指利用统计分析得到的服务长期性的、平均的性能表现。 [0017] QoWS监测包括三个方面的内容:服务会话信息的获取、服务会话信息的传输以及QoWS指标的计算。本发明采用应用程序接口钩子(API Hook)技术实现服务会话信息的获取,API Hook是操作系统为了能够灵活方便地添加新功能而提供的扩展机制,通过该技术可以对SOAP消息进行拦截和分析,以提取出服务会话的基本信息。本发明采用简单网络管理协议(Simple Network Management Protocol,SNMP)实现服务会话信息的传输,由SNMP管理者(即服务监测者)从SNMP代理(即服务提供者和服务使用者)周期性地读取服务会话信息。对于QoWS指标的计算部分,本发明的设计基本覆盖了当前典型QoWS指标的需要,即原始的服务会话信息基本满足当前典型QoWS指标的计算需要,但QoWS指标的计算不作为本发明的内容。
[0018] 如图1所示,端到端QoWS监测模型包括三个实体:服务提供者、服务使用者和服务监测者,该模型依赖如下假设:
[0019] 1.QoWS监测以约定质量为依据,监测服务质量是否达到约定标准以及达到的程度。
[0020] 2.三个实体存在于同一个SNMP管理域中,即它们共同支持同一管理标准,同时服务提供者和服务使用者均向服务监测者开放SNMP管理接口。
[0021] 约定质量是由服务等级协议(Service Level Agreement,SLA)定义和说明的。服务提供者按照服务等级为服务使用者提供相应服务及质量。服务等级可以由服务使用者指定,也可以由服务提供者根据服务使用者的属性进行配置。
[0022] 将服务会话信息归并到SNMP管理信息库的iso.org.dod.internet.mgmt.mib-2结点下,采用RFC1155标准将其转化为管理对象。管理对象涵盖了服务会话的基本信息,以供计算QoWS指标的需要,其结构分别如图2和图3所示。
[0023] 服务端管理对象(SQoWS_Group)有两个表:服务表ServTable和会话表SessionTable。ServTable将服务提供者所提供的所有服务形成一张表,描述它们的基本信息,其变量说明如下:
[0024] ●servNum:服务提供者所提供的服务的数量。
[0025] ●servEntry:某个服务的信息条目。
[0026] ●servIndex:表索引或服务编号,标识表中的每一条记录。
[0027] ●servURL:服务URL。
[0028] ●capacity:服务容量,是指该服务能同时处理请求的最大用户数。 [0029] ●operationSet:服务提供的所有的操作的集合。包括操作名operation和有效时间validTime。validTime用来为操作的响应时间设定一个阈值,如某操作在其有效时间内没有执行完毕,则视该操作为失效,其相应的服务会话状态为failure。 [0030] SessionTable描述了服务提供者所经历的和正在经历的全部服务会话的信息。其变量表示如下:
[0031] ●sessionNum:全部服务会话的数量。
[0032] ●sessionEntry:某个服务会话的信息条目。
[0033] ●sessionIndex:服务会话索引,标识表中的每一条记录。
[0034] ●sessionID:会话ID,唯一标识一个服务会话。
[0035] ●servURL:服务URL。
[0036] ●clientAddr:客户端地址。
[0037] ●status:服务会话的状态。包括active、delivered、failure和collected四个状态。active是指服务端正在处理来自客户端的请求,delivered是指服务操作在有效时间内已交付,failure是指服务操作在有效时间内没有交付,collected是指服务监测者已收集该会话的信息。
[0038] ●operation:服务所调用的操作。
[0039] ●deliveredParameters:交付质量参数。包括接收请求的时刻t(sr)和发出响应的时刻t(sc)。
[0040] 客户端管理对象(CQoWS_Group)描述了客户端的会话表SessionTable,其变量说明如下:
[0041] ●sessionNum:服务会话的数量,包括已经历的和正在经历的服务会话。 [0042] ●sessionIndex:表索引。
[0043] ●sessionID:会话ID。
[0044] ●servURL:服务URL。
[0045] ●validTime:会话有效时间,用来为服务的响应时间设定一个阈值,如某服务请求在其有效时间内没有收到响应,则视该会话为失效,其相应的服务会话状态为failure。 [0046] ●status:服务会话的状态。包括active、perceived、failure和collected四个状态。active是指客户端正在等待来自服务端的响应,perceived是指服务请求在会话有效时间内已收到响应,failure是指服务请求在会话有效时间内没有收到响应,collected是指服务监测者已收集该会话的信息。
[0047] ●operation:所调用的服务操作。
[0048] ●perceivedParameters:感知质量参数。包括发出请求的时刻t(cs)和接收响应的时刻t(cr)。
[0049] 如图1所示,该监测系统包括以下四个模:注册模块、SNMP代理模块、监测模块和评价模块。注册模块用于实现SLA的注册及约定质量的生成;SNMP代理模块用于服务会话信息的获取和SNMP协议实现;监测模块作为SNMP管理者与SNMP代理一同实现服务会话信息的传输;评价模块用于对约定质量达到的程度进行综合的、长期的评估; [0050] 所述的注册模块实现以下功能:
[0051] (1)服务提供者把与服务使用者协商后的服务等级协议向服务监测者进行注册; [0052] (2)注册模块将服务等级协议中的相关信息进行提取,生成约定质量的各个参数及参数 值;
[0053] (3)注册模块将约定质量参数发送给监测模块,作为所要监测的QoWS指标; [0054] 所述的SNMP代理模块实现以下功能:
[0055] SNMP代理模块分别在服务提供者端和服务使用者端采用API Hook应用程序接口钩子技术获取服务会话信息,并采用UCD-SNMP引擎实现SNMP功能;
[0056] 所述的监测模块实现以下功能:
[0057] (1)监测模块作为SNMP管理者周期性的向管理域中的服务提供者进行轮询,获取服务会话的管理信息,并且根据该信息中的线索对相应服务使用者端的管理信息进行读取;
[0058] (2)监测模块分别对服务提供者端和服务使用者端的会话信息进行处理,得到与约定质量参数所对应的交付质量参数值及感知质量参数值;
[0059] (3)监测模块将交付质量参数值、感知质量参数值和传输质量参数值发送给评价模块;
[0060] 所述的评价模块实现以下功能:
[0061] 评价模块对该服务的质量信息进行评估和统计。
[0062] 一种端到端Web服务质量监测方法,按如下步骤进行:
[0063] 步骤A:服务提供者把其与服务使用者协商后的服务等级协议向服务监测者进行注册;
[0064] 步骤B:服务监测者提取服务等级协议中的相关信息,生成约定质量的各个参数及参数值;
[0065] 步骤C:将约定质量参数作为所要监测的QoWS指标,分别在服务提供者端和服务使用者端采用API Hook应用程序接口钩子技术获取服务会话信息;
[0066] 步骤D:周期性的向管理域中的服务提供者(即SNMP代理)进行轮询,获取服务会话的管理信息,并且根据该信息中的线索对相应服务使用者端的管理信息进行读取; [0067] 步骤E:分别对服务提供者端和服务使用者端的会话信息进行处理,得到与约定质量参数所对应的交付质量参数值及感知质量参数值。其生成过程与具体的QoWS指标实例相关,由SNMP代理所获取的原始服务会话信息计算而成(对于QoWS指标的计算部分,本发明的设计基本覆盖了当前典型QoWS指标的需要,即原始的服务会话信息基本满足当前典型QoWS指标的计算需要,但QoWS指标的计算为本领域技术人员公知的常规技术,不做说明)。值得注意的是,有些QoWS参数在约定质量中指定的是交付质量,有些则指定的是感知质量,将计算出与之相对应的参数值。同时,还能够计算该服务会话所依赖的网络的传输质量,作为客观评估约定质量达到程度的重要因素。
[0068] 步骤F:根据交付质量参数值、感知质量参数值和传输质量参数值对服务会话的质量及服务质量进行评估和统计。
[0069] 由此完成了服务监测的整个过程,即以服务等级协议的注册为始,以服务评价为终。服务的统计质量可作为服务选取的标准,与服务使用者所指定的期望质量进行匹配以选取出最 符合用户需求的服务。
[0070] 步骤C的分解:
[0071] 步骤C1:分别在服务提供者端和服务使用者端拦截HTTP数据包; [0072] 步骤C2:对HTTP数据包进行过滤和分析;
[0073] 步骤C3:采用UCD-SNMP引擎将对应的服务端管理信息对象与客户端管理信息对象进行赋值。
[0074] 步骤C1的分解:
[0075] 步骤C11:通过重载库函数send()、recv()来截获数据包;
[0076] 步骤C12:记录下所截获的HTTP消息的时间戳,包括HTTP请求报文的发送时刻t(cs)、HTTP请求报文的接收时刻t(sr)、HTTP响应报文的发送时刻t(ss)及HTTP响应报文的接收时刻t(cr);
[0077] 步骤C13:为了获取服务会话的端到端信息,服务端管理对象结构和客户端管理对象结构中均设计了一个服务会话标识sessionID,用来标识一个端到端服务会话。由于服务会话是从服务使用者发起的,所以服务会话标识是由服务使用者端的SNMP代理所创建,在HTTP请求报文的请求行后插上一个首部行,字段名为SessionID,其值为当前时间戳; [0078] 步骤C14:将服务会话标识、时间戳及数据包大小发送到管道中。 [0079] 步骤C2的分解:
[0080] 步骤C21:从管道里读取数据;
[0081] 步骤C22:通过对HTTP消息的类型Content-Type和客户能够接收的消息类型Accept首部行进行判断,从而过滤非SOAP(Simple Object Access Protocol,简单对象访问协议)消息。判断消息类型Content-type首部行的值是否含有SOAP信息(application/soap+xml),如果有则该数据包是SOAP数据包,否则便认为该数据包不是SOAP数据包。如果不存在消息类型Content-Type首部行,则判断客户所能接收的消息类型Accept首部行的值是否含有SOAP信息(application/soap+xml),如果含有则认为该数据包是SOAP数据包;否则便认为该数据包不是SOAP数据包;
[0082] 步骤C23:通过处理HTTP GET请求和HTTP POST请求来获取服务操作operation参数值;
[0083] 步骤C3的分解:
[0084] 步骤C31:服务使用者端SNMP代理在分析完所发送的服务请求消息后,在客户端管理对象组CQoWS_Group中创建一个服务会话项sessionEntry及相应的服务会话索引sessionIndex,并将服务会话标识sessionID、服务地址servURL、服务操作operation和服务请求消息的发送时刻t(cs)参数进行赋值,同时将服务会话状态status赋值为active; [0085] 步骤C32:为客户端管理对象组中的服务会话有效时间validTime赋值,该有效时间用来为服务操作的响应时间设定一个阈值(最大值),如果服务使用者在有效时间内没有接收到 服务响应,则视该服务会话为无效;
[0086] 步骤C33:服务提供者端SNMP代理在分析完所接收的服务请求消息后,在服务端管理对象组的服务会话表SQoWS_Group.sessionTable中创建一个服务会话项sessionEntry及相应的服务会话索引sessionIndex,并将服务会话标识sessionID、客户地址clientAddr、服务地址servURL、服务操作operation和服务请求消息的接收时刻t(sr)参数进行赋值,同时将服务会话状态status赋值为active;
[0087] 步骤C34:为服务端管理对象组中的服务操作有效时间validTime赋值,该有效时间用来为服务的执行时间设定一个阈值(最大值),如果服务在有效时间内没有执行完毕,则视该服务会话为失效;
[0088] 步骤C35:服务提供者端SNMP代理如果在有效时间validTime内拦截到所发出的服务响应消息,则status更新为delivered,否则更新为failure;
[0089] 步骤C36:服务使用者端SNMP代理如果在有效时间validTime内拦截到所接收的服务响应消息,则status更新为perceived,否则更新为failure。
[0090] 步骤C32的分解:
[0091] 步骤C321:服务使用者端SNMP代理向服务监测者端SNMP管理者发送一个事件通知(扩展的陷入消息);
[0092] 步骤C322:监测者端SNMP管理者接收到事件通知后,根据约定质量中所指定的服务响应时间对validTime参数进行处理。需要注意的是,约定质量中所指定的服务响应时间是指服务在提供者端的执行时间,而validTime是指从发出请求到接收响应的时间的最大值。为了简单化,validTime参数赋值为服务响应时间的2倍,即validTime=2×约定响应时间;
[0093] 步骤C323:而后发送一条SNMP set指令,将处理后的值赋值给有效时间validTime。
[0094] 步骤C34的分解:
[0095] 步骤C341:服务提供者端SNMP代理向服务监测者端SNMP管理者发送一个事件通知(扩展的陷入消息);
[0096] 步骤C342:监测者端SNMP管理者接收到事件通知后,根据约定质量中所指定的服务响应时间对validTime参数进行处理。需要注意的是,约定质量中所指定的服务响应时间是指服务在提供者端的执行时间,而validTime是指服务执行时间的最大值。为了简单化,validTime参数赋值为增加30%的服务响应时间,即validTime=(1+30%)×约定响应时间;
[0097] 步骤C343:而后发送一条SNMP set指令,将处理后的值赋值给有效时间validTime。
[0098] 步骤D的分解:
[0099] 步骤D1:周期性的轮询服务端会话表SQoWS_Group.sessionTable,如果发现了新交付的服务会话(服务会话状态status=delivered or failure),则取出该会话所对应的客户地址clientAddr和服务会话标识sessionID,同时将服务会话状态status更新为collected;
[0100] 步骤D2:按照客户地址读取该客户的会话表CQoWS_Group,按照服务会话标识sessionID提取该服务会话在客户端的管理信息,并将其服务会话状态status更新为collected。
[0101] 步骤F的分解:
[0102] 步骤F1:对单次服务会话的质量进行评估;
[0103] 步骤F2:对各个QoWS指标进行长期评估;
[0104] 步骤F3:对服务质量进行长期评估,即对服务达到约定质量的程度进行统计,其计算方法为:
[0105] S为服务达到约定质量的程度,SEi为第i个QoWS指标达到约定值的程度,m为QoWS指标参数的个数。
[0106] 步骤F1的分解:
[0107] 步骤F11:对单次服务会话的各个QoWS指标参数进行评估,其计算方法为: [0108] 1.对于在SLA中所约定的交付质量参数的计算方法
[0109] 1)对于正参数,即参数值越大所反映的服务质量越好
[0110]
[0111] 2)对于负参数,即参数值越小所反映的服务质量越好
[0112]
[0113] 其中,Edi为第i个QoWS指标参数的交付值与约定值相比的程度,valuedi为第i个aQoWS指标参数在交付质量中的值(可以为空,即该指标所约定的不是交付值),valuei为第i个QoWS指标参数在约定质量中的值。
[0114] 对于1)和2)的结果:
[0115] 如果Edi为非负数,则说明该交付质量参数达到约定标准的程度; [0116] 如果Edi为负数,则说明该交付质量参数未达到约定标准的程度。 [0117] 2.对于在SLA中所约定的感知质量参数的计算方法
[0118] 1)对于正参数,即参数值越大所反映的服务质量越好
[0119]
[0120] 2)对于负参数,即参数值越小所反映的服务质量越好
[0121]
[0122] 其中,Epi为第i个QoWS指标参数的感知值与约定值相比的程度,valuepi为第i个QoWS指标参数在感知质量中的值(可以为空,即该指标所约定的不是感知值),valueai为第i个 QoWS指标参数在约定质量中的值。
[0123] 对于1)和2)的结果:
[0124] 如果Epi为非负数,则说明该感知质量参数达到约定标准的程度; [0125] 如果Epi为负数,则说明该感知质量参数未达到约定标准的程度。 [0126] 同时,评价模块还能够对计算结果进行分析,以客观评估服务质量。例如,如果感知质量没有达到约定标准,评价模块可以从交付质量、感知质量和传输质量三方面进行关联分析,以得出服务质量是在服务提供者端、服务使用者端或网络传输中的哪个环节出现了问题;
[0127] 步骤F12:对单次服务会话的质量进行综合评估,其计算方法为: [0128] SingleE为服务会话质量的评估值,m为QoWS指标的个数。值得注意的是Edi和Epi必有一个值为空,即第i个QoWS指标参数要么约定为交付值,要么约定为感知值,因此用Ei表示Edi或Epi。
[0129] 步骤F2的分解:
[0130] 步骤F21:对各个QoWS指标参数的长期评估,即生成QoWS指标的统计值,其计算方法为:
[0131] 1)对于QoWS指标参数交付值的统计:
[0132] SQoWSdi为第i个QoWS指标参数的交付统计值,n为服务会话的个数。
[0133] 2)对于QoWS指标参数感知值的统计:
[0134] SQoWSpi为第i个QoWS指标参数的感知统计值,n为服务会话的个数。
[0135] 步骤F22:对各个QoWS指标参数达到约定值的程度进行评估,其计算方法为: [0136] SEi为第i个QoWS指标达到约定值的程度,n为服务会话的个数。
[0137] 第i个QoWS指标参数要么约定为交付值,要么约定为感知值,因此可以用Ej表示Edj或Epj。
[0138] 本发明的优点:所提出的端到端QoWS监测方法能够就Web服务不同生命周期阶段的服务质量,即期望质量、约定质量、交付质量、传输质量、感知质量和统计质量进行监测,利用简单网络管理协议对服务会话进行管理,其实现方法简单有效且开销较低,并能够客观的、 综合的反映服务会话质量信息,以便为服务选取提供客观依据。附图说明
[0139] 图1为本发明端到端QoWS监测模型;
[0140] 图2为本发明服务端管理对象结构;
[0141] 图3为本发明客户端管理对象结构;
[0142] 图4为本发明实现方法的流程图
[0143] 图5为本发明获取服务会话管理信息的流程图;
[0144] 图6为本发明获取端到端服务会话质量的流程图;
[0145] 图7为本发明服务评价的流程图。

具体实施方式

[0146] 本发明结合具体实施例说明书附图进行说明。
[0147] 服务使用者和服务监测者的运行环境为:Intel Pentium M processor735(1.7GHz,400MHz FSB,2MB L2cache),1.2GB DDR2(support dual-channel)RAM,CentOS5操作系统,通过中国网通ADSL接入Internet,带宽为2Mbps,客户端程序采用Java编写。 [0148] 服务端的运行环境为:Intel Pentium M processor 735(1.7GHz,400MHz FSB,2MB L2cache),1.2GB DDR2(support dual-channel)RAM,CentOS5操作系统,通过100Mbps局域网接入Internet。Web服务采用Axis2开源软件开发包提供的、Java编写的股价查询服务StockQuoteService。该服务提供一个简单操作getPrice,用来获取某个公司的股价,公司名附在请求URL中,该操作发出请求数据包大小为500字节左右,服务端返回数据包大小为
273字节左右。
[0149] 如图3所示,该监测系统包括以下四个模块:注册模块、SNMP代理模块、监测模块和评价模块;注册模块用于实现SLA的注册及约定质量的生成;SNMP代理模块用于服务会话信息的获取和SNMP协议实现;监测模块作为SNMP管理者与SNMP代理一同实现服务会话信息的传输;评价模块用于对约定质量达到的程度进行综合的、长期的评估; [0150] 所述的注册模块实现以下功能:
[0151] (1)服务提供者把与服务使用者协商后的服务等级协议向服务监测者进行注册; [0152] (2)注册模块将服务等级协议中的相关信息进行提取,生成约定质量的各个参数及参数值;
[0153] (3)注册模块将约定质量参数发送给监测模块,作为所要监测的QoWS指标; [0154] 所述的SNMP代理模块实现以下功能:
[0155] SNMP代理模块分别在服务提供者端和服务使用者端采用API Hook应用程序接口钩子技术获取服务会话信息,并采用UCD-SNMP引擎实现SNMP功能;
[0156] 所述的监测模块实现以下功能:
[0157] (1)监测模块作为SNMP管理者周期性的向管理域中的服务提供者进行轮询,获取服务会话的管理信息,并且根据该信息中的线索对相应服务使用者端的管理信息进行读取;
[0158] (2)监测模块分别对服务提供者端和服务使用者端的会话信息进行处理,得到与约定质量参数所对应的交付质量参数值及感知质量参数值;
[0159] (3)监测模块将交付质量参数值、感知质量参数值和传输质量参数值发送给评价模块;
[0160] 所述的评价模块实现以下功能:
[0161] 评价模块对该服务的质量信息进行评估和统计。
[0162] 该监测方法,按图4所示的步骤进行:
[0163] 步骤A:服务提供者把其与服务使用者协商后的服务等级协议向服务监测者进行注册;
[0164] 步骤B:服务监测者提取服务等级协议中的相关信息,生成约定质量的各个参数及参数值;
[0165] 步骤C:将约定质量参数作为所要监测的QoWS指标,分别在服务提供者端和服务使用者端采用API Hook应用程序接口钩子技术获取服务会话信息;
[0166] 步骤D:周期性的向管理域中的服务提供者(即SNMP代理)进行轮询,获取服务会话的管理信息,并且根据该信息中的线索对相应服务使用者端的管理信息进行读取; [0167] 步骤E:分别对服务提供者端和服务使用者端的会话信息进行处理,得到与约定质量参数所对应的交付质量参数值及感知质量参数值。其生成过程与具体的QoWS指标实例相关,由SNMP代理所获取的原始服务会话信息计算而成(对于QoWS指标的计算部分,本发明的设计基本覆盖了当前典型QoWS指标的需要,即原始的服务会话信息基本满足当前典型QoWS指标的计算需要,但QoWS指标的计算为本领域技术人员公知的常规技术,不做额外说明)。本实例以最为典型的QoWS指标——响应时间为例,该QoWS指标包括期望响应时间、约定响应时间、交付响应时间、传输时间、感知响应时间和统计(交付)响应时间六个维度。期望响应时间由用户在服务选取时输入;约定响应时间由服务提供者进行注册;交付响应时间是指从服务提供者接收到服务请求到发送出服务响应的时间;传输时间是指网络的延时,用于对网络性能进行分析;感知响应时间是指从服务使用者发出服务请求到接收到服务响应的时间;统计响应时间是指交付响应时间的统计值。其计算公式分别如下: [0168] Td=t(ss)-t(sr),Td为交付响应时间,t(ss)为服务响应报文的发送时刻,t(sr)为服务请求报文的接收时刻。
[0169] Tp=t(cr)-t(cs),Tp为感知响应时间,t(cr)为服务服务响应报文的接收时刻,t(cs)为服务请求报文的发送时刻。
[0170] Tt=(t(sr)-t(cs))+(t(cr)-t(ss)),Tt为传输时间,假定服务端和客户端时钟同步。
[0171] Ts为统计响应时间,n为被监测的服务会话的个数。
[0172] 步骤F:根据交付质量参数值、感知质量参数值和传输质量参数值对服务会话的质量及服务质量进行评估和统计。
[0173] 由此完成了服务监测的整个过程,即以服务等级协议的注册为始,以服务评价为终。服务的统计质量可作为服务选取的标准,与服务使用者所指定的期望质量进行匹配以选取出最符合用户需求的服务。
[0174] 步骤C的分解,如图5所示:
[0175] 步骤C1:分别在服务提供者端和服务使用者端拦截HTTP数据包; [0176] 步骤C2:对HTTP数据包进行过滤和分析;
[0177] 步骤C3:采用UCD-SNMP引擎将对应的服务端管理信息对象与客户端管理信息对象进行赋值。
[0178] 步骤C1的分解:
[0179] 步骤C11:通过重载库函数send()、recv()来截获数据包;
[0180] 步骤C12:记录下所截获的HTTP消息的时间戳,包括HTTP请求报文的发送时刻t(cs)、HTTP请求报文的接收时刻t(sr)、HTTP响应报文的发送时刻t(ss)及HTTP响应报文的接收时刻t(cr);
[0181] 步骤C13:为了获取服务会话的端到端信息,服务端管理对象结构和客户端管理对象结构中均设计了一个服务会话标识sessionID,用来标识一个端到端服务会话。由于服务会话是从服务使用者发起的,所以服务会话标识是由服务使用者端的SNMP代理所创建,在HTTP请求报文的请求行后插上一个首部行,字段名为SessionID,其值为当前时间戳; [0182] 步骤C14:将服务会话标识、时间戳及数据包大小发送到管道中。 [0183] 步骤C2的分解:
[0184] 步骤C21:从管道里读取数据;
[0185] 步骤C22:通过对HTTP消息的类型Content-Type和客户能够接收的消息类型Accept首部行进行判断,从而过滤非SOAP(Simple Object Access Protocol,简单对象访问协议)消息。判断消息类型Content-type首部行的值是否含有SOAP信息(application/soap+xml),如果有则该数据包是SOAP数据包,否则便认为该数据包不是SOAP数据包。如果不存在消息类型Content-Type首部行,则判断客户所能接收的消息类型Accept首部行的值是否含有SOAP信息(application/soap+xml),如果含有则认为该数据包是SOAP数据包;否则便认为该数据包不是SOAP数据包;
[0186] 步骤C23:通过处理HTTP GET请求和HTTP POST请求来获取服务操作operation参数值;
[0187] 步骤C3的分解:
[0188] 步骤C31:服务使用者端SNMP代理在分析完所发送的服务请求消息后,在客户端管理对象组CQoWS_Group中创建一个服务会话项sessionEntry及相应的服务会话索引sessionIndex,并将服务会话标识sessionID、服务地址servURL、服务操作operation和服务请求消息的发送时刻t(cs)参数进行赋值,同时将服务会话状态status赋值为active; [0189] 步骤C32:为客户端管理对象组中的服务会话有效时间validTime赋值,该有效时间用来为服务操作的响应时间设定一个阈值(最大值),如果服务使用者在有效时间内没有接收到服务响应,则视该服务会话为无效;
[0190] 步骤C33:服务提供者端SNMP代理在分析完所接收的服务请求消息后,在服务端管理对象组的服务会话表SQoWS_Group.sessionTable中创建一个服务会话项sessionEntry及相应的服务会话索引sessionIndex,并将服务会话标识sessionID、客户地址clientAddr、服务地址servURL、服务操作operation和服务请求消息的接收时刻t(sr)参数进行赋值,同时将服务会话状态status赋值为active;
[0191] 步骤C34:为服务端管理对象组中的服务操作有效时间validTime赋值,该有效时间用来为服务的执行时间设定一个阈值(最大值),如果服务在有效时间内没有执行完毕,则视该服务会话为失效;
[0192] 步骤C35:服务提供者端SNMP代理如果在有效时间validTime内拦截到所发出的服务响应消息,则status更新为delivered,否则更新为failure;
[0193] 步骤C36:服务使用者端SNMP代理如果在有效时间validTime内拦截到所接收的服务响应消息,则status更新为perceived,否则更新为failure。
[0194] 步骤C32的分解:
[0195] 步骤C321:服务使用者端SNMP代理向服务监测者端SNMP管理者发送一个事件通知(扩展的陷入消息);
[0196] 步骤C322:监测者端SNMP管理者接收到事件通知后,根据约定质量中所指定的服务响应时间对validTime参数进行处理。需要注意的是,约定质量中所指定的服务响应时间是指服务在提供者端的执行时间,而validTime是指从发出请求到接收响应的时间的最大值。为了简单化,validTime参数赋值为服务响应时间的2倍,即validTime=2×约定响应时间;
[0197] 步骤C323:而后发送一条SNMP set指令,将处理后的值赋值给有效时间validTime。
[0198] 步骤C34的分解:
[0199] 步骤C341:服务提供者端SNMP代理向服务监测者端SNMP管理者发送一个事件通知(扩展的陷入消息);
[0200] 步骤C342:监测者端SNMP管理者接收到事件通知后,根据约定质量中所指定的服务响应时间对validTime参数进行处理。需要注意的是,约定质量中所指定的服务响应时间是指服务在提供者端的执行时间,而validTime是指服务执行时间的最大值。为了简单化, validTime参数赋值为增加30%的服务响应时间,即validTime=(1+30%)×约定响应时间;
[0201] 步骤C343:而后发送一条SNMP set指令,将处理后的值赋值给有效时间validTime。
[0202] 步骤D的分解,如图6所示:
[0203] 步骤D1:周期性的轮询服务端会话表SQoWS_Group.sessionTable,如果发现了新交付的服务会话(服务会话状态status=delivered or failure),则取出该会话所对应的客户地址clientAddr和服务会话标识sessionID,同时将服务会话状态status更新为collected;
[0204] 步骤D2:按照客户地址读取该客户的会话表CQoWS_Group,按照服务会话标识sessionID提取该服务会话在客户端的管理信息,并将其服务会话状态status更新为collected。
[0205] 步骤F的分解,如图7所示:
[0206] 步骤F1:对单次服务会话的质量进行评估;
[0207] 步骤F2:对各个QoWS指标进行长期评估;
[0208] 步骤F3:对服务质量进行长期评估,即对服务达到约定质量的程度进行统计,其计算方法为:
[0209] S为服务达到约定质量的程度,SEi为第i个QoWS指标达到约定值的程度,m为QoWS指标参数的个数。
[0210] 步骤F1的分解:
[0211] 步骤F11:对单次服务会话的各个QoWS指标参数进行评估,其计算方法为: [0212] 1.对于在SLA中所约定的交付质量参数的计算方法
[0213] 1)对于正参数,即参数值越大所反映的服务质量越好
[0214]
[0215] 2)对于负参数,即参数值越小所反映的服务质量越好
[0216]
[0217] 其中,Edi为第i个QoWS指标参数的交付值与约定值相比的程度,valuedi为第i个aQoWS指标参数在交付质量中的值(可以为空,即该指标所约定的不是交付值),valuei为第i个QoWS指标参数在约定质量中的值。
[0218] 对于1)和2)的结果:
[0219] 如果Edi为非负数,则说明该交付质量参数达到约定标准的程度; [0220] 如果Edi为负数,则说明该交付质量参数未达到约定标准的程度。 [0221] 2.对于在SLA中所约定的感知质量参数的计算方法
[0222] 1)对于正参数,即参数值越大所反映的服务质量越好
[0223]
[0224] 2)对于负参数,即参数值越小所反映的服务质量越好
[0225]
[0226] 其中,Epi为第i个QoWS指标参数的感知值与约定值相比的程度,valuepi为第i个QoWS指标参数在感知质量中的值(可以为空,即该指标所约定的不是感知值),valueai为第i个QoWS指标参数在约定质量中的值。
[0227] 对于1)和2)的结果:
[0228] 如果Epi为非负数,则说明该感知质量参数达到约定标准的程度; [0229] 如果Epi为负数,则说明该感知质量参数未达到约定标准的程度。 [0230] 同时,评价模块还能够对计算结果进行分析,以客观评估服务质量。例如,如果感知质量没有达到约定标准,评价模块可以从交付质量、感知质量和传输质量三方面进行关联分析,以得出服务质量是在服务提供者端、服务使用者端或网络传输中的哪个环节出现了问题;
[0231] 步骤F12:对单次服务会话的质量进行综合评估,其计算方法为: [0232] SingleE为服务会话质量的评估值,m为QoWS指标的个数。值得d p
注意的是Ei和Ei必有一个值为空,即第i个QoWS指标参数要么约定为交付值,要么约定d p
为感知值,因此用Ei表示Ei或Ei。
[0233] 步骤F2的分解:
[0234] 步骤F21:对各个QoWS指标参数的长期评估,即生成QoWS指标的统计值,其计算方法为:
[0235] 1)对于QoWS指标参数交付值的统计:
[0236] SQoWSdi为第i个QoWS指标参数的交付统计值,n为服务会话的个数。
[0237] 2)对于QoWS指标参数感知值的统计:
[0238] SQoWSpi为第i个QoWS指标参数的感知统计值,n为服务会话的个数。
[0239] 步骤F22:对各个QoWS指标参数达到约定值的程度进行评估,其计算方法为: [0240] SEi为第i个QoWS指标达到约定值的程度,n为服务会话的个数。
[0241] 第i个QoWS指标参数要么约定为交付值,要么约定为感知值,因此可以用Ej表示d pEj或Ej。
[0242] 以响应时间为实例的监测过程描述为:客户通过IE6.0浏览器对StockQuoteService服务的getPrice操作进行101次调用,每两次调用之间的间隔时间为
1秒。分别从服务端和客户端监测该服务操作的交付响应时间和感知响应时间,并生成传输时间。(由于Web服务需要加载和缓存,故服务在处理客户首次请求时需要花费较多的时间进行相关实例化操作。因此排除首次调用的记录)。以其中一次服务会话为例,实验结果如下表所示。
[0243]
[0244] 统计(交付)响应时间:通过步骤F的方法,即 对100次服务会话的交付响应时间进行均值计算,结果为3768微秒。
[0245] 服务评价过程:由于该实例中只包含响应时间一个QoWS指标,故对该次(如上表所示)服务会话响应时间的评估等同于对该次服务会话质量的评估,同时对对服务响应时间的长期评估等同于对服务质量的长期评估。其结果分别为:
[0246] 1)通过步骤F11的方法对该次服务会话的响应时间进行评估,即其结果是交付响应时间达到约定值,且优越约定值3个百分点;
[0247] 2)通过步骤F22的方法对服务响应时间的进行长期评估,即 100次监测的结果是平均交付响应时间达到约定值,且优越约定值13个百分点。
高效检索全球专利

专利汇是专利免费检索,专利查询,专利分析-国家发明专利查询检索分析平台,是提供专利分析,专利查询,专利检索等数据服务功能的知识产权数据服务商。

我们的产品包含105个国家的1.26亿组数据,免费查、免费专利分析。

申请试用

分析报告

专利汇分析报告产品可以对行业情报数据进行梳理分析,涉及维度包括行业专利基本状况分析、地域分析、技术分析、发明人分析、申请人分析、专利权人分析、失效分析、核心专利分析、法律分析、研发重点分析、企业专利处境分析、技术处境分析、专利寿命分析、企业定位分析、引证分析等超过60个分析角度,系统通过AI智能系统对图表进行解读,只需1分钟,一键生成行业专利分析报告。

申请试用

QQ群二维码
意见反馈