第 4 章：SOA 方法学

这是《SOA：原理方法实践》的第 4 章。在第 3 章我们已经详细阐述了作为一种新的方法，SOA使用哪些原理和方法去构建IT系统，并使得构建的IT系统更加灵活，更加和业务对齐。那么如何在实践的层面上，在IT的生命周期中贯彻SOA的原理和思想，一步步构建出符合SOA设计原则的IT系统呢？这个问题的答案属于SOA方法学的范畴。

广义上讲，SOA方法学贯穿于IT生命周期的各个阶段和各个方面：IT系统项目的规划，系统分析和设计，系统的实施，系统的部署和维护，以及整个过程中的监控和管理等。从实践的角度说，已经出现如下SOA方法学。

（1）面向服务的分析和设计（SOAD）。以服务为中心，根据业务需求发现服务、描述服务，并设计服务的实现。

（2）面向服务的开发过程。结合现有开发过程，规划以服务为中心的开发过程中的角色、职责、活动和工件。

（3）SOA的成熟度分析和迁移路线图。以服务为中心，分析现有或目标系统的成熟度，并设计从现有成熟度迁移到目标成熟度的路线图。

（4）SOA监管。设计组织和流程，确保SOA的设计原则在IT生命周期中得以贯彻，管理服务生命周期中的各种迁移的合理性等。

本章对SOA方法学的阐述主要集中在面向服务的分析和设计。首先介绍SOA方法学和主要的几种方法学的区别和联系，其次以IBM的SOMA（Service Oriented Modeling and Architecture，面向服务的建模与架构）为例，介绍SOA分析和设计中的主要内容和方法。

回页首

4.1 SOA方法学和其他方法学的比较

与SOA的设计原则类似，SOA方法学并不是全新的方法学，它是现有方法学的继承和发展。一方面，原有的方法学并不能解决由于服务概念的引入带来的问题，如怎样发现服务，怎样定义服务；另一方面，服务是一个水平的概念，而不是一个垂直的概念，在服务分析和设计的过程中，需要处理服务和现有方法学产物的关系，如业务流程和服务，企业架构和SOA，服务和对象等。因此服务的分析和设计最主要的职责在于发现服务、定义服务和实现服务，并指导如何和其他方法学结合完成这些职责。

如图4-1所示揭示了现有几种方法学的定位。图的横坐标将项目周期分为分析、设计和开发三个阶段，纵坐标将域分为应用、架构和业务。流程建模（BPM）用于业务领域的分析和设计，如业务流程的定义、业务数据的定义等；企业架构（EA）和方案架构（SA）侧重在架构领域的分析和设计，如根据业务需求确定目前目标业务系统和IT系统，根据目标系统需求设计主要架构元素和它们之间的关系；面向对象的分析和设计（OOAD）则贯穿分析、设计和开发三个阶段，它主要分析细粒度的业务需求，如用例，分析和设计实现这些需求的类和对象，以及它们之间的关系。

如图4-2所示，面向服务的分析和设计贯穿项目周期的三个阶段和IT系统的三个域。这暗示着，在操作层面上，面向服务的分析和设计会和其他方法学紧密相联。

1．BPM和SOA

业务流程建模是一个相当零散的领域，存在各种各样的方法和技术，有效的方法可以帮助企业对业务进行合理的划分，从而求得业务层面的灵活性。有些方法则侧重于流程建模本身，例如如何确定和定义业务流程中的业务活动、业务数据、业务规则、业务指标和业务事件等，但是BPM并不会帮助我们去发现和定义服务。从SOA的方法学来看，各种BPM的结果是面向服务的分析和设计的重要输入，如业务组件、业务流程和业务目标是服务发现的重要依据，而业务指标、业务数据、业务规则等是服务暴露的分析的重要依据。

2．EA和SOA

尽管和BPM一样，EA是一个零散的领域，但是当前的EA主要侧重于定义跨越业务单元边界的系统框架，企业范围内系统的主要构成元素，这些元素间的关系，以及将这些元素有机组合在一起的参考架构。但是，各种EA技术都缺乏业务领域的蓝图指导企业架构的设计。从SOA方法学来看，一方面，面向服务的分析和设计通过和BPM结合将业务分解为各种类型的服务，可以作为企业业务的蓝图指导企业架构的设计；另一方面，企业架构设计的结果，如参考架构，又是服务实现的重要依据。

3．OOAD和SOA

面向对象的分析和设计告诉我们使用Use Case捕获需求，并设计类、对象及对象间交互来满足Use Case定义的需求。但是面向对象的分析和设计往往只是局限在单个应用内部，它不会缺乏业务蓝图和企业架构蓝图的指导。从SOA方法学看，在原理层面上，OOAD中的很多设计原则，如抽象、隔离关注等被SOA继承和发扬，并应用于服务的定义和实现中。而在操作层面上，服务模型为OOAD进行类和对象设计提供了业务蓝图和企业架构蓝图，与此同时，Use Case作为对业务流程的补充说明被用于服务的发现和定义中。

回页首

