第
篇文章中
我讨论了异步操作性质以及它们如何应用于 Web 服务
在某些情况下对 Web 服务请求响应并不是立即提供而是在
请求事务完成后某个时候提供Web 服务规范标准和标准并不显式支持这种 异步操作(asynchronous operation)；但是那些标准确包含可以作为异步操作基础基础架构和机制通过本系列第部分您应该已经知道了如何使用现有基础架构来支持异步行为；如果您还没有看过那篇文章我强烈建议您去看看
那里信息将帮助您理解现在这部分 在这篇文章中
我将讨论异步 Web 服务几个设计模式这些模式将帮助客户机和服务提供者应用
开发者将他们代码设计为支持异步行为同时考虑到代码复杂性、给定传输使用以及显式确认需要您或许还有兴趣看看另个支持 Web 服务中异步行为包 Web 服务异步模式和基本传输类型
就象 Web 服务描述语言(Services Description Language
WSDL)规范标准版本 1.1 中定义那样这里讨论支持异步 Web 服务操作 4个模式以端点可以支持 4种基本传输类型为基础: 单向(One-way):端点接收
条消息 请求／响应(Request/response):端点接收
条消息并发送条对应消息 征求／响应(Solicit/response):端点发送
条消息并接收条对应消息 通知(Not
ication):端点发送条消息 IBM
Web 服务
框架和异步操作Web 服务
框架(Web Service Invocation FrameworkWSIF)向用来使用本地代理(例如个存根)异步 Web 服务客户机 API 提供了根据上下文使用区别传输能力本文中讨论许多模式都可以由 WSIF 组件支持这样允许真正支持异步 Web 服务操作我们应该注意
本文中讨论基本传输类型数目和模式数目的间是完全无关每
个模式都要引入个在客户机和服务提供者的间交换 相关器(correlator)用于把响应和请求关联起来相关器可以由参和交换任端提供它创建者可以根据底层传输来确定例如在使用 HTTPR 和 JMS 时消息源提供相关器:个事务标识或者 JMSMessageID 和 JMSCorrelationID 个组合 对于单方向操作
如果您正使用 HTTP 或者 HTTPS并且服务接收需要由客户机确认那么客户机 HTTP 协议处理在等待 HTTP 响应(例如个 200 状态码)时应该阻塞以确保请求已被服务提供者 HTTP 侦听器成功地接收对于客户机使用服务代理情况任何和请求有关
状态都应该会导致异常被抛出为服务代理接口建模使其模型和服务提供者定义 WSDL 操作相匹配很重要例如如果个客户机个单向操作代理将永远不会向客户机返回个参数(例如个状态码)这种交换将有效地使操作成为个请求／答复操作并且答复信息不是来自服务提供者人们期望 W3C
WSDL 工作组能够通过提供在 WSDL 内正式定义回调机制(例如回复地址)能力扩展语言异步操作支持同时上面列出 4种基本类型可以用于支持异步操作但是目前可用来使客户机端服务代理生成过程自动化 IDE 和其它 Web 服务工具般只支持请求／响应模型模式 1:单向和通知操作
在这个模式中
请求和响应是单独 WSDL 操作内定义两条消息请求被建模为个入站单向操作响应被建模为个出站通知操作每条消息都被作为单独传输层传送发送这个模式(参见 图 1)提供了客户机和服务提供者的间
高级分离它支持使用两个数据报在双方的间进行交换个用于请求个用于响应 图 1. 单向和通知操作
对于这个模式
客户机负责创建相关性标识(correlation ID)并通过双方已同意任种机制将其发送给服务提供者SOAP 报头、HTTP 报头和 JMSCorrelationID 都将是可接受机制 定义答复地址 ― 它指出响应应该发送到何处 ― 也是客户机
职责而向服务提供者通知这个地址思路方法取决于 WSDL 是如何为操作定义如果客户机发布了个支持单向操作通知侦听器服务它 WSDL 将包含该服务端口地址同样服务提供者将需要访问客户机服务 WSDL 来确定将响应发送到何处通过在请求上传递 WSDL 引用可以在提供者 Web 服务被部署时或运行时提供对通知侦听器服务 WSDL 访问权作为替代思路方法也可以把指出响应将发送到何处特定地址(例如 URI)作为请求参数显式提供这种模型也适用于发布和订阅(pub/sub)及事件通知类型
服务市场指数更新应用将是 pub/sub 服务个不错举例；事件通知服务举例包括这样应用 ― 该向有兴趣各方通知业务流程任务已经完成或者任务中异常、个长期运行报表已完成或达到了某些库存阈值把答复地址信息作为请求(例如订阅个主题或事件请求)参数来提供将使得服务提供者可以用极少管理支持来支持大量订户对于这个模式(在该模式中使用单独
传输层传送发送消息而不需要在客户机和服务提供者的间交换应用层确认)如果消息流支持业务流程非常重要所使用传输应该是被认为可靠模式 2:请求／答复操作
在这个模式中
请求和响应是单个请求／答复操作内定义两条消息并作为两个独立无关传输层传送发送这个模式(参见 图 2)也可以提供客户机和服务提供者的间
高级分离它支持为请求和响应使用两个数据报在双方的间进行交换但是要使用这个模式服务供提供者在运行时处理信息时肯定会更复杂点例如服务提供者将需要能够把它要发送响应目标地址(例如答复地址)作为输入参数处理 图 2. 请求／答复操作
对于这个模式
客户机负责创建相关性标识并通过双方已同意任种机制将其发送给服务提供者和前面样SOAP 报头、HTTP 报头和 JMSCorrelationID 都是可接受机制 定义指出响应应该发送到何处
答复地址也是客户机职责由于对这个模式使用单操作对地址或显式地址自身引用 必须作为请求参数提供例如如果客户机发布了个支持单向操作异步响应侦听器服务那么在请求上就可以提供对服务 WSDL 引用 这个模式也适用于其请求只产生
个响应通用服务；这种服务举例包括数据持久保存或检索或者由单个工作单元组成业务流程(比如次电子付款)启动模式 2 和模式 1 相似在这种模式中使用单独传输层传送发送消息而不需要在客户机和服务提供者的间交换应用层确认因此如果消息流支持业务流程非常重要用于这个模式传输也应该是被认为可靠模式 3:使用轮询
请求／答复操作在这个模式中
使用两个单独 WSDL 操作内定义 4条消息处理请求和响应请求被建模为请求／答复操作有两条消息(个传送和个答复)被作为单个传输层交换发送响应由第 2个请求检索它也被建模为请求／答复操作同时有两条消息被作为单个传输层交换发送这两个操作应该被作为同步流实现同时从服务提供者为每个请求返回信息为客户机提供每个请求定级别确认这个模式(参见 图 3)使得客户机端实现在支持基于自助
解决方案时更简单在这种模式中客户机应用启动所有交互同时还提供客户机和服务提供者的间定级别分离但是假设请求／答复操作是同步那么答复消息流将使用本机传输答复机制(例如HTTP 响应(HTTP Response)操作) 图 3. 使用轮询
请求／答复操作 
在 图 3
举例中服务提供者生成相关性标识客户机负责使用它检索响应；但理论上参和交换任方都可以创建相关性标识 由于不需要通知机制和侦听器组件
这个模式使得客户机实现更为简单但是客户机必须实现个工具使用这个工具它可以周期性地轮询来自服务提供者响应这个模式效率可能不是最高(如果服务请求尚未完成话每个响应可能需要多个请求来检索响应)但它使得实现更为简单因而这个模式适合优先考虑简单性和服务期望负载比较低情况某些服务类型可以从轮询中受益它们举例包括个长期运行业务流程开始、生成复杂报表请求以及基于浏览器、面向客户解决方案所使用服务模式 4:使用公布
请求／答复操作在这个模式中
使用两个单独 WSDL 操作内定义 4条消息处理请求和响应请求被建模为请求／答复操作同时有两条消息被作为单个传输层交换发送响应被建模为征求／答复操作同时有两条消息被作为单个传输层交换发送这两个操作应该被作为同步流实现同时从消费方为每个请求返回信息为请求方提供每个请求定级别确认这个模式(参见 图 4)和模式 1 相似
当使用同步传输时以及客户机和服务提供者要求个应用层确认时这个模式对 pub/sub 或事件通知服务很有用由于这种相似性模式 1 下给出举例情况也可由模式 4 来解决；其它要求显式确认服务类型举例包括用来交换医疗业或金融业对业务至关重要信息或机密信息 ― 例如资金转移或者保险索赔提出 ― 服务 图 4. 使用公布
请求／答复操作 
WebSphere 和异步 Web 服务模式
IBM
WebSphere Application Server 版本 4 和 WebSphere Studio Application Developer 目前完全支持模式 3但如果两个操作都是请求／答复模式它们也支持模式 4由服务提供者执行服务请求者角色向客户机发送响应对于这种情况服务提供者 WSDL 将不具有任何对响应操作( 图 4中操作 B)任何引用这将由客户机 WSDL 来定义如果为处理响应把客户机和服务提供者
角色反过来也可以为客户机把发送响应 WSDL 操作定义为请求／答复操作角色互换只是为了方便；这样做便于模式开发目前工具不支持征求／答复操作在双方的间流动消息不被更改；只是本文用来描述客户机和服务提供者角度模型会有区别结束语
对异步 Web 服务操作
支持既可以用同步传输协议也可以用异步传输协议来实现异步传输使用(这时内在提供请求和响应消息关联性并提供独立查询状态和检索响应消息机制)使得支持客户机端和服务提供者端异步操作更加容易面向消息中间件为 Web 服务请求和响应传输提供可靠消息传递同样同步传输也可以支持异步操作更简单实现特别是在客户机应用更倾向于自助风格时下表概述了本文中讨论
4个模式并为解决方案供应商提供了注解和注意事项异步模式 适用
传输 使用方法举例 注解和注意事项 1. 单向和通知操作 HTTPR、JMS、MQSeries 消息传递(MQSeries Messaging)、HTTP、HTTPS、RMI/IIOP、SMTP Pub/sub；事件通知 异步传输内在支持
当不需要保证请求或响应传递时可以使用同步操作 2. 请求／答复操作 HTTPR、JMS、MQSeries 消息传递(MQSeries Messaging)、HTTP、HTTPS、RMI/IIOP、SMTP 带
个响应般服务；事务性服务 异步传输内在支持当不需要保证请求或响应传递时可以使用同步操作 3. 使用轮询
请求／答复操作 HTTP、HTTPS * 、RMI/IIOP ** 自助 最简单客户机端实现同步传输很容易支持应用层确认(例如通过 HTTP 响应) 4. 使用公布
请求／答复操作 HTTP、HTTPS * 、RMI/IIOP ** Pub/sub；事件通知 比较简单客户机端实现和模式 1 相似但带有和同步传输起使用显式应用层确认 * :被当前
Web 服务工具支持 ** :虽然您也可以为这些模式使用异步传输
但这样做是不切实际异步传输提供使模式 1 和模式 2 更易于实现机制 就象本系列
第 1 部分声明那样Web 服务标准未来版本可能会简化对异步操作支持但使用本文中概述这几个模式您应该可以开始构建实现目前各种用途异步 Web 模式 
最新评论