【IT168 技术文章】
前言
本指南描述了服务总线（Aqualogic Enterprise Service Bus --- 简称:ESB）的一些典型使用场景、设计模式和实践经验。同时对于ESB上一些常见的问题予以解答。
本文的读者应该已经了解ESB的基础概念、进行了相关实践，以及熟悉ESB的管理配置界面。
使用流程元素
ESB提供了丰富的消息流程处理的模型，可以有多种方式来实现。因此需要有一个指导来表明在何时使用哪种方式比较适合。
何处执行转换（Transformations）
路由节点（route node）是消息流树上的一个页节点。如果我们需要转换成或需要转换的消息格式依赖于目标服务，因此在路由节点（route node）或发布节点（publish node）中的请求/响应动作。在发布节点的操作中，任何请求过程中的数据转换是发布动作目标服务所私有的。换一种方式讲，当发布完成后，任何请求信息的改变会回滚到初始状态。另一种请求动作是在outbound上下文变量（$outbound）中设定控制变量来影响系统对于发送出去消息的操作（如：设定服务质量QoS等）。
如果转换是在消息请求（或消息响应）过程中执行，而不考虑路由终点，那么需要在请求（或响应）的管道中配置消息转换。
例如，对于一个大批量的订单，需要对收到的SOAP报文生成一个订单汇总，并通过eMail发送给采购经理。为支持这种场景，在请求管道中需要包含一个发布动作。如果订单很大，请求动作需要将该订单转换成一个订单汇总，并将$attachments变量中的附件信息全部删除
假设请求中附件信息的转换不需要理会最终的路由节点，因此建议在请求管道中的一个阶段（stage）将附件进行格式的转换。
假设消息需要根据WS-addressing头信息路由到两个终点中的一个。其中第二个终点（Web Service）需要将SOAP消息体中的订单转换到一个新版本。此时，路由节点需要进行条件路由，以将信息发送到两个终点中的一个，在第二个路由终点的请求动作中需要对订单信息进行格式转换。另外，如果该服务采用的是JMS方式发送，还可以在$outbound变量中设定QoS为“exactly once”。
何时需要在消息流中使用分支
如果一个代理服务提供的WSDL中包含多个操作，通常建议采用操作分支（operational branching）来对每个操作分别处理消息。
如果一个代理服务的类型是 Any SOAP 或 Any XML，就需要在阶段动作中判断消息具体类型,然后需要一个条件分支（conditional branching），通过条件分支节点来根据消息类型路由消息 。
条件分支可以用于代理服务的最外层，来对外提供路由选择。例如：如果需要根据条件来调用服务A或服务B，上述动作如果不在路由节点中实现的话，就需要在消息流中配置条件路由。在每个分支中使用路由节点作为其子节点，这是一种典型的决策方式，但如果消息分支数量比较多的时候，配置每个分支中子节点的路由就不能算是一个好的方案了。
设计单一或多阶段（Stage Action）
管道中单一的阶段通常能够满足大多数使用案例。但是有些情况下，需要考虑多个阶段动作（stage action）。
相比于把所有用户操作放置到一个阶段动作中，采用多阶段的设计模式提供了一个自然的模块化设计机制。
在请求或响应的管道中，每个阶段可以具有独立的差错处理能力。当在管道中采用多个阶段操作，就可以避免在一个差错处理中来考虑各种动作所产生的差错处理。
如果使用了resume 动作（在差错处理中）或 skip 动作，其行为是在请求/响应管道的下一个阶段恢复处理。因此考虑到需要强调的业务逻辑，将resume 动作或 skip 动作之后的动作放置到下一个阶段中是一个好的设计原则。
在一个阶段中典型的动作包括：
消息的转换
消息汇报（report action）
通过一个循环，来进行WSCallout 以进行消息的丰富或路由
校验消息是否合法和抛出错误提示
发布消息的副本到一个终点目标
何处处理差错
ESB提供了三种差错处理的选择
在请求/响应管道中通过一个测试来校验。如果断言是真，就通过reply动作（或reply with failure）处理
在每个阶段层面、路由节点、管道节点或服务层等来捕获和处理消息
通过系统自带的差错处理机制来处理错误
通常情况下，最容易的差错处理是在最低的级别进行捕获，使用高级别的差错处理来处理更普遍的差错。但是对于inbound 的WS-Security 相关的差错只能在服务层进行捕获和处理。
如果输入的消息是一种请求/响应型的消息，差错处理还需要包括产生应答消息通过reply with failure动作发送回去。在HTTP方式，reply with failure会产生一个HTTP 500状态信息。而在JMS方式，reply with failure会将JMS属性JMS_BEA_Error设置成为ture。
如果服务是通过另外一个代理服务而调用的，其返回SOAP错误或传输错误，差错处理管道会被调用。对于SOAP访问，如果reply with failure动作被执行，则系统会将最初的SOAP错误会返回给调用者。否则，系统错误处理机制会产生一个新的SOAP错误信息发送回去。代理服务可以识别SOAP错误，但它通常是不需要检测消息（此种设计主要是考虑除非需要，可以尽量避免解析消息内容），因为HTTP返回状态设定的不是200和202，或者JMS属性JMS_BEA_Error设定为true。而对于非SOAP的消息，JMS_BEA_Error = true也会被设定以标识这是一个差错响应。
通常情况下，明确的对可预期的差错在管道之中进行处理是一个好的习惯，采用系统的差错处理机制只可用于不可预期的差错情况。
某些用例调用会报告一个错误，使用报告（report）动作可以处理此场景。例如：当请求管道报告消息以便跟踪时，但在报告动作后，其路由节点中的服务调用失败，报告消息只能解析为消息已经被提交处理。差错处理中的报告处理失败只能进行补偿操作，当有人在管理控制台中使用报告系统可以跟踪该消息，判断出最初提交的消息和其后续的差错表明该消息没有被正常处理。
