当我们都在为“SOA到底是什么”以及“SOA如何才能落地”的问题而争论的时候，我们可能很少真正站在我们的用户的角度去思考。虽然不同厂商或个人对SOA有着不同的理解，但对SOA所能实现的目的却基本一致认同，那就是实现企业IT资产的最大化复用，让IT变得更有弹性，更快地响应业务部门的需求，实现企业真正的“面向服务”。对于用户的CIO来说，那就是实现以业务为核心，提高IT系统扩展的灵活性以及IT资产的复用，达到业务灵活组合的状态从这个角度看，SOA最重要的是能否满足用户的需求。

　　作为信息化建设最为前沿的行业用户——银行而言，众多的厂商及所谓的资深架构师们在真正面对这些银行用户的发问时，往往显得力不从心，我们拿不出有力的证据来说服用户，来告诉银行的用户“你们的SOA应该如何去建设、你们的业务应该如何去封装复用……”这从众多商家每一次的新品发布或者机构组办的每一次高峰研讨之后银行用户失落的表情上面可以得到验证，而形成这样的根本原因在于——我们对于银行的业务诉求几乎一无所知。

　　银行SOA建设的业务需求

　　纵观国际银行业格局，欧洲银行业和美洲银行业仍是世界银行业的主导力量。本世纪初以来，国际大银行的企业贷款余额呈明显下降的趋势，而非利差业务收入的占比持续上升。面对日渐萎缩的传统业务和日益激烈的市场竞争，国际银行业出现了强化核心竞争力的趋势，即通过外购、外包、合资及合伙经营等形式将一些非核心业务分离出去，并在银行内部根据核心竞争力的定位实行机构重组。

　　其实，大集中之后，国内具有代表性的一些大型国有商业银行近几年通过总行集中规划的形式，在科技应用规划、项目群规划和实施、数据仓库与管理信息系统、企业资源管理（ERP）等项目的建设，在信息技术规划方面也吸收了“面向服务”的架构理念，已初步建立起近似面向SOA的系统级基础平台，也为银行长期的产品创新、服务流程重组和组织结构的调整提供了有力保障。但是，国内银行与国际先进银行相比，信息技术与业务的融合能力尚有很大提升空间，我们的信息技术虽然较强，但并未在业务应用上得到充分运用，无法通过业务流程、管理流程体现其价值，且信息技术投入与业务战略绩效指标不挂钩，缺乏系统统计和量化评估。信息技术如何更好的为业务所充分运用将是未来很多年内我国银行信息工作的重点之一。

　　为满足银行的业务战略目标和科技发展规划的要求，支持业务持续发展，降低开发成本，提高系统应变能力，解决银行“孤岛式”应用架构的现状，银行需要在参考案例实践及新技术发展的基础上，打造分层松耦合SOA式的银行IT总体架构。目的是分离服务提供方和服务使用方，横向整合应用系统间重叠部分。这种架构的特点是注重服务的重用，即架构支持不同渠道对共享服务的重复使用。这完全不同于传统的，从前端到业务逻辑到后台处理一条龙的、垂直化的系统开发方法，而是将系统分为不同的层次，以充分共享共同逻辑、服务和信息。

　　银行业务系统在其先期规划建设时主要是以产品和项目为中心，只服务于某些业务需要，没有也不会从全行的业务架构角度考虑进行建设，造成的结果是各个系统相互独立，渠道系统和服务系统成为一一对应的隶属关系，一个渠道只能向所对应的服务系统请求服务，一个服务系统也只向其所属的渠道发布服务。

　　孤立的系统无法有效地提供跨部门、跨系统的综合性信息，无法实现实时的信息存取和对业务流程的透视。企业的业务流程会同时涉及到多个应用系统，要求这些系统能够协同，但接口、架构的不统一往往使得这些本应紧密集成的应用系统成为了一个个“信息孤岛”。

　　随着业务不断的发展，渠道和服务系统之间也呈现出多对多的趋势，一个渠道需要向多个服务系统请求服务，一个服务系统也可能向多个渠道提供服务。多系统与多渠道的复杂的连接方式给系统的规划、开发、维护带来了空前的复杂性。

　　随着当前以客户为中心的经营模式的转换，需要为客户提供综合性的产品和业务服务，需要以客户为中心建立业务流程，给客户提供一致的客户体验，同时市场剧烈竞争的环境要求银行能快速的创造新的产品，快速向客户推出新产品和新的业务服务。为此要求各业务系统能同时为多个渠道服务，以给客户提供一致的客户体验，要求单个渠道能同时访问多个业务系统的服务，以组合不同业务系统提供的服务，同时也要求各应用系统之间实现数据交换和应用访问，以及要求将各应用系统提供的功能以流程的形式进行组合。

　　银行SOA建设的误区

