Web服务鉴定

2002-8-26 11:18:36【作者】 畅享网 【进入论坛】
广告

Web服务鉴定  

--Web服务的推荐系统和反馈机制


Scott Weller(scweller@us.ibm.com

Consulting IT Architect,IBM

2002 年 4 月

在实际应用中,Web 服务维持着一种复杂的均衡环境。本文将探究对初始化选择以及作为正在进行的提供者/消费者关系的一部分的 Web 服务进行鉴定的机制。

动机

Web 服务的承诺之一是可以交换“等同的”提供者而不会损失功能。如果提供者 B 和提供者 A 实现相同的接口,那么提供者 B 就可以替换掉提供者 A。我们自然期望在这样的提供者之间语义解释和操作都能保持一致。

但是,提供者不可能等同,尤其是在非功能性的意义上。而且一旦选择了某个提供者,就形成了一种关系,尤其对于企业关键的服务和那些需要锁定重要资源的服务(例如,在对等计算和网格计算中)。正如真实世界中一样,不论是医生、自动机器还是电话公司,都有可能逐渐习惯特定的提供者、交互模式和选择替代品的方式。

请考虑一下在搬家时寻找一位新的医生的问题。通过寻求推荐或搜索提供者名录来寻找符合某些特定条件的提供者(请想想 UDDI)。然后安排一次访问,从而“测试”这位医生。在 Web 服务机械的世界中,正确的结果(在这种情况下,医生提供正确的诊断)会满足交互。当然,有时您更倾向于另一种观点,甚至对于 Web 服务也是这样 — 在后文中会有更多内容。

当然,医生不仅仅是诊断引擎;作为人类,他们具有特殊交互技巧,处于特定环境中,可用性不断变化,等等。可能是这些其它值的复杂的加权总和决定您究竟是接受这位新医生还是继续搜索。万一在这段时间内您生病了,您可能还会回去找我们以前的、已经确定的医生。

就其(portType)定义来说,等同的 Web 服务确实是可交换的。尚未得到说明的是企业实际上将如何利用这种灵活性进行操作。企业可能会从咨询对 UDDI 注册中心中的企业条目评级(Web 服务 Consumer Reports?)的第三方开始。一旦选择了一个提供者,在试验提供者 B 的同时,企业可能继续使用提供者 A,不断比较结果,直到确信提供者(在功能上)确实是等同的。但是还有一些其它因素:提供者 B 也许能更快的计算结果,或者在高峰时期提供者 B 有时可能会不响应,或者提供者 B 的计算能达到更高的精度。另外一方面,提供者 B 可能会向客户收取服务费用,并且当服务没能以定时的方式提供时,提供者 B 可能会暂时将该客户“列入黑名单”,或者也许会拒绝任何占用资源较多的请求。

目前还没有对 Web 服务进行鉴定和惩罚的机制。本文提出了两种对 Web 服务进行鉴定的方式:对初始化选择进行静态鉴定,然后对正在进行的提供者/消费者关系进行动态鉴定。此外还提出了支持客户和提供者之间鉴定的 SOAP 头。

静态鉴定

正如上面所描述的,Web 服务选择本身很可能成为重要过程。一种显而易见的方法是,确定独立的服务鉴定者(即 WS 评级服务)对 UDDI 注册中心或 WS-Inspection 索引所指向的 Web 服务进行评级。这样,发布/查找/绑定过程就变成了发布/鉴定/推荐/绑定,如图 1 中所示。

图 1. 发布/鉴定/推荐/绑定


 

不那么正式,但更具活力的方法是使用基于 eBay 模型的评级系统,这种情况下消费者向独立的代理反馈,该代理则根据一组(实际的)标准认证规范累计分数。在这个例子中,累积的平均评级就成为认证的因素。发布/查找/绑定过程被扩展成如图 2 中所示包括鉴定,图中认证代理根据评级推荐服务;然后由消费者绑定、使用并最终提供它自己关于该服务的评级(即“鉴定”)。

图 2. 发布/查找/推荐/绑定/鉴定


 

您可以想象服务鉴定者或评级资源库本身就是 Web 服务,文档型 SOAP 消息在头块中传送按实际的或正式的标准所认可的鉴定维度。鉴定维度可能会包括下面列举的几个方面的 QoS(请参阅 Mani and Nagarajan),正如将要在 Service Level Agreement (SLA) 中指定的一样。

可用性(Availability)

可访问性(Accessibility)

完整性(Integrity)

性能(Performance)

可靠性(Reliability)

SOAP 头看上去可能象清单 1 这样。

清单 1. 静态鉴定的 SOAP 消息头

   <q:Envelope xmlns:q=...>
       <q:Header>
            <v:S-qualification xmlns:v=...>
                 <v:Availability value="9999" />
                 <v:Accessibility value="AsAdvertised" />
                 <v:Integrity value=... />
                 ...
            </v:S-qualification>
       </q:Header>
        ...
   </q:Envelope>

鉴定者的值可能是与所宣传的值相比较的绝对值(例如,在 UDDI 企业注册中心条目中),或者它们也可能仅仅指出质量是否与所宣传的相一致。

为了方便查找替代提供者,推荐或查找交互的 SOAP 消息中可能会有以前用过的(而且是现在不用的)提供者列表(空表可能表示第一次“查阅”)。

动态鉴定

一旦选择了一个 Web 服务,在其使用生命周期内,您怎样维持这种关系呢?对于商品服务,也许这不能算是问题。但是,对于企业关键的功能,由于非性能原因突然舍弃是站不住脚的。如同人类社会的交互中一样,Web 服务交互也包括那些为了使企业业绩最大化而必须不断被集成的功能性和非功能性方面。

例如,一家金融公司不可能因为意外而短暂的服务器故障就舍弃一个重要的服务提供者。但是,如果故障发生变得很频繁,那么这种关系就会受到损伤,并且这家金融公司最终将会选中新的提供者。同样,也不可能因偶而延迟支付而舍弃重要的客户。但是,如果应收账款增加,那么服务提供者将把该顾客降至较低的服务质量(Quality of Service,QoS),或者甚至会拒绝需要锁定重要资源的服务请求,直至重新建立财务信用。

动态鉴定主要针对从提供者和消费者的角度来看都是非 Web 服务功能性的方面,包括但不限于 SLA 中所确定的那些。如静态鉴定中提到的,很可能在服务交互的 SOAP 头块中传送鉴定维度。例如,我们可能会在下面的清单 2 鉴定维度之上使用一个简单的“好的或差的”评级系统(当然可以使用更粒化的列举的评级系统)。

清单 2. 动态鉴定的 SOAP 头

   <q:Envelope xmlns:q=...>
       <q:Header>
            <v:D-qualification xmlns:v=...>
                 <v:QoSasAgreed value="thumbs up"  />
                 <v:PaymentsInGoodStanding value="thumbs up" />
                 <v:LockedResoursesNotIdle value="thumbs down" />
                 ...
            </v:D-qualification>
       </q:Header>
        ...
   </q:Envelope>

 动态鉴定有着广泛的含义。人们可以想象一个服务提供者要求管理层的监督职能监视对其服务满意程度的整体状况,同样,服务消费者将不得不监视响应的非功能性方面以提供持续的反馈。从企业集成的立场而言,这会导致需要 CRM、金融和 SLA 一致性监视系统与提供或消费企业关键的 Web 服务的应用程序之间建立联系。对于交互端点(也就是说,并非 SOAP 消息本身的一部分)而言,评估鉴定维度所要求的计算(尤其是用于动态替换提供者或拒绝为消费者提供访问的机制)是至关重要的实现问题。

如同人类社会相互交流,会有一个机会进行“博弈”,并且有博弈理论响应。例如,服务消费者可能想要最大吞吐量,但是只付基本服务费用。他或她的“策略”是总是抱怨 QoS,起先服务提供者会改进这一维度。随着时间的推移,这一“策略”被识破,而“差的”成了“没有信息”。以牙还牙或者更好些“带容忍的以牙还牙”是对这种丢卒保车策略的可靠响应。

结束语

静态和动态鉴定分别针对 Web 服务选择以及在服务提供者和消费者之间正在进行的关系。

动态鉴定提供一种非舍弃的交互方式,其目的在于以一种半自动化的方式来解决非性能方面的问题。动态鉴定通过提供预报和提醒机制来加强在描述 Web 服务合约和协议方面所做的工作。

 致谢

特别感谢 Rawn Shah(rawn@us.ibm.com)和 Veronika Megler(vmegler@us.ibm.com)提出了深刻的评论和建议。

参考资料

  • 请单击文章上部或下部的讨论参加关于本文的讨论论坛
  • 关于 Web 服务的一本优秀的初级读物是 Programming Web Services with SOAP(作者 Snell、Tidwell 和 Kulchenko,O'Reilly 出版)。
  • 若需要博弈理论的介绍,请参阅 Game Theory(作者 Morton Davis,Dover 出版)。
  • 有关指定和使用 Web 服务中的 QoS 的非常好而且相关的文章是 理解Web服务的服务质量(作者 Mani 和 Nagarajan)。

关于作者

Scott Weller 是 IBM Global Services 的 Consulting IT Architect。他在软件开发方面有十八年的经验,包括交互设计、体系结构、团队领导、项目管理和技术策略。Scott 是著名的发明家,他有三项电子商务解决方案提交专利存档。您可以通过
scweller@us.ibm.com 与 Scott 联系。

如果您希望与本文章的作者或其所在机构,进一步交流,请联系:畅享网 姜小姐
jill.jiang@amteam.org | 021-51096826-112 | 在线联系
老孙的IT运维管理之道[原创]用户的BSM用户的IT业务管..

从企业实际的IT运营角度来看,BSM是推动IT与业务融合,实现、改善WCNG司IT管理和治理的最佳实践之一。

吕建伟 专栏和CIO问答软件项目实施管理

现实中很少能按照正规流程来的,所以只能把流程中的各个环节拆开,个个击破,以后就可以见招拆招了。

节能与优化IT 企业CIO过冬良策

当前金融危机的影响还在继续漫延,很多企业都在苦寻过冬的良策,在这种情况下,节能与优化技术与产品无疑成为CIO们关注的首要对象,本次选题就是针对节能与优化IT来为CIO们提供过冬的良……

观08软件并购风潮 议09巨头何处生花

2008,似乎注定是不平静的一年。有人说2008是并购年。业内人士表示,在全球软件行业,并购一直是大企业谋求做大做强的捷径之一,包括甲骨文、SAP,微软等全球软件巨头都为了扩大自己……