本文内容包括:
《服务建模》是本系列文章的第二部分。本系列的第一部分概览了实施 SOA 的简要步骤，并针对示例场景分析了采纳
SOA 的步骤和价值。本文首先介绍了服务建模的方法学；对示例场景进行流程建模，为服务建模做准备；在第一部分文章对现有业务和 IT
环境分析的基础上，结合价值分析和流程建模的结果，设计了目标的业务和 IT 场景；基于业务组件模型、流程模型以及业务目标进行服务建模的前两个步骤——服务发现和服务规约。
引言
以服务为中心的业务活动管理与监控是最近出现的一种热门的IT技术，它的目的在于帮助企业管理人员实时获悉企业运营状况，了解企业的战略实施进展。
《SOA 快速指南 1 2 3》系列文章是笔者近年来在 SOA 项目实施中的经验结晶。该系列文章结合一个汽车贷款流程， 介绍了在
SOA 的环境下如何基于 IBM 的现有产品构造业务活动管理解决方案，详细阐述了每个实施步骤中使用的 IBM 的方法学、技术和产品。希望通过本文的介绍，能够帮助读者理清业务流程管理所包含的基本概念，并了解构建解决方案所需要的基本步骤。
1. 服务建模方法论介绍
| 众所周知，面向对象的应用构建在类和对象之上。
随后发展起来的建模技术将相关的对象按照业务功能进行分组，就形成了组件的概念；对于跨组件的功能调用，则采用接口的形式暴露出来。
进一步的将接口的定义与接口的具体实现进行解耦，就催生了SOA。而作为业务和IT之间的契约的服务，是SOA最重要的概念。
因此面向对象、基于组件、面向服务是三个递进的抽象层次。
现在我们有OOAD（Object Oriented Analysis Design）和CBD（Component
Based Development）来进行面向对象和基于组件的建模与开发。但是没有一个好的方法来进行SOA的分析、设计和开发。SOMA（Service
Oriented Modeling Architecture）就是在这个背景下诞生的，其主要目的就是填补OOAD和CBD在建模领域留下的空白，为SOA实施提供一个方法学的指导。
需要特别指出的是，SOMA的出现并不是要替代OOAD或者CBD，正如CBD需要借助OOAD一样，SOMA也要借助OOAD和CBD进行实现层面的建模。
与OOAD和CBD相比较而言，SOMA贯穿整个IT建设的生命周期，在项目规划、设计、实施、运行中都起到重要的作用。本文就不展开阐述了，相关信息可见参考资料。
|
| SOA
快速指南 1 2 3 本系列是 IBM
中国软件开发实验室 SOA 设计中心近年来在 SOA 项目实施中的经验结晶。
- 项目概述
- 第 1 部分：SOA 采纳步骤和价值分析
- 第 2 部分：服务建模
- 第 3 部分：服务实现及架构设计
- 第 4 部分：快速实现服务集成模型
- 第 5 部分：逐步实现服务和持续集成
- 第 6 部分：以服务为中心的业务活动管理与监控
|
|
SOMA另外一个显著的特点就是将IT与业务对齐。在具体的实施过程中，SOMA将业务特性，如：业务目标、关键业务指标等，延伸到IT的分析和架构决策过程，从而缩小业务与IT之间的差距。具体来看，业务组件模型（或者类似业务分析方法论的结果）、端到端的业务流程以及关键业务指目标是SOMA的三项主要输入，SOA的实现则是SOA的输出，从这也可以看出SOMA的定位是在业务和IT之间。
图1：SOMA方法论
按照实施的阶段，SOMA分为服务发现、服务规约以及服务实现三个阶段。
1）服务发现：采用自上而下、自下而上和中间对齐的方式，得到服务的候选者。
自上而下 （业务领域分解）方式从业务着手进行分析，我们将业务进行领域分解、流程分解，以及进行变化分析。
业务组件模型是业务领域分解的输入。根据业务组件模型的详细描述，我们可以将业务领域按照业务职责细分为业务范围，并直接其映射到IT范畴的子系统，实现业务与IT的无缝连接。
顶级的业务流程是流程分解的输入。将业务流程分解成子流程或者业务活动，逐级进行，直到每个业务活动都是具备业务含义的最小单元。流程分解得到的业务活动树上的每一个节点，都是服务的候选者，构成了服务候选者组合。在大部分情况下，服务候选者组合都是一个很长的列表，加上自下而上和中间对齐方式还有可能发现新的服务，因此将服务候选者按照某种方式进行分类是一件非常必要的事情。业务领域分解的结果——业务范围是一个业务概念，同时可以无缝映射到IT范畴，因此它是一个好的分类原则。根据业务范围，服务候选者组合可以被划分服务候选者目录。
变化分析的目的是将业务领域中易变的部分和稳定的部分区分开来，通过将易变的业务逻辑及相关的业务规则剥离出来，保证未来的变化不会破坏现有设计，从而提升架构应对变化的能力。变化分析可能会从对未来需求的分析中发现一些新的服务候选者，这些服务候选者需要加入到服务候选者目录中。
自下而上（已有资产分析）方式的目的是利用已有资产来实现服务，已有资产包括：已有系统、套装或定制应用、行业规范或业务模型等。
通过对已有资产的业务功能、技术平台、架构以及实现方式的分析，除了能够验证服务候选者或者发现新的服务候选者，还能够通过分析已有系统、套装或定制应用的技术局限性尽早验证服务实现决策的可行性，为服务实现决策提供重要的依据。
中间对齐（业务目标建模）方式的目的是帮助发现与业务对齐的服务，并确保关键的服务在流程分解和已有资产分析的过程中没有被遗漏。
业务目标建模将业务目标分解成子目标，然后分析哪些服务是用来实现这些子目标的。在这个过程中，为了可以度量这些服务的执行情况并进而评估业务目标，我们会发现关键业务指标、度量值和相关的业务事件。
结合这三种方式的分析，我们发现服务候选者组合，并按照业务范围划分为服务目录。同时为服务规约做好其他准备，如：通过对已有资产分析进行的技术可行性评估、通过业务目标建模发现的业务事件等等。
2）服务规约：定义实现服务的服务组件的细节，包括，数据、规则、服务、可配置概要、可能的变更，同时还会涉及到消息、事件的定义和管理。
经过服务发现的阶段，我们得到了候选服务目录，接下来就需要决定暴露哪些服务。理论上所有的服务候选者都可以暴露为服务，但是一旦暴露为服务，该服务候选者就必须满足附加的安全性、性能等方面的要求，企业还必须为服务的规划、设计、开发、维护、监管支付额外的开支，因此我们会根据一定的规则来决定将哪些服务候选者暴露为服务。
这些规则包含以下几个方面：
- 业务对齐：该服务候选者可以支持相关的业务流程和业务目标。
- 可组装：该服务候选者满足技术中立、自包含以及无状态等特点，同时还满足复合应用的相关非功能性需求。
- 可重用：该服务候选者可以在不同的应用、流程中重用，从而减少重复的功能实现，降低开发和维护的成本。
基于企业应用开发的经验，我们还可以有其他一些方面的考虑。
在决定暴露特定的服务候选者为服务以后，服务规约还需要定义服务的消息、非功能性需求以及服务之间的依赖关系、组合关系。
3）服务实现：
根据对业务领域的理解和现有IT系统的分析，将服务的实现分配到相应的服务组件，并决定服务的实现方式。具体的实现方式，可以由已有系统暴露相关功能为服务，或者重新开发相关功能提供服务，也可以由合作伙伴来提供服务。无论采用哪种方式，都需要对于关键点进行技术可行性的分析。
2. 流程建模
定义和建模业务流程是提升业绩的关键因素。业务流程是一种可变的交互模式，当某个组织在实现特定的业务目标时，在该组织的组件及其环境之间发生了这些交互。业务流程通常很复杂，因为在应对独特而瞬息万变的环境时，人们会不断进行大量的更改。没有正式的流程文档和流程管理系统的话，这些流程复杂性就会使组织遇到不必要的障碍和瓶颈。一个良好构建的业务流程模型可以帮助您定位和排除那些隐藏的低效、高成本以及带来延迟的业务活动。
IBM? WebSphere? Business Modeler 是一个业务过程建模工具，该工具使您能够建模、设计、分析与生成业务过程报告、集成新的和修订的工作流，以及定义您的组织、资源和业务项。
本文的主题是服务建模，因此有必要阐述流程建模与服务建模的关系。
首先，进行着两项活动的角色有明显的不同，流程建模一般由业务人员或者业务咨询专家进行，而服务建模由SOA架构师在业务专员的支持下进行。
其次，两项活动看待研究对象的角度不同。流程建模从组织结构、业务流程及相关资源的角度来看待业务，流程建模关注业务活动之间的流动；服务建模则利用服务——业务与IT的契约来分析业务，服务建模关注业务活动之间的层次化和组合关系。
除了上面两点不同以外，这两项活动还是相互依赖，迭代进行的。粗粒度的流程模型是服务建模的重要输入之一，帮助SOA架构师了解业务需求。服务建模的过程发现并规约了服务，产生的结果——服务列表以及服务的主要业务属性帮助业务人员准确的定义流程模型中的业务活动和业务项。但是服务建模中IT的成分如安全性、可靠性，
流程建模并不关注；
而流程建模中的模拟运行和优化又和服务建模没有直接的关系。
根据对当前业务流程的分析，我们可以进行业务流程建模。图2展示了目标业务流程模型。
图2：基于角色的目标业务流程模型
3. 目标业务及IT环境分析
通过对现有业务环境的分析，新的业务流程必须将信贷员从繁复的人工操作中解放出来，通过自动化的方式降低信贷员的工作强度；同时通过业务规则的约束，控制过程中的操作风险和道德风险。图3就是我们设计的目标业务环境，信贷员只是整个流程中的参与者之一，由自动化的汽车贷款审批业务流程来担当承担业务流程的枢纽。
图3：目标业务环境
IT环境的目的是解释应用或流程在执行的过程中会与哪些相关的业务系统交互（包括交互的方式），此外，还解释相关业务人员与流程的交互方式。通过对IT环境的分析，我们可以了解已有系统的功能和相关技术指标，为后面的服务实现和架构设计提供重要的信息。根据业务模型的转型，相应的IT环境如图4所示。汽车贷款审批业务流程能够通过计算机技术自动与相关系统互联互通，同时申请人、信贷员以及信贷经理作为人工任务的执行者参与到业务流程中。
图4：目标IT环境
4. 服务发现
服务建模按照服务发现、服务规约和服务实现这三个步骤进行，本文会涉及前面两个步骤。服务实现与架构设计是本系列文章的下一篇文章的主题。
自上而下方式
通过对业务流程的分解，我们可以得到服务的候选者。如图5所示，每一个业务活动的单元都是服务的候选者。
图5：业务流程分解
中间对齐方式
通过与业务分析人员或业务咨询顾问的协作，我们可以获取服务建模的输入——业务目标。在本示例中，业务指标为"降低成本"和"降低欺诈风险"，并且通过销售成本、自服务比例和坏账率这三个关键业务指标来度量业务目标的实施情况。部分服务候选者可以与关键业务指标联系起来，例如：评估信用等级以及审批等服务候选者可以降低坏账率。
自下而上方式
通过对现有IT环境的分析，我们可以掌握现有系统的基本信息。了解到核心系统可以提供获取存、贷款记录的功能。
根据与业务目标的联系、与现有系统功能的映射，可以验证我们自上而下分析方法的结果，或者发现自上而下分析方法的遗漏。结合业务领域的分析，我们可以得到服务候选者列表。
由于服务候选者比较多，可以采用领域分解的结果来将服务候选者进行分类。领域分解的工作通常由资深的业务专家来进行，在本示例中，基于示范的目的，我们认为目标业务流程所涉及的业务范围包括客户服务和风险控制，并将它们作为分类的依据，得到服务候选者目录。
5. 服务规约
有了服务候选者目录，最重要的步骤就是服务暴露的决策，根据业务对齐、可重用性、业务可组装性等准则，我们决定暴露以下服务：
在决定暴露的服务以后，就需要对这些服务进行消息的定义和非功能性需求，同时需要定义相关的业务事件、规则。
实际项目中，服务规约会比较复杂，既包括具体的服务的操作、输入消息、输出消息，也包括相关联的业务目标、业务规则、业务事件，此外，非功能性需求等方面也是需要在服务实现以前定义。上表仅仅列举几个方面做简单的示意。
除了对单个的服务本身进行规约，服务规约还包括服务之间关系的描述，例如服务之间的依赖关系和包含关系。
在本示例中，汽车贷款流程由其他服务组装而成，评估信用等级由查询存款记录、查询贷款记录和计算信用等级组装而成；执行审批以前，必须先完成评估信用等级，因此从业务的角度来看，审批服务依赖于评估信用等级。 |