　　起初，在采用了企业服务总线（ESB）或者企业应用集成（EAI）技术实现各业务系统与各渠道系统和与各应用系统之间的集成后，我们的银行用户真的以为他们已经实现了一个看似是一劳永逸的服务架构，也期待着来自于业务部门的业务需求能够在这个基础之上像变魔术般的不断组合变幻。而实际情况是，我们的银行用户在花掉了大把费用之后，并没有看到他们能够在休息室内品着咖啡，神闲气定的情形出现，反而更加日复一日的加班以应对来自业务部门源源不断的业务需求。

　　在这种思想之下同，我们对ESB的立场是（并且一直认为）—— ESB作为SOA中的一种体系结构模式发挥了根本性的最主要作用，或者干脆认为——上了ESB就是实现了SOA。诚然，作为企业信息服务的一个重要组成部分，ESB能够为请求程序和提供程序之间的每个交互实时执行策略。但，ESB并不是企业实现SOA的全部，甚至是在IBM SOA Foundation 白皮书中的描述，也只是声明“ESB的存在是简化服务调用任务”而已。

　　因此，在IBM SOA Foundation的参考体系结构说明中，其建议也是仅当ESB在银行的面向SOA信息化建设路线图中有意义时才采用ESB。例如，如果一家银行的SOA之惑是“服务应该是多大粒度？服务应该如何架造？”等问题时，或者他们的SOA入口点以业务为中心，您可以推迟通过ESB实现的松散耦合，尽管您的参考体系结构中包括了ESB。

　　银行服务构造的完美境界

　　当我们在经过以上的分析后，我们基本已经明确，当我们国内的银行实施SOA策略时，往往需要解决银行服务的构造、银行服务管理、银行服务流程和银行服务治理四方面的问题。面向银行服务的架构，整个系统要借助服务的设计来完成建模，因此银行所需求服务的设计是整个系统中很重要的一环。对于中国银行用户实施SOA最为基础也是最为关键的“服务构造”这一环节，银行服务的设计构造牵涉到两个重要的概念，一个是粒度，一个是耦合。我们在一些纯IT的信息资料中，也看到了一些理论上的描述，在关于粒度方面的考虑，包括考虑服务粒度在“性能和规模、事务处理和状态、业务适应性”等方面的问题。

　　前两个纯技术方面的角度，我们不想再此过多讨论，我们更多的认为应该从“业务适应性”上来加以重视。了解你的业务，这样的话你才能够理解什么样的粒度是有意义的——虽然这看起来很符合逻辑，但是很多开发人员和工程师都不会因为要理解他们所做事情的蓝图而花费额外的精力。对于实现一个成功的银行服务设计，这是至关重要的。　也就是说，要从易用性和通用性上来考虑粒度。争取做到使用一个简单的操作来实现完整的商业任务，并且仅当绝对必要的时候才添加一个额外的操作。如果简单化使其更通用(反之亦然)， 那么你是正确的。如果你使得粒度适合，那么重用你的服务的机会就会大大增加。在这一点上，我们与我们的用户均一致认为，这需要业务部门人员的重度参与，需要他们来告诉我们他们需要的“服务”是长得什么样子的。我们在此的建议是，即使业务部门对于IT技术一无所知，我们也需要花费大量的时间与耐心与之沟通，直到我们能够明白他们的意图，或者他们向我们清晰的阐述他们所需要的服务的形状。

　　服务不是凭空想象出来的，它必须要满足客户的需求，而客户需求的体现就是系统要提供的功能，所以从这个意义上面来讲，系统功能模块的设计是服务设计的前提。

　　服务的基础是构件（或者叫做组件），一些重要的组件能够单独封装成服务。基础服务其实就是一个业务组件，它是基于商务对象的原子操作。它是封装好的组件，它只关心定义好的组件接口，和需要传递的对象，而不关心实现这个操作是如何用代码来实现。业务组件包含两个重要的含义，一个是“做什么”，另外一个是“对谁做什么”。

　　通过面向构件的SOA中间件中，从最小原子运算构件，到不同粒度业务构件均可以作为服务发布。这从有过先行经验的银行用户中也可以得到证实，在一些银行的实际建设过程当中，他们会根据各自的实际环境，就可以分割封装的服务进行一定程度的定义与发布。类如：整个银行的安全认证、整个银行的组织机构、统一信息查询等。但这些还只是限于IT系统本身的一些服务，我们需要的是能够实现包括：整个银行的业务操作类服务，如：银行的个人贷款服务、信用卡业务；整个银行的管理决策服务，如：额度管理、资产负债等。而后在这个基础之上，通过统一的服务管理与服务流程进行应用，才是银行SOA的完美境界。　

　　原文出处：http://gocom.primeton.com/modules/techresource/article1914.htm