当前多数银行都停留在渠道独立平台的阶段，各个渠道之间各自为政，不能复用业务逻辑，数据分散而缺乏条理，并且各渠道之间重复开发的任务很多，没有达到真正意义上的多渠道整合。如图 11-1 所示是目前国内多数银行的“信用卡申请”渠道架构，各渠道从前端到后端都有自己的一套实现。基于这样的渠道平台，银行的信用卡申请业务不能很好地进行多渠道整合，各渠道之间业务流程存在差异，业务数据不统一，给客户带来极大的不便，例如，客户在柜台进行的信用卡申请在网上银行和电话银行不能进行进度查询，或者客户如果想要修改错误信息，不能在网上银行进行修改，必须到银行柜台进行更正等。
尽管有些银行能够实现数据的共享，达到“多渠道整合”的效果，但也不是真正意义上的多渠道整合，只不过是数据库层次的简单复用，和真正的多渠道整合还有很大的差异。
图 11-1. 目前国内多数银行的渠道架构
A 银行的 SOA 整合方案基于 IBM BTT 产品。在方案中，银行的各渠道复用业务逻辑，各个渠道之间能够互相交互，作为一个整体为客户提供服务。下面以信用卡申请流程为例子，介绍在 A 银行的 SOA 整合架构中的信用卡申请场景，这里分步骤进行描述，整合场景如图 11-2 所示。
图 11-2. 基于 SOA 多渠道整合的 A 银行信用卡申请场景
步骤 1 客户到离家距离较近的银行柜台申请信用卡，柜台工作人员辅助其进行申请流程，当申请提交后，请求被 BTT 的渠道接入层捕获，这一层次上将会处理不同渠道的不同业务请求，做这个渠道相关的一系列处理工作。
步骤 2 申请流程被提交到“业务逻辑层”，这里业务逻辑层是和渠道无关的，业务逻辑可以被多渠道所复用。
步骤 3 信用卡申请业务流程执行，通过 BTT Adapter 与 WebSphere ESB 接入，业务消息将被转发到后台的银行核心系统、客户管理系统等。与客户管理系统交互，获取该客户的消费记录来评定客户的信用等级，而银行的核心银行系统或者信用卡业务系统运行信用卡业务逻辑。
步骤 4 银行需要花费两周左右的时间来审核、处理信用卡申请业务流程。
步骤 5 两周后的某一天，该客户到公司附近的一台 ATM 机进行取款，当插入银行卡，登录成功后，ATM 机界面提示该客户：“您两周前的信用卡申请业务已经成功处理完成，相应卡片和材料将会在一周内邮寄往您当时登记的地址。您当时登记的地址为：北京市海淀区＊＊街＊＊小区＊＊楼＊单元 401”。
步骤 6 当天客户在家中登录网络银行，当客户成功登录后，网页上会提示给该客户同样的信息。
上面我们描述了基于 IBM BTT 的 A 银行 SOA 整合方案的一个场景，如图 11-2 所示，从中我们可以看出以下几点：
1）A 银行实现了前端多渠道整合，各个渠道的客户端架构各不相同，相应的处理逻辑也各不相同。基于 IBM BTT 的 A 银行的 SOA 整合架构中，BTT 多渠道整合方案提供了渠道接入层，用于处理各个不同渠道发来的请求，处理渠道相关的逻辑，并把业务请求和请求数据传递到业务逻辑层和 SOA 整合层，进行业务逻辑 SOA 整合。
2）业务逻辑层是复用的业务逻辑，和前端渠道信息无关，并且可以被不同渠道复用。
3）银行各个渠道之间通过多渠道整合方案复用业务逻辑和业务数据，可以无缝地工作在一起，各个渠道作为一个整体向客户提供服务。
图 11-3 所示，是 A 银行的 SOA 整合架构图。
我们上面提到过该银行的 SOA 整合架构是基于 IBM BTT 的，从图中可以看出该银行的 SOA 整合架构从上到下分为以下几个层次：
1）前端渠道客户端层，这一层是各个不同的渠道的客户端架构和渠道应用软件的统称。客户端架构是指运行渠道应用软件客户端的平台，例如浏览器就是网络银行的客户端平台，柜台终端就是柜台系统的客户端平台。渠道应用软件是指不同渠道上的银行渠道软件，例如网络银行和柜台系统等。
2）渠道接入层，这一层用于处理来自不同渠道的业务请求，BTT 为每个渠道提供了请求处理器，专门处理这个渠道的业务请求。请求处理器主要做几个工作：接受来自该渠道的请求，处理并封装来自该渠道的数据，传入数据并调用后台业务逻辑，运行业务逻辑并接受后台业务运行结构，返回运行结果并显示到客户端。BTT 的渠道接入层允许用户进行扩展，以支持各自银行特定的渠道需求。
图 11-3. A 银行的 SOA 整合架构图
3）业务逻辑层，这个层是无渠道差别的业务逻辑，业务逻辑可以被各个渠道所复用。当渠道接入层调用业务逻辑层时，业务逻辑层只需要有相应业务数据及业务代号就可以被调用。业务逻辑层和渠道复用层配合实现 BTT 的多渠道整合结构的前端架构。
4）SOA 整合层，这一层是 BTT 的适配器，BTT 适配器遵循 JCA1.5 标准，提供了 Outbound，Inbound 通信。Outbound 通讯允许 BTT 应用程序主动发起请求与 WebSphere ESB 通信，Inbound 通讯通过消息驱动 Bean 接受来自外界的调用，达到与 BTT 交互的效果。
5）后台系统层，这一层包括银行的核心业务系统，也包括其他应用系统，例如 SAP ERP，CRM 系统等。它们作为整个 SOA 整合框架中的一部分，通过 JCA Adapter 与 BTT 通信。
在整个整合方案中 IBM BTT 具有前端渠道整合的优点，并具有良好的松耦合的 SOA 架构支持。通过 IBM BTT 以及后面章节要介绍的众多 IBM SOA 产品，可以实现 A 银行的 SOA 整合架构。
本节介绍 A 银行的信用卡申请流程，在接下来的几章中将从实战的角度来介绍如何对 A 银行的信用卡申请流程进行 SOA 整合。
信用卡申请流程的客户大致可细分为本地普通居民、工商业者及白领阶层。这三个客户群体有不同的信用卡需求，但所有客户对于银行的渠道需求都一样，也就是方便、便宜、快捷、准确与安全。我们根据不同客户的特点，推出不同的银行信用卡销售渠道，便于吸引客户，并提供高效服务。三类细分客户的需求分别是：
1）本地居民更注重方便与快捷；
2）工商业者更看重快捷与便宜；
3）白领阶层更看重方便与网上银行。
根据不同的客户细分，银行可以通过柜台、电话银行与网上银行等渠道传递信用卡产品。对于本地居民客户，一般会选用附近的柜台渠道，工商业者一般会选用附近柜台渠道或者电话银行渠道，白领阶层则更偏向于网络银行渠道。为争取更多客户，覆盖更多市场面积，本场景中的 A 银行信用卡申请流程将并发推出三渠道销售：柜台渠道、电话银行及网上银行。信用卡申请流程的业务流程如图 11-4 所示。
图 11-4 中的 10 个步骤描述分别如下：
1）客户递交申请表和相关资料；
2）前台柜员将客户身份资料和申请资料扫描后提交至信用卡申请处理中心；
3）信用卡申请处理中心按照事先约定规则和交易自动分配给申请初审柜员；
4）初审柜员对申请做出初步意见，在申请资料上做出批注；
5）向征信机构提交申请，查询征信报告；
6）征信机构提交征信报告；
7）向客户请求补充材料，或者初审拒绝，生成拒绝信给客户；
8）初审通过，送复审柜员处理（如果初审拒绝，以下步骤将不进行）；
9）复审未通过，生成拒绝信给客户（进行这一步骤，则以下步骤不再进行）；
10）复审通过，批准，处理结束。
根据各自业务策略和战略规划，每个银行都有自己不同的业务目标，IBM 根据在银行业多年的实践经验，给出针对零售银行业的多渠道整合应用参考架构，该架构面向服务架构（SOA）的参考架构，从业务上和技术上涵盖和概括完整的 IT 系统和建设的各个方面和内容，并形成服务的规划、创建、使用及监管等面向服务的技术参考架构，代表业界的技术发展方向。IBM 的 BTT 产品符合 SOA 参考架构，拥有前端的渠道整合和后端的业务整合，BTT 不仅是一套成熟的产品——在全球拥有近二百家银行用户使用 BTT 用于银行的核心基础架构，它更是一套编程模式和方法论，它总结并继承了业内的最佳实践思想，最大程度地符合现阶段及未来的银行业务发展需求。
本章主要介绍了上述的基于 IBM BTT 的银行业 SOA 架构以及该架构在银行业的应用，本章还介绍了“信用卡申请流程”流程，在接下来的章节中将以 A 银行的信用卡申请流程来讲解从前端渠道整合，到中间业务逻辑重用，以及最后到后端的 SOA 整合，从实战角度的介绍 A 银行的 SOA 整合。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14780828/viewspace-594427/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/14780828/viewspace-594427/
扫一扫
878
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
