在探讨信息系统的SOA架构概念时，一个非常重要的概念是：企业服务总线(ESB)。可以说，企业服务总线也是SOA的核心构成部分。要真正实现应用架构完善的SOA结构，简化SOA构件间的关系，就一定要建设好信息系统的企业级服务总线。

　　一、ESB企业服务总线的概念

　　二、建立银行的企业服务总线

　　三、银行服务总线的标准功能

　　四、企业服务总线的架构

　　一、ESB企业服务总线的概念

　　(一)总线的概念

　　在世界的各种类事物里，总需要相互联系和沟通。这些事物包括人与人之间，组织与组织之间，物理设备之间，应用程序与应用程序之间。

　　在没有总线的概念前，这些联系与沟通是自然发展建立起来的，一开始通常都呈现为点对点模式：

　　点对点的连接方式在连接对象比较少的时候，确实是一种简单和高效的连接方式。但其最大的问题是，当连接对象多的时候，连接路径会以指数方式剧增。连接路径数与连接对象数之间的关系是：

　　具体数字看下表：

　　可见，点对点的连接方式有以下明显的缺陷：

　　如果连接对象比较多，连接路径会非常多。连接拓扑图是一个复杂的多对多的网状结构。

　　如果连接对象各自的连接方式有差异，如：对于程序的连接，如果沟通的语言、文字、格式、方法等有差异，则每一个连接方都要同时支持和维护多种连接方式。

　　当某一个连接对象的连接方式发生变化，会引起其他所有与之连接的连接方有所变化。

　　基于以上几点，在多点互连的情况下，点对点连接方式成本高，可用性和可维护性低。显然不是一个好的连接方式。

　　随着技术的发展，另外一种连接方式开始逐步取代点对点的连接方式。这就是总线连接方式：

　　与点对点连接方式最大的区别是，总线连接方式把多对多的连接方式变成一对一的方式。所有连接方均与总线连接，然后通过总线再连接到需要连接的对方。这样，无论连接对象有多少，其连接路径数与连接方的数量永远一样。整个连接拓扑图是一个简单的星形结构。

　　不同连接对象如果连接方式有差异，可以通过总线完全屏蔽掉，做到对连接对象透明，无需各个连接对象关心。

　　总线的连接方式最早在许多硬件设计上得到广泛的使用。如处理芯片的数据总线，网络节点的交换机，大型计算机系统处理器与外围存储设备连接的集线器等。通过总线结构，把原来复杂的网状结构变成简单的星形结构，极大提高了硬件的可靠性和可用性。

　　(二)服务总线

　　随着计算机信息系统的发展，信息系统也越来越庞大、越来越复杂。总线的概念也引入到信息系统的架构建设上。跟随SOA的概念，信息系统的总线通常叫服务总线。其战略层的总线称之为企业服务总线(ESB)。

　　关于企业服务总线的概念，业界有许多定义，但一些基本定义是一致的，归纳如下：

　　企业服务总线是一个具有标准接口、实现了互连、通信、服务路由，支持实现SOA(Service Oriented Architecture，面向服务架构)的企业级信息系统基础平台。它提供消息驱动、事件驱动和文本导向的处理模式，支持基于内容的服务路由。SOA架构将各应用服务器(包括异构的服务器)上的各种服务连接到服务总线上，支持分布式的存储及分布式的处理、异步处理。为信息系统的真正松耦合提供了架构保障。简化了企业整个信息系统的复杂性，提高了信息系统架构的灵活性，降低企业内部信息共享的成本。

　　(三)企业服务总线的功能

　　通常认为，企业级服务总线需要具备如下功能：

　　1、 服务统一管理

　　为整个系统提供一个统一的、标准的、可靠的、可扩展的服务管理平台。

　　2、集成服务

　　提供基础的服务与定制的服务;支持集成服务模式;支持服务的分解，服务调度和路由，服务封装，服务组合。

　　3、公用服务

　　提供内置的各种公用服务。例如，认证服务，日志服务等。

　　一些厂家提供的企业服务总线产品，还会包括如下一些功能：

　　4、服务协议转换

　　通过把不同的通信协议转换成标准的报文，屏蔽异构系统的底层技术差异。

　　5、服务监控

　　提供服务等级管理及流量管理。提供多角度的服务实时监控、报警与交易分析报表。

　　6、安全体系

　　提供多种安全机制并支持和第三方安全系统的有效集成，提供有效的安全监控机制。

　　(四)ESB产品

　　企业服务总线是一个相对新的概念，其产品也是一些较新的产品。从目前的应用案例看，能称得上成熟、完善、通用、成功的案例不多。不同的企业服务总线产品，其功能会有所侧重，使用环境也会有所限定。据了解，目前有如下定位为企业服务总线的产品：

　　1、IBM

　　IBM的相关产品有：WESB、WMB、WDP。

　　2、Oracle

　　Oracle的相关产品有：OSB、ESB。

　　3、Microsoft

　　微软的ESB功能是通过一组产品实现。包括BizTalk、.Net等。

　　4、开源

　　还有一些开源产品，如：Jboss ESB、Mule ESB、ServiceMix/FUSE ESB、Synapse/WSO2 ESB等。

　　Jboss ESB架构图

　　二、建立银行的企业服务总线

　　企业服务总线无论在概念上还是在产品上，到目前为止，还处在成熟阶段。还没有普遍成功的案例。但金融信息系统的发展，切实需要我们实践这个概念。我们可以外购某个相对成熟的产品，通过大量的客户化形成自己的企业服务总线。另外，从发展新一代信息系统的角度，我们可以探讨如何建设自己的企业服务总线。

　　假设，我们的事务处理应用系统有两大部分：渠道系统和业务处理系统。渠道系统又有两大类：柜台终端和自助终端，各自有自己的前置服务器。业务系统分为三大系统：个人系统、卡系统、法人系统，各自也是配置在不同的服务器上。每一类渠道都可以访问任一个业务系统，三个业务系统间也会有业务关联。在没有建立总线结构时，它们之间的逻辑连接如下图：

　　从图-3可以看出，我们的应用系统被划分为两个层次：渠道层与业务处理层，分别用两个方框来表示。这两层共包含了五个子系统，分别用五个圆圈来表示。这种架构就是前面所说的点对点连接的架构。关系复杂且维护成本高。根据服务总线的概念，我们需要将其改造成为总线架构如下图：

　　从图-4可见，应用系统在渠道层与业务处理层中增加了一层、被划分为三层。这一层就是为了实现服务总线而划分出来的。

　　从服务总线的定义可知，服务总线承担的功能比较多。在服务总线里，我们可以把相关功能再进行细分。例如把企业服务总线功能中的一些辅助功能如：服务协议转换、服务认证、服务等级管理、服务流量管理等功能分拆到渠道整合去。功能进一步分拆后的服务总线如下图(图-5)：

　　从图-5可以看出，此时的服务总线包含了两部分，一部分是与各不同的渠道连接，接受各种各样的服务申请。另一部分与业务处理连接，根据接收到的服务申请，进行服务交付。

　　从图-3变换成图-5，表面上好像变化不大，但从概念上说，是有了一个质的变化。

　　从宏观上，我们把面对过程的计算机处理变成面向服务的计算机处理。图-5中的每一个圆圈，代表的是一种服务，其软件构成是一个服务构件。其中包括了：

　　柜台渠道服务

　　自助渠道服务

　　渠道整合服务

　　服务交付服务

　　个人业务服务

　　卡业务服务

　　法人业务服务

　　所有这些服务，他们之间的关系是服务申请方和服务提供方的关系。每一个服务构件，一方面接受处于服务流程上游的服务构件的服务申请，为其服务;另一方面，可以向处于服务流程下游的服务构件提出服务申请，要求其为自己服务。

　　以上几个构件构成整个应用系统的几大应用板块层次：

　　渠道层

　　渠道整合层

　　服务交付层

　　业务处理层

　　其中，作为企业服务总线的渠道整合与服务交付，一个对外、一个对内，实现服务总线的一系列功能。在应用系统架构划分时，可以将其划分为同一个层次，也可以把渠道整合与渠道划分为同一个层次。

　　在企业服务总线的具体设计上，要注意以下几点：

　　(一)渠道整合

