SOMA:面向服务的建模

随着SOA建设的深入，SOA所要求的各个相关方向也都在逐步深入，SOA的建模，SOA的测试，SOA的安全等等领域都给我们提出了新的要求。

针对SOA的建模，IBM作为SOA的主要提出者和倡导者，其提出了一套完整的理论一SOMA来对SOA的建设进行指导。

SOMA全称为Service Ori ented Modeling Architecture，面向服务的建模与体系结构。最早的SOMA版本源自两个独立的方法路线，一个是RUP for SOA，这是循着RUP的路线派生出来的方法分支，专门为SOA的应用提供方法论的指导。

另外一个分支是来自于IBM的全球服务部门(GBS)，全球服务部门在与客户一起做SOA项目的过程中，基于GS Method方法，逐渐总结出了一套SOA的分析设计方法，该方法最初叫SOMA。

在2004年开始，两个团队进行了会面，并将相关的术语进行了统一，并抽取了一个统一的框架，最终将该方法作为RUP中一个独立的交付流程，统一命名为SOMA，并在RMC7.2版本中正式，变成所有的客户可以使用的一个产品。

对于SOMA，其总体流程如图1所示，业务变换分析是一个可选步骤，我们可以将其理解成进行SOA系统建设的前期的评估，后面3个阶段将是SOMA的主题方法框架，分别为确定、规范、实现。

上述的四个阶段可以迭代的进行。例如，当业务变换分析阶段产出了一套工件后，后续可能执行多个确定和规范阶段以分割业务模型，并允许每个确定迭代处理一个子集(对于已确定服务的规范，情况同样如此)。

服务确定

第一个阶段是服务的确定，也就是识别出候选服务的过程。在识别服务时又可以通过三个主要的活动来进行：领域分解；目标服务建模和现有资产分析。

领域分解

领域分解是SOMA中的一种白顶向下的业务驱动的分解方法，通过领域分解，我们能识别出所有的候选的服务，标识出系统的功能边界，同时还能识别出企业的业务流程，分析业务功能的共性和差异性。

什么是业务领域?任何业务都由业务领域组成，业务领域是对用于提供相关业务功能并需要相似技能和专长的业务能力(功能)的逻辑分组。

领域分解活动又可以分解成三个任务：功能区域分解、流程分解、面向差异的分析。

首先来看看功能区域分解，领域可以分解成多个功能区域。功能区域为领域提供了一组内聚的业务功能。例如，“产品”领域中的一个功能区域可以是“产品开发”，其主要功能是开发和改进产品。

领域分解的输入可以是基于CBM产出的组件业务模型。功能领域分解首先描述用于定义每个领域的高级别的主要功能职责。接下来，每个领域又分解成更小更离散的功能区域。每个功能区域将按它负责的具体功能以及它与其他功能区域协作过程中所依赖的功能来进行描述。每个功能区域最后都会对应为一个业务系统。

功能区域形成了IT子系统边界定义的基础，并提供了对候选服务进行分类的方法。功能区域用作识别子系统和服务组件的起点。

功能区域是领域可分解到的最小粒度。在这个工作产品中，每个功能区域将按它负责的功能以及它依赖的其他功能区域功能进行精确描述。功能区域为领域提供了各组内聚业务功能(即：它们是整个领域功能的子集)。识别出清晰定义的功能区域对于业务建模启动计划的成功非常重要，因为对于建立各组内聚的基于业务的服务以及用来实现这些服务的子系统来说，功能区域是关键。

流程分解是用来识别服务的另一种手段，如果说功能区域分解的输入需要CBM的组件业务模型来作为输入，那么流程分解则需要我们在前期有业务建模的成果：业务参与者和业务用例。

流程分解的目的在于通过一个在高级别定义的业务用例，来表达业务或业务系统的意图和目标，并把这些意图和目标分解优化成一组通过业务流程来实现的业务用例。

在业务用例建模阶段实现的业务用例在这一阶段需要归类、优化并进一步细化可操作可执行的程度，而不仅仅停留在业务目标等宏观的大方向上。

第三个活动是面向差异的分析，所谓的面向差异的分析是将前面已经提炼的模型元素的公共部分提取出来，将公共部分和个性化部分分开，这样便于后续的实现层面来考虑。这是一个通用的方法，它其实适用于各类模型，任何时候。首先确定公共于所有应用程序的设计元素，然后确定因每个应用程序而异的元素，最后记录可变性。

目标服务建模

要理解目标服务建模，首先要理解业务目标和业务策略的区别和联系。业务策略着重于组织的外部表现，而不是组织的内部管理。业务目标定义为实现较高级别的目标需要完成的工作，而业务策略提供定义这些目标所处于其中的边界。

在以上介绍的流程分解或后续要介绍的现有资产分析过程中，目标服务建模有助于发现业务变化的服务，确保未遗漏重要的服务。通过清晰说明业务目标，目标服务建模还提供一种重要机制，可用于缩小范围，将精力集中在业务重点上。

它的过程是从业务目标开始，逐步细分成子目标，然后确定需要哪些服务以完成子目标。确定了KPI、度量和关联事件，使得可以衡量已确定服务的性能，并对照子目标对它们进行评估。整个过程分成两个步骤：先确定业务目标和KPI，然后确定服务，并将服务与目标关联起来。

