Web 服务测试论坛 (WSTF):架起承诺与现实之间的桥梁

基于 SOAP 的 Web 服务自许多年前创建以来已经走过了漫长的道路。最近,新规范的制定数量已减少许多,这使得社区有时间停下来深入研究已开发的基本基础结构。是否实现了 Web 服务的互操作性承诺?使用 Web 服务规范是否真的像预期的一样方便?本文将讨论这些问题,并介绍 Web 服务测试论坛 (WSTF)。WSTF 是一个基于社区的新论坛,目的是为了解决 Web 服务的互操作性问题。

Doug Davis, 架构师, IBM

Doug Davis 是 IBM Software Standards 部门的架构师。他以前担任过的职务包括 Emerging Technologies Toolkit、WebSphere Machine Translation、Team Connection 和 IBM Fortran 90 的技术总监。



2009 年 2 月 05 日

WS-* 系列规范的状态

尽管 Web 服务规范有时确实可以按预期工作,但是如果要定期使用它们,则您遇到的多数情况可能是它们不能如期运行。这很容易引起一些抱怨:规范太复杂,涉及内容太多,选项太多,规范作者和编码人员受资源约束,等等。尽管其中每个问题可能具有某些正确性,但是在许多情况下,一般性评论还可能适用于您从事的其他项目。本文将尝试深入研究一些与 Web 服务互操作性相关的基本问题。

大多数 WS-* 规范符合以下流程:

  1. 制定新的 WS-* 规范。
  2. 执行一些互操作性测试。
  3. 将规范带到标准组织。
  4. 执行更多互操作性测试。
  5. 完成后加上时间戳。

此流程的服务相对较好,但是,即使核心规范集并非始终对我们的客户即时可用,必定仍会缺少某些内容。

本文将探索缺少的内容可能是哪些,并介绍一个被称为 Web 服务测试论坛 (WSTF) 的新计划。WSTF 的目标是将 Web 服务社区的参与者集合起来并为他们提供论坛,以便讨论和解决他们面临的与规范互操作性相关的共同问题。


妨碍成功的障碍

可以提高 Web 服务的易用性和互操作性,而当前流程中不存在的三项内容为:

  • 客户参与
  • 长期的测试策略
  • 分享想法和关注内容的正式社区

客户自己动手

当前流程中缺少的关键内容之一是客户。尽管规范作者可能声称心中有客户及其场景,但是如果有大量客户无法在正常情况下使用最基本的资料,则显然会缺少一些内容。

满足客户需求应考虑许多方面。最基本的方面是仅满足客户的功能需求(例如,确保 SOAP 可靠地获得从点 A 到点 B 的消息 X)。除此之外,满足客户需求还有一些较小和较抽象的方面。

其他需求示例包括以下内容:客户有一个地方向多个 Web 服务供应商询问如何展开工作,以便询问者获得全面的回答。或者,能够快速看到多个实现与共同使用模式有何关系,而无需向每个供应商打电话,并询问他们设置测试环境所需的天数(或周数)。

这些较小和较抽象的客户需求实际上共同扮演着更重要的角色,从而确保 Web 服务社区实现其目标。遗憾的是,社区通常会忽略这些需求。

缺少全局的测试策略

另一个可能妨碍成功的障碍是如何设置互操作性和验证过程本身。测试的目的是验证 SOAP 端点可以发送和使用的规范内容,还是验证该规范可以与其余 Web 服务堆栈组合在一起,并实际满足客户需求?过去,测试的目的过分集中于前者,这就是为什么在测试事件中通常存在非常少的互操作性问题。

当侧重点是仅测试在网络中传输的 XML,而不是尝试解决高级业务问题时,很容易犯缺少全局性的错误。因此,当客户超出严格的脚本场景和测试场景时,工作会立即停止——即使考虑的用法是一般用法。

另外,当前互操作性测试的时间点 特性中还存在一些固有问题。在上面列出的过程中,规范将检查许多互操作性测试工作。这些工作暂时可能非常出色,但采用哪些措施来确保在完成这些活动后一切可以继续进行?再现这些互操作性环境可能非常耗时,并且通常需要其他供应商产品的知识。这两个因素会限制此方法作为长期解决方案的成功和高效性。

没有地方进行客观的讨论

请注意,上述内容并不意味着对过去执行的工作的批评。通过许多个人和团队的努力工作,已产生许多优秀的规范。来自许多不同公司和组织的众多人员汇集在一起来制定标准,这本身就是巨大的成功。不过,像大多数事情一样,只要努力工作,事情就会有起色。

