Web 服务响应模板模式:规范
Web 服务响应模板模式为异类环境中的服务提供者和客户端提供了对请求响应调用的更多控制和灵活性。WSRT 允许客户端控制服务结果,并根据规范优化数据流。同时,它还允许服务提供者开发自己提供的接口,而不会中断现有客户端的使用。我们将讨论 WSRT 模式规范以及用来改进服务接口的解决方案。
Web 服务响应模板模式为异类环境中的服务提供者和客户端提供了对请求响应调用的更多控制和灵活性。WSRT 允许客户端控制服务结果,并根据规范优化数据流。同时,它还允许服务提供者开发自己提供的接口,而不会中断现有客户端的使用。我们将讨论 WSRT 模式规范以及用来改进服务接口的解决方案。
环境
Web 服务已迅速成为异构环境中最常用的请求响应调用方式。不过,这些调用的冗长的 ASCII 特性将影响性能,从而使架构师转而考虑别的备选解决方案。
我们将深入了解在处理多个客户端时 Web 服务提供者可能面对的问题,以及如何使用 WS 响应模板模式解决这些问题。
问题
服务接口通常会带来以下问题:
- 服务接口通常是粗粒度的,但客户端通常希望对其访问的粒度进行更多的控制。
- 服务提供者需要在不影响现有客户端的情况下对其提供的接口进行改进。
Web 服务提供者在处理多个客户端时有一个常见的问题:WSDL 非常精确地对数据类型、消息和操作的接口进行了规定,从而隐式地限制客户端使用并不一定恰当的模式。服务提供者必须选择其公开的 WSDL,即使客户端知道其使用模式对应的最有效的接口也如此。
服务提供者必须选择是否为多个客户端提供多个接口——这非常难于实现和维护——还是提供单个“全能”折衷接口。
以汽车公司中的车辆数据服务为例。这个车辆服务的创建、读取、更新和删除 (CRUD) 操作需要供多个应用程序访问,因为汽车公司中的大部分应用程序都将需要访问车辆信息。不过,每个应用程序都将对其所需的车辆数据子集具有不同的要求。保修应用程序将需要不同于客户服务应用程序的车辆信息子集。此数据服务的提供者现在就面临着一个进退两难的问题:是提供具有不同车辆数据粒度级的多个接口,还是提供一个并不专门满足某个特定需求的全能接口。
客户端如何才能不再受到使用服务提供者指定的协定的限制?
决定因素
构建 Web 服务时,有多个决定因素。架构师需要能:
- 在现有 Web 服务标准上进行构建工作
- 提高 Web 服务接口的灵活性、粒度和易维护性
- 自定义服务结果并对客户端和服务器之间的数据流进行优化
- 允许使用者和提供者以抽象的数据和服务模型(而不是预先确定的接口)为基础进行开发。
解决方案
WS 响应模板模式(WS response template pattern,WSRT)允许客户端针对抽象数据和服务模型进行编程(而不直接针对 WSDL 指定的接口),然后指定将该模型中的信息子集作为服务调用结果返回。除了定义响应的结构外,客户端还可以提供其他搜索参数,以确定将要实际返回哪些对象。这样,客户端就能对服务结果进行更大的控制,以便根据自己的规范对数据流进行优化。此外,它还允许服务提供者在不会影响现有客户端的情况下开发其提供的接口。
WS 响应模板模式使服务接口变得更为灵活了。操作签名更改为接收请求模板(和密钥),然后返回响应模板。请求模板是松散类型的图表,其中所有属性都是可选的;响应模板是强类型的图表,其所有属性也是可选的。
- 本文关键词:

