关于SOA在银行系统中实施的一些讨论（简介，应用，开发，SOA和ESB）

最新推荐文章于 2021-04-02 18:24:54 发布

mydriverc2

最新推荐文章于 2021-04-02 18:24:54 发布

阅读量795

点赞数

分类专栏：中间件、总线

中间件、总线专栏收录该内容

18 篇文章 0 订阅

订阅专栏

http://www.itpub.net/forum.php?mod=viewthread&tid=1384486&extra=page%3D1&ordertype=1

我写了个东西，关于SOA在银行系统中实施的一些讨论。这里有很多高手，如有错误，欢迎拍砖

SOA简介

SOA （Service Oriented Architecture 面向服务架构）最早由Gartner公司提出（Gartner是国际权威IT研究与顾问咨询公司，曾提出ERP、SOA等划时代的概念）。遵循SOA规范的银行软件系统，可以理解为是多个松散子系统协同工作的结合体。“松散” (松耦合) 意味着每个子系统（在SOA架构中被称为服务：Service）独立开发，独立运行，但通常需要和别的子系统进行数据交互。比如有一个核心系统实现帐务处理的功能，另外还有ATM子系统，信用卡子系统，中间业务子系统等，需要和核心系统发生数据交互。著名业界研究公司Celent对SOA的定义是：”一个为了实现业务上和IT上的需求和开发的松耦合服务的集合”（"a set of loosely coupled modularservices to support both business and IT requirements."）

SOA是个新的架构理念，不过它是个全新的刚出生的宝宝吗？当然不是。看看软件架构的发展过程：面向过程->面向对象-〉面向组件-〉面向服务。对于一个有经验的开发者来说，知道了以前的那些架构，再了解这个SOA并不难。看看SOA说了什么：单元模块（服务）实现独立的功能（像不像函数、类、组件），模块之间的依赖关系（松耦合、紧耦合，这个在以前的架构中讨论很多了），模块协同工作的机制（函数调用、类调用、组件之间的消息通讯机制）。SOA里面的基本概念其实就是原有概念的扩展和提升。

那SOA好在哪里。个人理解它的一个重要优势就是把原有软件架构中那些主要体现在开发过程（如编码、详细设计）中的优点提升到系统的搭建、业务需求，系统的生命周期等更高层面了。这些优点在SOA上的体现可以总结为：

1
灵活性：每个服务可以在不同开发平台，用不同语言开发，不受平台和语言的限制。而且一个系统的搭建变成了一系列服务的的组合。使系统架构的设计变得很灵活。而且这种灵活性导致了一个项目可以引入多开发商分期实施，再统一项目管理。

2
复用性：每个服务可以一直重复利用，提高了开发效率。

3
一致性：一个服务实现单一的业务，实现具体业务和软件模块紧密联系。

4
对需求的快速反应：这种灵活性和复用使得业务需求的变化可以很快在软件系统中实现。

5
延长银行系统的生命周期：基本业务的服务化，以及服务的重用性，使得系统升级经常可以通过对旧服务的重组来实现。

6
协助现有业务流程和软件开发流程的改进：这点既是优点也可能是难点：

6.1
通过SOA转型，对现有业务流程是一次改进的机会，而且也改善业务的整合能力

6.2
实现业务之间配合和交流的标准化。譬如通过建立统一的服务接口，实现数据特征的统一，包括数据结构（如地址信息中要包含的属性）的统一，语义（如“客户”的定义）的改进，以及数据格式的统一，等等。

然而，从以上最后一个优点，也引出了实施SOA的一个最主要障碍，就是实施过程中和已有系统和业务流程的冲突。也就是说，SOA在行业中应用的优势主要体现在它得到全面实施之后，而它的缺点主要来自实施过程中和现有体系的冲突。通俗地说，它是个好东西，前提是它能被用上。当然这样的特点在很多新的软件开发理念实施的时候都有，比如MIS（ManagementInformation System 管理信息系统）和ERP（EnterpriseResource Planning 企业资源计划）的推广过程。SOA的实施过程可能有以下几个难点：