4.2 面向服务的分析和设计概述

本章以下小节将以IBM的SOMA为例，说明面向服务的分析和设计的主要任务和方法。 IBM的SOMA将面向服务的分析和设计分为服务发现、服务规约和服务实现。服务的实现包括服务、组件和服务组装的实现。

为了开始面向服务的分析和设计，如下的输入需要被用在分析和设计的过程中。

（1）业务领域（Business Domain）和业务功能域（Business Function Area）。业务领域和业务功能域的划分勾勒了目标企业的业务结构，它一方面帮助我们从全局的角度来理解目标企业的业务，另一方面也是我们进行组织服务层次结构的重要依据。

（2）业务流程（Business Process）。业务流程，尤其是第一级的业务流程，对企业经营全局至关重要。通常，通过第一级的业务流程可以追溯到企业中最为重要的业务活动，因此第一级业务流程是我们进行服务分析和设计的主要入口点。

（3）业务目标（Business Goal）。组织和业务流程都是为业务目标服务的，为了完成业务目标，组织和业务流程都有可能进行适当的调整。分析业务目标在有些时候可以帮助我们发现一些通过业务流程分析遗漏的服务；与此同时，业务目标也是服务描述中一部分重要的内容。

（4）现有系统（Existing System）。现有系统是目前业务活动和业务流程的写照，通过分析现有系统模块和功能，能够帮助发现服务。与此同时，对于现有系统的分析和理解是进行服务实现设计的重要前提。

在掌握了业务领域划分、业务流程、业务目标和现有系统后，SOMA按照三个阶段来进行服务分析和设计--发现服务、描述服务和服务实现，如图4-3所示。在SOMA三个阶段的分析和设计过程中，分析和设计人员还需要借助于传统方法中的一些素材，如业务环境和业务用例、IT环境、当前应用或组件的模型和设计等，从而完成与现有业务和IT紧密结合的服务规范和服务设计。在运用SOMA的过程中，这三个阶段并不是一次性完成的，一般需要一个迭代的过程。另外，从企业范围而言，分析和确定的服务模型也有一个演化的过程，并逐渐地精化，越来越贴近业务。

4.2.1 服务发现

服务发现是SOMA进行服务分析和设计的第一步。服务发现的主要任务，是确定在一定范围内（通常是企业范围，或若干关键业务流程范围内）可能成为服务的候选者列表。

目前有三种方式发现服务的候选者，它们分别是自上而下的领域分解、自下而上的现有系统分析和中间对齐的业务目标建模。

1．自上而下（领域分解）方式

自上而下的领域分解方式从业务着手进行分析，选择端到端的业务流程进行逐层分解至业务活动，并对其间涉及的业务活动和业务对象进行变化分析。

业务组件模型是业务领域分解的输入之一。业务组件模型是一种业务咨询和转型的工具，它根据业务职责、职责间的关系等因素，将业务细分为业务领域、业务执行层次和业务组件。由于企业内部和外部环境的不同，每个业务组件在成本、投资、竞争力等方面不尽相同，因此，每个业务组件在企业发展的过程中战略职责和演化的路径也是不同的，于是由于角度的不同，就形成了所谓的业务组件的"热点视图"。SOA是一种特别强调业务和IT互动的技术。对于面向服务的分析和设计，业务组件模型提供了进行服务划分的依据，而且这种划分的方法可以平滑地从业务视图细化到服务视图。

端到端的业务流程是业务领域分解的另一个输入。将业务流程分解成子流程或者业务活动，逐级进行，直到每个业务活动都是具备业务含义的最小单元。流程分解得到的业务活动树上的每一个节点，都是服务的候选者，构成了服务候选者组合。业务领域分解可以帮助发现主要的服务候选者，加上自下而上和中间对齐方式发现的新服务候选者，最终会构成一个服务候选者列表。在SOA的方法中，服务是业务组件间的契约，因此将服务候选者划分到业务组件，是服务分析中不可或缺的一步。服务候选者列表经过业务组件的划分，会最终形成层次化的服务目录。

变化分析的目的是将业务领域中易变的部分和稳定的部分区分开来，通过将易变的业务逻辑及相关的业务规则剥离出来，来保证未来的变化不会破坏现有设计，从而提升架构应对变化的能力。变化分析可能会从在未来需求的分析中发现一些新的服务候选者，这些服务候选者需要加入到服务候选者目录中。

2．自下而上（已有资产分析）方式

自下而上的已有资产分析方式的目的是利用已有资产来实现服务，已有资产包括：已有系统、套装或定制应用、行业规范或业务模型等。

通过对已有资产的业务功能、技术平台、架构及实现方式的分析，除了能够验证服务候选者或者发现新的服务候选者，还能够通过分析已有系统、套装或定制应用的技术局限性，尽早验证服务实现决策的可行性，为服务实现决策提供重要的依据。

3．中间对齐（业务目标建模）方式

中间对齐的业务目标建模方式的目的是帮助发现与业务对齐的服务，并确保关键的服务在流程分解和已有资产分析的过程中没有被遗漏。