Web 服务社区缺少的内容就是一个地方,将各种角色的成员汇集在一起,来讨论测试和其他与 Web 服务相关的问题。例如,Web 服务器供应商、ISV 或客户没地方去询问广大社区人员的问题。大多数的其他地方都具有本质上的局限性。向特定供应商提出询问时,得到的回答自然偏向于对该供应商自已产品的功能。


新计划

为帮助解决 Web 服务互操作性测试的一些当前问题,并排除上述障碍,已启动新的计划:Web 服务测试论坛 (WSTF)。WSTF 是基于社区的论坛,形式与开源社区类似。参与者可以自由建议新的互操作性测试方案,以及测试他们认为非常重要的方案。这是一种非常简单的想法,但下面的详细团队信息应有助于解释这一想法如何提高过去执行的操作。

成立 WSTF 最初的目的是为了执行在其他地方无法执行的基于场景的互操作性测试。具体说来,这是一种组合测试,其中对一组规范一起进行测试,以确保它们按预期方式真正组合在一起。不过,在运行这些较高级的组合测试之前,必须验证:1) 个别规范自身运行良好,2) 提出的场景不只是单个开发人员的想法,而且它基于实际的客户需求。

有了这一简单的想法后,就诞生了 WSTF。在最基本的层次上,WSTF 是一个供 Web 服务社区的所有成员讨论测试和任何与 Web 服务相关的其他问题的地方。


侧重于讨论测试的社区

仅为人们提供询问问题和讨论想法的论坛无法解决互操作性问题。论坛需要具有核心和目的。这就是 WSTF 的以客户为中心的场景提供的价值。

与以前的互操作性工作不同,WSTF 旨在验证和检查客户实际使用的场景和使用模式。Web 服务规范的作者总是含蓄地声明执行此任务,但是对各种标准创作活动的记录的检查清楚地显示缺少客户参与。这样会不可避免地导致较长时间(有时非常激烈)地讨论应该或不应该支持哪些规范。对场景本身的争论也很普通。在讨论中让客户直接参与对减少一些压力和流程长度大有裨益。

基于客户需求的测试场景

遗憾的是,互操作性场景通常止步于最具竞争力的 Web 服务供应商可以支持的内容。这将导致基于一个或多个供应商代码的场景,而没有客户需求。WSTF 将尝试更改这种情况。WSTF 希望从业务问题开始,应用适当的 Web 服务规范,然后进行测试——几乎与过去的流程相反。

互操作性测试的目标不应该验证场景是否可以互操作,而应该验证规范实际上是否满足客户在互操作性方式中的需求。完成此目标需要以前互操作性工作中没有的内容:客户。WSTF 的成功将取决于是否客观地将实际客户需求融入工作目标中。在理想的情况下,通过让客户自已加入团队,并提供关于场景的建议和指导可以做到这一点。当推出 WSTF 时,它已具有多个客户,这些客户都是该团队的一部分。客户的角色是为场景提供想法,并帮助该团队侧重于实际业务需求。

当前测试的场景数量很少,但是关注重点的改变已暴露以前互操作性测试中从未注意的多个互操作性问题(和严重的设计缺陷)。因此,即使在以前的所有成功测试中,也忽略了一些严重的问题。而且,这是由于以前的测试侧重于功能的特定实现,而不是侧重于测试这些功能是否实际可用并满足客户的需求。结果是客户成为发现这些问题的第一人——当然,这对谁都不是好事。

功能测试的基础

尽管以客户为中心非常重要,但是务必注意,传统的功能测试 在整体设计和 WSTF 中也有其一席之地。如果将功能测试视为一组构造块,则该功能测试是所有其他测试的基础。这意味着当 WSTF 尝试以高于过去的层次进行测试时,还必须继续确保 Web 服务规范基础本身是良好的。

就实践而言,这意味着过去测试的大多数场景将逐步被带入 WSTF。这将提供从以前的测试工作到 WSTF 的转换。参与以前的互操作性活动的供应商应该能够使用 WSTF 中的相同代码进行这些功能测试。这还将为回归测试提供支持。

长期存在的端点

