|
参数类型的处理由web 服务调用模块来完成。 由于本地客户端桩代码使用Axis2 的WSDL2JAVA 工具生成，因此WSDL 解析模块 在解析服务对应的名称、操作名称以及操作参数的名称完成后，需要将这些解析的 名称和服务对应的客户端桩代码的类名称，服务操作在服务类中对应的类名称，服 150 务操作的参数在服务操作类中对应的赋值函数名称一一对应。解析的结果封装成 Java 类的实例。对于数量很少的WSDL 文件数目，可以把封装之后的实例保存在内 存中供web 服务调用模块直接调用，服务搜索引擎Seekda.com[6]搜索了将近3 万的 公共服务，如果把对所有的这些服务的解析结果都保存在内存是不现实的，因此 WSDL 解析模块将Java 实例序列化为本地二进制文件，这样不仅减少对内存的需求， 155 同时避免重复解析，降低资源的消耗。 3） 解析完成后，对于没有出现解析错误的服务WSDL 文件，通过Axis2 的WSDL2JAVA 工具生成每个Web 服务对应的Java 客户端桩代码。 4） Web 服务的调用的具体流程如图2 右侧流程图所示。首先将由WSDL 解析模块保存 在本地的一部分解析结果反序列化为java 实例加载到内存中任务队列，然后从队列 160 中依次取任务开始对客户端桩代码的类进行实例化。我们采用了java 的反射机制， 根据解析结果从客户端桩代码中获得服务对应的客户端桩代码的类，服务操作在服 务类中对应的类，然后分别实例化。 WSDL 解析模块只解析操作参数的名称并没有解析服务操作参数的类型,web 服务调 用模块中利用如3 所示的流程获取并实例化服务操作的参数，同样利用java 反射机 165 制，获取服务操作参数对应的赋值函数的参数类型，如果参数类型不是基本的java 类型，则将参数类型实例化，并将实例化的参数压入参数实例栈中，如果参数类型 是基本的java 类型，则将参数赋值，然后从栈中弹出参数实例，用上次赋值的参数 将弹出的参数实例赋值，依次完成直到栈空，最后完成对服务操作参数的赋值。 170 图 3 服务操作的参数赋值具体流程 每调用完成一个服务的操作则记录调用服务操作的响应时间，调用完成服务的所有的操 作，则通知服务属性更新模块和测量节点位置更新模块进行相应的更新，并把更新结果 存储的Web 服务属性存储器中存储。 175 考虑到web 服务质量的动态变化特性，web 服务的调用是不间断循环进行，直到系统退 出，或者接收到任务调度节点的暂停消息为止。 1.2.2 用户端服务质量的预测流程 引言中介绍了web 服务质量具有地域相关和依赖用户的特性，这些特性导致不同用户 调用同一个服务的同一个操作所需要的响应时间有所差异，主要原因是服务调用需要经由网 180 络传递soap 消息来完成服务请求和响应的传送，传递soap 消息的时间是和网络延时相关的。 所以如果在已经测量web 服务的逻辑程序在web 服务部署节点上的运行的时间的基础上， 能预测出soap 消息从服务部署节点到服务用户节点的传输时间，即可完成对用户调用服务 所需响应时间的预测。 实际上调用服务的响应时间除了包括soap消息的传输时间和web 服务操作的执行时间， 185 还包括soap 消息的解包和打包时间，但是由于打包和解包时间太短不容易分离和测量，则 将它们合并为web 服务操作的执行时间当中。 用户端服务质量的测量是由服务测量节点和RTT 估测器共同完成的。 1） 首先任务调度器接收用户的请求后，根据任务分配策略将用户请求控制信息分配到 合适的Web 服务测量节点，以使测量节点完成用户的网络定位。 190 任务分配策略有两种： 从已启动的服务测量节点中随机选取五个节点来测量本节点到用户端节点的网络 延迟； 从距离用户节点地理距离最近的已启动的服务测量节点中选取五个节点来测量本 节点到用户端节点网络延迟。 195 实验证明第二种任务分配策略的预测准确度较高。由于网络距离不能等同于地理距 离，因此当用户节点到某一个选中节点间的网络状态极差时，这种任务分配策略的 预测准确度会有所降低。 2） 已选中的服务测量节点接收到包含用户IP 地址的用户请求控制信息，用户网络距离 测量模块向用户机器发送Ping 消息，测量本测量节点到用户节点的网络距离，并将 200 消息往返时间发送到RTT 估算器。 3） 服务质量测量流程和用户端服务质量的预测流程是两个独立的过程，Web 服务调用 器调用完成一个服务，通知测量节点更新测量节点在网络中的位置。测量节点位置 更新完成后更web 服务的网络位置，测量节点向服务部署节点发送ping 消息以得到 测量节点到服务部署节点的网络延时，通过该测量时延更新服务部署节点的坐标， 205 具体网络位置更新算法在本文中不再阐述，该算法是一种基于Vivaldi 算法的更新服 务资源虚拟位置的算法。更新后的结果最终存储到web 服务属性存储器中。测量节 点的位置更新和服务的位置更新必须同步进行，实验表明两者的更新不同步会导致 预测准确度下降，因为服务的位置更新是根据测量节点的位置确定的，所以如果服 务的位置更新之前测量节点还是旧的那么服务的位置的定位误差加大。 210 4） 整个系统采用的网络模型为欧几里得空间，因此由服务测量节点和服务测量节点到 用户节点的网络距离和服务测量节点的网络坐标即可计算出用户节点的网络坐标， 完成用户节点的定位。RTT 估测器接收到所有的被调度测量节点返回的用户网络距 离或者定时器超时，从web 服务属性存储器中获取所有的被调度的服务测量节点的 网络位置，结合服务测量节点到用户节点的网络距离计算出用户的网络位置。然后 215 从web 服务属性存储器中获取web 服务的网络位置。由用户的网络位置和web 服务 的网络位置即可计算出soap 消息从用户端用web 服务所需的响应时间，最后结合测 量的服务执行时间，估算出用户端调用web 服务的响应时间，完成最后的估算工作。 2 实验结果 2.1 实验平台 220 PlanetLab[7]是一个开放式全球性实验平台，此平台在全球部署了上百个节点，提供了一 个真实的分布全世界的实验环境，因此本系统采用PlanetLab 作为我们系统的测试环境，从 PlanetLab 选取的17 个节点中分别部署主控节点和多个服务质量测量节点，以采集服务在不 同地理位置的服务质量，为了达到实验的真实性和提高预测的准确度，这些选取的服务质量 测量节点尽量分布在全球各地，并且在web 服务分布多的地点部署较多服务质量测量节点。 225 2.2 结果验证 为了更好的说明实验验证结果以及更真实的验证方法的准确性，本节用我们的估测平台 来对分别在部署地为美国、欧洲的服务在同一用户端被调用的响应时间进行预测，可以很好 的说明我们的实验验证具有一般性。 表1 web 服务属性列表 服务名称 操作名称 参数名称 服务位置IP 服务地理位置 StockQuote getQuote GetQuote 173.201.44.188 美国 GeoAddress addressSimple addressExSimple address addressEx addressAdvanced available AddressSimple AddressExSimple Address AddressEx AddressAdvanced Available 195.225.101.171 荷兰 235 系统对服务StockQuote 和GeoAddress 在估测目标用户节点（IP 地址为211.68.70.36， 位于中国）上调用需要的响应时间，进行了持续12 个小时的实验预测。为了验证预测结果 的准确度，在估测目标用户节点上同时对两个服务进行实际调用，并记录了调用实际花费的 时间，如果实际调用时间和预测时间能吻合，则说明我们系统对服务质量的预测准确可靠。 图4 显示了估测目标用户节点调用服务StockQuote 的getQuote 操作响应时间的实际测 240 量值和预测值的对比图，图5 显示了估测目标用户节点调用服务GeoAddress 的addressEx 操作响应时间的实际测量值和预测值的对比图。由图可见，预测值和实际测量值的曲线基本 吻合，在误差范围内。由此可以表明我们的方法可以比较准确的预测用户调用服务获得的服 务质量。 245 图 4 节点211.68.70.36 测量的服务StockQuote 的getQuote 网络延迟预测值和测量值 图 5 节点211.68.70.36 测量的服务GeoAddress 的addressEx 操作网络延迟预测值和测量值 250 由于估测目标用户节点对服务的实际调用和系统对估测目标用户节点调用服务所得服 务质量的预测过程是两个完全独立的过程，所以上面两图的测量时间点和预测的时间点不能 完全重合，但是图中两条曲线的递增和递减的趋势一致，从而说明我们的方法能够较准确的 预测出web 在用户端呈现的服务质量。 3 相关工作 255 论文[8]提出了一种采用分布式的Web 服务QoS 测量方法，该方法从世界不同的地理位 置采集Web 服务的QoS 属性信息。该方法很好的结合了Web 服务QoS 与地域相关的特点， 但是事实上即使一个地区地理位置相离很近的两个用户节点调用同一个服务得到的服务 QoS 也是会有差异的，有时这种差异还很大，主要原因是调用Web 服务的服务QoS 不仅和 用户到Web 服务的部署位置的距离有关还和用户机器所处网络环境的状况有关，所以仅仅 260 依靠用户节点和服务部署点地理位置不足以预测服务质量。和我们的工作不同，论文[8]的测 量目的只是获得web 服务在分布节点上被调用时的服务质量数据，并没有获得web 服务在 用户端被调用时的服务质量，它的最终目的只是为验证基于web 服务QoS 的技术和模型的 正确性提供了QoS 数据集，而我们的目的是不需要用户参与的前提下得到用户端调用服务 时可以获得的web 服务的QoS。 265 论文[9]提出了一种自动测量web 服务质量的工具，这种工具采用集中测量方式，安装在 客户端，用户可以通过客户端软件测量服务在用户节点上被调用时可以获得的服务质量。我 们的测量方式则采用分布式测量，不依赖用户，也就是用户端不需要安装任何客户端程序， 只需要通过浏览器就可以获得服务在用户端上被调用可获得的服务质量，用户还可以指定估 测目标节点，因而我们的系统灵活性和实用性更强。 270 本文提出的web 服务质量估测平台中用到的算法将不在本文中阐述，算法是一种结合 了网络测量的新颖的预测服务质量的方法，是在实际测量数据的基础上进行的预测，即考虑 学术论文网Tag：代写代发论文 论文发表 计算机论文 职称论文发表 |
