莱芜商业银行SOA解决方案.doc

1.1 客户现状与其它行业一样，目前商业银行之间竞争很激烈，IT是解决银行生存和发展问题的有力武器，既要配合业务的推广，又要帮助银行开展新业务。银行业务在不断发展，IT技术也日新月异，导致银行内部的系统和应用种类繁多，结构也非常复杂。如何在业务和技术两个层面上对这些系统进行整合已经成为摆在银行IT部门面前最重要的问题。在业务方面，银行希望能够灵活的定义业务模型，以快 速应对不断变化的业务需求；降低成本，去除冗余的系统和应用；同时还能够有效的利用现有的系统和应用；最终实现横向的端到端的整合，将分散的独立的系统整 合在一起，合并为一个完整的系统。在技术方面，银行希望减少应用程序接口的数量和复杂程度，并且让所有的应用的能够互相通信，不论这些应用采用什么编程语 言，用于哪种操作平台，也不管它们使用了什么开发模型、协议和数据模型。1.2 面临的挑战日益复杂的IT基础架构越来越多的系统被独立的建立，越来越多的系统需要相互沟通，以完成复杂的业务功能。尽管用户已经在一定程度上建立了用于整合的系统，如大前置系统，但往往由于缺乏统一的整合规范，导致业务的灵活创新并不是一件容易的事。更加灵活的业务模型身处一个越来越具有竞争性的环境，需要更快速的业务实现能力并推向市场，同时需要创新业务的能力以吸引更多的客户。莱芜商业银行面临的挑战由于银行卡系统与核心业务系统分离，导致银行卡系统必须通过前置与核心系统交互。而在前置上的相关定制缺乏灵活性，导致开展新的业务非常困难。 由于支付系统与核心系统直连，因此不能支持卡业务。考虑到未来网银系统、客服系统将会陆续的建设，它们与现有系统的交互关系将会变得非常复杂，单纯依赖 大前置恐怕难以胜任。莱芜商业银行现有的业务系统涵盖了如下几个相对独立的系统：综合业务（核心）系统、银行卡系统（上海银联）、国结系统、中间业务系统、银联系统、信贷系统、ATMP系统、兴业银银通系统、支付系统前置和山东银联前置（山东银联2.0和柜面通）。如下图：1在实际的生产运营中，上述的架构目前面临着如下问题：由于银行卡系统与核心业务系统分离，导致银行卡系统必须通过前置与核心系统交互。而在前置上的相关定制缺乏灵活性，导致开展新的业务非常困难。考虑到未来网银系统、客服系统将会陆续的建设，它们与现有系统的交互关系将会变得复杂，单纯依赖莱芜大前置恐怕难以胜任。经过仔细研究，我们为莱芜商业银行部署了如下方案：21.3 解决方案IBM提供了以SOA整合为基础的中小商业银行解决方案可以帮助你解决上述问题。这套方案采用了ESB（企业服务总线）技术。ESB是SOA整 合中的基础设施，它通过一组丰富的功能，实现对应用程序之间交互的管理和监视，能够在银行内部和银行之间连接新的和现有软件应用程序。它支持服务可视化， 从而在服务请求程序和服务提供程序之间提供了多方面的分离。以ESB为企业整合系统的核心，可以有效的重用了现有的服务及系统，降低了时间、成本以及集成的风险，实现了灵活的业务模型，为新业务的开展提供了可能与方法。而且，它制定了基础的集成规范，为未来系统的集成提供指导标准。3服务消费系统通过多渠道整合平台（MCI Platform）来统一的接入ESB，也可以通过开发独立的前端适配器接入ESB。由服务网关（Services Gateway）来完成整合请求与非整合请求的分流。2 系统架构采用ESB技术，可以快速在SOA架构中部署现有的应用。下图是系统架构图。它有五个主要组成部分：ESB、服务提供者（Service provider）、服务使用者（Service Consumer）以及ESB分别与服务提供者和服务使用者的连接部分。ESB：这个架构的核心组件，它将所需的服务ESB服务与现有的服务组件连接起来，并提供日志和错误处理等功能。服务提供者：在服务组件库中注册的服务组件。服务使用者：发出服务请求连接部分：建立ESB和前/后端系统的通讯，将ESB与一些固定的接口连接起来。4整个ESB核心程序包由MB消息流开发实现。其工作流程有两条主线：服务请求处理流程和服务响应处理流程。在服务请求处理流程中处理服务请求报 文，完整填充服务的分解结构信息，服务状态控制，设置并执行报文路由，向服务提供系统发起服务请求。在服务响应处理流程中处理服务响应报文。审核服务的处 理状态，决定是否结束服务，还是交由服务控制流程继续请求后续的服务。服务错误处理，服务流水记录，服务冲正等功能作为公用的流程由服务请求流程及响应流 程所共用。下图是ESB系统核心功能简图。5ESB系统核心功能有如下特点：原始组件封装和注册：按照标准的格式封装现有系统的各个服务组件，并在服务组件库（Services Repository）中注册。原子组合服务实现：按照业务需求编排已经注册的原始服务组件，形成原子服务或组合服务，并向服务请求者发布为ESB服务。在实现的过程中，能够自动控制服务各步骤的切换，并且对于组合服务能够自动构造各个步骤的请求报文格式，自动合并各步骤的响应结果。自动实现路由控制：服务请求者无需知道服务提供者的所在物理位置，由ESB完成服务请求者与服务提供者之间的连接。服务自动冲正：对于组合服务，如果在处理某步的请求时发生了错误，则ESB系统会主动发起冲正请求，将先前的各步骤的数据更改复原，就象这个ESB服务发生之前一样。冲正过程可由用户灵活配置。服务错误处理：对于出错的服务，进入错误处理流程， 记录错误日志及流水， 请求冲正处理， 组织冲正报文，并通知服务请求者。服务流水及日志记录：记录报文及流水至数据库中。订阅/发布服务：实现主题订阅及主题发布的服务模式。不确定服务查询：服务提供者为ESB， 通过查询日志流水， 获取失败的ESB服务各步骤处理状态信息， 并将查询结果返回给服务请求者。数据缓存储：为提高数据访问性能，将数据库中关键的数据缓存至内存中访问。服务授权控制：完成对发布的ESB服务的访问权限管理及控制，可以限制服务是否可由服务请求者所访问。ESB系统架构中，Adapter也是不可或缺的一部分（又做Connector）。下图为ESB解决方案中的Adapter框架。6它封装了典型的Adapter功能。包括：提供MQ接入功能：完成对ESB的接入功能， 也可用来接入其它的MQ系统。提供Socket接入功能：完成对使用Socket进行通讯的系统的接入。 可用来连接服务请求系统及服务响应系统。提供完成报文格式转换的接口：此接口将被用来实现ESB报文及原始服务系统之间的转换过程， 每个系统都有相对独立的报文格式， 因此此接口的实现逻辑也应有所不同， 用户需要自己去实现转换的逻辑。提供多线程及线程池的管理功能：对请求的接入可提供线程池管理功能，以提高并发处理效率。提供配置管理接口，用来配置参数信息：各个组件的功能接口都是可配置的。 比如，可对Socket接入IP及端口， 线程池的大小， JDBC连接配置等。提供数据库信息访问接口：在数据转换过程中，需要将交易的请求数据格式和响应数据格式存放到数据库中，适配器将从数据库中读取这些信息放入到缓存（Cache Manager）中。错误处理功能：错误异常处理接口（Error Handler）将错误代码直接打包到报文里面，并传送给ESB， 由ESB进一步处理（包括超时错误处理），适配器不对错误进行任何的逻辑处理与操作。提供日志记录功能：主要用于程序开发调试和错误跟踪，以及交易内容、适配器性能、守护类线程状态等的纪录，是一个基于文件的日志组件（Log）。可以被方便的用来实现一个实际的Adapter：前端Adapter： 接收来自服务请求系统的请求，通过数据转换接口将请求报文转换为ESB格式。 然后发往ESB并同步接收响应报文， 将响应报文转换为服务请求系统格式， 并返回到服务请求系统。后端Adapter： 接收来自于ESB系统的请求报文， 通过数据转换接口将请求报文转换为服务提供系统所需要的原始格式， 向服务提供系统发起请求并同步接收响应报文， 将响应报文转换为ESB格式， 并返回至ESB系统。此框架对于上述两种Adapter的实现均能够很好的适用， 只需要在配置时指定是做哪种Adapter用即可。4 商业效益IBM提供的中小银行ESB解决方案，内置ESB系统核心功能，可以有效缩短开发周期，减少开发成本，降低了时间、成本以及集成的风险。使用它 可以实现灵活的业务模型，充分重用现有的服务和系统，并可随业务需要灵活编排业务流程模型。它的可扩展性很好，为业务创新提供了全新的平台，对于特有的功 能，用户可在ESB的实现中填加扩展流程实现。而且，这套解决方案充分利用WebSphere产品提供的集群技术、容错技术、安全技术和管理技术，具有独 一无二的健壮性和安全性，新系统可以随时以一致的接口