以前的互操作性测试工作是时间点声明。如果成功,则测试将证明某一组实现可聚集在一起,并互操作一次。不能保证测试以后会继续正确地工作,也没有用于新实现的方法,以验证它们是否可以与其他任何人进行互操作。每种实现都可以(或可能)在内部 建立其他实现来执行此互操作性测试,但这是一项非常昂贵和耗时的工作——每个供应商都需要进行复制。WSTF 将尝试减少此开销,方法是提供对整个社区可用的共享和长期存在的测试端点集。

长期存在 端点的想法可以将 WSTF 从其他 Web 服务测试工作中区分开来。在 WSTF 中,每种场景都具有一个支持该场景的端点列表。通过承载和列出端点,每个实现不仅按描述情况支持场景,而且还尝试让其他人随时可用这些端点。这意味着在 WSTF 中完成的测试不是在某个时间点可行,它是一项连续测试工作。

当供应商更新产品或开发新的实现时,他们可以使用端点来验证他们的新代码是否工作,并确保没有将错误引入现有实现中。尽管这在过去由每个供应商通过承载其他供应商的实现就做到了这一点,但是 WSTF 允许真正的专家承载他们自己的代码——让开发人员放手开发他们自已的实现。

WSTF 可提供指向端点本身的 URL,而不是提供规范的实际实现。这意味着供应商可以测试尚未发布的代码。在验证最新版本未出现任何退化之前,他们不再需要等待,直到其他供应商的产品公开提供。

前瞻性场景

除已讨论的两个测试视图外(以客户为中心和以规范为中心),WSTF 还提供了第三个视图:前瞻性 场景。前瞻性场景尝试按过去未使用的方法使用规范。这可以作为一种尝试,先于实际开发一步,这样供应商可以在客户使用之前发现问题。

前瞻性测试与执行新的组合测试一样简单——一起测试以前未测试的 Web 服务规范。例如,WS-ReliableMessaging 和 WS-Transaction 已使用多年,但是将二者一起使用时,从未执行过任何正式测试。没有理由预测它们不能够很好地组合,但是在实际执行测试之前,仍然是不确定的。

前瞻性场景的另一种类型是在当前 Web 服务体系结构中公开漏洞。这些场景最有可能通过描述业务需求开始。然后,在尝试确定哪些 Web 服务规范最适于解决该问题的流程时,社区可能认识到需要新东西。

避免供应商锁定

今天,当出现与 Web 服务规范相关的新需求时,开发的解决方案通常是特定于供应商的。与特定的 Web 服务供应商协作的客户也许能够开发出满足其目前需求的解决方案,不过,它一般只局限于一个实现。这意味着,可以互操作(甚至可移植)的解决方案的可能性将显著下降。这最终会挫败 Web 服务的主要卖点之一——缺少供应商锁定。

通过为 Web 服务社区提供方便讨论想法和问题的地方(别处无法提供),WSTF 将提供一种方法,以避免创建无法互操作的解决方案。Web 服务社区的大多数其他论坛侧重于某一规范的开发,或侧重于特定的实现。就本质而言,这些论坛中的讨论具有局限性或偏差。因为 WSTF 是社区驱动的,并且对每个人开放,所以讨论可以在那里继续,否则不可能发生。

例如,对于前面所述的特定于供应商的解决方案,如果改为在 WSTF 中进行讨论,则多个供应商都可以参与。如果存在不需要任何形式创造(新的 Web 服务规范)的解决方案,那么一起工作的所有供应商可确保该解决方案不会将客户锁定到一个特定产品中。如果使用现有规范无法解决问题,则社区可以确定需要新的 Web 服务规范(也许是 Profile,或者更改现有规范)。单个供应商最好从整个社区进行参与,并生成一次性类型的解决方案,将客户锁定到一个实现选择。

WSTF 不是一个规范制定组织,但它可提供一个进行初始讨论的地方。随着讨论的进行,WSTF 的成员(较多时为 Web 服务社区)可决定举办其他适当活动的时间和内容。


结构和治理

WSTF 实际上是一个非常简单的轻量级组织。在其核心中,Web 站点仅包括一组场景。场景由成员自已管理,有些类似于传统的 wiki 站点。任何成员可以在任何时间修改任何文档——类似于开源模型。

隐私的重要性

WSTF 和典型的开源模型之间的一个主要区别是 WSTF 的隐私 特性。在开源模型中,所有的工作对全球可视。由于一些非常重要的原因,WSTF 中的大多数工作以秘密方式执行。

