级别： 初级 Scott Simmons, 执行 IT 架构师, IBM
2009 年 9 月 24 日 
随着银行的解决方案实现从紧密耦合的业务线应用程序体系架构转向采用基于 SOA 的方法，我们正在见证核心银行系统实现的变迁。此外，在解决方案设计中发生这些改变的同时，基于传统消息传递技术、以集成为中心的方法也逐渐转向基于企业服务总线（Enterprise Service Bus，ESB）模式和更为开放服务的架构。本文解释银行在这一转变过程中实现连接所采用的一些方法，并描述正在出现的一些关键模式，它们支持当前及下一代银行解决方案的并存。
来自 IBM WebSphere Developer Technical Journal。
银行系统中正在改进的连接方法
历史上，银行企业都是围绕企业业务线进行组织，其中每个小组负责执行自己特定功能的策略，比如贷款和投资计划。因此，每个小组也定义和管理 IT 应用的改进，比如贷款和抵押处理、信用卡处理和 CASA（经常帐户/储蓄帐户）解决方案。IT 共享功能和运营管理功能服从于中心 IT 功能。所以，通过消息或网关产品共享功能的需求导致跨企业连接解决方案的诞生。通常，这些解决方案被构建为一个反应性响应，而不是事先规划好的方法，因而，这些解决方案通常在灵活性和弹性方面存在局限性。随着面向服务设计的出现，这些第一代集成解决方案逐渐成为企业 SOA 方法的一部分。
在过去的 3-5 年间，SOA 已经成为世界各地大型银行的关键架构设计方法。尽管 SOA 最初用于支持非核心银行功能，但是 SOA 现在已成为用于转变企业事务银行系统的关键策略。利用该方法，银行使用基于服务的设计扩展核心银行系统，使之具有新的功能，以及通过基于通道的解决方案与后端系统集成，以支持银行 IT 现代化的业务服务方法。
核心银行解决方案的连接方法
银行客户根据其核心系统实现的不同设计和实现不同的 SOA 解决方案。具有现有大型机实现的银行倾向于采用基于现有 CICS® 或 IMS™ 组件的自下而上的服务实现方法。通过公开服务来访问大型机的功能，并且通常基于应用分析识别服务。随着新服务客户的潜在负载不断增长，解决可伸缩性问题成为当务之急，该方法面临着挑战。此外，服务设计需要确保所提供服务的业务适用性，并且需要在正确的粒度级别进行定义。这两个方面难以与纯自下而上解决方案设计相吻合。以下服务公开、ESB 或消息代理技术可以在基于通道的应用程序（比如 Internet 银行系统）之间和现有企业应用之间提供服务虚拟化、中介、路由和/或转化。这个中介主题在本系列的第 1 部分 exploring the Enterprise Service Bus 中有详细介绍。
另一方面，实现打包核心银行应用程序的银行采用一种与 SOA 和连接稍微不同的方法。这些客户的服务设计通常基于与应用程序（比如 Finacle Integrator、Fidelity Xpress 和 SAP 的 Exchange Infrastructure）一起提供的入站和出站服务/消息接口。由于所提供的供应商服务可能与来自业务驱动设计的实际解决方案需求不符，这种方法也会面临挑战。在这些情况下，ESB 解决方案通常为转换和中介提供打包的应用程序和银行应用程序（核心及非核心），以解决/减轻不相符的问题。
随着 SOA 的出现，银行通常基于组织领域来定义和分类服务，而这种基于领域的方法也在他们的 ESB 方法中得到了证明。例如，经常可以看到与帐户管理、贷款发放、客户管理及其他关键业务领域对应的服务分类。连接拓扑通常也对应于业务线（例如，贷款管理和联系中心），而较大的银行也倾向于基于区域上的临近来部署 ESB 解决方案。例如，我们可以看到正在形成这样一种趋势，银行通常在总部运行集中式 ESB，在区域数据中心或者分支机构运行与集中式 ESB 关联的区域 ESB（见图 1）。
图 1. 与业务线及区域临近对应的连接
要更为详细地了解有关连接基础设施和联邦的内容，Greg Flurry 关于 企业中的联邦连接 的文章是一个不错的起点。
ESB 设计趋势
正如前面所提到的，具有遗留 SOA 实现的银行采用反应性设计方法，这种方法以集成现有 ESB 和消息传递解决方案为基础。刚开始将 SOA 合并到其企业 IT 策略中的银行倾向于在连接拓扑中更加具有前摄性，其中合并了 ESB、服务注册和服务管理方法作为基础。
例如，一家大型银行正在从定制的、基于大型机的、使用 IBM® WebSphere® MQ 作为核心传输方案的消息解决方案，向基于 JMS 的、合并分布式商业 ESB 的解决方案迁移。目标体系架构将提供 WebSphere MQ，还提供对核心银行解决方案层组件的基于 SOAP/REST 的调用。作为迭代部署方法的一部分，银行将向 ESB 实例再次启用 WebSphere MQ 解决方案中的现有功能。
另一个常见的趋势是，应用服务网关模式来为服务端点提供增强的访问安全。我们看到过这种方法用于支持与大型机功能的中介，如图 2 所示。
图 2. 用于增强访问安全的服务网关模式
该体系架构方法在基础设施的多个运营层启用服务调用；例如，向分布式和大型机服务提供路由和访问网关支持。对于在大型机上提供服务的银行，推荐的目标拓扑定义一个与实际服务端点一起配置的集中企业 ESB 实例，一个额外的服务网关层使用 IBM WebSphere DataPower® Appliances 卸载安全处理、XML 验证和解析及服务路由。
合并和收购场景可能导致联邦连接实现。一家全球银行正处于解决方案的设计阶段，将支持在两个成员组织之间联邦的业务服务。在本例中，银行计划在分布式层使用 ESB 来支持信用卡操作，此外还将通过配置在大型机上的 ESB 实例提供基于 CICS 的零售银行服务。推荐的设计将在信用卡和银行功能之间提供互操作性，同时优化对驻留在大型机上服务的访问。图 3 显示了该方法的优势，即在大型机上提供服务的虚拟化和聚合，而不是在分布式层具有单个 ESB 实例。双 ESB 方法通过在接近服务端点的地方提供请求的服务聚合而最小化数据移动，另外还提供能力通过服务网关直接调用基于大型机的服务。
图 3. 服务虚拟化和聚合的优势
稍加注意就可以看到，银行系统中的 SOA 解决方案与业务线定义的服务领域概念是耦合的。正如前面提到过的，该方法与业务匹配，但是需要很好的设计和运行时治理。由于职责方面的挑战，对于客户来说，前摄性地在这些方法的规划和管理上进行投资是至关重要的。没有稳固的体系架构基础和强大的 SOA 治理模型，这些方法将很快变成不可管理的体系架构，从而失去实现 SOA 的优势。
图中揭示了我们当前在银行中看到的一些关键连接趋势，以及一些与金融机构合作得到的关键实现建议。
致谢
应该指出的是，本文的成果基本上建立在 IBM 技术社区得出的最佳实践的基础之上，衷心感谢 Marc-Thomas Schmidt、Rachel Reinitz、Greg Flurry 和 Michael Ellis 等人。此外，作者还要感谢 Greg Flurry 严格审查了本文并提出宝贵意见。
参考资料 学习
获得产品和技术
关于作者  | 
| | Scott Simmons 是 IBM Worldwide Banking Center of Excellence 的首席银行解决方案架构师。在供职于 Banking Center of Excellence 之前，Scott 曾经是 Worldwide SOA Technical Architecture 团队的首席架构师，是全球 50 多个 IBM SOA 架构师的技术领导者。Scott 既是 IBM 认证的高级 IT 架构师，也是 Open Group 的总 IT 架构师。Scott 擅长于为客户和合作伙伴设计、开发及实现 SOA 体系架构，他还是一个认证的 SOA 解决方案设计师。Scott 在很多杂志上发表过文章，包括 WebSphere Developer Technical Journal、Web Services Journal 和 WebSphere Journal。在 IBM 工作之前，Scott 曾经是 Chief Technology Office 的首席架构师，在 Peregrine/Extricity 担任技术解决方案主管。Scott 在集成、消息架构以及采用 Vitria、Illustra/Informix 和 Sybase 的数据架构设计/部署方面具有广泛的经验。 |
对本文的评价
| 