1．
实施过程中导致的业务流程上的变化，而带来的时间和费用上成本

2．
SOA实施过程中，原有系统的模块重组，可能导致系统的复杂化。

3．
业务流程上，甚至可能带来企业组织结构上的改变，导致人事变动等一些非技术的问题出现。

SOA另外一个潜在问题是，国内的银行业的某些强调时间和效率的业务流程，可能不适合SOA的松耦合架构。SOA虽然在架构组织上有优势，但是服务之间的频繁交付一定程度上是以牺牲效率为代价的。但是基于国内银行业庞大的个人用户基数以及操作的频繁性，大量OLTP（On-LineTransaction Process 联机事务过程）的处理，使得某些个人业务强调高效性和准确性，可能高度统一的紧耦合系统架构更适合。这也是实施SOA过程中必须考虑的。

关于SOA的优缺点，还可以参考建行的刘立先生在SOA中国路演的讲座【1】，以及IBM和Bank Techonlogy的两篇文章【2】【3】中的讨论。

说起来，SOA和软件开发中另外一个体系AOSE（Agent Oriented Software Engineering 面向代理软件工程）倒是很相似，这也是我的技术方向之一。它的核心组件代理（Agent）是传统开发理念中对象（Object）的扩展，而且更复杂，功能更强大；具有消息驱动，目标坚持，自主决策，以及环境适应等特点，形象的比喻就像一个软件机器人。Agent这些特点和SOA中服务（Service）的特征很很类似。而Agents之间的基于消息驱动的工作机制，也和SOA架构中各种服务协同工作的原理有着很大的相似性。如果利用Agent帮助SOA的开发也是软件研究一个讨论的话题。如果有AOSE的研究或开发背景，再转入到SOA领域是一件很顺手的事情。

SOA在银行业的应用

SOA规范在国际的银行业中已经得到了大力提倡和推广。独立研究机构FORRESTER RESEARCH在2010年夏季对全球80家著名金融企业的决策者调查报告【4】显示，超过80％的企业在他们的系统中采用了SOA。在所有被调查者中，虽然有80％左右的公司在业务应用中使用SOA比例小于1/3，但是超过70％的公司打算在未来两年内让这个比例超过1/3。另外这份报告还建议，银行最好独立于提供商来决定如何实施SOA，建议银行根据自己的实际情况来制定SOA的实施计划。因为每个银行都有自己独特的业务流程和系统架构，而软件提供商通常只给出一个通用解决方案。这些建议的本质就是银行要自己拿主意。

在具体的例子中，不乏成功的案例【3】。譬如美国国民城市银行（实施了ORACLE的EBA系统）是最早实施SOA架构的银行之一。该银行的技术总监McCartin介绍，该行的SOA是一个高度分散的模型（decentralized SOA model），实现了服务的高度复用性。平均每个服务可被3.1项业务功能使用，而且2007年通过服务的复用，在新的业务系统开发中节约了1600万美元。而美洲银行
（实施SAP的ERP系统），利用SOA架构来促进系统标准化以及整合能力。尤其美洲银行在并构其他银行的过程中，SOA使得被合并银行的原有系统能快速高效地被整合到美洲银行的系统中。在国内的应用中，建行利用普元公司的EOS系统，实施了SOA架构，是一个成功的例子【5】。

SOA的开发

SOA的开发并没有一个严格的大一统标准，由各个软件产商自行定义。比较流行的标准有SCA（ServiceComponent Architecture 服务构件结构）【6】
和 WCF（Windows Communication Foundation）【7】。前者由开放组织OSOA提供，并得到很多主流软件开发商的支持，包括IBM, ORACLE, SAP以及国内的普元公司。后者主要是微软提出的基于Windows平台的SOA开发标准。（这又是一个微软搞自己的标准对抗全世界的现象。

）

以SCA标准为例，它定义了一个遵循SOA规范来进行系统建模的过程。这个建模过程的核心思想是通过专门开发的软件构件（component）来实现服务，并通过软件构件的相互调用来实现业务流程。这个建模过程有两个主要部分：构件开发：每个构件实现相关的服务以及调用其他服务（类似于生产单个汽车零件）；构件组装：把相关组件组装起来实现业务流程（类似于把零件组装起来成为一辆汽车）。

