SOA笔记（3）

很多时候，我反感“套话”、“官话”、“口号”之类的，我把它叫做鸟语，意思就是不是人说的话。闲聊的时候，如果有人用总结性的语言或者书本上的语言和我说话，我都有以下几个反应：

1 这家伙不知道自己在说些什么，满嘴瞎说，说到哪算哪。

2 这家伙对这个一点都不懂，没有自己的观点和体会，为了掩饰这一点，只好引用“名言警句”了。

3 这家伙其实知道问题的核心在哪，不过为了某种目的，不告诉我，企图把我引向其他的方向。

我能理解这些方式。因为很多时候，我都是这么干的。

今天想阐述的是SOA实施方法论，对于上周的博文进行展开。很多都是论述，很枯燥，但不是上面的三种心态。因为没办法，套话绕不过去，总要有总结性发言才行，这样才能提升、升华。下次SOA笔记将结合证券行业的网上交易业务谈谈如何SOA化。（下面摘自我自己整理的《SOA在证券经纪业务行业的发展》一文）

2. SOA实施方法论

2.1 SOA概述

SOA：Service-Oriented Architecture，面向服务的体系结构。随着全球经济一体化的深入发展，敏捷的、不受限制的集成业务的需求已经成为关键的业务需求。企业希望能够实现集成企业内外的信息，同时又能够随时更新这样的集成。SOA通过应用组件和传输协议的松散耦合、服务的即时绑定，从而实现业务组件的虚拟化，造就一个虚拟的集成架构或者集成平台服务总线，使服务集成不受任何限制，可以同时集成.NET组件和J2EE组件，以及集成其他遗留系统的各种应用，从而使IT能够随着业务需求的变化而自由调整。

SOA的基本要素有：

l 松散耦合：服务之间、业务组件和传输协议之间相互依赖程度比较低。

l 粗粒度：SOA服务的接口与编程API相比，要更接近用户的业务操作。

l 位置和传输协议透明：客户端通过服务总线访问服务组件，降低两者之间的关联程度。

SOA的基本技术有：

l ESB，服务总线：实现传输协议和位置的解耦。

l SCA，服务组件架构：SOA编程模型，实现组件接口和传输协议解耦。

l SDO，服务数据对象：实现数据代码与业务代码的解耦。

l BPEL，业务流程语言，将服务组件集成起来创造新的业务模型。

2.2 SOA实施方法论

在SOA实施过程中，缺少方法论的支持，最终会形成杂乱的Web Services集合。引入方法论后，如同软件设计引入架构设计，对于构建完整的系统都有很大的帮助。

指导SOA实施方法论主要分为4个步骤：

l SOA计划和监控：在业务和IT层面评估SOA的价值，规划SOA实施策略。

l 服务建模和架构设计：分析业务流程，设计服务模型和SOA架构。

l 服务实现和组装：基于SOA编程模型，采用开源产品或商业产品实现SOA服务。

l 服务部署和管理。采用集成式服务平台安装部署。

SOA实施过程总览：

3. SOA计划和监控

3.1 SOA价值评估

SOA价值评估通过分析证券公司业务目标以及现状的差距，寻找SOA的价值所在。分析结果指导服务建模及架构设计，同时作为验证的重要依据。

随着中国资本市场经过2006-2007年大牛市的高速发展，新一代的投资者迫切需要证券公司提供有价值的综合理财服务，将会使2008年券商经纪业务市场的竞争将更加激烈。目前从客户贡献度来看，“二八”法则并没有出现转折性的变化，活跃客户不多，客户挖掘潜力相当大。如何将服务理念贯穿到经纪业务的各个环节，实现新的业务机会、收费机会、改善客户沟通、减少客户差错、提高销售的有效性，将是一个巨大的挑战。SOA将会帮助证券公司更好地实现这些业务目标。

 

3.2 SOA成熟度分析

对企业SOA成熟度的分析侧重于目前成熟度和目标成熟度。分析结果用于证券公司评估不同实施阶段的效果，并确立正确的实施目标。在此阶段，主要是根据IBM的SOA成熟度模型SIMM对证券公司进行分析和评价。

IBM的SOA成熟度模型将SOA成熟度划分为7个层次：

l Level 1 Silo：简单的数据整合，架构脆弱无法应对外界的变更。

l Level 2 Integrated：应用整合，接近于EAI。在整合的手段上面更加讲究，并尝试着通过数据整合来分解与重构系统。

