级别： 中级 Tendai Chinoda, 顾问软件工程师, IBM
2009 年 5 月 13 日 本文为设计用于部署到 WebSphere ESB 的中介提供了概念和最佳实践的“整体”视图。本文描述了形成设计基础的先决构件（系统上下文、需求和用例）。您还可以使用此方法为其他 IBM ESB 产品设计 ESB 解决方案。本文针对负责设计如下解决方案的 SOA 解决方案架构师和设计团队：这些解决方案整合了核心 ESB 模式以处理复杂的企业系统交互。
引言
本文向您介绍如何设计用于部署到 IBM® WebSphere® Enterprise Service Bus 的中介。本文概括了一个业务场景上下文中的设计工作，以及先决设计构件的生成——系统上下文、需求和用例文档。
解决方案体系结构与设计方法是 IT 架构师和专家社区所熟知的。在架构和设计基于 SOA 的解决方案时，我们将详述跨越 SOA 解决方案堆栈各层的已知解决方案体系结构要素和设计解决方案。
图 1. SOA 参考体系结构——解决方案堆栈视图
在 SOA 中，将应用 ESB 体系结构模式以促进服务提供者与请求者之间的通信。请参见使用参考架构设计 SOA 解决方案和下面的图 2。
ESB 的职责包括：
- 接口映射——源和目标系统之间的接口映射
- 路由——到一个或多个端点的请求路由（提供者不需要知道到达使用者端点的路由语义）
- 数据转换——应用程序特定格式之间的来回数据转换
- 协议转换——源/目标系统之间的通信通道协议转换
- 服务质量——支持服务质量，包括有保证的交付、日志记录、安全性、错误检测和审核。
图 2. SOA 参考体系结构——中间件基础结构视图
使用参考架构设计 SOA 解决方案讨论了针对部署到 WebSphere ESB 的 ESB 解决方案的设计概念，但这些概念在设计针对任何 IBM ESB 产品服务的 ESB 解决方案时也适用，如下所示：
图 3. WebSphere ESB 产品
业务场景
本文中引用的业务场景使用一家虚构的公司和问题空间来描绘现实世界中的系统集成挑战，以及如何通过 SOA 解决方案解决那些挑战。
背景知识
TPCBanking Corporation 的战略业务与 IT 团队决定扩展现有的客户支持业务组合。该扩展将扩展客户支持代表提供的服务，以包括贷款处理和为客户发起自动记帐支付。这样的扩展将需要集成三个独立的 TPCBanking IT 系统：
战略业务与 IT 团队做出的重要决策是参与 IBM 的联合 SOA 计划。根据该计划并通过采用 IBM Smart SOA 方法，该团队定义了映射到 IBM SOA 重用和 IBM SOA 连接性入口点的高级需求。
SOA 重用入口点需求
TPCBanking 将使现有的 IT 资产能够支持服务，从而支持他们的客户支持业务组合的扩展。
- 贷款处理和自动记帐支付系统将分别公开服务，以允许从分支机构系统同步客户帐户信息。
- 分支机构系统将使现有的应用程序代码能够支持服务，以允许自动记帐支付系统在发生记帐支付时更新帐户信息。
SOA 连接性入口点需求
TPCBanking 将通过 ESB 来集成系统以促进无缝的消息和信息流。
- 分支机构系统将向 ESB 提交帐户更新，ESB 将执行必要的中介并将帐户更新路由到贷款处理和自动记帐支付系统（以实现同步）。
- 自动记帐支付系统将向 ESB 提交帐户余额更新，ESB 将执行必要的中介并将帐户余额更新转发到分支机构系统。
战略业务与 IT 团队已请求 SOA 解决方案体系结构与设计团队设计一个利用 WebSphere ESB 功能进行系统集成的解决方案。除了上面列出的高级需求以外，战略业务与 IT 团队还为 SOA 解决方案体系结构团队提供了他们建议的系统之间的信息流视图：
图 4. 建议的 TPCBanking 解决方案系统上下文关系图
从何处着手呢？
作为最佳实践，在设计 ESB 解决方案前，最好充分了解、确定并列出该解决方案的需求和功能行为。因此，即使解决方案特定于 ESB，也应该将诸如系统上下文、需求和用例文档等常见体系结构和设计构件视为设计先决条件。基于 SOA 的解决方案设计的特别方法如果排除了列出范围、系统上下文、需求和功能行为（特定于 ESB 实现）的任务，则所设计的解决方案不完备或不满足需求的风险就会增加。
业务场景：工作分解结构
下面显示了由解决方案体系结构与设计团队编制的工作分解结构（work breakdown structure，WBS），其中包括生成先决设计构件的任务，然后跟着是中介的设计。
TPCBanking 项目管理团队角色和缩写
- 自动记帐支付系统技术所有者——ABPSTO
- 分支机构系统技术所有者——BSTO
- 业务分析人员——BA
- 客户支持经理——CSM
- 设计团队——DT
- IT 经理——ITM
- 贷款处理系统技术所有者——LPSTO
- 项目经理——PM
- 解决方案架构师——SA
- 战略业务经理——SBM
TPCBanking ESB 解决方案设计 WBS
| 任务 | 子任务 | 所有者 | 参与者 | | 1：执行初步讨论和访谈 | 1.1：业务场景和挑战概述
| SBM、ITM、CSM | SBM、ITM、CSM、BA、PM、SA | | 1.2：复核高级需求和建议的系统视图 | SBM 和 ITM | SBM、ITM、CSM、BA、PM、SA | | 1.3：定义设计工作的目标和范围并做文档记录 | PM | SBM、ITM、CSM、BA、PM、SA | | 2：执行系统级别的定义活动（针对每个系统） | 2.1：系统级别的技术深入研究 | 系统技术所有者 | BSTO、LPSTO、ABPSTO、SA、PM | |
| 2.2：对系统描述、公开的接口、标准、协议、安全性、规范做文档记录 | SA | BSTO、LPSTO、ABPSTO、SA、PM | | 3：执行信息流分析 | 3.1：对系统之间的每个信息流的有效负载进行技术深入研究 | BA | SA、BA、BSTO、LPSTO、ABPSTO | |
| 3.2：对源、目标、交互模式、频率、数据量等做文档记录 | SA | SA、BA、BSTO、LPSTO、ABPSTO | | 4：执行端到端 (E2E) 场景分析 | 4.1：列出触发系统之间的数据流的 E2E 场景。 | BA | SA、BA | |
| 4.2：确定将从 ESB 服务获益的中介流逻辑（即协议转换、接口映射、数据聚合等等） | SA | SA、BA | |
| 4.3：对 E2E 信息流描述做文档记录 | SA | SA、BA | |
| 4.4：生成修订后的系统上下文关系图并做文档记录 | SA | SA、BA | | 每个 E2E 场景的需求和用例定义 | | 5：定义/重新定义需求 | 5.1：确定/复核 ESB 基本需求，以支持从源到目标系统的信息流。 | SA、BA | SA、BA | |
| 5.2：确定/复核 ESB 非功能需求，以支持从源到目标系统的信息流（协议、标准、安全性、日志记录、审核等等） | SA、BA | SA、BA | |
| 5.3：对 ESB 解决方案需求做文档记录 | BA | SA、BA | | 6：定义信息流的用例（功能行为） | 6.1：定义 E2E 场景上下文中的用例 | SA、BA | SA、BA | |
| 6.2：捕获在用例定义过程中确定的其他需求 | SA、BA | SA、BA | |
| 6.3：验证所有需求到用例的可跟踪性 | BA | SA、BA | |
| 6.4：对用例做文档记录 | BA | SA、BA | | 7：审批系统上下文、需求和用例 | 7.1：团队复核/签字同意系统上下文、需求和用例 | BA | SBM、ITM、CSM、BA、PM、SA | |
| 7.2：使用反馈更新文档 | SA、BA | SBM、ITM、CSM、BA、PM、SA | | 中介设计活动——迭代 | | 8：定义入站和出站服务契约 | 8.1：确定支持每个信息流所需要的入站和出站服务契约。 | SA | SA、DT、BA | |
| 8.2: 针对每个出站接口，收集分支机构、自动记帐支付和贷款处理系统公开的服务的现有 Web 服务定义语言（Web Service Definition Language，WSDL）文件。 | SA | BSTO、LPSTO、ABPSTO、SA、DT | |
| 8.3：针对每个入站接口，定义 ESB 公开的服务的 WSDL。 | SA | BSTO、LPSTO、ABPSTO、SA、DT | | 9：设计中介 | 9.1：用例细化以确定中介 | SA | SA、DT | |
| 9.2：每个入站服务契约（ESB 导出）设计：
中介模块
中介 SCA 组装关系图
中介流组件
请求流
响应流 | SA | SA、DT | |
| 9.2：设计视图 | SA | SA、DT | |
| 9.3：对中介设计做文档记录 | SA | SA、DT |
初步讨论和访谈
初步讨论的目的是让解决方案架构师获得全面的视图，并了解需要某个解决方案的业务场景和当前挑战。该讨论应该总结出清楚的定义，并就设计工作的目标和范围达成一致意见。
业务场景：设计目标和范围
下面显示了解决方案体系结构与设计团队在初步讨论结束时所记录的目标和范围：
TPCBanking ESB：解决方案体系结构与设计目标
- 定义并记录物理和逻辑 ESB 体系结构，以支持 TPCBanking 分支机构、贷款处理和自动记帐支付系统之间的连接性和信息流。
- 设计 WebSphere ESB 中介并做文档记录，以支持 TPCBanking 分支机构、贷款处理和自动记帐支付系统之间的端到端（End-to-End，E2E）信息流的实现。
TPCBanking ESB：解决方案体系结构与设计范围
ESB 解决方案体系结构与设计工作的范围是设计可促进以下内容的 WebSphere ESB 中介和支持服务：
- 用于将客户帐户更新从分支机构系统同步到贷款处理和自动记帐支付系统的信息流。
- 用于将客户帐户余额从自动记帐支付系统调整到分支机构系统的信息流。
系统上下文
一旦定义了设计工作的目标和范围，任务 2 至 4 将使解决方案架构师能够定义外部系统的特征及其与 ESB 的交互。这些特征应该包括：
- 与 ESB 交互的外部系统的描述
- 外部系统的技术方面，例如安全性和用于与系统集成的通信协议。
- 标识源和/或目标系统，以及信息流（有效负载）和交互模式。
- 所传输数据的来源以及每个导致系统间信息流的事件的触发器。
系统上下文关系图将正在设计的系统作为黑箱提供了其图形视图，并显示了通过该系统从外部源到目标系统的信息/数据流。其中每个流将需要 ESB 中的中介逻辑。对源系统公开接口以后，ESB 对中介逻辑的实现和对目标系统的调用就代表了设计工作的系统边界。
业务场景：系统上下文
在任务 2 至 4 结束时，解决方案体系结构与设计团队对每个系统的特征做文档记录，并生成建议的解决方案（源自图 4）的修订视图（请参见图 5）。修订视图将 ESB 显示为黑箱，从而促进系统之间的连接性和交互。
TPCBanking ESB：外部系统特征和修订后的建议解决方案
分支机构系统：
分支机构系统承载分支机构管理应用程序（Branch Management Application，BMA）
- BMA 是一个 Java EE 应用程序，支持 SOAP 1.1 Web 服务客户端和服务器调用。
- BMA 承载的 Web 服务已公开并通过 SOAP/HTTP 可用。
- BMA 与 WS-I Basic Profile 1.1 兼容。
贷款处理系统：
贷款处理系统承载贷款处理应用程序（Loan Processing Application，LPA）：
- LPA 是一个支持 SOAP 1.1 Web 服务客户端调用的门户应用程序。
- LPA 承载的 Web 服务已公开并通过 SOAP/HTTP 可用。
- LPA 与 WS-I Basic Profile 1.1 兼容。
- 针对 LPA 的传入 Web 服务请求的身份验证需要 WS-Security 1.0 的客户端支持。
自动记帐支付系统：
自动记帐支付系统承载自动记帐支付应用程序（Auto Bill Pay Application，ABPA）：
- ABPA 是一个 CICS 应用程序，并带有支持 SOAP 1.1 Web 服务客户端调用的扩展。
- ABPA 承载的 Web 服务已公开并通过 SOAP/JMS 可用。
- ABPA 与 WS-I Basic Profile 1.1 兼容。
图 5. TPCBanking 的修订后的 ESB 解决方案系统上下文关系图
需求定义
可以对系统上下文中列出的系统之间的信息流做进一步的分析，从而确定特定于 ESB 的需求以支持流。ESB 解决方案的完整需求列表应该同时包括通用和特定于场景的功能/非功能需求。通用需求是不同 ESB 实现之间所共有的（即非功能需求），而特定于场景的需求则是业务场景所特有的。
用于确定需求的策略
可以使用系统上下文中获得并记录的信息来确定通用需求（标准、规范、交互模式等），特别是任务 2 和 3 中记录的技术信息。对外部系统支持的标准、规范、安全性和交互模式进行分析，有利于确定 ESB 为了与每个外部系统交互所必须支持的需求。
还可以从系统上下文中记录的信息确定特定于场景的需求（源/目标系统之间的往返中介流逻辑），特别是在任务 4 中记录的中介流逻辑。对于系统上下文中记录的每个流，我们将确定 ESB 解决方案所必须支持的功能和非功能需求，以便将流从源中转到目标系统。
业务场景：需求
下面列出了解决方案体系结构与设计团队在任务 5 中确定的通用和特定于场景的需求的子集：
TPCBanking ESB：非功能需求
ESB 客户端支持：
- ESB 应该支持可从 SOAP Web 服务客户端（从 BMA、ABPA）访问的服务端点
ESB 协议支持：
- ESB 应该支持可通过 SOAP/HTTP（从 BMA）访问的服务端点
- ESB 应该支持可通过 SOAP/JMS（从 ABPA）访问的服务端点
ESB 标准和规范支持：
- ESB 应该支持以下 Web 服务标准和规范
- SOAP 1.1
- WS-Security1.0
- WS-I BasicProfile 1.1
ESB 交互模式支持：
- ESB 应该支持对外部系统承载的 Web 服务的出站异步调用。
- ESB 应该支持对外部系统承载的 Web 服务的出站同步调用。
- ESB 应该支持外部系统对 ESB 承载的 Web 服务的入站异步调用。
- ESB 应该支持外部系统对 ESB 承载的 Web 服务的入站同步调用。
TPCBanking ESB：功能需求——同步帐户信息
分支机构系统——同步帐户信息（入站）：
- ESB 应该提供并公开一个同步的“同步帐户信息服务”，以供分支机构系统调用
- 在分支机构系统调用 ESB 的同步帐户信息服务时，ESB 应该执行必要的中介逻辑，并将请求转发到贷款处理系统。
- 在分支机构系统调用 ESB 的同步帐户信息服务时，ESB 应该执行必要的中介逻辑，并将请求转发到自动记帐支付系统。
- 在分支机构系统调用 ESB 的同步帐户信息服务时，ESB 应该支持服务调用与到贷款处理和自动记帐支付系统的请求转发之间的事务划分。
- 在分支机构系统调用 ESB 的同步帐户信息服务时，ESB 应该支持到贷款处理和自动记帐支付系统的有保证和有序的信息交付。
贷款处理系统——同步帐户信息（出站）：
- ESB 应该支持对贷款处理系统公开的同步帐户信息服务的同步调用。
自动记帐支付系统——同步帐户信息（出站）：
- ESB 应该支持对自动记帐支付系统公开的同步帐户信息服务的同步调用。
TPCBanking ESB：功能需求——调整帐户余额
自动记帐支付系统——调整帐户余额（入站）：
- ESB 应该提供并公开一个同步的“调整帐户余额服务”，以供自动记帐支付系统调用
- 在自动记帐支付系统调用 ESB 的调整帐户余额服务时，ESB 应该执行必要的接口映射和数据转换，并将请求转发到分支机构系统
- 在自动记帐支付系统调用 ESB 的调整帐户余额服务时，ESB 应该支持服务调用与到分支机构系统的请求转发之间的事务划分。
分支机构系统——调整帐户余额（出站）：
- ESB 应该支持对分支机构系统公开的调整帐户余额服务的同步调用。
用例定义
用例有助于以预定义的方式描述 E2E 业务场景，从而捕获所设计的应用程序或系统的功能行为。在用例的上下文中和应用于 ESB 解决方案的情况下可以最清楚地了解需求，用例为中介设计提供了蓝图。
为 ESB 解决方案定义的用例应该从系统交互的角度描述功能行为，并着重于定义 ESB 实现的功能需求的范围。可以从任务 4 中列出的 E2E 场景得出用例定义，并且一经定义，所有的需求都应该可追溯到一个或多个用例。在用例定义活动过程中发现新需求也是非常普遍的现象。
业务场景：用例
下面显示了解决方案体系结构与设计团队在任务 6 中为“同步帐户信息”流定义的用例片段：
TPCBanking ESB：用例 001——同步帐户信息
触发器/前提条件：
成功结果：
- 分支机构系统调用 ESB，并将客户帐户更新同步到下游系统
失败结果：
- 分支机构系统无法调用 ESB，并且未将客户帐户更新同步到下游系统
- ESB 无法调用下游系统，并且未将客户帐户更新同步到下游系统
主要参与者：
次要参与者：
- 分支机构管理应用程序 (BMA)
- 贷款处理应用程序 (LPA)
- 自动记帐支付应用程序 (ABPA)
事件序列：
- 1. BMA 处理客户帐户更新事务。
- 2. BMA 向 ESB SynchCustAcctInfo 服务提交同步客户帐户信息 (SynchCustAcctInfo) 请求并等待响应。
- 3. ESB 接收 SynchCustAcctInfo 请求并将请求排入队列以待按顺序（按交付排序）处理。
- 4. ESB 向 BMA 返回响应以表明该请求已收到并且正在进行处理。
- 5. BMA 接收并记录来自 ESB 的表明该请求已收到并且正在进行处理的响应。
- 6. ESB 确定 SynchCustAcctInfo 请求中的帐户更新事务类型。
- 7. 对于客户地址/联系人和帐户余额更新，ESB 应该执行必要的接口映射和转换，然后将 SynchCustAcctInfo 请求转发给 LPA SynchCustAcctInfo 服务并等待响应。
- 8. 对于帐户余额更新，ESB 应该执行必要的接口映射和转换，然后将 SynchCustAcctInfo 请求转发给 ABPA SynchCustAcctInfo 服务。
- 9. ESB 接收来自 LPA 的表明该请求已收到并且正在进行处理的响应。
- 10. ESB 记录所有事务的完成
事务划分：
- BMA 对 ESB 服务的调用以及到 LPA 和 ABPA 服务的转发应该在单独的事务中进行。
事件序列的变化：
- 2.a BMA 无法调用 ESB 上的 (SynchCustAcctInfo) 服务，并且未将更新同步到下游系统。
- 2.b BMA 按照错误处理策略处理通信错误。
- 7.a ESB 无法调用 LPA 上的 SynchCustAcctInfo 服务，并且未在 LPA 上同步更新。
- 7.b ESB 按照错误处理策略处理通信错误。
- 8.a ESB 无法调用 ABPA 上的 SynchCustAcctInfo 服务，并且未在 ABPA 上同步更新。
- 8.b ESB 按照错误处理策略处理通信错误。
其他信息：
基于用例 001 中的事件编号 6、7 和 8，解决方案体系结构与设计团队确定了以下遗漏的需求，需要将它们作为“同步帐户信息”流的功能需求包括进来：
TPCBanking ESB：功能需求——同步帐户信息
分支机构系统——同步帐户信息（入站）：
- 在分支机构系统调用 ESB 同步帐户信息服务时，ESB 应该确定事务类型，并且仅将客户地址/联系人和帐户余额更新路由到贷款处理系统。
- 在分支机构系统调用 ESB 同步帐户信息服务时，ESB 应该确定事务类型，并且仅将帐户余额更新路由到自动记帐支付系统。
需求验证
将要设计的 ESB 解决方案的需求验证和签收的合理检查点是在完成定义用例的时候。WBS 中的任务 7 为业务团队提供了检查系统上下文、需求和用例以及确保遵守业务解决方案范围和目标的机会。
中介设计
可以通过各种方法完成中介设计，WBS 中的任务 8 和 9 包括了规定最优中介设计方法的子任务。
- 1. 确定和收集服务契约及定义
- 2. 用例细化——确定中介
- 3. 白板会议——列出中介逻辑
- 4. 中介设计——生成设计构件以做文档记录
确定和收集服务契约及定义
对于每个流，确定 ESB 与外部系统之间的入站和出站服务契约。对于 Web 服务，将采用 Web 服务定义语言（Web Services Description Language，WSDL）文件描述契约。
入站服务契约
对于 ESB 将公开的服务（入站服务调用），应该与源系统协商服务契约，并提供用于将请求从源路由到目标系统的服务端点。构成 WSDL 的详细模式、消息、操作和其他元素将随着设计的发展相应地插入进来并最终完成。
出站服务契约
对于 ESB 将调用的服务（出站服务调用），服务提供者提供的 WSDL 文件将用作出站服务契约。ESB 充当客户端和中介点，因此必须遵守服务提供者提供的服务契约。
业务场景：入站服务契约
通过复核系统上下文并与分支机构管理应用程序所有者举行讨论，解决方案与体系结构团队能够为进入 ESB 的“同步客户帐户信息”流定义以下初步的入站服务契约。
TPCBanking ESB：入站服务契约——同步帐户信息
服务名称：
- CustomerAccountManagementService
服务操作：
传入参数：
- ESBSynchCustAccountInfoBO
| 名称 | 类型 | 是否必需 | | accountNumber | INT | 是 | | accountType | STRING | 是 | | routingNumber | INT | 是 | | accountOpenDate | DATETIME | 是 | | branchNumber | INT | 是 | | autoBillPayAuthCode | INT | 是 | | customerSSN | STRING | 是 | | customerFirstName | STRING | 是 | | customerLastName | STRING | 是 | | homeAddress | ESBADDRESSBO | 是 | | homePhone | STRING | 是 | | businessAddress | ESBADDRESSBO | 是 | | businessPhone | STRING | 是 | | otherPhone | STRING | 否 | | emailAddress | STRING | 否 | | txCode | INT | 是 | | txDate | DATETIME | 是 | | previousBalance | INT | 是 | | currentBalance | INT | 是 |
嵌入：
| 名称 | 类型 | 是否必需 | | addressLine1 | STRING | 是 | | addressLine2 | STRING | 是 | | city | STRING | 是 | | state | STRING | 是 | | zip | STRING | 是 |
传出参数：
| 名称 | 类型 | 是否必需 | | retCode | INT | 是 | | details | STRING | 是 |
应用程序异常：
| 名称 | 类型 | 是否必需 | | errorCode | INT | 是 | | details | STRING | 是 |
业务场景：出站服务契约
解决方案体系结构与设计团队在贷款处理应用程序 (LPA) 和自动记帐支付应用程序 (ABPA) 所有者提供的 WSDL 文件基础上记录的出站服务契约包括以下服务名称、操作和有效负载。
TPCBanking ESB：出站服务契约——同步帐户信息
服务名称：
- LPACustomerAccountService
服务操作：
- LPACustomerAccountService.postCustAccountUpdateTx (synch)
传入参数：
| 名称 | 类型 | 是否必需 | | accountNo | INT | 是 | | accountType | STRING | 是 | | accountOwnerFN | STRING | 是 | | accountOwnerLN | STRING | 是 | | accountOwnerSSNo | STRING | 是 | | openDate | DATETIME | 是 | | transactionType | INT | 是 | | transactionDate | DATETIME | 是 | | previousBalance | INT | 是 | | newBalance | INT | 是 | | description | STRING | 是 |
传出参数：
| 名称 | 类型 | 是否必需 | | retCode | INT | 是 | | details | STRING | 是 |
应用程序异常：
| 名称 | 类型 | 是否必需 | | errorCode | INT | 是 | | details | STRING | 是 |
服务名称：
- ABPACustomerAccountService
服务操作：
- ABPACustomerAccountService.postCustAccountUpdateTx (asynch)
传入参数：
| 名称 | 类型 | 是否必需 | | accountNumber | INT | 是 | | routingNumber | INT | 是 | | accountType | STRING | 是 | | transactionDate | DATETIME | 是 | | previousBalance | INT | 是 | | newBalance | INT | 是 | | autoBillPayAuthCode | INT | 是 | | accountOwnerFName | STRING | 是 | | accountOwnerLName | STRING | 是 | | accountOwnerAddr1 | STRING | 是 | | accountOwnerAddr2 | STRING | 是 | | accountOwnerCity | STRING | 是 | | accountOwnerState | ENUM | 是 | | accountOwnerZip | STRING | 是 |
用例细化——确定中介
充分了解服务契约以后，下一步是确定所需的中介以促进从源到目标系统的数据传输。在该过程中的此刻，用例已经列出了系统的功能行为；我们可以详述用例中的事件序列，以确定用于支持功能的中介。
业务场景：用例细化——确定中介
下面显示了解决方案体系结构团队为了确定用于支持“同步帐户信息”流的中介而对用例 001 进行的细化：
TPCBanking ESB：用例 001——同步帐户信息（含中介）
触发器/前提条件：
成功结果：
- 分支机构系统调用 ESB，并将客户帐户更新同步到下游系统
失败结果：
- 分支机构系统无法调用 ESB，并且未将客户帐户更新同步到下游系统
- ESB 无法调用下游系统，并且未将客户帐户更新同步到下游系统
主要参与者：
次要参与者：
- 分支机构管理应用程序 (BMA)
- 贷款处理应用程序 (LPA)
- 自动记帐支付应用程序 (ABPA)
ESB 中介：
- SynchCustAcctInfoMediation
- PostSynchCustAcctInfoMediation
服务端点：
- ESB——CustomerAccountManagementService
- LPA——CustomerAccountService
- ABPA——CustomerAccountService
事件序列：（含中介详细信息）：
- 1. BMA 处理客户帐户更新事务。
- 2. BMA 向 ESB 的 CustomerAccountManagementService 提交同步客户帐户信息 (SynchCustAcctInfo) 请求并等待响应。
- 3. ESB 的 SynchCustAcctInfoMediation 接收 SynchCustAcctInfo 请求并将 SynchCustAcctInfo 转发给 PostSynchCustAcctInfoMediation 以做进一步处理。
- 4. ESB 的 SynchCustAcctInfoMediation 向 BMA 返回响应以表明请求已收到并且正在进行处理。
- 5. BMA 接收来自 ESB 的表明请求已收到并且正在进行处理的响应。
- 6. ESB PostSynchCustAcctInfoMediation 确定 SynchCustAcctInfo 请求的帐户更新事务类型。
- 7. 对于客户地址/联系人和帐户余额更新，ESB 的 PostSynchCustAcctInfoMediation 执行必要的接口映射和转换，将 SynchCustAcctInfo 请求转发给 LPACustomerAccountService，并等待响应。
- 8. 对于帐户余额更新，ESB 的 PostSynchCustAcctInfoMediation 执行必要的接口映射和转换，并将 SynchCustAcctInfo 请求转发给 ABPACustomerAccountService。
- 9. ESB 的 PostSynchCustAcctInfoMediation 接收来自 LPA 的表明请求已收到并且正在进行处理的响应。
- 10. ESB 记录所有事务的完成
事务划分：（含中介详细信息）：
- ESB 的 CustomerAccountManagementService 调用、到 SynchCustAcctInfoMediation 的路由和到 PostCustAcctInfoMediation 的交付应该在单独的事务上下文中进行，与请求的处理以及到 LPA 和 ABPA 服务的请求转发分离开来。
图 6. 同步客户帐户信息——事务划分
事件序列的变化：（含错误处理服务）
- 2.a BMA 无法调用 ESB 的 CustomerAccountManagementService，并且未将更新同步到下游系统。
- 2.b BMA 按照错误处理策略处理通信错误。
- 7.a ESB 的 PostSynchCustAcctInfoMediation 无法调用 LPA 的 CustomerAccountService，并且未在 LPA 上同步更新。
- 7.b ESB 的 PostSynchCustAcctInfoMediation 将请求转发给 ESB 错误处理服务（请参见图 7）。
- 7.c.ESB 错误处理服务按照错误处理策略处理通信错误。
- 8.a ESB 的 PostSynchCustAcctInfoMediation 无法调用 ABPA 的 CustomerAccountService，并且未在 ABPA 上同步更新。
- 8.b ESB 的 PostSynchCustAcctInfoMediation 将请求转发给 ESB 错误处理服务（请参见图 7）。
- 8.c.ESB 错误处理服务按照错误处理策略处理通信错误。
图 7. 同步客户帐户信息——错误处理
白板——列出中介逻辑
安排好事件序列并确定中介以后，设计团队现在可以主持白板设计会议，以列出中介流逻辑的内部构件。白板会议应该产生描绘中介流逻辑的关系图。
在 WebSphere Integration Developer 中设计中介
WebSphere Integration Developer V6.1 使开发人员可以构建跨越 WebSphere Process Server、WebSphere ESB 和 WebSphere Adapters 的基于 SOA 的集成解决方案。解决方案体系结构与设计团队还可以使用该工具完成旨在部署到这些环境的解决方案的设计。WebSphere ESB V6.1.2 提供了一组受支持的预定义中介原语，并且通过 WebSphere Integration Developer V6.1，设计团队还可以使用公共分类（中介原语）创建中介流的图形表示形式，以便与开发团队交流。
集成开发人员对该工具的预期用途是详细实现中介以支持该设计，而设计团队对该工具的预期用途则是生成设计构件，以表达用于支持需求的所需中介逻辑。
业务场景：WebSphere Integration Developer 设计构件
解决方案体系结构与设计团队为了生成详细中介设计构件而在 WebSphere Integration Developer V6.1 中执行的设计工作如下所示：
1. 对于每个入站和出站服务契约
2. 对于每个入站服务契约（将作为 SCA 导出公开）
- 创建中介模块
- 生成 SCA 组装关系图
- 创建中介流组件
3. 对于入站服务契约上的每个操作
然后可以对这些步骤中生成的设计构件打包，并作为项目交换文件（请参见“下载”部分）导出，以供开发团队用作参考。下面几个部分取自解决方案体系结构与设计团队向开发团队提供的“同步帐户信息”流设计文档。
TPC Banking ESB：外部构件库：
包含向外部 ESB 客户端（即 CustomerAccountManagementService）公开的服务的 WSDL 和模式定义。
TPC Banking ESB：内部构件库：
包含向内部 ESB 中介（即 PostSynchCustAcctInfoService、ErrorHandlingService、ExceptionHandlingService）公开的服务的 WSDL 和模式定义。
TPC Banking ESB：LPA 构件库：
包含贷款处理应用程序的 LPACustomerAccountService 的 WSDL 和模式定义。
TPC Banking ESB：ABPA 构件库：
包含自动记帐支付应用程序的 ABPACustomerAccountService 的 WSDL 和模式定义。
TPC Banking ESB：Synch Customer Account Info 中介：
Synch Customer Account Info 中介是用于处理来自 BMA 的 SynchCustAcctInfo 请求的 ESB 入口点。该中介通过将请求转发给 ESB 的 Post Synch Customer Account Info 中介来开始请求的处理。一旦成功转发请求以进行处理，该中介将向 BMA 返回响应，表明该请求已收到并且已提交以进行处理。
SCA 组装关系图和中介流设计如图 8 和 9 所示：
图 8. Synch Customer Account 中介——SCA 组装关系图
图 9. Synch Customer Account Info 中介——中介流设计
TPC Banking ESB：Post-Synch Customer Account Info 中介：
Post-Synch Customer Account Info 中介由 Synch Customer Account Info 中介调用来将请求中转和转发到 LPA 和 BMA 客户帐户服务。该中介接收请求并基于事务类型对请求进行筛选。
对于帐户余额更新事务，该中介转换请求并将其转发给 ABPA 客户服务。
对于帐户余额和客户数据（联系人/地址）更新，该中介转换请求并将其转发到 LPA 客户服务。
所有其他事务类型不转发到 ABPA 或 LPA 客户帐户服务。
如果在调用 ABPA 和/或 LPA 客户帐户服务时发生通信错误，该中介将把请求转发到错误处理服务。
如果在调用 LPA 客户帐户服务时返回了 LPA 流程异常，该中介将把异常映射到某个 ESB 异常，并将该异常转发给异常处理服务。SCA 组装关系图和中介流设计如图 10 和 11 所示：
图 10. Post Synch Customer Account 中介——SCA 组装关系图
图 11. Post Synch Customer Account Info 中介——中介流设计
支持需求的设计决策点
与在每个设计中一样，对体系结构和设计决策做文档记录是非常重要的。特别是，应该对有关设计模式和所应用的最佳实践的决策进行传达和做文档记录，以供开发团队参考。
业务场景：决策点
下面列出了解决方案与体系结构团队为“同步帐户信息”流提供的决策和设计模式：
TPC Banking ESB：解决方案设计决策——同步帐户信息
设计决策：
- 使用错误处理服务来封装通信错误的错误处理决策的实现。
设计模式（错误和异常处理）：
- ESB 应该在检测到无法解决的通信或系统异常错误条件时调用错误处理服务。
优点：
- 外部化和集中的错误处理策略管理
- 关注事项分离：ESB 中介中用于数据传输的中介逻辑与错误处理服务实现中用于错误处理策略的业务逻辑分离。
缺点：
- 移交给外部服务后，失去了连续和有序的请求交付。
- 事件排序带来了中介与错误处理服务之间的数据依赖性，以确保不会在被转发给错误处理服务的请求之前处理传入请求。
设计决策（接收与处理请求之间的事务划分）：
- 同步请求的接收与到目标系统（该系统通过移交给异步端点来实现）的请求路由之间的事务划分。
设计模式：
- 源系统向 ESB 提交同步请求。
- T1：源系统向 ESB 发送请求，ESB 将请求转发到某个队列，ESB 响应请求。
- T2：ESB 从队列检索消息，将请求中转并路由到目标系统
优点：
- 有保证的消息交付以实现有保证的处理。
- 源系统不受下游系统消息处理的制约
- 从源的发送和从目标系统的接收在事务上分离了。
缺点：
- 在到下游系统的通信失败的情况下，源系统不知道已失败的事务。
设计决策（有序的请求处理）：
设计模式：
- 源系统向 ESB 提交同步请求。接收中介异步调用（放在队列上）一个后续中介，后者从队列检索消息，并按照接收请求的顺序（FIFO 队列）将请求中转和路由到下游系统。在将正在处理的消息作为已处理消息提交之前，该后续中介不处理下一个消息。
优点：
缺点：
错误处理策略
定义错误处理策略应该是任何体系结构设计的基本组成部分，包括 ESB 解决方案的体系结构设计。下面是为 ESB 解决方案定义策略的一些重要指导原则：
- 策略定义应该列出错误条件的业务影响。
- 每个策略应该将最高效和最有效地减少和消除业务影响作为其目标（并非始终那么容易）。因此作为策略定义的一部分，应该有针对错误条件解决的非常明确的策略，以及有关如何降低或消除业务影响的指示。
- 在检测到无法解决的错误条件时，应该将每个策略映射到原始触发事件。例如，在调用某个服务的重试次数超过限制以后，或者在服务的调用返回了系统异常时。
- 策略定义应该基于用例中定义的失败实例对无法解决的错误类型进行归类。这可以确保策略与需求保持一致。注意：可能存在识别出新需求的情况
- 除了尝试中转和传输数据以外，策略定义应该避免在 ESB 中显式存储瞬时有效负载。
- ESB 不应该负责管理下游系统的失败数据处理。相反，作为最佳实践，ESB 应该负责在处理系统之间的数据传输时减轻错误影响。
- 针对目标端点上发生的应用程序错误（作为错误或应用程序异常返回）的策略定义不应该包括错误处理服务所进行的解决。ESB 可以将日志记录和/或从目标到源系统的错误转发作为需求。如果发生错误或应用程序异常，应用的将是在应用程序级别定义的策略。如果需要重新提交，源应该使用 ESB 发起重新提交，以促进数据传输。
- 策略定义应该包括实现选项和首选设计注意事项选择。务必要让业务团队清楚实现某个策略所需要的工作。这使得业务团队能够将业务影响与实现工作和成本进行权衡。如果需要的话，修订策略以最大限度降低实现成本的做法并不鲜见。
- 策略定义应该指定与错误处理任务相关联的角色（例如，ESB、错误处理服务、系统管理员等等）。
业务场景：错误处理策略
通过与业务团队和应用程序所有者协作，解决方案与体系结构团队能够为“同步帐户信息”和“调整帐户余额”流定义错误处理策略。下面总结了在 ESB 检测到它无法连接到一个或多个下游服务时的策略定义：
TPC Banking ESB：错误处理策略——同步客户帐户信息（出站）
错误现象：
错误结果：
错误条件类别：
源系统：
中介：
目标系统：
业务相关性：
- 基于帐户历史记录信息做出贷款处理决策
- 基于帐户余额信息处理自动记帐支付事务
业务影响：
策略参与者（角色）：
- ESB 系统
- 错误处理服务
- 贷款系统 IT 管理员
- 自动记帐支付系统 IT 管理员
策略错误解决策略：
参与者 = ESB 系统：
- 1. ESB 系统检测到无法解决的通信错误条件，并向错误处理服务提交 HandleCommError 请求。
- 2. ESB 系统进入 CommSysError 状态，并将后续数据请求转发给错误处理服务，直到 CommSysError 状态指示为已由错误处理服务清除。
- 3. 一旦 CommSysError 状态指示为已清除，ESB 将立即恢复后续请求的处理。
- 4. 到下游系统的后续请求的成功处理将解决积压的业务影响。
参与者 = 错误处理服务：
- 1. 错误处理服务接收到 HandleCommError 请求，并将错误条件通知贷款处理和/或自动记帐支付系统 IT 管理员。
- 2. 错误处理服务查询传入的 SynchCustAcct 请求，并对该事务做日志记录以用于审核目的
- 3. 错误处理服务为贷款处理和/或自动记帐支付系统管理员公开交互机制，以指示错误解决情况。
- 4. 错误处理服务等待来自贷款处理和/或自动记帐支付系统管理员表明通信错误已解决的指示。
如果是贷款系统：
- 5. 错误处理服务按照接收请求的顺序为排入队列的事务处理 SynchCustAcct 请求（针对每个帐户）。说明：帐户历史记录对于做出贷款决策最为重要
如果是自动记帐支付系统：
- 6. 错误处理服务为排入队列的事务处理最新 SynchCustAcct 请求（针对每个帐户）。说明：自动记帐支付事务需要的是帐户上的当前余额
- 7. 错误处理服务继续接受传入请求，直到队列积压的处理完成，此时它将向 ESB 指示 CommSysError 已解决。说明：这应该与队列积压的处理进行同步
- 8. 错误处理服务通知贷款处理和/或自动记帐支付系统 IT 管理员错误积压已处理完成。
参与者 = 贷款系统管理员：
- 1. 贷款系统管理员接收到错误条件通知，并设法解决贷款系统问题。
- 2. 贷款系统管理员更新贷款处理应用程序 (LPA)，以指示所有贷款处理决策将需要分支机构手动确认帐户历史记录的准确性，直到错误条件得到解决。
- 3. 贷款系统管理员与错误处理服务交互，以指示问题已得到解决。
- 4. 贷款系统管理员提交错误实例和解决报告。
- 5. 贷款系统管理员接收到来自错误处理服务的通知，表明积压已完成处理，并且清除了 LPA 上的指示器以消除分支机构的手动确认需求。
参与者 = 自动记帐支付系统 IT 管理员：
- 1. 自动记帐支付系统 IT 管理员接收到错误条件通知，并设法解决贷款系统问题。
- 2. 自动记帐支付系统管理员设置自动记帐支付应用程序 (LPA) 的状态，以拒绝所有传入的自动记帐支付请求；在问题得到解决之前，客户必须发送手动支付，以防止使用错误的帐户余额信息处理任何支付。
- 3. 自动记帐支付系统管理员与错误处理服务交互，以指示问题已得到解决。
- 4. 自动记帐支付系统管理员提交错误实例和解决报告。
- 5. 自动记帐支付系统管理员接收到来自错误处理服务的通知，表明积压已完成处理，并且已重置状态以允许使用最新帐户余额信息处理传入自动记帐支付请求。
实现选项：
|
操作
|
选项
| ESB 将请求转发给错误处理服务
| 选项 1：ESB 通过同步 Service Invoke 原语转发请求
优点：
§
中介流中的简单调用
缺点：
§
无 | 错误处理服务通知贷款和/或自动记帐支付系统 IT 管理员
| 选项 1：错误处理服务通过 WebSphere 电子邮件适配器将通知的生成和提交过程自动化
优点：
§
只需最少的编码逻辑
§
重用适配器功能来提交电子邮件
§
SCA 绑定和服务调用
缺点：
§
需要用于通过适配器提交电子邮件的附加设计框架
选项 2：错误处理服务通过 JavaMail API 以编程方式将通知的生成和提交过程自动化
优点：
§
采用编程方式并由应用程序控制
缺点：
§
需要用于编程实现的附加业务逻辑
§
需要用于通过 JavaMail API 提交电子邮件的附加设计框架 | | 错误处理服务为贷款系统和/或自动记帐支付 IT 管理员提供交互机制 | 选项 1：通过 WebSphere Process Server 人工任务进行人工交互
§
只需最少的编码逻辑
§
SCA 绑定和对人工任务组件的服务调用
§
现成提供了预先存在的 UI，可以实现快速部署和测试。
缺点：
§
需要用于人工任务启动和处理的附加设计框架
选项 2：通过编程接口 Java API 的 Web 界面或 Web 服务调用进行交互
优点：
§
技术无关性
缺点：
§
需要为尚未计划的用户界面进行附加编码
§
客户端和服务器端需要过多的编码以支持交互
§
仍然需要用于启动编程调用的用户界面 |
首选实现选项：
|
操作
|
选项
| ESB 将请求转发给错误处理服务
| ESB 通过同步 Service Invoke 原语转发请求 | 错误处理服务通知贷款和/或自动记帐支付系统 IT 管理员
| 错误处理服务通过 WebSphere 电子邮件适配器将通知的生成和提交过程自动化 | | 错误处理服务为贷款系统和/或自动记帐支付管理员提供交互机制 | 通过 WebSphere Process Server 人工任务进行人工交互 |
新的 ESB 需求和更改请求：
- ESB 应该检测到下游服务的无法解决的通信错误，并且应该支持调用错误处理策略中列出的错误处理服务和功能行为，以检测错误解决情况并继续正常的请求处理。
对错误处理服务的需求——单独对 LPA 和 ABPA 做文档记录。
结束语
本文介绍了设计用于部署到 WebSphere ESB 的中介的整体方法。工作分解结构用于在业务场景的上下文中阐明设计工作，其中包括了生成必要设计构件以及为中介的设计和文档生成构件的任务。
下载 | 描述 | 名字 | 大小 | 下载方法 |
|---|
| Code sample | ESBDesignArtifacts.zip | 89 KB | HTTP |
|---|
参考资料 学习
获得产品和技术
讨论
-
WebSphere 论坛：这是一个针对特定产品的论坛，在这个论坛中，您可以获得技术问题的解答，并与其他 WebSphere 用户分享您的专业技术。
关于作者  | | | Tendai Chinoda 是 IBM Business Partner Technical Enablement - WebSphere Competency Center 的咨询软件工程师。他为 IBM WebSphere 系列产品的主要 ISV 和业务合作伙伴提供支持服务。Tendai 通过了 IBM Certified for On Demand Business - Solution Designer 认证、IBM Certified Solution Developer - Web Services Development with WebSphere Studio V5 认证和 Sun Certified Programmer for the Java 2 Platform 1.2 认证，并通过了一些其他 WebSphere 产品认证。他获得了田纳西州立大学（位于田纳西州纳什维尔）的电子工程学士学位，并取得了宾夕法尼亚州立大学（位于宾夕法尼亚州的 University Park）的计算机科学与工程硕士学位。 |
对本文的评价
| 