业务目标建模将业务目标分解成子目标，然后分析哪些服务是用来实现这些子目标的。在这个过程中，为了可以度量这些服务的执行情况并进而评估业务目标，我们会发现关键业务指标、度量值和相关的业务事件。

结合这三种方式的分析，我们发现服务候选者组合，并按照业务范围划分为服务目录。同时为服务规约做好其他准备，如通过对已有资产分析进行的技术可行性评估，通过业务目标建模发现的业务事件等。

关于服务发现示例，请参见本书第13章"SOA体系结构的实例讲解"。

4.2.2 服务规约

经过服务发现阶段，服务目录基本形成，但是对于每个服务本身的属性信息依然零散。为了能够将服务作为业务和IT层面互动的契约，服务规约阶段是必不可少的。服务规约阶段的主要任务是规范性地描述服务各个方面的属性，其中既包括输入/输出消息等功能性属性，服务安全约束和响应时间等服务质量约束，以及服务在业务层面的诸多属性，如涉及的业务规则、业务事件、时间/人员消耗等。与此同时，规范描述服务相关方面的关系也很重要，如服务间依赖关系，服务和业务组件间关系，服务和IT组件间关系和服务消息间关系等。

进行服务暴露决策是服务规约的第一步。理论上所有的服务候选者都可以暴露为服务，但是一旦暴露为服务，该服务候选者就必须满足附加的安全性、性能等方面的要求。企业还必须为服务的规划、设计、开发、维护、监管支付额外的开支，因此，我们会根据一定的规则来决定将哪些服务候选者暴露为服务。

这些规则包含以下几个方面：

• 业务对齐。该服务候选者可以支持相关的业务流程和业务目标。
• 可组装。该服务候选者满足技术中立、自包含及无状态等特点，同时还满足复合应用的相关非功能性需求。
• 可重用。该服务候选者可以在不同的应用、流程中重用，从而减少重复的功能实现，降低开发和维护的成本。

基于企业应用开发的经验，我们还可以有其他一些方面的考虑。

经过服务暴露决策后，层次化的服务目录基本形成。下一步是结合传统的方法学对服务各方面属性进行描述。这里说的传统的方法学是指企业架构，面向对象的分析和设计等。在企业架构方法学的产物中，企业数据模型有助于服务消息的定义，IT组件模型有助于服务和IT组件间关系的描述，企业安全架构有助于服务安全约束规约，企业基础设施架构有助于服务质量的描述。在面向对象分析和设计的产物中，业务用例和系统用例有助于服务消息、服务相关业务规则和业务事件等描述，组件静态模型和动态模型有助于描述服务间关系。

经过服务规约，服务组件（企业组件）和服务的各个方面的属性被规范下来，它会成为业务和IT层面互动的基础。以后，业务对IT的新需求会体现为服务层面的变更，IT层面的变化会尽量遵循服务规约。在SOA监管的配合下，任何对服务规约的变更都是可管理和可控制的。

关于服务规约示例，请参见本书第13章"SOA体系结构的实例讲解"。

4.2.3 服务实现

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

为了将服务契约落在实地，服务实现阶段通过差距分析，并结合传统方法学完成每个服务实现决策。这其中包括的内容甚多，其主要内容如下。

（1）现有系统分析：调研现有系统架构，了解架构风格、主要架构元素和能力和架构元素的基本特征；调研现有应用，了解应用主要功能和对外接口，技术实现特征等；如果应用构建已经遵循基于组件开发规范，编制应用已有组件目录；如果应用并没有组件化，将应用覆盖的业务功能和服务规约确定的企业组件进行映射，确定应用现有"组件"目录。

（2）确定服务分配：通过服务组件和现有系统分析确定的IT组件间差距分析，确定服务组件和IT组件间映射关系。例如，一个服务组件对应一个或多个IT组件，没有IT组件和服务组件对应，没有服务组件和IT组件对应，服务组件和IT组件对应时有能力缺失或不匹配等。经过差距分析，一些服务中介被确定下来去实现服务路由，或消息格式等不匹配现象，一些新的IT组件被确定下来，如实现某业务流程的组件或实现人工服务的组件等。最终，服务组件都被映射到IT组件上，从而完成服务分配。

（3）服务实现决策：服务分配仅仅确定了需要哪些组件来实现服务，但是并没有实现的策略和技术层面的决策。服务实现决策首先帮助确定服务实现策略，是在现有基础上进行服务包装，还是重新构建，如果重新构建，是采用已经包装好的应用，还是外包，或者自己构建；如果是服务包装的话，有哪些候选方案等。通常服务实现决策和传统的架构决策是关联在一起的。

（4）服务基础设施设计：服务的功能实现，非功能需求的满足都需要服务基础设施的支持。在进行服务实现决策后，需要根据具体的需求确定服务基础设施的能力，如用于支撑人工服务的人工服务容器，用于支撑服务编排的流程引擎等。

将服务实现阶段的各种产物和传统设计方法结合起来，就可以开始指导实际服务实现的实施。