在过程的 从下到上的部分或者 现有系统分析中，现有的系统被分析和选择作为可行的候选，来为支持业务过程的底层服务功能性实现提供低消耗的解决方案。在这个过程中，你分析和利用了来自遗留和打包应用程序的 API、事务和模块。在有些情况下，为了支持服务的功能重新模块化现有的资产需要遗留系统的组件化。
中间向外视图由 目标服务建模组成，来验证和发现自顶向下或自底向上的服务鉴别手段中没有捕捉到的其他服务。它将服务连结到目标和子目标、关键性能指示和尺度。
服务分级和分类
这个活动在服务被指定时开始。将服务分级为服务层次是非常重要的，反映了服务的复合或者不规则的本性：服务可以也应该由良好粒度的组建和服务组成，分级帮助决定合成和分层，以及基于层次的相互依赖服务的协同构建。同样，它帮助减轻服务增值综合症，这种症状中，越来越多的小粒度的服务被定义、设计和部署，却缺乏控制，导致了主要的性能、可伸缩性和管理问题。更加重要的是，服务增值未能提供服务，这些服务对业务是非常有用的。
子系统分析
这个活动获取上面域分解过程中发现的子系统，并且指定子系统之间的相互依赖和流程。它同样将域分解过程中鉴别的用例作为子系统接口上公开的服务。子系统的分析包含创建对象模型来表现内部工作方式，以及所包含的公开服务并且实现它们的子系统设计。这时，“子系统”的设计结构将实现为大粒度组件实现构造，在下面的活动中实现服务。
组件指定
在下面的主要活动中，实现服务的组件的细节将指定：
数据
规则
服务
可配置概要
变更
消息和时间指定以及管理定义出现在这一步骤中。
服务分配
服务分配包括分派服务到目前鉴别的子系统。这些子系统具有实现了他们所公布的功能的企业组件。你经常会简单化假定，子系统同企业组件有一对一的联系。 结构化组件在你使用模式来构造企业组件时会通过以下几点的联合的形式出现：
中介体
Facade
规则对象
可配置概要
工厂
服务分配同样由服务的指派和在 SOA 层中实现他们的组件组成。组件和服务向 SOA 层中的分配是一个关键的任务，需要关键架构决策的文件和决议，这些决策不仅仅同应用程序架构有关系，也同在运行时设计和用来支持 SOA 实现的技术操作架构有关的。
服务实现
这个步骤指出实现给定服务的软件必须被选择或者自定义构建。其他可用的选项包括使用 Web 服务来集成、转化、订阅和外购不同功能。在这个步骤中，你决定哪个遗留系统模块用来实现给定的服务，以及哪个服务将从基础来构建。服务的其他实现决策不同于业务功能包括：服务的安全、管理和监视。
事实上，项目趋向于利用任意数量的相应的努力来满足关闭的机会窗口。因此，我推荐并行的管理三个流。
自顶向下的域分解（过程建模和分解，基于变更的分析，方针和业务规则分析，领域特定行为建模（使用语法和图表））是同供组件化（模块化）和服务公开候选的现有遗留资产的分析并行控制。为了获得项目背后的业务意图和使服务同业务意图密切合作，目标服务建模可以来控制。
结束语
本文中，我以基于服务架构、它的层和架构决策的相关类型的基础知识来开始。接下来，我通过一种方法，描写了基于服务建模的活动，以及从服务消费者和提供者角度来看活动的重要性（服务代理将在后面的文章中涉及到）。这种方式为决定基于服务架构的三个基础方面提供了在分析和设计活动方面详细的指导：服务，流程和实现服务的组件。我还描述了一个模板，你可以用它来在 SOA 的每个层上为你的架构进行决策。
我提到了，对于服务鉴别，自顶向下、自底向上和跨部分、目标模型分析三种手段的结合非常重要。接下来我关注了一下服务指定和实现的主要活动。
这一系列的下一篇文章中，我将应用该方法到帐户管理的空领域中，并且用例子来描述每个步骤。除鉴别、指定和实现之外，我还将讨论基于服务建模手段的其余活动，包含用来支持完整的 SOA 生命周期的部署、监视、管理和控制。
文章来源于领测软件测试网 https://www.ltesting.net/