WSTF 隐私特性的最重要原因是由于成员希望进行自由和开放的讨论,而不用担心任何负面影响。成员应该能够讨论新的想法、问题、甚至产品的缺点,而不必担心以后可能会以某些消极方式利用这些讨论反对他们。出于这个原因,新成员签署的参与协议包括以下两个基本概念(有关完整的详细信息,请参阅实际协议):

  • WSTF 中所述(或完成)的任何内容对 WSTF 是专有的。此规则的一个例外是场景发布(下面是详细信息)。
  • 在讨论过程中引入团队的任何内容(例如,有关场景的想法)都是在免版税条件下引入团队的。这可以保护团队成员不被其他成员因专利侵权而控告。

发布成熟的场景

如上所述,场景是非 WSTF 成员可以看到的唯一内容。场景达到某一成熟 度后,该场景的实现人员可以进行表决,以允许非 WSTF 成员查看——即他们同意发布场景。WSTF 章程中定义的成熟场景满足以下条件:

  • 处理场景的 WSTF 成员同意发布场景——如何决定完全由他们自己负责。
  • 场景至少有五种不同的实现。
  • 至少三分之二的实现人员同意发布场景。

就很多方面而言,此审批过程类似于开源社区如何表决是否发行新的代码版本。所不同的是,在 WSTF 中未发布的场景对非成员不可视。其原因在于如果 WSTF 成功,并成为整个 Web 服务社区联合开发互操作性场景并进行测试的地方,则需要较安全的网络。WSTF 的创始人需要确保组织真正基于社区,而不是被一两个大供应商控制。

在发布之前,对场景要求的条件最少,这样可以保证 WSTF 发布的场景 获得广泛的社区支持。如果所有的场景对每个人立即可用,则不可能知道某个场景是可以实际互操作的场景并由许多供应商支持,还是仅为一个供应商的解决方案,并可能导致锁定

需要重点注意的是,场景的发布对围绕场景进行的测试结果没有太大影响。发布的场景和未发布的场景具有相同的 WSTF 可用功能——唯一不同是非成员用户是否可以看到它们。这意味着,即使某个场景不被五个或多个成员支持,它仍可以利用 WSTF 的所有相同好处(网站、邮件列表等)。


场景构件

除了其详细描述和说明外,每个场景都有三个其他构件:与场景文档相关的补充文件(例如、模式文档、关系图等等),一个特定于场景的邮件列表以及一个端点列表。

除了用于一般主题讨论的 WSTF 邮件列表外,每个场景还提供其本身的独有邮件列表。这允许成员将他们收到的邮件数量限制在他们仅感兴趣的场景。

与每个场景关联的端点列表 类似于以前互操作性测试提供的内容。场景的每个实现都提供一个指向该场景实现的 URL。随 URL 一起,端点还可以有选择地提供其他信息,如:

  • 关于实现的限制(例如,它支持哪个 SOAP 版本)。
  • 哪个版本的产品承载端点。
  • 示例代码。鼓励 WSTF 的成员提供其示例应用程序的实现。由于场景本身可能使用非常普通的样式编写,因此应用程序代码不应包含所有者信息。所以,提供实现可以帮助希望在其自己的部署中模仿这些场景的起步客户。
  • 其他文档。有时,客户在尝试部署其代码时遇到的问题与 SOAP 堆栈或规范中的错误并不相关,而是没有详细说明如何配置产品的文档。对于每个场景,供应商可以包括准确的配置信息(或任何其他有用数据),以帮助客户自己再现环境。
  • 提供联系信息,以便在出现有关端点的问题时进行联系。

每个端点的所有者决定端点 URL 提供多少可选信息。每个端点的所有者还可以自由选择在发布场景之后端点是否显示在外部端点页。这使得供应商对特定场景的参与不被团队知道。这之所以重要是因为过去有这样的例子,即公司希望参与某个规范的测试,但不想让公众知道他们支持该规范。

通常鼓励所有者在场景发布后公开他们的端点,以便他们能够从非 WSTF 成员执行的测试中获益。不过,公司可能出于各种原因希望不被公众知道,WSTF 提供此选项就是为了解决这一问题。


互操作性测试是关键

当然,WSTF 背后的主要目的是互操作性测试本身。实际测试将遵循以前多次使用的相同模型。实现将使用与某个场景关联的端点列表来验证两端的代码如期运行。