l Level 3 Componentized：功能性整合，业务主要的部分和关键路径将被组件化和模块化，使用transformation和renovation方式对基于J2EE或者.NET遗留系统进行重构。组件或者模块的边界与范围将更将清晰。组件的整合是通过接口和它们之间的操作规范。

l Level 4 Services：流程整合，可以在一定范围内定义与提供服务给内部组织或者外部的商业伙伴使用。

l Level 5 Composite services：供应链整合，服务可以扩展到整个服务生态系统（service eco-system），根据需求，一个服务可以在供应商，经销商，消费者之间流动。

l Level 6 Virtualized services：能够建立一个虚拟的基础结构(virtual infrastructure) ，应用程序可以基于这个基础结构来运行。达到这个等级之前必须对应用程序，以及它的服务，组件和流程进行解耦（decouple）。这个基础结构可以被很好的调节，并结合过网格观点和网格服务来实现敏捷性。监控，管理和事件也会被具体化。

Level 7 Dynamically reconfigurable services：依照具体化的规定、管理和监控，服务可以在运行时进行动态组合。

证券公司已经拥有了比较完备的信息系统基础架构，业务流程比较清晰规范，对SOA的一些相关技术规范由相对的了解。因此，是一个合适的对象使用SOA来构建其业务。分析SIMM模型和结合证券公司的IT系统现状，要实现真正的SOA架构，最低限度要做到Level 4。而要更好地实现证券公司的需求，涉及到多个IT系统等部门级的SOA化，目标应该是Level 5。

4. 服务建模和架构设计

4.1 BPM经纪业务流程建模

一套完整的证券公司业务的经营流程模式，对有效的分析和整合业务的每个细节以及对客户提供有价值服务起了非常重要的作用。此模式建立在将单个任务及业务活动融为整体，从而组成交易事件的基础上。

流程建模主要分为4个层次：

l 任务：完成业务活动必须的步骤。

l 业务活动：工作整体，一般由个人完成，对客户只能产生很少价值。

l 流程：通过一系列业务活动的有序组成，对客户产生有价值的服务。

事件：顺序型的流程结合起来以最好的来服务客户。

（BPM结果略）

4.2 CBM业务组件建模

随着内部专业化日趋成熟，业务活动的整合将公司变成一个由不同业务模块组成的网络，每个模块中都包含一系列彼此关联的活动。这些模块既能为组织发挥独特作用，又能作为单独实体运行。

IBM将这些模块称为"业务组件"，业务组件是公司的基本建筑单元，它们彼此松散连接。业务组件允许企业进行扩展或发展，而不会像传统的"硬连接"业务模式那样增加组织的复杂性。

组件化商业模式通常为客户提供"面向未来"的业务框架，促使企业朝着完全成熟的内部专业化组织发展，CBM能够作为诊断工具，帮助那些采用复杂商业模式的公司识别并隔离问题，能在不增加组织复杂度的情况下实现企业内部的专业化，同时不会使客户感觉到企业内部发生着的变化。

CBM 工具在弥补业务和技术之间的差距上表现得十分杰出。它提供的主要内容-即业务组件映射-是企业情况的单页快照（One Page Snapshot），可让管理人员通过相同的角度确定出决策的框架。单页快照可以将一个企业表现在一张纸上。

（CBM结果略）

4.3 SOMA服务建模

SOMA，Service Oriented Modeling Architecture，是为面向服务的分析和设计提出的架构方法。我们有OOAD(Object Oriented Analysis Design)和CBD(Component Based Development)来进行面向对象和基于组件的建模与开发。但是没有一个好的方法来进行SOA的分析、设计和开发。SOMA就是在这个背景下诞生的，其主要目的就是填补OOAD和CBD在建模领域留下的空白，为SOA实施提供一个方法学的指导。

SOMA一个显著的特点是将IT与业务对齐。在具体的实施过程中，SOMA将业务特性，如：业务目标、关键业务指标等，延伸到IT的分析和架构决策过程，从而缩小业务与IT之间的差距。具体来看，CBM业务组件模型、BPM流程模型以及关键业务指标是SOMA的三项主要输入，SOA的实现则是SOMA的输出。从这也可以看出SOMA的定位是在业务和IT之间。

SOMA方法论图：

按照实施的阶段，SOMA分为服务发现、服务规约以及服务实现三个阶段。

4.3.1 服务发现

服务发现，采用自上而下、自下而上和中间对齐的方式，得到服务的候选者。