　　从总线的概念看，渠道整合应该是服务总线的一部分。建立渠道整合服务层，有几个作用。一是如上所述，把一些属于服务总线的辅助功能从服务交付构件剥离，使服务交付构件功能更为单一。二是屏蔽各种各样渠道的物理差异，使服务交付构件仅面对一个服务对象。第三点是最重要的一点，把从各渠道传递上来的服务申请信息，转换成标准的有限的服务要求信息。

　　(二)标准服务接口

　　从服务总线的概念可知，服务总线提供的是一种统一和标准的服务管理。为了能够做到这一点，服务交付层应该使用统一和标准的协议和报文。

　　图-5中红色的连线，使用的就是标准的协议和报文。

　　三、银行服务总线的标准功能

　　银行信息系统的企业级服务总线只提供有关客户服务的管理功能，如：服务分析、服务分拆、服务转发、服务流程控制、服务路由控制、服务结果返回等，不提供客户服务本身的服务功能。也就是说，所有业务功能全部交给其他业务处理服务去实现。

　　1、服务分析

　　通常，应用系统的客户通过应用系统的各种人机交互界面，向应用系统提交服务要求。该服务要求通过系统的各种渠道送到系统的渠道整合层。渠道整合层把客户各种各样的服务要求整合为标准的服务申请报文，送到服务交付层。这些标准报文的头部通常都有相应的服务交易代码或功能代码。服务交付层通过对交易代码的分析，就能知道本服务申请的具体服务要求。

　　2、服务分拆与转发

　　服务交付层知道了客户服务要求的具体内容后，要把服务交给后面的具体服务构件去完成具体的服务。客户服务的构成有许多类型，有简单的服务，有复杂的服务。所谓简单服务，就是一个服务构件就能完成的服务。对于这种服务，服务交付层直接把服务要求转给相应的服务构件去完成。但对于大多数的服务要求，都不是简单服务，其服务需要通过若干个服务构件甚至一些系统外的信息系统共同服务才能完成。这时，服务交付层要把一个客户服务要求拆分为若干个子服务。把子服务有序地分别转发给相应的服务构件去完成。

　　3、服务流程控制

　　对于复杂服务，一方面，服务交付层要把服务分解成若干个子服务，要按一定的顺序，把这些子服务交给相应的服务构件。由于各子服务之间通常有一定的因果关系。前一个服务的输出往往是下一个服务的输入，所以，服务总线通常还要把上一流程的某些处理结果打包给下一流程。

　　另一方面，服务交付层还要控制整个服务流程的走向。因为复杂服务流程比较长，每一个服务环节都会出现一些影响后续服务流程的结果。这些结果包括一些正常的流程选择条件和非正常事件。对于流程选择条件，服务总线根据不同的条件选择不同的流程，让服务正常持续下去。而对于出现的非正常事件，服务流程将不能正常完成。这些事件有些是由于提交的服务要求没有完全符合业务规则，如密码不符或余额不足等;另外也可能是环境的原因，如网络问题等。当某一个服务环节出了意外，整个服务流程也许不能完整走下去。需要转到另外的错误处理流程。

　　4、服务路由控制

　　服务交付层要把各子服务转发给各服务构件，要知道服务构件的物理位置。根据SOA松耦合的概念，松耦合既包含了软件模块之间的松耦合，还包含了软件与硬件之间、与地理位置的松耦合。应用系统的架构不强求规定哪一项服务配置在哪种机器里，也不强求规定该机器是在本地还是在远程。服务交付层通过解析服务配置表，找到相应构件的名称和位置，把子服务转发给该服务构件。

　　5、服务结果打包与最终返回

　　除了服务转换间的信息打包外，当所有的子服务返回的结果均为正确时，服务交付层把服务最终结果整理打包返回渠道整合层。相反，只要有某个子服务出现意外，服务交付层马上中断正常的服务流程，根据不同的意外情况，向渠道整合层返回不同的错误代码。

　　四、企业服务总线的架构

　　(一)宏观架构

　　如上所述，建立了上述的服务总线后，解决了信息系统各应用大板块之间的松耦合，实现了宏观的总线架构。下一步，总线结构还可以在大板块内进一步展开。

　　随着我们信息系统的各业务处理系统不断发展，其处理不光覆盖了核心银行业务，还包括了客户管理业务、代理业务、内部管理业务等。所有这些业务可以分类组成若干个大的业务板块。其中有一些板块，不光里头包含了许多业务。且板块内部的各种业务相互间关系比较密切，与板块外部业务的关系相对松散。对于这些大的业务板块，如核心银行板块，我们可以在板块内建立总线结构：

