也许SOA 已死，也许它渴望着避风港，但确定的是在好的SOA 是由什么构成这个问题上依然充满了未知。很多供应商提供了SOA 工具，表明看来是否采用SOA 取决于你现在所处的阶段，但实际上这只是他们兜售工具的一种手段而已。就像 IBM 所说的这样：
你的公司对面向服务的架构（SOA）是什么立场？你是否清楚当前 SOA 的成熟度和改进的可能性？IBM SOA 资产工具可以帮助你充分利用 SOA 的价值，因为其目标就是不断改进公司的成熟度级别。
然而一旦采用了 SOA（无论使用到何种程度），你都需要对其进行测试。还好那些向你兜售工具的供应商也提供了相应的解决方案，但好的 SOA 测试工具是由什么构成的呢，你是否已经被绑定到特定的 SOA 基础设施上了呢？这就是 Eric Roch 所提出的问题。他给出了一些选择标准：
- 感知测试的接口：用于测试的标准化接口和消息
- 基于消息的测试自动化：对测试脚本的记录、重放和管理
- 虚拟化：模拟虚拟的服务供应商和消费者的能力
- 模仿：作为衰退测试的一部分而模仿应用的能力
- 负载测试：进行负载测试的能力
- 验证：组件（消息）与应用（数据存储）级别上的验证功能
- 组件：支持 Java 与 / 或.NET 组件
- 自省：支持 WSDL 与 XML 以生成数据和运行测试
- 管理：管理测试用例、脚本、数据与结果
- 安全：SSL、WS security 联盟、数字签名
- 符合工业的数据格式：如 EDI、HL7 等
- 持续测试：自动构建、部署与测试
几年前， InfoWorld 曾报道过几个基于 SOAP 的测试工具：
基本说来，测试基于 SOAP 的 Web Service 涉及到三个步骤：构建 SOAP 请求、提交请求并解析相应。听起来很简单，实则不然。有效的 SOAP 测试工具不能仅仅以对用户友好的方式来构建请求，它还必须能够让用户以真实的序列组织并安排请求，提供改变请求输入值的方式并智能的调整请求以将 Web Service 暴露给参差不齐的使用场景。简言之，工具应该可以在最接近真实世界的情况下运行。
尽管工业界已经认识到Web Service 仅仅是SOA 的一个方面，但不可否认的是现在的大多数工具都认为SOA 就是SOAP 和WSDL。
你有中意的SOA 测试工具么？对Eric 的标准有什么不同意见？你知道有哪些好工具能跨越不同的实现技术么？
查看英文原文： Which SOA Testing Tool?
暂无签名
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论