自上而下方式从业务着手进行分析。将业务进行领域分解、流程分成，以及进行变化分析。CBM业务组件模型是业务领域分解的输入。根据业务组件模型的详细描述，可以将业务领域按照业务职责细分为业务范围，并直接将其映射到IT范畴的子系统，实现业务与IT的无缝连接。顶级的业务流程是流程分解的输入。将业务流程分解为子流程或者业务活动，逐渐进行，直到每个业务活动都是具备业务含义的最小单元。流程分解得到的业务活动树上的每一个节点，都是服务的候选者，构成了服务候选者组合。在大部分情况下，服务候选者组合都是一个很长的列表，加上自下而上和中间对齐方式还有可能发现新的服务，因此将服务候选者按照某种方式进行分类是一件非常必要的事情。业务领域分解的结果—业务范围是一个业务概念，同时可以无缝映射到IT范畴，因此可以根据业务范围，将服务候选者组合划分为候选者目录。

自下而上（已有资产分析）方式的目的是利用已有资产来实现服务，已有资产包括：已有系统、套装或定制应用、行业规范或业务模型等。通过对已有资产的业务功能、技术平台、架构以及实现方式的分析，除了能够验证服务候选者或发现新的服务候选者，还能够通过分析已有系统、套装或定制应用的技术局限性尽早验证服务实现决策的可行性，为服务实现决策提供重要的依据。

中间对齐（业务目标建模）方式的目的是帮助发现与业务对齐的服务，并确保关键的服务在流程分解和已有资产分析的过程中没有被遗漏。业务目标建模将业务目标分解成子目标，然后分析哪些服务是用来实现这些子目标的。在这个过程中，为了可以度量这些服务的执行情况并进而评估业务目标，我们会发现关键业务指标、度量值和相关的业务事件。

结合这三种方式的分析，我们发现服务候选者组合，并按照业务范围划分为服务目录。同时为服务规约做好其他准备。

4.3.2 服务规约

服务规约，服务级协定（Service Level Agreements, SLA），定义实现服务的服务组件的细节，包括：数据、规则、服务、可配置概要、可能的变更，同时还会涉及到消息、事件的定义和管理。

经过服务发现的阶段，我们得到了候选服务目录，接下来就需要决定暴露哪些服务。理论上所有的服务候选者都可以暴露为服务，但是一旦暴露为服务，该服务候选者就必须满足附加的安全性、性能等方面的要求，企业还必须为服务的规划、设计、开发、维护、监管支付额外的开支，因此我们会根据一定的规则来决定将哪些服务候选者暴露为服务。

在本文中，在服务发现中定义了服务后，我们需要进一步对这些服务进行规范化，从而可以将这些服务从业务层面落实到IT的层面。对于业务部门而言，他们需要了解的是自己需要提供哪些服务及自己的流程需要依赖哪些部门的哪些服务。但是，对于IT部门的人来说，仅仅这些信息还是不够的，他们还需要定义每一个这样的服务都有什么样的的输入和输出，以及什么样的错误处理能力。因此，我们需要定义每一个服务的接口。要达到这样一个目的，需要对于该业务流程及涉及的其他一些业务流程的数据进行建模。

5 服务实现

经过服务规约阶段，作为业务和IT互动的服务契约已经形成。但是服务契约和IT的现状还是有很大差距，如何某个服务对应的业务罗杰分散于不同的应用中，某些服务目前主要依靠人工完成，还没有IT层面的实现。

服务实现基于服务规约和现有系统分析，确定服务实现的策略。其主要步骤如下：

l 现有系统分析：调用现有系统架构和应用，将应用覆盖的业务功能和服务规约确定的企业目录进行映射。

l 服务实现决策：确定服务的实现策略及设计架构。决定是在现有基础上进行服务包装，还是重新构建等等。

l 服务实现：通过服务包装、新服务开发和服务中介等实现方式开发SOA架构的服务。

l 服务组装：以统一的服务形式为基础，通过组装模型，实现更大范围的业务敏捷性。

5.1 架构设计

在具体实现证券经纪业务的SOA架构之前，首先介绍一下SOA参考架构。SOA参考架构是一种组织SOA的构建元素—服务的方式。我们希望通过这种参考架构为企业架构提供一种指导和参考，使得新的需求能够更快的得到响应。参考架构如下所示：