　　在图-6里，对于核心银行应用，与图-5相比，服务交付由一层变为两层：服务交付与核心银行交付。这种变化，对于包括核心银行里原来的各个服务以及其他所有服务来说，完全是透明的。假设有一个客户服务是代发工资。在图-5的服务交付对应配置表里，配置了两个子服务，先是法人系统的工资转出服务，下一个是个人系统的工资转入服务。但在图-6里，服务交付对应配置表里只配置了一个核心银行服务，先把服务转发给核心银行交付。而在核心银行交付的对应配置表里，配置了两个子服务：法人、个人服务。从这个例子，可以看出服务总线的灵活与方便。

　　在图-6里，从概念来说，渠道整合、服务交付以及各板块的交付合在一起，构成整个企业级服务总线。但在物理配置上，各业务板块的服务交付应该靠近各业务板块，或者与各业务板块配置在同一个服务器里。因为在板块内设置服务交付的前提是我们认为该板块内的各种应用是关系密切的，它们之间会有比较多的交互。把板块的服务交付配置在板块内，可以提高效率，减少开销。当然，如果板块内部的应用关系并不密切，我们就未必需要要设置两层的交付。

　　多层的服务总线架构与多层的网络架构概念完全一样。众所周知，比较大的网络体系通常会采取三层架构：核心层、汇聚层、接入层，各层通过其节点交换机：核心交换机、汇聚交换机、接入交换机完成多层的数据传递与交换。相对于银行信息系统，如果采取两层的服务总线结构，服务交付相当于核心交换机;核心银行服务交付相当于接入交换机。通过系统的两层总线，完成服务的交付与流程的控制。

　　(二)服务交付层的内部架构

　　服务交付层的基本架构是由一组结构大致相同的程序组成。这一组程序我们可以把它称之为服务交易引擎。其中每一个程序通常对应一类客户服务，对应一类交易。并对应与该类服务相关的一组子服务、一组程序。而每一组流程相似的交易通常对应一个标准报文。

　　服务交付层还有一组与交易相对应的配置表。配置表的内容有完成该交易所需要的各子服务名、子服务物理路由、子服务后续流程条件码、条件码对应后续服务等信息。交易引擎就是通过检索配置表，解释其中内容，以确定交易的具体服务内容。并确定服务构件名、服务构件路由、服务流程、服务返回内容等。

　　通过建立完善的企业服务总线，整个信息系统形成一个以服务总线为中心、逐层往外扩展的的星型网络。分散的渠道把各种服务要求分层汇集到渠道整合，服务交付又分层地把服务分解为各子服务，再分发到各个具体的应用，然后汇集各个子服务的处理结果，原路返回服务的提交处。

　　ESB注册试用

　　LinkESB由厦门明延科技研发，公司十年专注企业服务总线， 我们致力于打造企业共享服务平台提供商，打造企业上下游的生态圈。传统的企业信息化都是围绕内部人员展开，是一个封闭的系统，而未来的企业信息化，不仅服务企业内部，还要保证上下游企业互联互通，同时客户通过手机可以及时查到到业务的进展。我们的解决方案：

　　1. 业务上以用户为中心

　　2. 技术上以服务为中心

　　3. 决策上以数据为中心

　　解决方案图

　　LinkESB自2007年经过多年的行业沉淀，研发了国内外先进的企业服务平台套件，先后应用于海南省电信、海航集团、厦门国际银行、厦门建发股份、夏商集团等大型企业的IT建设中，以及云评众联与坤龙云海等全国性的行业互联网平台的应用。综合对比国内外ESB产商，厦门明延科技的LinkESB在各种行业项目中应用最为广泛，值得依赖!

　　你是不是万事具备，就差一个程序员了？

　　错!

　　你其实差的是一整套解决方案

　　了解LinkESB企业服务总线请联系我们，我们拥有全套互联网平台建设经验：平台规划+技术服务架构+开发平台+实施方案+运营思路。

　　打开LinkESB网站，一分钟注册开发者账号开始试用吧!

http://news.chinabyte.com/480/14198980.shtml