为了实现一个SOA系统，SCA还需要另外两个要素，一个是数据模型。业务的核心是数据，大多数业务流程也可以理解为是对数据的处理过程。SOA作为一个抽象的架构规范，它需要一个数据模型来定义组件所访问的数据格式以及访问外部数据源的接口。OSOA组织提供了SDO（Service Data Objects 服务数据对象）规范【8】，作为SCA的姐妹标准。SDO定义了数据图（datagraph）作为基本的数据单元，每个数据试图是一个树状的或者图形结构的数据对象。SDO定义的接口可以读写各种外部数据源，如XML，数据库，文本文件等。外部数据被SDO数据读取后存为数据图的格式，供内部构件访问。

SCA所需的第二个要素是业务流程描述。一个业务流程是一系列服务的编排组合（需要一个例子）。一个的SOA系统需要相应的方式来描述各种业务流程（服务的编排组合，流程的状态管理等）。业务流程可以通过专门的流程语言来描述，例如BPEL（BusinessProcess Execution Language 业务流程执行语言）。一个用BPEL描述的业务流程可以实现成一个服务，供其它相关服务使用。

在SCA标准中，基本的软件发布单元（可被外部系统使用的）是组合构件（composites）。组合构件提供了可以直接被外部系统使用的基本业务服务，譬如帐务管理、信用卡管理、日志记录等。一个业务流程的搭建也是基于组合构件的排列组合。每个组合构件提供的服务可被别的组合构件或者外部系统直接调用，也可以调用别的系统的组合构件。譬如帐务管理构件调用日志记录等构件来进行日志记录（很类似函数调用）。一个组合构件由一个或者多个底层构件（component）组成，每个底层构件实现一个单一的服务，也可以调用或被其他底层构件调用。譬如帐务管理的组合组件内可以有结算、存款、贷款等底层构件。SOA系统－》组合构件－》底层构件的关系有点类似于传统软件开发中系统－》模块－》类之间的关系，当然结构和相互之间的关系更复杂。关于SCA标准的更详细介绍，可参考【6】。关于SCA, SDO 和BPEL之间的关系，可参考SOSA官网的介绍【9】【10】。

另外，对于SCA标准是否可以完美实现SOA，也存在一些争议。David Chappell（Oracle公司副总裁及SOA首席技术专家）就提出SCA的一个特点是一个组合构件内的基本构件必须是由同一软件厂商的技术开发的（a single-vendor construct）。譬如一个组合构件不能由.Net C#开发的基本构件和Java开发的EJB基本构件组合而成。这个特点影响了SCA系统的交互性，具体到开发流程中，也就是单一的组合构件必须在同一软件厂商的平台上开发。不过个人认为这只是理论严谨性的问题，在实践开发中似乎不是个大问题，一个组合构件由同一平台开发也是有好处的，有助于提高它的开发效率和运行效率。毕竟一个组合构件对应一个基本业务服务，就好比一个团队工作里的一个成员。成员之间的合作可以讨论耦合度和合作方式，但是每个成员自己要做的事情还是要讲求效率优先。

SOA和ESB

以上谈的都是规范和标准层面的问题，具体到开发层面，还有一个重要概念就是ESB (Enterprise Service Bus 企业服务总线)。ESB就是一根连接各种服务的纽带，也可以理解为放置各种服务，使之能够协同工作的容器【12】【13】。ESB并不是SOA的特有的，而是可以帮助实现SOA的一项技术。它的重要性在于解决一个很现实的问题：不同服务（主要是实现服务的程序模块）之间进行数据交互时，数据格式不统一的问题。特别不同服务可能是不同语言开发的，也可能是不同时期开发的新旧不同的程序模块。它们的接口很可能具有不同的数据格式。一个ESB就像一个万能翻译器，实现构件之间的交互。ESB的实现标准也没有一个统一的规范，不同厂商各有标准。一般来说ESB要具有以下几个特点：