首先我将看一下你想要构建什么，也就是 SOA 和它的层。接下来我将通过讨论创建 SOA 所需主要的活动和技术来描述如何构建 SOA。
作为一个示例，我们假设你正在开发一个项目，并且目标是将一部分具有自服务帐目系统的银行业务线移植到 SOA上。
为了移植到 SOA，你需要一些超出服务建模的附加元素。它们包括：
采用和成熟模型。在 SOA 和 Web 服务的采用上你的企业处在那个成熟的相对级别上？采用的每个不同的级别都与它自己的唯一的要求。
评估。你有一些领导者吗？你已经涉足 Web 服务了吗？作为结果的架构好到什么程度？你应该继续维持同样的方向吗？这将衡量企业 SOA 吗？你已经考虑了所有应该考虑的事情了吗？
策略和规划活动。你如何规划到 SOA 的移植？你需要考虑的步骤、工具、方法、技术、标准和培训是什么？你的路线图和远景是什么？你如何达到目的？计划是什么？
管理方法。现有的 API 和能力是否应该变成服务？如果不是，哪个是符合条件的？每个服务都应该以通过某种方式为业务带来价值为目的来创建。你如何样毫无妨碍的来管理这些过程？
实行最佳实践。什么是可靠和经过测试的方式来实现安全，确保性能，遵从互操作性标准，设计来作改变？
除了本文中描述的鉴别、制定和实现之外，基于服务的建模方法还包含了支持完整 SOA 生命周期的部署、监视、管理和控制所需的技术。
上面的关于移植到 SOA 和实现以后附加活动的讨论应该得到它们自己的文章，本系列中我将在随后的列中接触到这个。目前，让我们假设你为项目定义了范围，并且决定了集中在什么地方：已经定义了一个焦点，用来将现有的系统或服务转化到一系列新的系统和服务。现在你可以开始基于服务建模来构建你的基于服务的架构。
SOA 的一个架构模板
SOA 的一个抽象观点将它描述为与业务过程结合在一起的合成服务的部分分层架构。 图 3 呈现了这种类型的架构。
服务和组建之间的关系是，企业级的组件（大粒度的企业或者业务线组件）实现该服务并且负责提供它们的功能和维持它们的服务质量。通过组合这些公开的服务到合成的应用程序，就可以支持业务过程流。综合的架构通过使用 Enterprise Service Bus（ESB）支持这些服务、组件和流程的路由、中介和转化。为了服务质量和非功能性的需求，必须监视和管理已经部署的服务。
图 3：SOA 层
文章来源于领测软件测试网 https://www.ltesting.net/