业务目标建模是在SOA分析中用的比较多的一种方法，因为该活动对其他的建模具有非常有用的限定范围作用，因此无论在什么情况下，都推荐采用目标服务建模。专门的自顶向下法和专门的自底向上法对于确定业务目标都是不够的，必须同时从这两个方向调查和同步业务目标。

现有资产分析

现有资产分析包含两个步骤，一个是现有资产的分析，另外一个步骤是进行技术可行性的探索。

现有资产分析是为了实现服务而利用现有资产(例如现有系统，如打包或定制的应用程序)、行业标准和模型的过程。现有资产分析将使用由下至上的方法来识别并验证候选服务、组件和流程。出于风险管理目的，应该尽早地评估与现有系统有关的技术约束。因此，服务实现决策的技术可行性分析通常在现有资产分析过程中(或之后)尽快进行。

而技术可行性探索定义了如何根据现有的体系结构需求和风险情况为SOA解决方案开发体系结构概念验证。它主要从上一步现有资产分析中获得输入，并和下一阶段的服务规范中的对服务组合进行建模过程结合起来进行架构验证。该技术验证主要针对的是

现有系统，所以在执行此任务的同时，需要检查并考虑以下事项：异常处理；进程和数据分发；数据的可用性。授权／认证机制；批处理的延迟等。

服务规范

在规范阶段有三个大的活动，执行服务规范、执行子系统分析和执行组件规范。

执行服务规范

所谓的服务规范是指对服务的结构和行为做进一步的详细定义，应该能够详细的描述出接口、消息、服务组合以及供应商的服务分配等相关的信息。

该活动直接包含四个子活动，两个任务。四个子活动分别为：对服务依赖关系建模；对服务组合和流程建模，记录服务的非功能性需求；记录服务的状态管理决策。两个任务，一为服务的石蕊测试，一为定义服务消息。

服务石蕊测试是一个迭代的过程，在其迭代的过程中一边测试，一边执行如下活动：对服务依赖关系的建模，对服务的组合和流程建模，记录服务的非功能性需求，记录服务状态管理决策等等。

一旦选定了候选服务并在服务组合中进行了记录，则需要确定哪些应暴露为服务。理论上讲，所有的服务都可以暴露出来，可以通过将候选服务的接口导出为服务描述来暴露所有候选服务，但这样做在经济上和实践中都是不可行的。

暴露“所有类的所有方法”的天真决定将使得服务的数量达到无法承受、无法管理的程度从而带来巨大的性能和服务管理问题。因此，我们需要一些标准来帮助决定是否暴露某项服务，而最重要的是决定是否要资助创建提供服务功能的服务组件，以及该服务的维护、监视、安全．性、性能和其他服务级别协议。

服务石蕊测试是一组用来过滤候选服务的标准，通过该标准，来判断和决策是否要暴露合适的服务集合。如果业务选择显现未通过服务石蕊测试的候选服务，则意味着与SOA关联的利益将不会实现。

不满足服务石蕊测试的候选服务必须以某种方式实施，因为它们是满足业务需求所必需的。它们可以在服务组件上作为方法来实施，且无需生成WSDL或其他形式的服务定义；或者可以用作不可显现的实体。

指定服务消息

通信服务和组件之间的消息是SOA的关键部分。它们不仅包含给定服务调用的输入和输出消息，还包含信息流经过应用程序体系结构的各层时，在企业中使用的内部消息格式。在指定服务消息的任务中，我们需要确定并描述出服务的输入和输出消息格式和内容，服务与底层数据模型的关系，消息之间的映射关系等内容。

其他四个子活动分别完成了对服务模型及服务规范的精化。

执行子系统分析，这一过程是业务领域向IT领域过度的一个过程，是将前面分析出的业务系统映射到IT系统中，这也是传统的RUP的子系统分析过程在SOA中的一种扩展和创新。

其主要的任务是通过业务分析模型及其相应的子系统设计，确定功能区域之间的关系根据模型和外部接口的交互和协作，定义出子系统接口的行为，根据服务组件，确定子系统的内部结构；定义子系统接口和组件、类之间的实现关系；确定子系统间的依赖关系。

执行组件规范

组件规范是详细描述组件的核心活动，SOA中的S服务(service)是通过服务组件来实现的，它们属于满足特定业务功能的子系统。每个服务组件都有责任确保它将实现的服务的Qos。

作为企业级的资产，每个服务组件都具有与自身关联的筹资、管理和维护方面的资格。基础结构管理必须到位以确保服务组件的可用性、负载均衡、安全性、性能，版本控制以及整体运行状况，它们将负责实施一组服务的功能并确保其服务质量。

功能组件和技术组件可以在多个服务组件中使用。服务组件规范包含四个子活动：确定组件的属性；确定事件和消息，对组件流进行建模，创建组件类图。以及一个任务：执行面向差异的分析。

服务实现

SOMA的第三个阶段叫实现，其实质是关于实现的决策，是为整个的SOA架构做概念验证。其核心活动为实现决策。实现决策包含两个活动和两个任务。分别为记录服务的实现决策，将服务组件分配到层，将组件分配到层，以及执行详细的技术可行性探索。

SOMA和传统的OOAD方法是相辅相成的关系，其关注于更宏观的层次上，是OOAD的一种有效延伸。随着SOA的持续发展，SOMA方法也将逐步完善，目前最新的SOMA3.0已经完成，还没有正式，在新版中，将分析和设计延伸到了具体的实现而不是实现决策，使得SOMA更加完整。