如果在测试过程中一切顺利,则围绕场景的讨论可能不会有什么内容。但是,如果不是如预期的那样,则有兴趣的成员将通过场景特定的邮件列表讨论他们的关注内容。通常,这些讨论将生成围绕应如何使用规范的最佳实践£?或有关设计人员可能选择的应用程序的指导。然后通常将这些内容归入发现部分下的场景文档。

如以前提到的,围绕场景的讨论可能产生新的规范或概要思想。在其他情况下,这些讨论可能导致发现现有规范的问题。在 WSTF 社区中进行有关现有规范的任何初始讨论之后,进一步讨论应移动到更合适的地点。WSTF 本身不将这些问题带至适当的位置,而由个别 WSTF 成员执行此任务。

例如,假设在 WS-ReliableMessaging 规范中发现了一个问题。尽管如何解决问题的一些最初思想可能在 WSTF 中讨论,但认为该问题特别重要而需要进一步讨论的 WSTF 成员可以将该问题反映给规范作者——可能是 OASIS WSRX 技术委员会。然后,该技术委员会将决定如何以最佳方式解决此问题。

与其他互操作性工作不同,不阻止 WSTF 检查其开发的任一阶段的任何 Web 服务规范。对其他团队的设计是阻止他们限制其严格界定的字符。WSTF 没有此类限制。它可以在规范位于标准组织中甚至在此之前测试规范。

例如,WS-I 只能检查退出标准组织的规范。这通常意味着,解决规范中发现的任何严重问题已为时过晚。相反,WSTF 可以选择继续和开始测试并向新的 W3C 工作组提供反馈,以标准化多个规范(如 WS-MetadataExchange)。WSTF 可以在工作组实际开始自己的测试以及规范完成之前就及早开始此项工作。这可以发现规范中的一些明显问题以及仅在将多个 Web 服务规范组合在一起时才能立即发现的一些不太明显的组合问题。


重在参与

由于 WSTF 的目标之一是为整个 Web 服务社区真正开放测试论坛,进入门槛保持在非常低的水平。不设任何会员期限,也不收任何费用。唯一的要求是成员需要签订参与协议。网站相对较小并由 IBM 托管,但它不包含 IBM 的任何署名、徽标或市场营销信息。

鼓励 Web 服务社区的所有成员加入 WSTF。除了不收取任何费用之外,也没有任何批准流程。

尽管希望所有 WSTF 成员参与某级别,但没有最小参与要求。成员可以决定他们参与的多少。欢迎希望简化加入和阅读邮件列表的成员这些做。

开发场景的参与向任何人开放——不只对 Web 服务供应商。非供应商的参与实际上对 WSTF 的成功至关重要。为确保在实际场景中完成测试,WSTF 将需要客户、ISV 和其他人在整个场景开发过程中提供建议和指导。


WSTF 的未来发展

本文使用了术语 Web 服务 作为 SOAP 的代名词,但 WSTF 实际上并不只局限在基于 SOAP 的 Web 服务测试。WSTF 将其测试扩展到其他 Web 服务 测试不存在任何限制。

例如,WSTF 将允许甚至鼓励测试 SOAP/Web 服务在特定域中的使用。还允许测试 REST/Web 服务并且在不远的将来就可能实现。

WSTF 不只是有关基于 SOAP 的互操作性测试——它还是关于 Web 服务的互操作性测试,并且由社区本身与时俱进地确定其含意。


结束语

成立 WSTF 主要是为了确保在客户发现之前就已发现和解决了 WS-* 规范集的互操作性问题。WSTF 的结构还总体上为 Web 服务社区提供了更广泛的好处。通过为共同的思想提供公共测试地点和位置,WSTF 可以弥补社区和 Web 服务开放式开发方面的脱节。

WSTF 可以提供一个论坛,其中任何人都可以与 Web 服务社区中所有类型和规模的参与者探讨问题。WSTF 的组织者尽最大努力确保 WSTF 在有限的政治空间专注于技术讨论——希望这一活动能够继续下去。

有关详细信息,请访问 WSTF 网站:http://www.wstf.org 或发送电子邮件至 admin@wstf.org

参考资料

学习

获得产品和技术

  • 下载 IBM 产品评估版,获得来自 DB2®、Lotus®、Rational®、Tivoli® 和 WebSphere® 的应用程序开发工具和中间件产品。

讨论

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=SOA and web services
ArticleID=368181
ArticleTitle=Web 服务测试论坛 (WSTF):架起承诺与现实之间的桥梁
publish-date=02052009