其中左侧的绿色部分的开发服务（Development Services）表示建模和组装；中间的蓝色部分表示部署，含有交互服务（Interaction Services）、流程服务（Process Services）、信息服务（Information Services）、伙伴服务（Partner Services）、访问服务（Access Services）、应用服务（Business App Services）；右边的深蓝色部分IT服务管理（IT Services Management）表示管理。中枢部分是企业服务总线（Enterprise Service Bus），在服务之间提供连通性支持。

SOA参考架构描述了企业范围内SOA方案所需要的关键能力。工具是集成架构的基本组件，SOA参考架构则提供了开发服务和业务创新优化服务。开发服务用于实现新开发的组件以及重用基础架构的能力；业务创新优化服务用于从IT和业务两个层面来监控和管理运行情况。

企业服务总线ESB是SOA参考架构的核心。它为整个架构范围内所有服务提供相互通讯的能力。其中传输服务、事件服务以及中介服务都是通过ESB来提供的。

交互服务将IT的功能和数据传递给最终用户，并满足用户特定的使用习惯。流程服务提供服务控制能力，将多个服务串起来实现一个业务流程。信息服务通过联合、复制和转换来解决基于不同实现方式的不同数据源之间的数据共享难题。

SOA解决方案中的很多服务都是有已有应用提供的，访问服务提供已有应用、打包应用程序与ESB之间的桥接能力，使得已有应用的功能能以服务的形式对外暴露出来。

在业务流程需要与外部的合作伙伴、供应商交互的情况下，伙伴服务提供一组文档、协议以及伙伴管理的能力。应用服务为新的应用组件提供运行时服务。作为所有能力的基础，基础服务用于优化通过率、性能和可靠性。IT服务管理包括对服务、应用和资源的管理和保护能力，如通过负载均衡来有效的分配系统计算资源。

SOA参考架构是一个完整的企业架构，可以覆盖整个企业范围内集成的需求。参考架构中的服务通过模块化的方式进行集成，因此SOA的实现可以从一个小的项目来启动，在新的项目实施的时候，新的功能能够轻松的加到架构中，通过渐进的方式在企业范围内扩大集成的范围。

5.2 服务实现

无论怎样进行服务建模，服务最终都将由不同的服务组件来实现。因此服务实现是衔接服务建模和组件详细设计的关键步骤。服务实现首先将服务分配到相应的服务组件，然后逐个分析服务实现方式并进行技术可行性的验证。在服务发现的过程中，我们根据业务领域的分析结果将服务按照业务范围进行分类。在服务实现的过程中，将业务范围直接映射到服务组件，从而实现业务与IT的一致性。

5.3 服务组装

在SOA环境下，服务包括功能接口、服务质量约定和业务策略等，它们用于组件化地对业务建模，通常其粒度比技术层次上的对象或者组件接口要粗。而服务组装就是通过将这些服务编排在一起形成业务流程。当业务流程发生变化时，有些变化通过改变服务的配置（如业务策略）来完成，有些变化通过重新组装已有服务来完成，有些变化要用到现有服务之外的业务功能，则需要外购或者开发少量新服务，然后重新组装。

业务流程执行语言Business Process Execution Language（BPEL），已经成为编排这些服务和管理业务流程的无缺陷执行的事实标准。BPEL是一门用于自动化业务流程的形式规约语言。 用XML文档写入BPEL中的流程能在Web 服务之间以标准化的交互方式得到精心组织。

 

6 服务部署和管理

在SOA的规划和项目实施过程中，基础设施及技术不但提供给SOA参与者使用，同时也提供对收集量指标的支持和对SOA参与者的度量能力。其中ESB服务总线、服务管理、服务注册和服务存储库（企业资产Repository），是支撑SOA运维管理体系的重要的基础设施。下图是SOA服务的典型部署场景：

服务存储库提供IT资产的管理能力，跟踪服务的依赖关系，统计服务重用的情况，提供服务工程规范有效性度量指标的数据。服务注册用于设计时和运行时的服务发现、发布和审批。同时也存储服务配置信息，接受服务管理的反馈信息。服务管理提供SOA系统的运行时管理能力，可以定义管理规则、收集服务运行信息，触发告警，分析故障原因，提供SLA能力。

在SOA策略中，用于监控和管理的仪表盘应用被视作SOA的核心组件之一，它是高效实施SOA策略所必须的约束和规范。

管理完善的公司都会为其业务建立起核心的度量指标体系。同样，IT也必须利用指标去度量IT支撑业务的性能。SOA系统度量的结果将被回馈给架构人员和业务流程分析人员，用于SOA系统的持续改进。